Server-client connection design

Task for week 49

Part 1

In this task you'll need to implement a simple game loop for server and client. You can use any transport layer protocol you see suitable for this task (UDP/TCP/SCTP) and devise a protocol by yourself.

The basic game loop for client goes as follows:

/-> input() -> process() -> send_changes() -> update() -> render() -\

And for server:

/-> input() -> process() -> update() -> send_changes() -\

input(): Get input from stdin and/or network

process(): Process the input from stdin and/or network

update(): Update the game states with the processed information

send_changes(): Send changes (server: delta changes to world, client: key presses) to server/clients

render(): Draw new game screen based on changed world information

Each loop should be executed within certain time, which is dependent on the game frame rate (not the UI frame rate of the client, but these two are still connected). Here the game FPS is set 20, clients can, of course, send all the keypresses received during one frame immediately after the event occurs, but the server should send the changes exactly 20 times in one second.

Here you do not have to implement anything complex, implement a simple handshake between client and server where an player id is exchanged and after that each keypress on the client will be sent to the server. The delta states sent by the server consist of these keypresses, which are identified with the player id and sent as a sequence of keypresses in received order.

The clients do not have to render anything more than just print out the pressed keys (alphanumeric character or integer value) and the deltas that are received from the server.

The server should keep track of the clients at some level, depending on the transport layer protocol selected. The server should be able to distinguish between different clients from one computer.

See the example from previous exercises for time measurements.

Part 2

In this task 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 Part 1 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.

Reading material

A blog about networking for game programmers by the Lead Network Programmer on God of War: Ascension, Glenn Fiedler.

A detailed chapter of a to-be-released game programming patterns book about game loop design by Bob Nystrom (Electronic Arts Tiburon).

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

  • It is 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).