|
|
|
|
|
by toast0
1246 days ago
|
|
Ok, so option 1) is to make internet multiplayer run on a game server, not peer to peer, but that's not exactly running the game on their own computers. Another option would be for the peers to only send data that the other should know (fog of war), but that's a lot trickier. Because you then need to figure out how to validate the unseen data wasn't cheating, too. You might be able to do something with this today, because storage, computation, and bandwdith has grown so much. Maybe store all the local state changes, and when a block becomes visible, send its current state first, and then stream the history as time permits; the other side would accept the state initialy, until it could fully validate it.
You would need some way to keep the randomizers in sync and fair, too. But that only protects from seeing what should be invisible; you could still have computer enhanced movement and maybe enhanced display of data attributes that weren't supposed to be human visible. |
|
However for something like an RTS, the amount of data in game state updates can be prohibitively large to transmit to clients. The deterministic lockstep networking model described in the article is a solution to that problem. In that system, the only data transmitted is input, and each client updates locally, so it does require them to have a copy of the entire game state.