Book of Travels
Book of Travels is an game by Might & Delight, it is an RPG game with focus on multiplayer interaction.
I had a 8 months internship at Might & Delight and which I am currently now working at. I am working as a Generalist Programmer and I have delved into many different components in the game. The game is setup with third party Mirror component for all the network interactions.
I have been fixing up current systems to make them work synchronous between Client & Server. Weather, Transportation & Grouping.
But also just overall fixes of gameplay, audio and interactions elements.
Trailer on the reveal date of Book of Travels.
I have been tasked with doing several fixes for the weather system.
We had issues of NPCs not taking out their umbrella during heavy rain. Players got affected by the rain and sometimes not at all, and also weather particles wasn't synced properly between the server and clients.
The focus I did here was what information is being sent and how is it pinged between players and NPCs. I was carefully setting the ping only when neccessary to avoid over consumption of messages to the server.
A player with permission can change weather using the debug menu, in which calls the server to change the weather, and then it will accordingly send a message back to all other NPCS & Player Clients to react and set: Day & Weather Status.
I was leading the death feature, the dying mechanic is a feature that involves being able to enter the spirit realm in the same world but with a whole different look and feel. You will be able to meet unique NPCs and explore different unlockable interactions and more are on the way.
There were several things to take in to consideration when developing it. Ghosts should not be able to interact with alive NPCs, effects need to be removed or hidden, almost all interactions are going to be disabled and weather/particles need to be changed based only on the client in this state.
Trailer for the Death Feature for Book of Travels
I did improve our weather system that can now take in different templates based in a dying state. That would control particles and fog based on timing variables.
The lighting system were also improved so that we can have different lighting during Day/Night and in which you can set different LUT files at those time of day to have more power to adjust the colors.
For interactions I am using one function to check all the valid interactions and in which we can hinder the player to interact with certain things. Effects needed some adjustment as well, we have several effects that we do not want to disappear that would return when you revive so had to make logic to have those saved.
The death state is recognized by adding an effect to the player that is invisible, this is added/removed during loading times when the death/revive transition happens.
Endeavours in the game is multiplayer interactions that players can interact with. You can describe it as a small task that you can stumble upon and multiple people can interact with it to finish it.
We had issues of endeavours not syncing properly, audio looping, they were sometimes non-interactable. Problem was that much of the disruptive behaviour from clicking on it was caused by mutliple calls on same function on different places. We also sent interaction logic to non-local players which would confuse the system.
Interacting with an endeavour that syncs, opens up and plays the correct sound with two people interacting with it.
The solution was to go through step by step starting from the click on interactable button, that starts the player's statemachine interaction. Figure out what information should be sent to the local player's client and what should the server know and how it should react.
We also had variables that wasn't synced at the correct time when it was created/solved. Is the endeavour connected to an NPC? Then the NPC should be properly spawned and then create the endeavour and hook it up.
Many sync issues was fixed with doing a synclist that synced all variables at the same time when the endeavour was created/updated.
In the game we have vehicles that player can aboard both Trains and Boats, these are vehicles that the server calculate and sends needed information to the clients.
Several problems with this was that the player got teleported away from boats just before reaching the destination. Players could get stuck on trains and even disappear when switching levels.
We are updating vehicles on the server, and I noticed that the vehicles on the server sometimes reached the destination before the clients did, this resulted in the server trying to set the player to the navmesh which then tried to sync this to the client causing an error teleportation to the middle of the level.
Two player interacting with a vehicle and syncing properly without erroneous behaviours.
This navmesh sync is not really needed, I set it up so that when the client leaves the vehicle we set a sync instead.
Other issues among vehicles is figured out by understanding how the server interprets when to switch level to the clients, when and how. The level switch to the client should behave differently setting the player to an vehicle and should switch to it accordingly.