zoot

You'd need to translate "Wololo" to the language of each of the 9 civilizations first

I don't think it was OT, it's valid to ask how things work. We just need to agree that we can't optimize the game for every thinkable situation at the same time.

Shouldn't it attack aggressive Gaia entities, though? That seems to be the bug that is reported.

Or, perhaps, to state it in another way: if the P2P model worked for so many other RTSs, it probably will for us too.

Apart from whatever bandwidth the client-server model may or may not consume, it would require radical changes to the simulation for it to understand state changes instead of player commands.

No, in the P2P case we send player commands. In the client-server case we'd send state changes. Each player command can translate into numerous state changes, and therein lies the difference in bandwidth.

That is wrong. In the P2P case we send 5 packets per second (one every 200 ms) per peer per peer. In the float-proof client-server case we'd send hundreds upon hundreds packets to account for position, health, animation state etc. of every given unit, building, projectile etc. per peer. And there is no "we may want to grow to 16 players". The player cap is fixed.

As far as I can tell, the color of the tower is white, which is reserved for Gaia IIRC.

The number of user commands (move unit, train unit etc.) per turn are much lower than the number of state changes (position, health, UnitAI changes of hundreds of units and projectiles etc.) per turn and we're capped at 8 players, so the amount of "exponentiation" is limited. (The game host may even act as a 'thin' server, distributing player commands so there is no "exponentiation" at all. I don't know the networking model well enough to know whether it actually does that.)

I believe the point quantumstate made is that peer-to-peer is standard for RTS because it conserves bandwidth and is less lag prone than client-server, which is essential when you have hundreds units moving around as opposed to just a few in e.g. an FPS.

It is mainly a network issue, yes. Each network client calculates the game state by itself. So if I shoot an arrow at a unit, and one client calculates the damage as 20 and another client calculates the damage as 21, the clients quickly come irrecuperably out of sync if this happens all the time for all units.

We have zero tolerance for precision issues. The problem is that small imprecisions quickly accumulate over turns, leading to desync.

Are you aware of the legal issues related to using Tolkien-related content? There was another mod that was discontinued in part because of this: http://wildfiregames.com/tla/about.html

IIRC, wall towers do not receive the "Crenellations" bonus, which means they are weaker in terms of firepower. I could be wrong, though.

If you are redesigning scripting access, I recommend taking this issue into consideration: http://trac.wildfire...com/ticket/1589 In short, we need a 'manager' or something similar which can be accessed from all ScriptInterface instances.

As far as benchmarking goes, this could be a vaguely related ticket: http://trac.wildfiregames.com/ticket/417

The "church had no tolerance of science" thing is an old stereotypical view of the Middle Ages that no one really subscribes to today. http://bede.org.uk/university.htm

Would be cute if we could hack the territory manager to show them around the edge of the territory automatically. Just for cosmetics/ambience of course.

How difficult is it actually to replace fixed points with floats? If it's a relatively simple change, it's probably better to leave it for a volunteer contributor.

Thanks for testing. Must be the expected behavior then.

The time frame is 500 BC to 1 BC.

Indeed, I believe this is how the engine currently handles textures etc.

I agree. If the goal is performance, you might as well take the full step and use a binary format. I would suggest retaining XML as the 'source'/'authoring' format, and then having some mechanism in the engine to convert it to binary "on the fly", and then store the binary result in the game's cache. That makes for a nice balance between optimization and mod-friendliness that is also used for textures etc. I'm a bit dubious that flowfields can really be used like that. What if you have a loop in the flow? A proper cache in combination with the new pathfinder algorithm seems like a better course to me.

It seems to have some nice features, like spatial culling (so things don't pop into view) and animation interpolation. http://www.ogre3d.org/about/features Could be an interesting project for someone if 0 A.D. moves to Git

I guess the disadvantage of using an off-the-shelf engine is that there is an element of bloat/unneeded features and you become locked into an architecture that is designed for the generic case rather than your specific case.