zoot
-
Posts
1.557 -
Joined
-
Last visited
-
Days Won
9
Posts posted by zoot
-
-
- sorry about network OT discussion, really just laying down clearly the condition to change from fp if float, and pointing derminism is a real complexity problem for sofwtare dev.
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.
-
AI won't defend its ally anyway currently. It's not clever enough to do that.
Shouldn't it attack aggressive Gaia entities, though? That seems to be the bug that is reported.
-
Now, on the other hand, it seems to me this whole debate is quickly getting into the "unconstructive" area. There's a little too much being thrown in the air with numbers flying all over the place. I would suggest a little recap of the points debated here, because based on what is being discussed, it sounds a little too much like the whole game code needs to be rewrote absolutely-or-it's-never-gonna-work, and that's not going to be very constructive.
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.
-
@zoot: Well let's say 20 packet per seconds:
P2p: each player sends and receives, 8 player => 8*20*8 => 1280
ClientServ: 8*20+8*20: 320.
Meaning, in terms of latency a non-neglibile gains in all case.
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.
-
@zoot: not sure P2P is really less bandwith, each client must send its user actions to each other clients anyways, so it grows exponentially with the numbers of players, whereas client server, it's as single send per client, and server issue agregated info once per client (with clever update/quantization/compression tricks to minimize bandwidth). So even latency might be better with client-server, minimizing the buffer bloat of p2p (huge number of packet, each having to pass the buffering of each network equipement.)
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.
-
1
-
-
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.
-
2
-
-
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.
-
1
-
-
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.
-
If a 'loose' file is found, it always has higher priority, so 'data/test.txt' would be used instead of 'packs/test.pack::/test.txt'.
Indeed, I believe this is how the engine currently handles textures etc.
-
In the distribution version, I believe everything is packed in one zip blob. If this still isn't efficient enough, maybe take a look at the pbf format: http://code.google.com/p/protobuf/ The reading speed of PBF is about 6 times that of XML, and the files are a lot smaller.
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.
So flowfields (backwards pathfinding+storing) could help with that. Flowfields are mentionned on the forums here.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.
Suggestions for 0 A.D.
in Gameplay Discussion
Posted
You'd need to translate "Wololo" to the language of each of the 9 civilizations first