2008年01月16日
User Input and State Updates
Happy New Year!
In this article we’re going to take a break from coding and cover processing state updates and user input over the network.
Networked state updates and input processing is difficult because of security problems and Internet latency. When I say latency, I mean data transmission time + data processing time. Lag on the other hand is the visual effect of latency such as jittering or warping.
Ideally if there was no latency we could use a lock-step method for the client and server. The lock-step method is when the server waits for all clients to send updates before continuing to the next update. This would make sure that all clients are synchronized all of the time.
Games in the past such as Doom and Duke Nukem 3d used a method similar to the peer to peer lock step model for networked game play.
Of course we don’t live in a world with no latency so this method causes some problems. The game’s latency is equivalent to the slowest client. If one client has a bad connection others suffer because the server can’t continue until it receives that client’s update packet.
One other problem we have is one of the player’s using a hacked client sending fake state updates.
When Quake came out it used completely different network architecture called the Server - Client model. This basically meant the client did nothing but send key strokes and update the visible scene from messages received from the server. The server did all the processing of movement and updates based on the key strokes received from the client. The server is the authority and the client is just a dumb terminal.
Using that model they could avoid latency problems caused by slow client connections. Since the server can update asynchronously from the clients. It also made it more difficult for the player to cheat because all the processing of the logic was done server side. Although Quake still had the problem of input latency. The time for the client to send the key stroke + server to process and update the client + time to send back the data to the client could sometimes take a while. When the player hits the movement or fire key the response would not be instantaneous causing problems for fast moving games. Imagine turning the steering wheel of your car and it not turning till half a second later. It may seen like a short time but it is noticeable for times larger than 200ms.
When QuakeWorld came out it resolved the input lag problem by allowing the client to process it’s own movement until the next server update was received. This is called client-side prediction. When the player hits a key the player reacts immediately, not waiting for the server reply first. This does not compromise the server’s authority because when the client receives the next server update it adjusts it’s state to match the server’s state. If your player’s simulation code is same on all machines these discrepancies should be minor.
Besides the main player, proxy clients also need to be synchronized. Proxy clients are the visible players that are connected to the same server as your client. Their movement is usually determined by interpolation or extrapolation done on the client-side.
Interpolation can be done by taking the two previous–or possibly more–positions received from the server and interpolating between them. There are a few problems with doing interpolation. The client is always in the past; if you place two computers side by side they will not be synchronized. The reason why, is that it requires time for one client state to be broad-casted to another client. Also if you finish interpolating from state A to state B and state C has not arrived your player will be stuck at state B until state C has been received because you have nothing to interpolate to. This often causes sudden stops or jerks in your player’s movement. One solution is to predict the amount of packets you need to buffer before interpolating. This is similar to problems faced by VOIP communication.
With extrapolation the player will see the current not past state of all players. This is often done by taking the current states such as velocity and extrapolating the next position from that. This is called dead-reckoning. The problem with extrapolation is if your client’s simulation differs from the server-side simulation this can cause large discrepancies when the server state update is received by the client. When the client corrects it’s state there will be a visible lag. Objects like bullets which have predictable directions and velocities work well but object which move erratically like FPS player’s have a higher chance of visible lag.
In addition to those problems there are also some other things to consider
- Different frame rates
- Different frame rates can cause changes in physics simulations on each client leading to incorrect extrapolation or interpolation.
- Time Synchronization
- Clients with clocks not synchronized to the server will send state updates with time stamps too old or too new leading to incorrect server side state updates.
MMO games usually use a combination of interpolation and server-client with prediction model. Extrapolation is usually only used in MO style games because requires a large amount of packets to be sent to prevent lag. In my next article we will discuss and create a simple application demonstrating movement interpolation and client-side prediction.
Here are some links that go into more detail about what I spoke about
Dead-reckoning, Interpolation
http://www.gamasutra.com/view/feature/1421/propagation_of_visual_entity_.php
Networked Physics
http://www.gaffer.org/game-physics/ Read the comments they are quite informative.
Client-side prediction
http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
Leave a Comment
Trackbacked