Repeated intro
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.
What changed
0 fixes2 additions0 changes0 removals
addedNow, 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.”
addedIn 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
The Guild 3 changes
addedNow, 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.”
addedIn 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
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.
Ongoing challenges 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
