#Supreme commander 2 desync how to#
#Supreme commander 2 desync full#

I suspected that Spring used a hybrid system of some kind (it does a certain amount of rollback, and massive games do work), but peer-to-peer lockstep networking has been fairly common for RTS games for the longest time, Supreme Commander being just one example.

#Supreme commander 2 desync how to#

Do you have an example of a game that uses P2P hosting? I'd be interested to learn about how to maintain consistency in that. Warcraft 3) doesn't, so desync is an issue (and replays can only play forward). Basically, you can run synced simulations with or without the server also running the simulation (I reckon TF2 hosts would run a simulation of their own, but I'm not sure). But spring does not use P2P, and thus P2P is not the reason for desyncs. My point is, P2P or dedicated hosting are not directly related to how you run your simulation of the game. Client prediction is a common technique to work around this). (Note that this implies that each client is only allowed to execute actions after the host has received the respective packet and returned it, which means that the game can feel 'stiff' to control if your latency is higher. If you have a server, then all packets are distributed in a defined order (and are thus received by the clients in a set order). Running synced simulations in a peer-to-peer environment sounds like hell to me. In video encoding terms, that's what I frames are used for. Examples include SC2, DotA 2, Path of Exile and many more.

#Supreme commander 2 desync full#

Since transferring the full game state after every action is infeasible for virtually any real time multiplayer game (you can probably get away with it in turn based games like chess), almost every contemporary multiplayer game relies on synced simulation to a certain extent, although most newer games include having certain states transmitted for replay (and anti-desync) purposes. In video encoding terms, that's basically purely P frames. (I apologize for calling everything 'spring server' and 'spring host' even if there's special names for them). The spring server still doesn't run the simulation and so has no clue what's going on until a client says 'I won!', so similarly all clients are equally 'right' due to a lack of a canonical state.

Spring is not peer-to-peer (so no quadratic scaling of network connections) because every packet is sent from one client to the spring host and then from the host to all clients. I think you are confusing some things here, Shadowfurењ“33. Others just use peer-to-peer because the sim is simple enough to reasonably work for everyone, but involves enough objects that state transfer is very wasteful, but involves so few players (usually 2-4) that the burden of picking a server (since the server would have 0 lag, so that unfairness is a problem that requires a third party) isn't really worth anything compared to the ease of just connecting the players to each other. Because of this, of RTS games, only those designed for massive numbers of players (Planetary Annihilation) or with computing requirements that can only be reasonably expected out of a relative handful of people (Achron) opt for client-server architecture.

The disadvantages of peer-to-peer are that there is no canonical state to work from, and the number of network connections is proportional to the square of the number of players (everyone connects to everyone else). Small networking basics lesson below: The advantages of peer-to-peer are that it does not require a lot of dedicated computing power to run for anyone (unlike a server), and reduces the amount of network traffic, as no state information needs to be sent to anyone. Unlike in a client-server architecture, no system is doing the heavy lifting and just leaving the other systems to handle rendering and sending inputs. Because a fundamental part of peer-to-peer architecture is that all people who are connected are considered equal.