Entry 40 - Multiplayer. Synchronization of Base

In this post, I'll talk about the most difficult task I had to implement: synchronization of the base. This synchronization included building/moving constructions, crafting items with bare hands and on tables, growing and gathering plants, feeding and controlling animals, and interactions with ghosts.

The difficulty here was in a wide variety of closely intertwined mechanics. Synchronization of all these processes had to be done very carefully so as not to break anything. There were significant changes of code and - in order to make sure everything works correctly - I gradually uploaded these changes to Steam (I combined such changes of the mechanic with small updates and with new decorations). Because these changes can potentially break the game, I always try to update in the morning and regularly check the mail/Discord/forum in Steam during the day to see if there are bug reports. On several occasions, there were some bugs indeed, but they were quickly detected and fixed.

Constructions

As I wrote earlier, for multiplayer I had to make virtual images of all locations in order to be able to synchronize environmental objects between players if the players are in different locations. But I didn't have to do this for buildings, because such a scheme has already been implemented for them. Even in singleplayer, ghosts can work with some constructions while the player is traveling around the world, so I needed these buildings to be in memory all the time.

Therefore, data on everything built by the player (i.e. position, state, items inside, etc.) is constantly stored in the computer's memory within virtual copies of all constructions. This data storage architecture turned out to be very useful when implementing multiplayer. Because the image of each building is already in memory (even if the location itself with this construction is not loaded now), and each construction has an unique ID, this greatly facilitates synchronization; everything works exactly the same way as with the objects of the environment (bushes, stones, and items on the ground). The only difference is that, instead of virtual worlds made specifically for synchronizing environmental objects, I use virtual worlds made for ghosts. Therefore, the opening/closing of windows and doors, changing the mannequin's poses, and the inscriptions on signs and portals were all implemented quite quickly.

Chests and other storage units caused far more trouble. I had to significantly refine the system of resolving collisions between players' actions to avoid, for example, such situations: several players simultaneously click on an apple in the chest and it goes into everyone's inventory. Now, this system can also resolve conflicts of territories. For example, if two players want to build a construct on the same piece of land at the same time.

Crafting and building

All crafting takes place on the server computer. Clients process only their own manual crafting. Everything that happens on the tables, building of new constructions, growth of plants on seedbeds, etc. is processed by the server. I had to completely redo the way of measuring time intervals for crafting. In singleplayer, when we teleport between worlds, the whole game is paused; time stops and all crafting freezes. In multiplayer, this behavior is unacceptable because if the server player teleports to another world and is currently loading another location, other players should still see that crafting on the table continues. There was also a lot of work with resolution of conflicts. Conflict resolution was especially difficult when using tables with built-in storages and when planting on seedbeds with the use of fertilizers that lie in a fertilizer storage. The difficulty here is that one player can start crafting from items that are on the table and, at this moment, another player can take some resources from this table into their own inventory. Additionally, if one player plants flora with fertilizers then the other player takes these fertilizers from the storage. These tasks are not very difficult, but I had to think a lot on taking these possible scenarios into account.

These two videos demonstrate the synchronization of using constructions, crafting, and building:

Feeding animals and controlling ghosts

Synchronization of feeding animals was even more difficult, especially automatic feeding when the animal itself eats from the trough. In addition to resolving all possible conflicts with the animal itself and the trough's inventory, I had to take into account the ability of the animal to reach the trough. Troughs are designed in such a way that if animals don't have direct access to them, they will not be able to take food from there. And again, this becomes a problem if the server player is in another location. In singleplayer this was not a problem; the availability of the trough could not change while the player was in another location. Therefore, when the player changed the location, each animal simply remembered the list of troughs to which it has access. In multiplayer, availability can change. While the server is fighting monsters somewhere in the swamps, the client can open some gates and make the trough available. All such moments require additional synchronization.

Ghosts had the apotheosis of various mechanics interweaving; their synchronization was the most difficult moment in the whole game. Ghosts are characters, so their animations and position need to be synchronized. They also participate in crafting, they can be controlled, you can talk to them, they have their own settings (priority of work), they can interact with the story and progress, have scenario items in the pouch, etc. Ghosts are the only characters in the game, besides the main character, who can move around locations. Individually, these tasks would not be difficult, but here they all occur in one character. Therefore, when synchronizing each individual ability of the ghost, I had to keep all of their other abilities in mind so that everything worked smoothly. All of this took about two weeks and a lot of my nerves.

Now, the good news. The list of tasks I gave earlier has already been fully implemented. The last thing added to it was the synchronization of monsters, bosses, scenario events, and the magic sphere. There is still one point I forgot to include in the list initially: synchronization of the minimap. In addition, I'm going to record a new trailer that demonstrates multiplayer capabilities. The game will need to be thoroughly tested and perhaps its balance will be slightly changed for several players.