Hello adventurers,
we hope you’re all having a great summer! 🌞
Since HotJoin remains our top priority and keeps us busy most of the time, we’re dedicating this DevLog to the feature itself and want to share some deeper insights with you:
Why do things sometimes take longer than they seem?
The It's easy, you just have to add XYZ phenomenon.
For HotJoin, we first had to find an approach that reliably works with our existing multiplayer architecture. We tried three different approaches—and only the third one turned out to be viable.
Starting point (Version 0.1.4)
Our game is split into multiple scenes. Before the refactor, there were essentially two: a Menu scene and a Game scene. For HotJoin to make sense, we wanted players to choose their skin and role before joining.
In 0.1.4, the lobby lived in the Menu scene. When everyone was ready, all players switched at the same time to the Game scene. The game waited for everyone because loading game-relevant data happens locally on each system. In the Game scene, we then loaded the network objects—everything the cats interact with.
First approach
Keep the scenes as in 0.1.4. The host sends the necessary information on request to late joining clients who want to join from the menu.
Result: Acceptable for one client. Multiple simultaneous joins led to synchronization errors between clients. On top of that, the amount of data we needed to send with this approach was too large 😥
Second approach
We added an additional Data scene containing all important network objects that clients need for HotJoin.
Result: Unfortunately, our multiplayer plugin synchronized all objects with the clients by default, which made a data scene pointless 🥲 While people were still in the lobby, you could already hear the rest of the group fighting evil badgers. The integration of Steam Friend Invites also showed that a Data scene alone would not be enough. We needed a different approach 🤔
Third approach (0.2.0)
We decoupled the Menu scene completely from the networking layer and moved skin and role selection into a separate Room scene. The required network objects can be preloaded there, and late joiners can fetch all the information they need for a consistent entry.
From approach two, we learned that while all objects are synchronized by default, you can disable synchronization for specific objects. In the room scene, we therefore only load the essential objects. Only when the countdown has expired do we synchronize the rest of the world, and the group or individual hot-joining clients switch to the game scene in a controlled manner.
Conclusion
With the new structure — Menu → Room scene (selection & warm-up) → Game scene — we were able to reduce waiting time by loading important objects before entering the room. We also now have a standardized entry path that we can target both via Steam Friend Invites and save games (everyone always loads into the room first) 🥳 As they say, hindsight is 20/20. If we had known right away what wouldn't work, we would have started with the third approach 😅
Okay, enough talk — time to put the final touches on HotJoin. You’ve been patient, and we can’t wait to get it into your hands very very soon 😲🥰🐯