I am still toying with several multiplayer data synchronization methods. This time, there is no server and no client. Instead, players simply exchange their input. Each game instance then applies deterministic operations which, based on the player input (which is the same for all instances, since it is sent over the network) and the initial state (which I will assume identical for all instances), results in the exact same final state for all players - thus only requiring synchronization when a player joins the game, and which can be received from any participating player. Naive approach The easiest method is to decide that all players must send their current input state at time T. Then, once the input states for all players at time T are received by the game, the T+1 step is computed based on those states. This way, the latency of all players is that of the highest-latency player (since all players have to wait for his states to reach them). When a low-latency setup is assumed (or when latency has no heavy impact on gameplay), this solution is acceptable and extremely easy to implement, even on top of an otherwise single-player game. Incorporating prediction However, latency does matter. Because quite often the input of a player will be very similar to his input at the previous time step (in terms of button presses, for instance) it appears that predicting the input of other players can be viable. What happens when a player's actions are mispredicted? Well, the game would have to return to its latest synchronized state (the time of the previously received input status from ALL players) and run all the prediction again. I imagine that this could be done by accessing all synchronized game objects through a layer of indirection: this would allow changes to be stored as diffs instead of actual value changes, and the diffs could simply be removed upon misprediction (or made permanent upon correct prediction). This does have the disadvantage of severely constraining the game logic through this additional layer of indirection - and also has me wondering how to manage such things as irreversible function calls and object destructions. That is my first problem: how to implement a transparent and general diff/rollback system for a game?Refining prediction An additional thing to consider is the fact that while the input of one player might have been mispredicted, this often has no real incidence on the game (except on the position of that player's character). Instead of performing a complete rollback over several time steps, one could imagine only a selective rollback, where things that could not possibly be affected by the misprediction are kept in their (assumed correct) predicted state. That is my second problem: how to implement a selective diff/rollback system for a game?Initial synchronization The last problem to be dealt with is the case where a new player joins the game. Such a player would then require the current game state (at time step T), which could indeed be provided to him using the diff system, along with all input states since time step T. My last problem is: how to handle the serialization of potentialy generic game data in a way that is efficient for sending over the network?

Unless the game is too complex to be handled by traditional methods (such as an RTS, in which case the latency can easily be hidden and dynamic joining isn't much of an issue) you're just making things hard for yourself. We implemented something similar but I can't help feeling that the whole game was a tech-demo to see if the networking model was viable (it was, but it's implementation is messy to say the least).

In any event I strongly suggest that you assign a server, which can be done dynamically if necessary, but having an authorative server around simplifies so many things. Even with the best of NAT punch-throughs all players still won't be able to reach each other meaning that someone must still forward input, besides just consider a detail like how you're going to synchronize the timers without a server. Or who's got the authority when a single player starts sending different input to different peers?

As for handling states and predictions I suggest that you read this: clicky.

It basically describes our method except that we also used p2p to transmit input as an optimization, so we would repredict a single player's state individually from the 'safe state' whenever we recieved peer input. Of course on top of all this you've got a normal interpolation system to smooth everything out in between.

But in general I'd say stay away and try to make things easier for yourself, Q3's networking model is simply beautiful for instance.

edit: BTW I hope you like fixed point because a deterministic simulation almost certainly implies giving up on floating point.
Oh, and you probably want to read this too.

[Edited by - doynax on December 10, 2005 10:33:51 AM]

You are a wealth of resources, thank you!

I'm currently reading through all of this, and I will comment on it once I am done.

Concerning your floating-point / fixed-point remark: my target platforms do not all support floating-point numbers, so no matter what networking system I choose, I will still have to use fixed-point (and I already do, as a matter of fact).

My game engine has some nifty features by design (such as interpolation being a direct consequence, and not something added on top of it; as well as updates only being applied to objects that require it, which reduces a lot the game logic steps; and a 'natural' way to synchronize timers) which I feel might form a good symbiosis with this method of networking.

Also, do you know any insightful resources about Q3 networking that you might recomment?

Quote:

Original post by ToohrVyk Also, do you know any insightful resources about Q3 networking that you might recomment?

This was all I could find through google right now, although I'm sure I've seen other documents. In any even the basic principle is ridiculously simple, and contrary to popular belief I've found the Q3 source quite readable.

If you're dead-set on this approach I'd be willing to discuss it further. I suspect that many of our problems stemed it being our first networking project and a general wish to do things ourselves and do it "right".
I can't say I didn't learn anything from the experience at least ;)