FPS networking with server sending input instead of gamestate

Question

Why do all fps games have the server send gamestate instead of input which is smaller?

One reason I can sort of see is that if the server sends input to the clients and a packet gets dropped then the client will not be able to gave an accurate simulation until a resend of that packet occurs which could be an entire timeout plus one way trip latency. Presumably this is considered unreasonable for a real time fps game.

But what if at time T the server sends the input processed at time T to the client and at time T+1 the server sends the input processed at time T and time T+1. This way if the packet containing the input processed at time T is dropped the client will get the next packet sent by the server which contains the input processed at time T and time T+1. Thus the client will not stall on the simulation because the server is redundantly sending previous input. The server stops sending a previous input when it gets an ack from the client.

This seems to avoid sending the entire game state. Can someone tell me why this idea is just bad and why no fps games use it?

Answer 1

Non player characters don't have 'input', and neither do projectiles. In fact a lot of the time players aren't acting as a result of input but as a result of physics. So, generating artificial inputs for some of these entities is extra work.

It also assumes that all clients will handle input in exactly the same way, and this won't be the case if there is any interaction between the characters because each player will see a slightly different game state due to latency and their own actions. Clients can fix this with a rollback and replay approach but that is more complicated when you have to do it for every entity and its input instead of just your own input.

Elaboration based on comments:

• Not every server-side action (eg. AI, physics-led behaviour) has a simple or natural representation as 'input', so often it's easier to just send the results, ie. the changed state;
• Even where there is a usable representation, it's not necessarily cheaper to send than the new state. (eg. If you send a vector representing a projectile's movement, that is likely to be exactly the same size as a vector representing its new position.)
• Not every algorithm is trivial to run in exact synchronisation on different machines. eg. Some graphics systems do strange things to the floating point subsystem.
• Every client sees a different view of the world anyway, if you're doing prediction on the client, which is usually necessary for faster games such as FPSes where units move very quickly. Inputs taken based on a predicted state can turn out to be invalid, which means there needs to be some way of resolving them, which can be complex.
• One way of simplifying a system like this involves sticking to discrete timesteps and ensuring that each timestep is identical across all clients (also known as 'lockstep') but this doesn't suit all games, especially faster paced ones, as a reliance on perfect information comes at a latency cost, often covered up by animations and client-side delays.
• resending extra input in the case of error is less efficient in the face of high packet loss than sending new state. There comes a point when it is cheaper both in bandwidth and in processing time to send an updated state than to send a bunch of sequential updates, and in terms of coding time it may not be worth writing both code paths if you know that just sending states will do.

Answer 2

Strategy games usually send input, while shooters usually send gamedata. However there are exceptions. For example Halo : Reach runs in lockstep in some online game modes, sending only input.

There are multiple reasons for this:

1. Shooters have a lot less game data than strategy games
2. It's easier to keep the game in sync
3. It reduces lag as long as the game data to send is small

Shooters have a lot less game data than strategy games

A typical shooter has 10 people shooting at each other. The data for this is small, for each player you only need to know the position, direction, speed, health and current weapon. Once people start shooting it's going to be a bit more but that data doesn't need to be retransmitted to every player. In strategy games you have to send this for all 100 units of all the 10 players, which quickly explodes into a gigantic game state.

It's easier to keep the game in sync

When everyone sends their game data the server knows exactly the state of each player's game and can thus easily compare everyone's game state to see if it's in sync. If it isn't in sync the server can usually tell who isn't, because the data is received from multiple sources, and can send messages to correct it. If the server only receives input and through some weird errors one player goes out of sync then there is no easy way to repair it so the player has to be dropped.

It reduces lag as long as the game data to send is small

When sending input data you are usually running in lockstep. This means that each client get's a turn, the server then decides the outcome and sends the changes (as input) to all the clients. This means that you have to keep waiting on the player with the highest latency. (You could run without lockstep, but I have no idea how that would work on just input since you're bound to desync soon then).

Why don't all non-RTS games just send game state

There are also a few good reasons for just sending input data. You can't cheat with input data, while it's fairly easy to cheat with modifying your game state, and it's easier to resolve bug with happen due to lag since everyone is running at the pace of the slowest player so everyone sees the same thing happening for each event.

Further reading

• http://www.altdevblogaday.com/2011/07/09/synchronous-rts-engines-and-a-tale-of-desyncs/
• http://www.gamasutra.com/view/feature/131503/1500_archers_on_a_288_network_.php
• http://downloads.bungie.net/presentations/David_Aldridge_Programming_Gameplay_Networking_Halo_final_pub_without_video.pptx
• http://www.aorensoftware.com/blog/2011/01/28/determinism-in-games/
• http://en.wikipedia.org/wiki/Two_Generals'_Problem