Jump to content

quantumstate

WFG Retired
  • Posts

    1.146
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by quantumstate

  1. It was all, resource only and military only. Team only doesn't make much sense to me.
  2. It is quite hard to judge whether us both being mauryan made a significant difference. They were generally playing better than us, we lost three games in a row though the last one was quite a lot closer. The uploaded game was the second.
  3. Me and alpha taking a beating against Oimat and Alkazar.
  4. With AoE2 you could have multiple players controlling the same units. This allows what you suggest but with no forced separation of roles. It seems fairly likely that we will include this in 0 A.D. because it is quite a neat feature and is very easy to implement. Separating the military from the economic sounds like quite a lot more work and seems like quite a niche feature so is much less likely. It sounds interesting though.
  5. People often have names which are tricky to say and the name isn't immediately visible either. It is much easier to see that you are attacking the blue player. In my experience of playing AoE2 online player color was used almost exclusively. Maybe we can make the colorblind palette as similar to the normal palette as possible.
  6. AI's cannot currently spawn units.
  7. That doesn't sounds very safe. You have just given full access to those devices to anything on your machine. It might be worth looking for help somewhere else like a gentoo help forum.
  8. Modding will probably be done in the same way we develop the game now. It seems very unlikely that we would tie ourselves to steam in any way. Steam would just be a another distribution channel.
  9. Yes, the mobility doesn't help very much. You cannot build an army from one training facility so you need a solid base somewhere, and the economy advantage mainly applies in mid game where you can gather without placing a lot of CC's. By late game you need structures to protect your eco from the enemy.
  10. Our terrain is 3d so unit positions do vary in z. The camera angle is changeable so that is properly 3D as well. Also using an octtree makes things more flexible if someone adds flying units. It would be possible to use a quadtree but I think it is simpler and more robust to use an octtree and performance should be good enough. The game has the simulation which is network synchronised, this does all of the game play. The simulation is currently run 2/5 times per second (multi/single player). So this handles moving units from a gameplay perspective. Obviously 2 turns a second would look terrible so there is an interpolation layer so that the graphics system gets nice smooth movement. So since it is purely graphical it only needs to be done for stuff on the screen.
  11. At the moment I am finding it difficult to spend much time on programming stuff after working as a programmer all day so am unwilling to commit to any significant task.
  12. Not so shortly but never mind. A decision will now be made. I am in favour of the 100% health method. My key reasons are: Simplicity, there is only 1 attribute which is health. Buildings are strong, I don't want them to be easier to build when the enemy is attacking. Construction should be discouraged in a combat situation.
  13. Eventually getting round to replying, after far too long. This is an issue, I think we should drop this feature. This is something that I implemented so I have given it significant thought. It used to work like you said, with a simple 50% hit chance. I'm pretty uncertain about this. Some people like being able to dodge missiles but this does introduce a big element of micro. Simply having attack/armour types just doesn't seem to be flexible enough for what we want. Just having bonuses leads to having to create a huge amount of bonuses which also means the player needs to learn a lot of things. I think it is reasonable to have both, the armour gives the broad picture with bonuses giving extra detail to create more interesting interactions. I'm not sure why you put "Bugs" in quotes. This is a genuine bug that is unintended behaviour, it is a release blocker for the v1.0 release. I'm not convinced about it being better to pick one or the other. I can see your argument about it being cleaner, though I think the armour/attack type is actually more in the physical simulation camp. I would say that we should treat the more "physical" stuff as the core and give little boosts with the "artificial" stuff to introduce variety. Attack move will definitely be there, perhaps some of the others as well.
  14. Another relatively easy but significant item is to make the sim interpolation only do work when an entity changes position. This saves doing calculations every frame for a load of trees and buildings. This will have a more significant impact now until the oct tree filtering for the sim interpolation gets implemented (since then the calculation can be avoided for everything which is not in sight), I still think it is worth having anyway though.
  15. There has been no reported progress on the above things. I think you could fairly safely work on anything.
  16. To save a mess of two people both making changes to the map and then uploading I think it would be better to have the next person willing to work on the map claiming it in this thread.
  17. Our game is designed to be fully moddable, all the units in game and quite a lot of the gameplay logic are implemented as a "mod" currently. I think the plan is to have maps which are actually mods so custom units and buildings will come as part of that.
  18. This is unlikely to happen for the main game. Our focus is more on tactical army control instead of special units. Thanks for posting it though.
  19. Also in the console you can use Engine.SetSimRate(0.5) to run at 50% speed (any number you want can be chosen).
  20. Hi. It is expected that this game will make your hardware work pretty hard. Even when we have improved performance this is still likely to happen since games are intensive applications.
  21. The infinite scroll issue sounds bad. It helps a lot with these things if you can find a set of steps to reproduce the issue. That way a developer can follow your steps and see the infinite scrolling happen which makes it a lot easier to find the problem in the code and fix it.
  22. It pops up the messages in real time which is why it is so fast. Once you have read it through I would recommend making sure you can keep up when playing. With some recent changes to the game it is a bit out of date, it will now be possible to do things faster than it suggests.
  23. I'm quite occupied currently, could I also postphone it for now.
  24. Another idea for something to work on is reversible technologies. Currently we have auto researching techs, these research instantly when the conditions are fulfilled. A reversible etch will auto research and will also automatically unresearch itself when the requirements are no longer satisfied. This can then be used for special buildings which have some bonus like +15% farming rate. So the tech will require the special building, and if that building happens to get destroyed the tech will be unresearched and the bonus will be gone. This shouldn't be too hard to add. The main issue is that currently when a tech is researched the effects get pushed into a list, when the tech is unresearched its effects need to be removed from the list, so the tech needs to be associated with the effects in some way. It should be pretty self contained in the TechnologyManager.js file (binaries/data/mods/public/simulation/components).
  25. They might have the same GUI, the code behind would be different though.
×
×
  • Create New...