3 ms·

I don't think anybody has ever shipped anything like what you propose to simulate a real-time game, but if they did, it would be more of a curiosity. For one,

I don't think anybody has ever shipped anything like what you propose to simulate a real-time game, but if they did, it would be more of a curiosity. For one, the client must not be able to tell the server "what happened" (e.g. "I shot player B"), because that would make cheating trivial without significant extra development effort. Rather, the client simply transmits only its own input for the server to process in its simulation. The server then gives the authoritative answer as to "what happened" to all clients. The client may need to patch up any visual discrepancy that may arise from differences in the client-local simulation. What you propose of course isn't impossible and it's exactly what I'd expect people with a DLT background to attempt, it just doesn't really have much of an upside for what it requires. It's the wrong trade-off for the domain.

mrkeen 6y ago
> For one, the client must not be able to tell the server "what happened" (e.g. "I shot player B"), because that would make cheating trivial without significant extra development effort. The distinction I'm making is not between "I'm now moving forward" and "I'm at x position", it's between "I'm now moving forward" (mutation) and "I started moving forward at time t" (what happened). > Rather, the client simply transmits only its own input for the server to process in its simulation. The server then gives the authoritative answer as to "what happened" to all clients. This glosses over too much and doesn't pick a side - direct mutation or event log? How does the server simulate the game state in the face of out-of-order or dropped events? > I don't think anybody has ever shipped anything like what you propose to simulate a real-time game, but if they did, it would be more of a curiosity. https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking The lag compensation system keeps a history of all recent player positions for one second. If a user command is executed, the server estimates at what time the command was created as follows: Command Execution Time = Current Server Time - Packet Latency - Client View Interpolation Then the server moves all other players - only players - back to where they were at the command execution time. The user command is executed and the hit is detected correctly. After the user command has been processed, the players revert to their original positions. https://www.jfedor.org/quake3/ Everything in Quake 3, both client and server, happens in response to events. Player input like mouse movement and keypresses, and also packets received from the network, all go through a unified event system. Even the passing of time is communicated to the engine using a separate type of event. In addition to decoupling the engine from operating system specific code, this opens up an interesting possibility. During normal gameplay it’s possible to record all the events going through the queue in a journal file.
- gridlockd 6y ago
  Fair enough, I understand what you mean now. By namedropping Paxos and Raft you were leading me onto something quite different.

mrkeen 6y ago

> For one, the client must not be able to tell the server "what happened" (e.g. "I shot player B"), because that would make cheating trivial without significant extra development effort. The distinction I'm making is not between "I'm now moving forward" and "I'm at x position", it's between "I'm now moving forward" (mutation) and "I started moving forward at time t" (what happened). > Rather, the client simply transmits only its own input for the server to process in its simulation. The server then gives the authoritative answer as to "what happened" to all clients. This glosses over too much and doesn't pick a side - direct mutation or event log? How does the server simulate the game state in the face of out-of-order or dropped events? > I don't think anybody has ever shipped anything like what you propose to simulate a real-time game, but if they did, it would be more of a curiosity. https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking The lag compensation system keeps a history of all recent player positions for one second. If a user command is executed, the server estimates at what time the command was created as follows: Command Execution Time = Current Server Time - Packet Latency - Client View Interpolation Then the server moves all other players - only players - back to where they were at the command execution time. The user command is executed and the hit is detected correctly. After the user command has been processed, the players revert to their original positions. https://www.jfedor.org/quake3/ Everything in Quake 3, both client and server, happens in response to events. Player input like mouse movement and keypresses, and also packets received from the network, all go through a unified event system. Even the passing of time is communicated to the engine using a separate type of event. In addition to decoupling the engine from operating system specific code, this opens up an interesting possibility. During normal gameplay it’s possible to record all the events going through the queue in a journal file.

gridlockd 6y ago
Fair enough, I understand what you mean now. By namedropping Paxos and Raft you were leading me onto something quite different.