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.
Yes, not having the entire game state on the user's computer in the first place is a solid choice. And for many games, that's exactly how multiplayer works. They run all the logic on a server, "never trust the client" (that is, validate all the input that clients send to the server), and only send data the user needs to know.
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.
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.