Networking Programming Module
Solo Development
Year:  4th year HKU  | 2020

Technical Engine: Unity
Language: C#
Difficulty: ★★★★★



On this page you will find a playthrough, explanations, and a code snippet.

I have voluntarily followed the last core module for the bachelor of Game Development, so the programming classes. This module was about learning how to make a small multiplayer game using Unity's new networking system (MLAPI). The task was to make a text-based adventure game for up to 4 players, and we worked with the protocol that our teacher made for us. The documentation on this new system was still a bit meager when we made this, so that added to the challenge. Before starting the game, players have to log in (in game). For this part, we used MySQLi and created a database in phpMyAdmin, with some simple HTML forms for creating an account. In my version, the maze is randomly generated. This was part of the third core programming module, which I couldn't finish (hand in to the teacher) as I was very busy with my internship. I was very happy I could incorporate the knowledge here.



I created 2 classes, one for the server behaviour and one for the client behaviour. We then worked with messages; this contained the (de)serializable content as per the protocol per message. I created a containerclass for these messages that would remember which message came from which connection, so I could properly show who did what in the text adventure. For the rest, when I got the first message working, the rest of the messagetypes was quite easy to get working because the system behind it worked the same; get the message, put it in the container with the connection and add it to a queue.

The hardest part was the following, which we got explained by the teacher but it was difficult for me to wrap my head around at at first. (Now I get it is extremely helpful!) For every message type, we made a UnityEvent (we made a subclass and called it MessageEvent) of that type.


When a message eventually got dequeued, it would automatically fire the right function that would handle that specific message. This made the code a lot more clear to work with.

As an extra in this module, I added a random maze generator. This was explained in the third programming core module, but I only followed that module a tiny bit as I had my internship during that time as well. As I programmed it, I used a lot of visualization of where the players were spawned, as well as monsters and treasures (not visible in the picture below). It was a lot easier to test like this because I could test situations like players meeting each other, players running into monsters or finding the exit.

Visualized maze on the host. This was just for me for testing, and not visible in the final product.


Server Behaviour