Multiplayer Game
Online games can be highly demanding on computer networks. They require both high bandwidth and low-latency communication, often between large groups of players.
Assignment Description
In this assignment, you design, implement, and demo your own online-multiplayer game. To participate in this assignment, you first need to write a plan for your game and get it approved. Your plan must at least contain the following three parts:
A description of the game itself, and how it is played.
A design of your game, including its networking requirements. To get your plan approved, you must show that these requirements pose sufficient networking challenges. Examples of sufficiently challenging designs are:
Design a (real-time strategy) game that uses lock-step simulation15 and UDP.
Design a high-paced shooter game that uses dead-reckoning and UDP.
Design a game where one of the clients functions as the server, but can recover if this client/server fails.
We also appreciate advanced and new ideas. Do not be afraid to be creative!
A description of your approach, and how this will meet your requirements.
Discuss your plan with the teacher before getting started. Plans are only approved if their requirements are sufficiently complex. If you plan to complete this assignment, submit your game plan several weeks before the assignment deadline and assume that your plan will require several rounds of feedback before it is approved. If your plan is not approved, you cannot complete this assignment.
Requirements
Submit your plan on Canvas.
Your plan must be approved by the teacher.
Build your game such that it meets the agreed-upon requirements.
Evaluation
Demo your game to, or play your game with(!), the TA. Show the TA the source code and explain how your game works, how your game meets its requirements, and how you solved challenges encountered along the way.
Template for Game Plan
The Game Plan must be submitted and approved before implementing the game assignment. Be aware that the principal component of your project needs to be represented by the networking side.
Title:
Write down what you want to call your game. Be creative!
Game Description:
This section presents a high-level description of your game.
What is the overall goal of your game?
Are there any specific roles within the game?
How will players interact with the game world? With each other?
How is networking the core element of your game?
Design:
Provide a general overview of the game you intend to implement alongside screenshots of existing games or a simple mockup designed by you.
Networking:
Will your game utilize a special network architecture (e.g. peer-to-peer or client-server)?
Why did you choose your game?
Provide a diagram of the network topology used in the game.
Advanced Networking Features:
Why is your game challenging to implement?
What networking features do you want to implement in your game?
How do you plan to implement the challenges?
Functional and Non-functional Requirements (terms definitions):
What are the completion criteria for each requirement?
How can you test each requirement to ensure it is implemented correctly?
Provide at least two functional and two non-functional requirements respecting the following format:
We are looking forward to seeing your great ideas!
Example of past Game Plans
Online Multiplayer Pong
Title: Pong
Game Description:
The game will feature a lobby that connects players with their online opponents. When there is only one player in a lobby, or if a player cannot yet be matched with another opponent, they will be shown a friendly message asking them to wait. Once two different players are matched, the game starts. In the game, there is a moving ball initially heading towards one of the players. The ball bounces off the horizontal walls and players’ rackets. Players can move their rackets to deflect the ball from the vertical wall behind them. If a player fails to position their racket to deflect the ball, and the ball goes past their racket, their opponent's score increases by 1. The game continues until one of the players reaches a score of 13.
Design:
Networking:
The game will use a client-server model and the UDP protocol for better responsiveness. When connecting to the game, clients will send a message requesting to join the game until they receive an acknowledgment from the server. The server will keep track of players who want to play and, whenever there is a pair of players, will send messages informing the clients that the game has started. When both clients acknowledge the start of the game, the game begins. Throughout the game, the server will send the ball's position, scores, time of send, ball direction, player rackets’ positions, and player rackets’ directions in JSON format. Clients will examine the time of arrival and the last time a packet was sent and use dead-reckoning to calculate where the ball is supposed to be at the current moment. Clients will then respond with the positions of their rackets, direction, and time of send. The server will examine clients’ current and previous racket positions and, using packet timestamps will determine whether the move was possible under normal, "non-hacked" game conditions. If a client fails this check, they will be kicked out of the game. The server will also use dead-reckoning to determine where the rackets should be, and this position will be used for all game-related calculations.
Advanced Networking Features:
Feature name
Why you want to implement it
High-level plan
UDP protocol
This will be used for real-time gameplay and faster server and client updates.
Both servers and clients will use acknowledgments for the lobby connection requests and game start requests. The server will also handle client disconnections by measuring the time since the last packet was sent. If the time delta exceeds a threshold, the client will be disconnected and the game will be finished.
Dead-reckoning
This will be used for a more responsive gaming experience and to compensate for potential lost packets during the use of the UDP protocol
Both clients will use it for the ball position and the server will use it for the racket position. Dead-reckoning will use the position from the last arrived packets, direction, and current time. Since both the ball and racket speeds will be standardized, the server or client will be able to calculate the current expected position of the object.
Cheat-detection
This will be used to prevent unfair play and forged clients.
The server will save the last packet from the client and will calculate the maximum possible position a client could have, using the current and previous packet timestamps and the known, standardized racket movement speed in advance. If the client is outside of the maximum position bound, they will be kicked out of the game and the game will be finished.
Functional and Non-Functional Requirements:
Requirement
Type (functional / non-functional)
Completion criteria
Testing High-Level Description
The ball has to move and get reflected of rackets and horizontal walls
Functional
Ball moves and gets reflected off rackets and horizontal walls
We will play a game in front of the TA and show working ball functionality
The game should have a lobby, which upon opponent connection, the player leaves and the game starts
Functional
Lobby and game transitions are implemented
We will connect with one client to the server, show the client’s lobby screen, and then connect with another client starting the game
The server has to implement cheat detection and be able to detect forged clients
Functional
Cheat detection implemented
We will forge one of the clients, increasing their racket speed by a factor of three, and show then when attempting to play with the forged client, a player is kicked out of the game.
The game should use dead reckoning for responsive gameplay and packet loss compensation. Dead-reckoning should be used for ball and racket positions.
Functional
Dead-reckoning is implemented both in server and client for ball and racket positions
We will show our code and dead-reckoning implementation.
The game should use the UDP protocol
Functional
Game networking is implemented using UDP
We will show our code
The game should stay functional if up to 50% of the packets are lost both by clients and servers.
Non-functional
The game stays functional when 50% of the client’s and server’s packets are lost
We will introduce a logic in our code which with probability p will drop and not send the packet. We will then make probability 0.5 and show that the game stays functional
The game should stay functional with packets delayed up to 0.5 seconds
Non-functional
The game stays functional when the packet delay is 0.5 second
We will introduce an artificial packet between the packet submitted by the game and the packet sent to the server. We then will set the delay to 0.5 and show that the game stays functional
Title: Hostless Terraria
Game Description:
The game is a tile based box game in which you can shape your own world together with other people. Anyone should be able to join the game, regardless of whether or not the original world creator is online, as long as at least one player is currently playing. The game should recover from any of the players disconnecting during a game, and should bring the disconnected player up to date when they reconnect. This approach should use no dedicated server to minimize cost of operation, but synchronize the entire game state between all players in a peer-to-peer fashion, making sure the actions of one player are seen by all the other players.
Design:
Networking:
Anyone should be able to join the game, regardless of whether or not the original world creator is online, as long as at least one player is currently playing. The game should recover from any of the players disconnecting during a game, and should bring the disconnected player up to date when they reconnect. This approach should use no dedicated server to minimize cost of operation, but synchronize the entire game state between all players in a peer-to-peer fashion, making sure the actions of one player are seen by all the other players.
This is challenging because the world is a state that needs to be synchronized between potentially very many people, but it is in nature infinite in size, which means simple approaches to synchronization will not work. It is also challenging because players need not be constantly connected to the game, but must have the entire state brought up to date when they connect.
Advanced Networking Features:
Lockstep simulation
To share the state of the game
We will be using a lockstep simulation technique to synchronize the world between clients, where every action (like a block place or break) will be broadcasted to every client, which will simulate the action on their own internal state. The game host will act as a relay for any action broadcasts, and in the event that it disconnects, a new host will be elected by the remaining clients.
Client log
To keep count of actions of each player
These actions will be recorded by every client in a log. Each action will have a short hash code, such that the integrity of the action received can be easily checked. Furthermore, each hash code is also based on its previous hash code, creating a sort of blockchain, such that a client that misses a broadcasted action can recognize this fact when it receives the next action and its hash does not check out with what it currently has in the log. It can then ask the current host for every missed message by sending it its last known good log entry hash. The host should then send it every missed action since then, which the client will simulate. This mechanism will also be used when a disconnected player reconnects and indicates its last known log entry.
UDP protocol
This will be used for real-time gameplay and faster server and client updates.
UDP protocol provides efficient and low-latency communication between clients and the host.
Functional and Non-functional Requirements:
User can break blocks
Functional
The block is deleted after pressing the tab
We will play a game in front of the TA and show the functionality
FPS counter
Non-functional
Will update the users logged into the game
We will connect with 2 players and disconnect one
User can move
Functional
The user can move arround the game screen
We will play a game in front of the TA and show the functionality
Client log
Non-functional
The user will move arround to a place that is different than the initial one
Disconnect a player and recconect to see if the state is kept
Last updated