alpha123

Not only that, but sending even just the locations of 1200 units would take SO MUCH bandwidth. See this excellent article about how Age of Empires used p2p with command passing to handle 1500 units on a 28.8 modem. Those guys know what they're talking about.

Fortresses do fire arrows. As far as units/siege goes, for most civs champions and siege units are trained from fortresses, for others champions are trained in a special building.

Er... did you just say you're great and thus people hate you? Not to mention insulting Amish at the same time. At least your derogatory isn't undercurrent, it's right out there in the open.... Anyway, I'd say the most influential civilization was Israel. They affected the histories of the Egyptians, Persians, and Seleucids, as well as being a great nation of their own for a while. But probably the most important part was that Judaism is the basis of Christianity (Jesus was Jewish, after all). Christian monks preserved knowledge during the (not quite so) "Dark Ages", Christian scientists like Newton and Pascal discovered all sorts of interesting things (motivated by trying to understand the world from a theistic worldview), and currently it's the most popular religion in the world (although that doesn't really mean much). Just my 2¢. I'm not a historian by any means.

Trees I completely agree with you on; they definitely should not be regenerating. There are plenty of trees on the maps currently, they take a decent amount of time to chop down each one, and they're in large clumps so you don't have to build a ton of dropsites. None of those things are true of fruit, and they probably shouldn't be. (They should gather fast and the map probably shouldn't be littered with them, although I'd certainly be happy if they were in bigger clumps.) Fruit should be a viable food source, which it simply isn't right now. It should require more micro than other sources, but should also be more efficient. It's completely optional micromanagement: if the player doesn't want to do it, they can simply go for corrals and/or farms, both of which should require basically no micro but also be less efficient than fruit. The same is true of fish. I'd like regenerating fish. I think I'll make a patch for regenerating food sources, then we can playtest this a bit.

We basically already have that mechanic, in that it's already possible -- and frequently done -- to spot enemy units moving to build a new civ center and taking them out. Reading your opponent is an important part of any strategy game. Currently it's not particularly difficult to tell when your opponent is moving to build a new CC, especially since foundations aren't hidden before building is started. Especially when you're playing against the AI which doesn't try to stop you.

Don't think I don't know this game. Wall towers don't benefit from the Crenellations tech, which gives 40% more arrows for each garrisoned soldier and is basically necessary for effective tower usage. Also, regular towers have significantly better range. HP doesn't mean a whole lot. If you can't take out enemy siege equipment it doesn't really matter whether your towers have 1000 HP or 5000 HP. Current wisdom is to use fully garrisoned regular towers and fortresses in conjunction with archer balls to take out enemy spearmen so that your melee cavalry have easy access to enemy siege equipment. Catapults have greater range than wall towers, but not regular towers, so wall towers are not particularly useful for defense. There's a reason competitive players rarely use walls. The only way the AI can get walls to begin with is if it's playing as the Iberian civ, in which case it might delete it's towers to avoid the problem of pathfinding around gates (units tend to get stuck). Basically, the AI doesn't support walls at all right now. It can't build them and if it starts with them they only hinder it.

Er... given that the AI can't build walls, I think those are regular towers that you're seeing. Wall towers are actually weaker than regular ones, with the exception that non-siege units can't attack them. The plan is eventually to have wall towers not shoot unless garrisoned, which would make this a non-issue.

Oh yes, I forgot the AIs do their own pathfinding. In that case there would be a substantial speedup in single player. IIRC SpiderMonkey 17 doesn't have a significantly different GC than 1.8.5 (I think it's just a regular mark-and-sweep collector). Eventually it will have a generational/compacting GC, which will definitely help with the AI out-of-memory erros.

It's only the long range pathfinder that Philip was working on (and will finish - IIRC he'll work on it again after the Git migration), and the short range one is at least as much of a bottleneck (most of Combat Demo Huge is spent in the short range pathfinder). The long range one has some really really horrible cases (it ends up searching the entire map often with large formations ) which is why it was being worked on first. If you are reasonably familiar with the code, I highly suggest working on the short range pathfinder - you seem qualified for the job, and it's a huge performance bottleneck right now (20% with floats will look like nothing). If he did say that, I'd say he's wrong. As you mentioned in the OP, UnitAI is entirely in JS. It's not that JavaScript is much of a bottleneck right now (we don't really do anything particularly performance intensive in it), but I'm almost certain there will be a visible speedup from a newer SpiderMonkey (the latest versions are really quite fast, like V8 fast). FreeType 2 would be excellent - not only would it boost performance a bit, the fonts in-game look a little ugly currently.

Thanks. There's this great page on the wiki: http://trac.wildfiregames.com/wiki/GamePerformance

Basically, each unit has an armor level (actually 3, for pierce, hack, and crush) and a percentage is calculated from that level. Then, any attacks that hit take that percentage less damage. Here's an example: a unit has level 3 pierce armor and gets shot by a 20 pierce arrow. Level 3 is 27% damage reduction, so the unit only takes 15 damage, instead of 20. The reason it's in level instead of percentages directly is so that techs can simply increment the level instead of messing around with percentages. Really all the user needs to know is the higher the level the less damage their units take.

Yup, each civ has a fortress in City Phase. That sounds like a good idea. Maybe a "0 A.D. for Age of Empires fans" page or something. Possibly on the website rather than in the game, although I could definitely see it as part of the in-game manual.

Smart people who think of efficient algorithms. Most of the bottleneck right now is pathfinding. The current pathfinder is a fairly naive A* pathfinder, and is pretty slow. A lot of games either use A* with a quadtree (SC:BW I think, and AoM and some others) or HPA*. The new pathfinder will use JPS, a newer approach that is at least as fast and has some other nice properties. Commercial games also do some clever tricks to make the pathfinder faster. Some of those might already be implemented in 0 A.D. actually, it's just that the short-range pathfinder is too slow for them to be particularly noticeable. I'm not sure how things like the range manager are handled in commercial games - given that they are proprietary as opposed to open source that would be very difficult to figure out. Most big games also use highly optimized renderers, although ours is reasonably fast right now it would be nice to move to a tried-and-true renderer like Ogre3D, but that would be extremely difficult.

Er... we don't do ages. There are already 3 phases in the game: Village Phase (what you start in), Town Phase, and City Phase. I don't think anyone will add any more than that.

Yup. Quantumstate should probably review it though.

Er... did you play the game? We have 3 types of Greeks: Athenians, Macedonians, and Spartans, while a generic Hellenes faction that mixes all of them is in some scenarios. Also, Ptolemaic Egypt is on the way (that's sort of Greek), and Thebans may make it in as well.

Already done. They're only available in scenarios; you cannot build them. We already have that. The Mauryans have an Elephant Stables structure. Persians do not, as they didn't use elephants very frequently. Every civ as some unique units.

Well, Ogre3D supports OpenGL ES 1.1 or higher. So this would probably make porting easier. Hm, the more I think about it, the better it would be to use an established rendering engine like Ogre.

It happens to me regardless of mode (single player, multiplayer, windowed, fullscreen).

I can reproduce this on Windows. quantumstate was unable to on Linux, so I assume it's a platform thing. I'm not using the autobuild though, so it could be an issue with my build, I guess.

Hm. If it's about as much effort to make the pyrogenesis renderer work well and fast as it is to migrate to Ogre, then of course we should definitely go the Ogre way. Cool. Thanks for the shader explanation (I'm not a graphics programmer, although I dabble with it occasionally). According to their features page, Ogre supports GLSL and ARB shaders, so we wouldn't even have to ditch the older assembly ones. GLSL would probably lock us into the OpenGL backend though, which means we might lose some nice performance enhancements from Direct3D on Windows. I agree. I haven't really found that rendering is a big bottleneck currently, and I'm on fairly old (2009) hardware. I'm starting to think that in the long term, we will almost certainly want Ogre regardless of the cost of migrating, if only so that we don't have to keep updating the graphics code -- it'll magically get faster as new techniques are implemented in Ogre.

Basically the only downside to Ogre is the time it takes to integrate it. 0 A.D. is on GitHub (although that's just a mirror of the SVN repo), so someone could fork it and try. However, I think there are far more pressing matters, both performance and gameplay wise, to work on. IMO, definitely wait for Part 2 (Part 1 is already taking a while, and the current renderer really isn't that bad). How difficult would it be to port myconid's awesome graphics stuff to Ogre, anyway? He did a lot of great work, and I'd hate to throw that away when migrating.

I think this would be a very good idea. XML is easy to read, create, and modify, but loading times are much too slow currently. Regarding UnitAI: I don't think it's much of a bottleneck currently, and will only get faster with newer SpiderMonkey releases (rough guess: 10% faster with the SpiderMonkey 17 upgrade, another 15% with the next one (22? - whatever will have IonMonkey)). Also... it's a bit of a disaster currently, so I'm very hesitant to rewrite it in C++, which is a much less maintainable language than JavaScript.

At this point it would be harder to migrate to Ogre3D than to finish Pyrogenesis's renderer, I think. zoot: I think Ogre is flexible enough so that wouldn't be much of a problem. I'm of the opinion it does suffer slightly from feature bloat though.

Big +1 to both of these.