Multiplayer chase

The main focus of this personal project was to learn how to make multiplayer systems! With a strong foundation in C# and Unity, I took the chance to learn and explore all of the unique components that go into creating a networked multiplayer game and how I could make my own implementation. Utilizing Unity’s proprietary networking solution, Netcode for GameObjects (NGO), I synchronized gameplay events across different players on a P2P, locally hosted network.

For this project, I decided it would be best to keep the mechanics as complicated as necessary but as simple as possible to keep my scope of work creeping out of my allotted timeframe of six weeks. So I did my best to implement a variation of Mario Chase, where one player is hunted by three other players and if they’re caught then the hunters win.

LEARNING THE BASICS

When starting this project, I had little prior knowledge of networking let alone networked multiplayer games. The first task I gave myself was to find reliable resources to give me a foundation on this topic. I spent the two weeks delving into how it all works: network protocols, architecture, topology, models, components, and lots of other terminology that was new to me.

After garnering a basic understanding of everything, I decided it was time to make some tough decisions. I wanted to go further than to make split screen multiplayer, but still keep it simple as possible, so I chose to make a game using P2P. Since Unity 6 had been out for a while, I decided to use NGO for my networking solution, and utilize Multiplayer Play Mode for testing.

A “simple” setup

The next step was to set up NGO in editor and make the simplest possible gameplay I could just to make sure it all worked. Since by now I knew I wanted a game that was third-person, I decided to make a character with third-person movement from scratch and sync that across the network.

In a single-player game, all you need to do is write the movement code and hook up a camera and you’re finished! However, in my case making any changes to the player means that it needs to be synced across the network. I had to learn how to put the concepts of ownership and authority into practice for any clients to see changes being made on the host’s machine. I had to give extra thought to the code involving movement, rotation, camera setup, and even the color that the player begins with for it to function correctly!

REMOTE PROCEDURE CALLS

I wanted to have a round-based system where the text at the top of the screen dictates the gameplay for each player. For this to work, the text needed to be controlled by the server (host), but displayed differently on each client based on the current state of the round. For example, the messages that are displayed in the video on the right need to be synced so that all players are given the correct instructions at the appropriate time.

To implement this feature, I had to learn how to use remote procedure calls (RPCs) to communicate events between the server and specific clients. The countdowns use an RPC that is synced across all clients whereas the individual messages would have to determine whether the player is being chased or not and then send a customized message based on it. RPCs are used across the project for teleport events, message updates, collisions, and more!

DIVE ABILITY

I wanted to challenge myself by adding a player mechanic other than movement to add to the gameplay. I compiled and edited various animations online and stuck them onto a single humanoid rig. I set up an animation controller for the movement and input for the ability.

However, the struggle came when I needed to have a client communicate a message to the server via collision. I had to make a hitbox component that was used to communicate messages to the player, which then called an RPC to communicate to the server that a player had been caught by another. The server then immediately ends the round and calls another RPC to sync the “The red guy has been caught” message between clients.