DevDiary #16 Part 1 – “Of Hosts and Clients” – February 2021
Hello everyone! In DevDiary #16 Part 1 we want to give you some insight into the Multiplayer mode of The Guild 3, how it works, what challenges we are facing and how we are approaching them.
Before we dig deeper into the multiplayer mode, we want to briefly shift to another topic: we are aware that a lot of questions about the editor have come up recently. We would like to tell you that, while the editor is still something we are planning to release, it will not happen before the game is finished. The editor is still undergoing changes as we progress with the production of the game.
Now, let’s head back to the topic of this DevDiary. First, we want to give you a short overview of the general architecture. The Guild 3 uses the very common Client-Server architecture. One player (the one who starts the game) gets a special Host (also known as Server) role assigned which means their instance of the game gets to decide what is happening in the game world. The other players are Clients who need to send requests to the Host to influence the game.
For example, if a Client wants to send one of their characters to attack someone else, they will send a request to the Host that basically says “Please, execute action Attack with Alice on target Bob”. The Host will then verify the request and check if Alice is able to start this action (e.g. Alice is not sitting in jail currently and Bob can be attacked). If the request is valid, the Host will start the process of executing the attack. The first step in the process is to send Alice to run towards Bob. The Host will then broadcast to all Clients what has changed. The changes will list for example: “Alice now has an action Attack with target Bob. Alice is now running towards Bob.” As the action gets executed over time, the host will broadcast additional updates such as “Alice has reached her destination and is now standing at position X. Alice is now playing the animation punch. The hitpoints of Bob are now 20.”
So to sum it up, a Client sends requests to the Host that describe the actions that they wish to perform. The Host will validate the requests and inform all clients via broadcast messages which changes have occurred in the world.
There are two primary challenges for making the Multiplayer mode run stable and reliably. In the past, we have had many problems related to these two topics. And even now we are still struggling with them from time to time, since they are related to how the underlying networking system works in The Guild 3 and are very hard to solve completely.
In today’s DevDiary, we want to focus on the first issue, which is a very technical one. For Host and Client to be able to communicate effectively, they need to have a shared knowledge about which characters exist in the world. In the example above, they were sending messages about the characters Alice and Bob. For this to work, both have to have a list of all the characters that exist in the world. Both have to know that in the current world there exists Alice, Bob, Charly, Dave, etc. And this list can change because characters can die and new ones can be born. So at some point in time, the Host will need to send a message to all Clients that says: “There is a new character Eve. She stands at position X, has brown hair and is wearing a commoner’s garb (as well as all the other things there are to know about Eve).” Everyone needs to remember about Eve so that when a later message arrives that says “Eve has changed her clothes and is now wearing plate mail”, all the Clients know what to do and display Eve in the new piece of armor.
When things go wrong, it can happen that a Client has forgotten about Eve and does not know what needs to happen when a message mentions Eve. Depending on the case it can go unnoticed for a while, but in the worst case these situations can crash the game. Of course, this issue exists not only for characters, but also for buildings, trees, items and all the cog wheels that make The Guild 3 work.
This type of problem is notoriously hard to diagnose and fix. Usually, when we encounter a crash related to this, it is already too late to understand what went wrong. For example, imagine a crash that happens because a Client received a message that says “Alice is now running towards Eve” and the Client does not know who Eve is. To fix the issue we need to find out why the Client does not remember Eve and when they forgot about her. At the point in time when the game crashed, this can be hard to find out.
The most reliable tool we have to solve such issues are log files. In a log file, we can record a history of changes that happened in the game. Whenever a character dies or a new character is born, an entry is added to the log file. If we have a log file for such a game session that crashed, then we can look into the history and find out at what time Eve was forgotten. Based on that it is usually possible to find out where things went wrong and fix the bug. We have made good progress at finding and solving many of these issues, but from time to time we still find some, so our work is not fully done yet.
We hope this DevDiary gives you a rough idea how the Multiplayers mode works. In the next DevDiary we will continue with the Multiplayer topic and explain another issue that is difficult to solve. Stay tuned for part 2 in March!