Entry 35 - Multiplayer

Preparation

The first thing to do when planning multiplayer was to formulate the basic requirements for the result. To transfer packets between players, I again (as in the first part of the game) wanted to operate with the tools provided by Steam. This would allow me not to use dedicated servers or white IP from one of the players. Also, as I wrote earlier, I want to give players complete freedom regardless from each other to move around the game world. This possibility was absent in the first part - it was done for reasons of saving time on development, but negatively affected on gameplay. The main difficulty here is that the world is divided into several locations, which are loaded separately. When exiting a location, the game saves to disk all the changes that occurred in that location while the hero was there, and then unloads the location from memory to free up resources for a new one.

But imagine such situation: there is player 1 (server) and player 2. Player 2 goes to another location and starts to cut down trees there. But suddenly his Internet connection breaks, and he disconnects. Player 1 himself goes to that location, and he should see that trees have been cut down. But who and when will send him information that there are no more trees? The connection with player 2 has already been lost, and at the moment when he was chopping down these trees, the entire location was unloaded from player 1's memory and he didn't know anything about what kind of trees there are at all. 

It turns out that in a network game, the server (player who started the game) must continue to receive changes about the unloaded locations if other players are there. To solve this problem, the server stores simplified virtual representations of all locations, and in real time synchronizes them with real objects that other players see on their screen. Such implicit interaction between players makes it impossible to use third-party ready-made solutions that are available in Unity store, so I decided to write all the network code myself. But it's OK, I already have enough experience! In addition, the code written specifically for the game can be significantly optimized, unlike universal ready-made solutions.

What is already done

 Completed tasks:

• Lobby (the place where players gather in a team to play together)
• Starting the game and setting up the connection between the players
• Auxiliary tools
• Synchronization of heroes (equipment, position, animations)
• Interaction with the environment
• Jumping between worlds
• Synchronization of audio and video effects

The last point is what has been done since I posted the previous post, so here is a new video that demonstrates these possibilities:

What I still have to do

• Synchronization of constructions (2 weeks)
• Synchronization of crafting and building (1 week)
• Synchronization of monsters (2 weeks)
• Synchronization of quests and scenario events (2 weeks)
• Testing (2 weeks)

(Time estimates are approximate)

I will tell you more about these tasks in the future posts. Also I'll write about all the difficulties I faced and how I solved them. You may notice that more than half of the tasks are already done. In addition, there are many purely technical tasks among the ready ones. Such tasks are more difficult, because there is a lot of work, which remains behind the scenes and does not lead to any visible changes. When you write code for 2 weeks, and nothing changes visually in the game - it starts to depress, motivation decreases, and work begins to go slower. But almost all such tasks are already behind. 

What do we have now? As you can see, there is still about 9 weeks of work left. In each new post I'll indicate at what stage the development is at the moment. If everything goes smoothly, there is a chance that multiplayer will be released before the end of this year. However, the more realistic prospect is that it will be released in January.