> In a case like Worms where there are concurrent actions and random reveal choices inside each turn... If some deterministic state and random number is created for each player at the start of the turn, then their inputs can be reproducibly mapped to the results of all the random choices. In that case you can just upload the inputs and let the server work out what happened based on the hash the player was given (i.e., let the server replay each player's inputs against that hash and figure out the result).

No, this is the worst of the two cases: it allows predicting all outcomes at the start of the turn AND allows manipulating the outcome. So, in a territory control scheme like Team17, you can choose whether to pick up that crate now, or wait a turn or two until picking it up will result in a better outcome.

> But the server is not another player. It's not a player at all. It's the arbiter of truth.

No, that's not how peer-to-peer games work. In the current implementation, it is the "arbiter of truth" because it's the "server" in the TCP/IP sense, but it is still run and controlled by a player, and should not have any intrinsic advantage.

> At some point games will just accept this and allow the player with too slow of a connection to be disadvantaged.

Maybe games with a centralized networking model. We deliberately avoided doing anything in this direction for Worms Armageddon because it puts a death clock on the game and the community - see all games which are no longer playable because the developer/publisher decided that keeping the servers online was no longer profitable.

> To the extent that a server should tolerate slow connections, it is a handicap given by the game to players with slow connections.

In the hypothetical secure scheme I described above, ALL players are affected, not just the slowest one.