Well, I've decided to create a small RTS game, but haven't really thought about multiplayer until a week ago. I'm currently working on the sound-part of the framework I want to get running before starting the real game, but I couldn't stop thinking about how to add the ability to play against/with other people over the net. It would be great if you could comment on my theory, point out flaws or just give me a hug :). I need a system that is able to synchronize states of dynamic objects within the game. Total unit count is to be considered to be less than 1000. This includes all controlable units (wich is propably under 50 per player) and other noncontrollable entities like rockets (basically everything that could change it's position in a nonlinear manner). I read the article from the forums faq that explained how the networking system worked for AoE and the ones, but I decided to try out something else. Instead of sending player commands to the server and then trying to keep every client in sync, I want the server to distribute the position of all entities to all clients. Server: -receive player input -calculate new position for all entities (using a 3rd party physics system, where needed) -distribute those positions (and other states as well) to each client Client: -send player input to server -place entities according to their state (when received from server) I know I can't update every position every tick, so I would apply some sort of filter to what is being sendet and what not. The clients would then interpolate the entities positions based on velocity until they get a new state. I'll write some test applications in a week or so to stress out the connection and try to implement my ideas. I wonder if anyone has some experience with that kind of centralized system and would share his experience with me :)

Well, I should have done the math, your point is quite right.
However I wonder if I need 30 updates per second. I think I'll have to use some sort of algorithm, that filters out important and unimportant notifications, to minimize the bandwidth:

-Slow moving entities can be updated every nth frame
-Only fast moving entities have to be updated every frame
-Entities with a fixed velocity (simple bullets for example) don't need to update their position at all, just their state (hit something, etc...)

I don't think my system will work over the internet, because of the enormous bandwith requirements, but I hope I can get it working over LAN.
Thanks for the input.

Games where there are lots of units, but some command latency (200-400 ms) is acceptable, are the ideal case for the input-synchronous networking mechanism.
Check out the "Archers" article link from the Forum FAQ for a very good write-up on how to do it without busting the network budget.

If I understood the article correctly, I will only have to send player/AI controls to all clients and the clients will the calculate the position for the units. This requires all algorithms to be deterministic (same input produces same output). But I'm not really shure if I can guarantee that.

My biggest concern is the physic engine I'm using which is PhysX from NVidia/Ageia. I have no idea what complex maths is behind calculating the object's position, orientation, etc...
Having that in mind I wonder if all my calculations will be in sync if the same command arrives at different times at different clients (thus breaking the deterministic approach).

The FPS way to deal with this seems in terms of simplicity better to me: It eats up the bandwidth, but I will never ever have to deal with non-synchronized content: The server calculates position, orientation, etc... and distributes it to every client.