How Online Game Works

Have you ever played a multiplayer game online? Ever wondered how multiplayer games work?

As a player it seems like all the player actually exist in the virtual world and sharing consistent movements/action with all. But what actually happens underneath is different from what we see from outside.

Typically most modern online games employ a client-server model.

In a pure client-server model a player sends inputs such as key presses, mouse movement and clicks to the server. In response the server updates the state of your character in the game world and replies with a packet containing the updated state of your character and other players.

Most of the time the server will have a "refresh rate" which is the frequency at which it updates player information. The faster the better, especially in a game where every moment matters.

Normally many ticks necessary to give the user a real time experience. Tick means, the number of times per second that the information gets updated. On each tick, the client might send player's movements, attacks or any change to the game world.

There's one authoritative version of the world held on the server. But various tricks are used to make sure the clients are not waiting on the server before displaying action.

There can be some deterministic action and non deterministic action.

In deterministic action the server can predict the future state of the object based on some initial data. For example, to render any gun shot event the server only needs to know some initial info like direction and force. Based on this info the server can tell client how to render the event.

In non deterministic action server can not predict the future state. So the clients need to send regular stream of data to the server. Having received the input data, done the simulation, the server sends out packets containing an authoritative version of all the client's positions.

Simulation code takes these input streams, simulates motion and resolves them into character / vehicle positions. This simulation can run both on the server and on the client.

From a programming point of view, we need to cope with latency. In the time it takes for the message to arrive, things will have moved. To cope with latency, both server and client have to play tricks with time.

Client-side Prediction

To give the player immediate feedback after a keypress, the client can predict what the state of the server is going to be after it receives the player's input and render this immediately. The client then reports its new position to the server. To predict the proper state change, the client must also simulate the game world.

However, due to latency, the client and server may become out-of-sync. The server may repeatedly inform the client that it needs a correction at this point, which will result in the player's unrealistic movement.

To compensate for syncing issues, one strategy is for the server to tolerate a certain amount of difference between what it thinks the player's position should be and what the player reports. Once this is added, rendering the local player's position change immediately leads to a much smoother game.

There are some other ways to mask latency. We'll discuss more in the future.

References:

http://gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/