Posted February 23, 2023 by Sabiha
#networking #designprocess
The core concept was based around general local or couch co-op games, where two players have minimal interaction options but need to collaborate to complete the level.
The game is a 3D top-down local co-op game that you can play with 2 people on the same local network. You are tasked to clean up the playground space by picking up objects and dropping them in the correct locations.
Note: The main focus of this project was to learn to work with Unity’s Netcode Library and Multiplayer Tools, as a result, the level design was kept to a minimum.
You are a part of Little Bear’s Cleaning crew, a crew that goes around cleaning up messes. You are tasked with cleaning up the playground.
Bear 1/Bear 2 - Play as a Bear to clean up the messes.
Pick up the color-coded balls and drop them at the color-coded platforms to clean up. Avoid and navigate around obstacles, and collaborate with Player 2 to clean up faster!
The main focus of this project was to learn to work with Unity’s Netcode Library and Multiplayer Tools, as a result, the level design was kept to a minimum.
Project Length: 2 weeks
Tools: This project was made with Unity with a 3D Universal Render Pipeline (URP) template as the base.
Packages Used:
Other tools used:
Task Tracking & Source Control:
The JIRA Scrum project consisted of 1-week sprints and several epics under which stories were assigned.
Epics:
The original base-level design was to create three rooms in a house - Hall, Kitchen, and Laundry, but certain ideas were split further down to meet the time constraints.
For the Barebones prototype, I decided to start with a single room - the hall. The environment is a room with 4 walls. 3 are visible and one wall in direct view of the camera is hidden.
Basic shapes in approximate sizes were created to get a general understanding of the space - and check if it was too big or too small for two players to navigate.
When I started brainstorming the concept of the game, I want it to eventually expand to incorporate a multiplayer networking design. To gain the knowledge required to build multiplayer, I did a lot of reading and summarized a lot of notes.
Below are some of the core concepts and eventually the design decisions I took.
Note: These notes are based on my understanding, so please correct me if there was an error!
There are different ways to handle communication among players. Some of the common ones are:
One of the common designs used in online multiplayer games.
From the above, we can see that there is a possibility of a delay from when the user performs an action to when the update is made on the user screen. To handle this, one option is Client Server Prediction
In client-server prediction, as the name suggests, the client predicts something. This something is the client player action between the time when the inputs are sent to their server and awaiting a response back. The client predicts a possible position for the player based on its previous actions, e.g a ball bouncing in a direction at a speed of 5 m/s. The client locally predicts it will continue in the same direction at the same speed until it receives the updated position from the server and then updates the local value to the server value. While this is great, it also introduces the next problem, which is what happens if the local client prediction was different than the one server eventually sent back.
Rubber banding is when the local predicted position on the client end is ahead of the server result, when the data is sent back to the client, it causes the player to "rubber-band" back to where it started from or a few steps back from where the player currently is.
To avoid this, we can use a data structure. The last few snapshots of player input are added to the buffer. When the updated result from the server is returned, we compare the sequence number with those in the buffer and discard any snapshots that are older than the server sequence number.
This is one of the earliest protocols used in multiplayer games. Here there is no Client / Server structure, instead, each client sends its game state to all others and awaits information from all other clients in the network before proceeding further. The drawback is that the latency is not great because of the waiting to hear back from each of the players.
There are a few variations and strategies you can add in for Lag Compensation, Entity Interpolation, etc.
Formulating these questions helped me identify the important aspects when considering networking.
Netcode was used as a library, among the players, the player that joins as Host is treated as both Server and Client. All other players that join later are considered clients.
The core gameplay loop is as follows:
Core Game Data:
While this approach can be modified with the addition of a circular buffer to maintain along with Tick rate and positions, this would be explored in future features and projects.
Testing of the game involved playing with 2 players and creating a “Bug Report” Jira ticket containing the following:
The initial concept was redesigned to a playground-like scene to fit better with the objects that were being picked up and dropped.
Art & Music:
As the focus of this project was to learn and create a simple networking sample, I used the KayKit Character Animations and Mini-Game Variety Pack by KayKit and Music by Olexy from Pixabay.
Thank you for reading! Feel free to leave your thoughts/feedback on the process!