Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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?

share|improve this question
2  
What makes you so sure no fps games use it? –  William 'MindWorX' Mariager May 22 '12 at 5:00
    
at least all the well known fps games send game state: quakes, half lifes, call of duties, etc. –  user782220 May 22 '12 at 5:41
    
One game does actually: Halo Wars - however it ALSO sends the state, it merely uses the input state to improve client-side prediction. The state always has the last say though. –  Jonathan Dickinson May 22 '12 at 12:46
    
As mentioned below Halo Reach does this too downloads.bungie.net/presentations/… –  Roy T. May 22 '12 at 20:08
    
Here's the talk to go with the presentation Roy T. posted. –  Richard Marskell - Drackir May 26 '12 at 4:09
add comment

2 Answers

up vote 4 down vote accepted

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.
share|improve this answer
    
Maybe you should expand your answer some more because this doesn't make sense to me and I know that you know more than I know ;). NPCs that aren't affected by the player directly are affected by their AI routines and physics, since these routines should behave deterministically on all platforms (for a correct implementation) the 'input' of these doesn't need to be send. As for interaction between clients with the 'input' approach the usual solution is lockstep, where all clients together take a step after all client's haven taken their previous step and the server has received all new inputs. –  Roy T. May 22 '12 at 14:33
    
AI routines don't typically create input, they change values directly - so sending the 'input' is equivalent to sending their state. Also, AI routines run in the past as far as clients are concerned because they only receive information about them after the changes have already made, which can affect the client's local input (because the target may have moved or changed significantly in that time). The lockstep concept is irrelevant for most FPS games because it's not a practical idea where client prediction is in place. –  Kylotan May 22 '12 at 16:48
    
AI routines that change values directly do this because of some rule in their algorithm. That algorithm is the same on all clients and on each client the same rule will be executed in the same time step, so once the AI becomes active it doesn't need any more synchronization. All the other state, that might affect the AI indirectly is kept in sync via input. –  Roy T. May 22 '12 at 18:04
    
(a) The same algorithm can work differently across different computers (eg. floating point calculations), (b) each player sees a different world state since their local changes are only known to them - this means the outcome in each case can be different. You would fix this by using 'time steps' where all the information is known but that means running the simulation in the past, not the present - this is why it's only done for strategy games, not shooters. –  Kylotan May 22 '12 at 19:44
2  
No, because sending input would never 'fail' - it's just harder to do well, because (a) not everything has a simple representation as 'input', and sometimes it's as expensive as sending the state itself, (b) not every algorithm is trivial to run in exact synchronisation on different machines, (c) not every game is suited to fixed timesteps, (d) stacking extra input in the case of error is less efficient in the face of high packet loss than sending new state. –  Kylotan May 23 '12 at 13:23
show 5 more comments

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

share|improve this answer
    
Great answer. It would be nice to read some articles about this, do you know of any good ones that you've read? –  Phil May 23 '12 at 12:50
1  
There are quite a few great ones. For better organization I'll add them to the answer. –  Roy T. May 23 '12 at 12:52
    
Thank you. Interesting content. –  Phil May 30 '12 at 22:28
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.