Which network framework should be chosen for Hero’s Crucible

Made by Jord Leek

Figure 1: 2 connected players moving.
Figure 2: 8 connected players.

Table of contents

  • 1 Introduction
  • 2 Requirements
    • 2.1 Cost
    • 2.2 Hosting environment
    • 2.3 Scalability
    • 2.4 Ease of use
    • 2.5 Comparability to current framework
  • 3 Network frameworks
    • 3.1 Mirror
    • 3.2 MLAPI
  • 4 Framework choice
  • 5 How to convert
  • 6 Future
  • 7 Test
  • 8 Sources

1 Introduction

Hero’s Crucible (HC) is a real-time strategy game that is being developed by HvA. Each year a few students work on the game to make it better. The development team changes twice a year. The game currently uses Photon PUN as the networking framework. The biggest problem with using this framework is its cost. The free tier of the framework only supports 20 concurrently connected users or CCU for short. In table 1 it shows the pricing of PUN based on the amount of CCU. The problem with these costs is that they do not fit in the budget for Hero’s Crucible.

My goal for this project was looking into multiplayer framework to find a solution to this problem. This meant that one of the biggest requirements for the multiplayer framework implementation would be pricing, with the best option being free of course.

Table 1(Photon z.d.)

2 Requirements

Before I started could decide on what framework to choose, I first had to gather some criteria on which I could compare the frameworks. After having a conversation with the product owner of Hero’s Crucible about what the requirements are for the networking in the game. We came up with a few critical problems with the current solution and what would be required to have in the next network implementation. I looked at the following criteria:

  • Cost
  • Hosting environment
  • Scalability
  • Ease of use
  • Comparibilty to current framework

2.1 Cost

Starting with the most important requirement, like I said before the budget for Hero’s Crucible is not very big. The best option for a network framework for HC would be a framework that does not have any costs to host. Of course, this is not totally possible if we want to have public servers hosted that anyone can use, because hosting a server costs money. We could choose an option to have the player base host their one server because this would cost us nothing. Only this brings its own problems with it.

2.2 Hosting environment

The hosting environment is important in the case we want people to be able to host their own servers. It’s not possible to know if all players will have a windows machine. Therefore, it would be good to support Linux, MacOS and Windows. If the game only releases for windows we can also make the server only run on windows, but it would be nice to be able to support all operating systems.

2.3 Scalabilty

Currently scalability is not our problem because this is in the hands of Photon. Only when we make our own servers, we need to have a way to be able to deploy more server if the number of players increases. But because servers are expensive there needs to be a way to run more games on one server. The most important part is that this needs to be done easily. For example, by just executing an exe.

2.4 Ease of use

The development team of HC changes twice a year. Because of this it is important to use a framework that is easy to understand and has a lot of resources to learn. The product owner wants to finish the development of HC before the first semester of next school year. To be able to achieve this the framework should not take up much time to implement. Having a big feature set could help with this because it will result in having to write less code.

2.5 Comparability to current framework

To minimize the implementation time even further it would be preferable if the framework that will be chosen that is comparable to the current framework, photon PUN. This is not the most important criteria because the networking code in HC is intertwined with the game logic so a big portion will have to be rewritten anyways.

3 Network frameworks

To be able to decide on what framework to use we first need to look at which frameworks we can choose from. Out of research done by House (2020), we can see the most used frameworks for networking in Unity. This research was done with a survey of over 200 Unity users, in which we asked about their experiences with specific netcode frameworks, 20 in-depth interviews with users actively shipping multiplayer games with Unity and learnings from prototypes we built with MLAPI, DarkRift 2, and Photon Quantum. House (2020) made an overview of his findings as you can see in figure 3.

Figure 3: Overview of network frameworks (House, 2020)

House (2020) also create a flowchart to help you choose the right network implementation for project. In the case of Hero’s Crucible, the best option would be Photon Quantum. The only problem being the hefty price tag. The only options that are free are Mirror and MLAPI. Based on this, these frameworks that were investigated further. The option to not use a framework and make our own networking implementation was also considered but with the limited time for HC, this was not the best course of action to take.

Figure 4: Flowchart to choose framework (House, 2020)

3.1 Mirror

“Mirror is a high level Networking API for Unity, supporting different low level Transports” (Mirror networking, n.d.). Mirror is an opensource project which has become beloved by the Unity community. Mirror has a lot of detailed tutorials on all parts of making a multiplayer game. If we look at the criteria that were setup for this research, we will find that Mirror fits a lot of them.

Starting out with cost, Mirror does not force us to use their servers for hosting. This means that we can choose freely how we want to deploy servers. If we want to host a dedicated server on for example Strato this will be around $30/month (Strato, n.d.). This is comparable to between 100 CCU and 500 CCU with the current framework. So, if we choose this option of hosting, we need to be able to guaranty more CCU/$. But with Mirror we can also let people host their own servers.

Mirror is a package that can be imported in Unity and with this we build a Unity project. Unity supports a lot of platforms to build to. This means that we could host servers on any platform that Unity supports as a building platform.

With Mirror you can run executables as server instances this means that for scalability the only thing, we needed to do is run another instance. This could only be achieved if this does not overload the server.

During this semester, one of my fellow students did research into the performance of making your own network implementation and using a framework. For this performance test he used Mirror. For the implementation of Mirror, he only needed one workday. For this project I also started working with Mirror, all I need to learn Mirror was one tutorial of two hours and the Mirror documentation.

Mirror is mostly comparable to Photon PUN. The only big difference being that Mirror dropped support for networked events. Mirror dropped this functionality because lots of people found them confusing and it could also be achieved by using other function in Mirror.


MLAPI or Netcode for GameObjects is a new networking framework made by Unity at the time of writing this it is still a preview package. This means that the package is not fully integrated in Unity yet and for versions 2020.3 it is not even available in the package manager. Version 2020.3 can still use MLAPI, but you will have to use the git repository to do so.

The cost of hosting servers with MLAPI is almost the same as with Mirror because we do not have to use Unity servers. So, for MLAPI we can also use the same strategy as with Mirror. Using a dedicated server or letting people host their own servers. Because of this scalability is also a nonissue.

Following the research of House (2020), we can see that MLAPI is less easy to use than Mirror but not by a lot. Furter, there are less tutorials and other resources to learn MLAPI because it is still in development and has not been out for very long. Because it is still in development there could also be some problems with them changing parts of the framework. If this happens the networking code in HC would have to be rewritten again.

MLAPI has most of the functionality of Photon PUN. And with time it could be that MLAPI implements more functionality because it is still being developed.

4 Framework choice

In the previous chapter we looked at two free multiplayer frameworks. Both are pretty good options. Neither one of the frameworks has a big overhand over the other one. The biggest difference between the two is that MLAPI is still in preview. There are less learning resources because it has not been released fully.

The development team of Hero’s Crucible changes twice a year so it would be great to have a lot of learning resources so the code base can be easily understood by each new development team. Because this is the only real difference, I started developing prototypes for both Mirror and MLAPI. during this development I noticed that developing a with Mirror felt a lot easier and de documentation was better structured. I could also find more answers to problems I ran into because it has been out for longer and has a big community.

After making these small prototypes it was clear to me that Mirror would be the better candidate for HC. But based on my research this could just be preference because they do not differ much.

5 How to convert

To get an insight into what it will take to convert the networking implementation from Photon PUN to Mirror I made a prototype with a requirements list which contained what I wanted to accomplish to make a simulation of all components that are in HC. This list consisted of making a lobby system, moving units to positions and making these units attack each other when in a certain range. In combination with being able to build a headless server, these were the minimum requirements for the prototype. The biggest problem that we will encounter during the conversion from Photon PUN to Mirror is that mirror dropped support for networked events and HC mainly uses these for all communication. Furtermore, both frameworks have a lot of the same functionality so most thing or maybe all can be recreated in Mirror.

Making the units move was the easiest part of the prototype. The only thing I needed to do was give the units a NetworkTransform component to sync their positions. By sending the new target location for a given unit to the server it would set the new target for the NavMesh and update the position server side. The server then sends the new location of the unit to all the clients because of the NetworkTransform. The attacking of the units is handled by the server. The server sets targets if units are in range and lets them do damage based on a cooldown.

Figure 5: Setting a new position for the units of a player.
Figure 6: The attack logic. This only runs on the server.

The lobby system was a bit more difficult to make because I only wanted to show a start button for player 1. After a bit of figuring out how to check if you are the first player in the lobby and setting a boolean when all players are ready, I figured out how to make the lobby system behave like I wanted it to. The nice thing about Mirror was that it could handle a lot of the lobby system for me because it can handle all the scene loading.

Figure 7: Setting the start button only active for the first player.

The making of a headless server was done by making a server build in Unity with build options. To be able to host more servers on one device I needed to be able to run the server on different ports. In unity I could simply change the port number in the inspector but with the server build I had to find a different solution. I chose to use an argument called -port {portnumber} to set the port for the server. I implemented the reading of this argument and setting the port number myself.

Figure 8: Getting the command line aguments and setting the port.

6 Future

Because whole HC has to be rewritten there are some options we can benefit from these include:

  • Making the game deterministic which can help in developing anti cheat and have all clients be identical. This could also minimize network traffic because packets could be smaller to where it only sends the action and timestamp.
  • Prediction is also an option that can be implemented to increase the player exprience by making the game look smoother. (Gambetta, z.d.)

Furthermore, it would be nice to implement a listing server. This would especially be great if players start hosting their own servers. A listing server would be a way to find all open servers to be able to start a game. Another option would be making our own server. If we make our own server, we will still need a way to create new instances for every lobby that is created. This can be done because we can specify the port for each instance. If we go this route, we will need to create a server that routes us to the correct instance or creates a new one when all are full. Which of these options will be taken has to be discussed with the product owner and development team of HC.

7 Test

To test the prototype to see if it is even viable to use this implementation on servers that we host ourselves, I have investigated the performance of the prototype and checked how many full games we could play. To test this, I used my laptop as the ‘server’ and my PC to run all the clients. The bare minimum of games I want to be able to run is tree. All game will be full of eight players. This would mean that we have 24 CCU. This is more than we could support for free with Photon. If any player could host at least three servers this would increase the possible game count a lot. If we needed to host our own servers this, we would have to be able to justify the costs. The cost of hosting a server is around $30/month. If we compare that to Photon this would be between 100 and 500 CCU. So, to justify the cost of switching to Mirror and hosting a server we would need to be able to run around 50 fully loaded games.

For this test I made a little NodeJS program that can start and kill server instances based on web requests to be able to easily start and stop servers. This code can be seen in figure 9 and 10.

Figure 9: Server manager code part 1.
Figure 10: Server manager code part 2.

In figure 11 and 12 you can see what the load is of running a server with 8 players. 8 connected clienst are shown in figure 13. The utilization numbers will go up once we implement more game logic but being able to run 3 games at full capacity with these numbers is decent. de columns from left to right are CPU-utilization, memory usage, disk usage and network usage.

Figure 11: Running 2 instances with 8 players each.
Figure 12: Running 3 instances with 8 players each.
Figure 13: 8 connected clients in lobby.

8 Sources

Gambetta, G. (n.d.). Client-Side Prediction and Server Reconciliation – Gabriel Gambetta. Retrieved 24 March 2022, from https://www.gabrielgambetta.com/client-side-prediction-server-reconciliation.html

House, B. (2020, September 8). Choosing the right netcode for your game. Retrieved 15 March 2022, from https://blog.unity.com/technology/choosing-the-right-netcode-for-your-game

Mirror networking. (n.d.). Mirror Networking – Open Source Networking for Unity. Retrieved 11 April 2022, from https://mirror-networking.com/

Photon. (n.d.). Photon PUN Pricing Plans | Photon Engine. Retrieved 7 April 2022, from https://www.photonengine.com/en-US/PUN/Pricing

Strato. (n.d.). Dedicated Linux servers: veel power & lage prijzen | STRATO. Retrieved 11 April 2022, from https://www.strato.nl/server/dedicated-server-linux/

Unity. (2022, April 8). About Netcode for GameObjects | Unity Multiplayer Networking. Retrieved 11 April 2022, from https://docs-multiplayer.unity3d.com/netcode/current/about/index.html

Related Posts