unnamed networked game - 2d multi-player top down shooter
PROJECT TIMESCALE: october 2014 - december 2014
Below is the short write up I did for this project.
Application Description
•The program is a multi-player game for 2-4 players.
•Each player controls a bike on their own computer.
•They can rotate left or right and move forwards or backwards by pressing either the arrow keys or the WASD keys.
•They use the spacebar to fire a projectile.
•The goal is to survive by avoiding other players’ projectiles whilst using your own projectiles to defeat other players.
Chosen Network Architecture
•The program uses a client-server architecture.
•Each player uses a client to control their own bike and see the other bikes.
•The server keeps track of the game world and handles collision detection.
•After a player enters inputs to control their bike, these inputs are sent to the server so it can update it’s copy of the bike.
•The server sends out the position data it has stored for each bike to the clients so the clients can update the bikes not controlled by their own user.
Protocols Used
•The game uses a mixture of the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP).
•TCP is used for connecting the clients to the server and sending inputs from the clients to the server.
•This ensures that the server’s copy of the game world is accurate.
•UDP is used to send position updates from the server to the clients.
•Position updates need to be sent constantly so using TCP could significantly slow down the game over a network with significant latency.
•Also it doesn't matter if an update is missed since the client can use prediction and interpolation to keep the bikes synced between clients.
Chosen Network API
•The client and server are both written using C++ with SFML (Simple and Fast Multimedia Library) which is distributed under the zlib/png license.
•Developer has experience using SFML from previous game projects and its networking code, although limited, is easy to understand and lends itself well to game applications.
•The server uses the following networking tools provided by SFML:
•A sf::TcpListener which listens for new TCP client connections.
•A list of bikes which each contain a sf::TcpSocket for receiving inputs from each client.
•A sf::SocketSelector which provides a way to wait until the listener is ready to receive new client connections and wait until inputs are available to be received from the list of TCP sockets
•A sf::UdpSocket which is used to send position updates to each client.
•A client uses the following networking tools provided by SFML:
• A sf::TcpSocket which is used to confirm when the client has joined the server and the game has started and is used to send inputs to the server.
•A sf::SocketSelector which provides a way to wait until the server join and game start confirmations are available from the server.
•A sf::UdpSocket which is used to receive position updates from the server.
•Both the server and clients use multiple instances of sf::Packet to package data together before sending it and unpack data after receiving it.
Application Description
•The program is a multi-player game for 2-4 players.
•Each player controls a bike on their own computer.
•They can rotate left or right and move forwards or backwards by pressing either the arrow keys or the WASD keys.
•They use the spacebar to fire a projectile.
•The goal is to survive by avoiding other players’ projectiles whilst using your own projectiles to defeat other players.
Chosen Network Architecture
•The program uses a client-server architecture.
•Each player uses a client to control their own bike and see the other bikes.
•The server keeps track of the game world and handles collision detection.
•After a player enters inputs to control their bike, these inputs are sent to the server so it can update it’s copy of the bike.
•The server sends out the position data it has stored for each bike to the clients so the clients can update the bikes not controlled by their own user.
Protocols Used
•The game uses a mixture of the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP).
•TCP is used for connecting the clients to the server and sending inputs from the clients to the server.
•This ensures that the server’s copy of the game world is accurate.
•UDP is used to send position updates from the server to the clients.
•Position updates need to be sent constantly so using TCP could significantly slow down the game over a network with significant latency.
•Also it doesn't matter if an update is missed since the client can use prediction and interpolation to keep the bikes synced between clients.
Chosen Network API
•The client and server are both written using C++ with SFML (Simple and Fast Multimedia Library) which is distributed under the zlib/png license.
•Developer has experience using SFML from previous game projects and its networking code, although limited, is easy to understand and lends itself well to game applications.
•The server uses the following networking tools provided by SFML:
•A sf::TcpListener which listens for new TCP client connections.
•A list of bikes which each contain a sf::TcpSocket for receiving inputs from each client.
•A sf::SocketSelector which provides a way to wait until the listener is ready to receive new client connections and wait until inputs are available to be received from the list of TCP sockets
•A sf::UdpSocket which is used to send position updates to each client.
•A client uses the following networking tools provided by SFML:
• A sf::TcpSocket which is used to confirm when the client has joined the server and the game has started and is used to send inputs to the server.
•A sf::SocketSelector which provides a way to wait until the server join and game start confirmations are available from the server.
•A sf::UdpSocket which is used to receive position updates from the server.
•Both the server and clients use multiple instances of sf::Packet to package data together before sending it and unpack data after receiving it.
Prediction and Interpolation Techniques
•Prediction and interpolation will be used in each client for all the bikes that client doesn’t control.
•For prediction, the client will assume that the last received input is still correct until a new input is received.
•E.g. Bike was moving forward in last message so bike is still moving forward.
•For interpolation, when the bike’s position in the client doesn’t match the position in the server, the bike will turn to face that position and move towards it.
•E.g. Bike was at bottom of screen when it should be at the top so it turns upwards and then moves forward.
Critical Evaluation
•The program still needs a lot of work before it can run over networks with very high latency.
•Rather than sending inputs every frame, it would be better to only send them when they have changed.
•Some sort of lobby state could be used to connect clients to the server rather than doing it in the game state update.
•The player interpolation is very basic. Would be better to interpolate to the next predicted position rather than the last known position.
•Using a simulation time scale would create better synchronisation between clients.
•Projectile fired messages only sent by UDP so could easily miss projectiles on other clients.
•Prediction and interpolation will be used in each client for all the bikes that client doesn’t control.
•For prediction, the client will assume that the last received input is still correct until a new input is received.
•E.g. Bike was moving forward in last message so bike is still moving forward.
•For interpolation, when the bike’s position in the client doesn’t match the position in the server, the bike will turn to face that position and move towards it.
•E.g. Bike was at bottom of screen when it should be at the top so it turns upwards and then moves forward.
Critical Evaluation
•The program still needs a lot of work before it can run over networks with very high latency.
•Rather than sending inputs every frame, it would be better to only send them when they have changed.
•Some sort of lobby state could be used to connect clients to the server rather than doing it in the game state update.
•The player interpolation is very basic. Would be better to interpolate to the next predicted position rather than the last known position.
•Using a simulation time scale would create better synchronisation between clients.
•Projectile fired messages only sent by UDP so could easily miss projectiles on other clients.