Game environment : a vehicle control game, where the player constructs large voxel contraptions and drives them around in multiplayer.
I'd like for players to be able to leave their seats and run around in the vehicles while they are moving. I'd like the vehicles to be able to reach realistic speeds - hundreds of kilometers/second in the worst case - without any chance of players ever glitching through the floor or outside, etc, even if another player is at the helm. I'd like for 2 player controlled vehicles, both "moving" at ludicrous speeds, to be able to dock in space. I don't want there to be any visual glitches whatsoever - no warping, rubber banding, juddering, or the sky moving funny if one player is looking out the window while another player is on the helm.
I see one way to do this, but it has a cost and I'm unclear if this is the only option.
It's real simple. Player updates a GUI that controls a vehicle. It's indirect control - a player might click the mouse on the 'navball' to choose a new orientation, or choose a new setting on the throttle.
GUI updates instantly with a color indicating that the action hasn't actually started yet.
These GUI actions get sent via the usual UDP spam mechanism to the server. (50 times a second you send a new set of UDP packets containing any unacknowledged actions).
Server updates it's internal state/sim model from the GUI changes. Server now starts uploading to all clients a TCP message containing the new state of the game world, specific to the events each player has "subscribed" to. (player client has mandatory things it must subscribe to, things within a certain radius of the player model itself, and other stuff is by request by the player client.)
The new state is set in the "future". Clients now generate intermediate game states that are then used for rendering of the world, with the intermediate state series adjusted so it will always end up precisely aligned with the new state.
So the cost : input lag. About 500-1000 ms. Press a button to open a door? 500-1000 ms will pass, then the door starts opening. Summon a lift? Send the lift to a floor? Adjust course on a spaceship? All have a delay.
The benefit is that all players with pings below about 500 ms never see any glitches from the environment. Everything is always exactly where it really is, synchronized with the server, and everything should move smoothly. There would be no problems with doors or lifts when multiple players are using them, because every player shares the same game world in sync with everyone else.
Player models and things that can be affected by the player model in real time can't be done this way. If you see another player in multiplayer, you are not seeing where they are now, just where your client is guessing they are (future state prediction). So you would have to have the authoritative server pass through immediately in a separate thread any UDP state updates from other players. P2P would be even better.
This makes small bouncing objects the players can shove around extremely problematic : I cannot think of a perfect solution for them. Either they warp and rubber band and jitter to where the authoritative server says they are, or they have async and local which also creates edge case bugs.
