Thank you for checking out my third devlog for Torches & Treasures! We're starting to get into some more in depth game mechanics as progress continues. This past week I've been focusing on dungeon access. Specifically a Door and Key system. I want this system to be modular and also expandable while maintaining flexibility. Remember my motto has been "Simplicity is key" pun not intended.  I also need to determine which parts of this system needs to be networked across all clients and then implement
that logic.

Doors - Syncd

I implemented a networked door system  which ensures that when one player opens a door, it reflects that change across all connected clients. The system is built around a door script that handles both the opening animation and the networking logic. First, I created the base door functionality, where the door starts in a closed position and rotates to an open position when the player presses F while inside a trigger zone. The rotation is handled with a smooth Quaternion.Lerp() animation to make the door swing open naturally.

To synchronize this behavior across the network, I added Mirror's [Command] and [ClientRpc] methods. When a player presses F, the script calls a Command method that runs on the server. Since any client can trigger this, I added requiresAuthority = false to allow non-host players to activate the door. The Command method assigns authority to the player who opened the door, ensuring they control its state. Once the server confirms the door should open, it broadcasts RpcOpenDoor() to all clients, which triggers the OpenDoor() coroutine to animate the door for everyone.

Key System

This system allows players to unlock and open doors based on their inventory and the required keys. It's a crucial feature for creating a more immersive world where progress is tied to exploration and item collection.

The Problem:

I needed a way to make doors interactive while ensuring that players could only open certain doors if they had a specific key. If no key is required, the door should be unlocked by default and be accessible to all players. The challenge was making this system both flexible and intuitive, ensuring that the doors could easily be unlocked or locked depending on whether a key was set.

Solution:

The core idea was to create a key system where each door could be associated with a specific key identified by an ID. If the player has the corresponding key in their inventory, they can open the door. If no key is required (i.e., the requiredKeyID is empty), the door would automatically be unlocked and accessible to the player.

Each door has a requiredKeyID, which corresponds to a unique key required to open it. If no key is specified (i.e., requiredKeyID is empty), we assume the door is unlocked by default. The requiredKeyID is the key that must be in the player’s inventory for them to interact with the door. If the key is missing, the door will not open.

For the key item I added a keyID property to my Item class and also added the new type to Itemtype class. This way we can properly register and use the key item with our doors.



First we test the default unlocked door without a key, then the locked door with and without key in our inventory. Everything works as designed! The only syncing we need to do here is on the inventory side. We want any objects which have been picked up to reflect across all clients.

More Map Rooms

I made two more rooms for my first map. A small Sanctuary room and hallway. 

The sanctuary room will be used for healing players before a big battle. The idea is to make these types of rooms  a one time use for healing.  These rooms can also be hidden from players, or have an obstructed entrance requiring players to find an alternative means to enter, such as breaking down the wall or finding a passage way. 

The hallway is pretty basic and I attached an end room because why not? I can always remove it after placement if its not needed for that application. 

New Title Screen

Created a new 3d title screen scene with two playable heros sitting at campfire. The context is that typically the Rogue is leading the way and knows a dungeon well enough. Here he seems to be near incapacitated so the brave but not so quick witted Knight is charged with navigating the dungeon and looks on at his map.

Up ahead

What about other ways to lock and unlock doors? We can do some sort of switchable lock/unlock method. Someone stands on a stone tile, it unlocks or opens a door. Open by objective is another method. Implementing a health system and traps. Implementing harmful zone effects. These are things I am working on now.