Server-client connection design #2

Task for week 49

In this exercise your task is to implement a simple client side prediction using any protocol you see suitable for the task (UDP/TCP/SCTP). Use the server and the client from the previous exercise but in this task set the server update rate to 2 FPS and the client update rate to 4 FPS. This means that server sends updates twice during one second whereas the client updates own game state and screen four times in one second.

The server should reply to the client the id that is given to the client (1,2,3,…,n) after the client has sent some HELLO packet. The client can use this id (or character, if you wish) for drawing own marker on the screen. Support at least 2 players.

The client should send only UP,DOWN,LEFT,RIGHT (KEY_UP,KEY_DOWN,KEY_LEFT,KEY_RIGHT if ncurses is used) keypresses to the server which indicate travel direction of the player. The advance rate of each player is fixed: tile/frame, i.e. in one second the character can progress 4 tiles. The player character keeps going to the direction until stopped or the direction is changed. Each keyboard event is sent to the server immediately.

The server delivers the player status to each client at every update interval. The status should contain at least: game frame number, id1, id1 x and y coordinate, id1 moving direction, id2, id2 x and y coordinate, id2 moving direction. The initial message the server sends should contain an empty moving direction.

Server naturally has to update the client positions by the movement direction: the server has the “master” clock. Even though the updates arrive with 2 FPS, the server has to track the game progression and update the player positions according to the movement changes sent by the clients.

Each client uses the status updates provided by the server to place markers on the area. The area can be any size and the “world” should wrap around (when character moves to, e.g., upper bound of the area it will appear next from the bottom of the area). Since the update rate of the client is twice fast as the server update rate, the client predicts the next position of other player(s) by using the coordinates and movement direction. If the update contains different coordinates as the ones the client has for the player of for the other player(s) each player is moved to that position, i.e. the game state is corrected using information from authoritative server.

The process on client

/-> select() --> input_user() -> process() -> send_changes() -> update_own() -> predict() -> timer_elapsed() ---> yes  -> render() -\
|             \                                                               /                                \                    |
|              \-> server_update() -> correct_positions() -> update_world() -/                                  \- no-\             |
|                                                                                                                     |             |
\----------------------------------------------------------------------------------------------------------------------------------/

select(): Check where input is triggered

input_user(): Get the input user gave.

process(): Check what key was pressed (send only the direction-keys, ignore others)

send_changes(): Send the key press to the server.

update_own(): Update own location on the game state

timer_elapsed(): Has enough time passed since last predict & render?

predict(): Move other players according to their last position and direction by one tile.

render(): Draw new screen based on own changed, world changed or predicted coordinates of player(s).

server_update(): Server sent us an updated game state

correct_positions(): Correct positions of each player on the “world”

update_world(): Update the world information

Do not worry about synchronizing client starting times, game clocks or latencies here. Just implement simple prediction to client.

Additional reading

Algorithms and Networking for Computer Games by Smed & Hakonen (e-book, access limited to LUT network

  • It can be recommended to read Part II Chapters 8 and 9

Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization by Yahn W. Bernier, Valve Software.

Third assignment announcement

At the end of this exercise the assignment 3 - the group work is revealed. You should form groups and report them to the assistant by email at the end of the week 49 (one email/group).