It's the same principle as instant replays in many games, including shooters. If all players have an identical game state and process the same input, then their output state should also be identical. In an 8 player game of SupCom, every player has an identical copy of the game state and follows an identical code path. Instead of transferring over per unit state information (position, health, etc) over the network, only player input needs to be sent across the networks 2. With a fully synchronous lockstep architecture! In a synchronous engine every client executes the exact same code at the exact same frame rate. With so many units it would require multiple orders of magnitude more bandwidth than is acceptable.
The typical FPS client-server architecture will clearly not work. That's thousands of units in a single game. It must support 8 player multiplayer, on the internet, with hundreds of units per army. :)įirst things first, what are the requirements for our game? To help give an idea, here's the announcement trailer for Supreme Commander 1 (2006). Finding similarities between the SupCom engine and other games shall be left as an exercise for the reader. For simplicity's sake, I'm going to discuss the SupCom engine specifically from this point forward. StarCraft and Warcraft 3 have had desync bugs during beta periods, so it's safe to say they work in a similar manner. My experience in this area comes from working with the Supreme Commander engine at Gas Powered Games. Have you ever played a game like StarCraft or Supreme Commander and gotten an error message that says "Desync Detected" followed by the game closing? Do you wonder what that means? It stems from certain engine architectures commonly used by RTS games 1.
0 kommentar(er)
