Weekly Update – January 21, 2022

Two big features were completed this week: lighting and partial wall hiding. Both of these features affect what the player sees to produce a more authentic dungeon crawling experience. Finishing them feels great; they required a lot of brain power! 

  • Lighting (v0.95). Lighting now works as desired, mostly. With the ambient lighting, shadows, and illumination, the maps feel a lot more like dark and foreboding dungeons. It may be too much; I’m still tweaking brightness, colors, and distances to get the right balance of visibility. Also, the frame rate has taken a hit, so I will need to improve performance.
  • Added partial wall hiding. Now, the portions of walls that the player can’t see, for example the other side of a wall shared by two rooms, are hidden. This prevents players from knowing what’s on the other side of a wall. It also solves the problem of secret doors being too easy to spot.
Partial wall hiding
  • New test console features. Entities can be spawned in specific locations now (previously they spawned in a random cell adjacent to the player). Extended logging can now be enabled/disabled from the console. These features were added to speed up testing. I’m often using the console to spawn health potions – I need to have more of those drop in the game and/or do some more balancing.
  • Map generation bug fixes. Some objects, such as braziers, were being added under walls or next to doors.
  • Time-consuming animation bug fix. Occasionally, the player’s character would stop responding to player input and effectively bring the game to a halt. I used a new test console feature to view the game turn state and found that the game was stuck on an enemy actor’s turn. I added some breakpoints and found a clue: the actor’s state was stuck in attacking; the actor never received the event that’s fired when an attack animation finishes. That made some sense, because the attack animation wasn’t playing in the first place. I thought maybe it had to do with how I had configured the animation controller and transitions in Unity, or perhaps it was periodically skipping animation frames that fired events. There are plenty of reports of these types of issues in the Unity forums. Those turned out to be red herrings, though it took hours to realize that. The real cause was some code I recently introduced (mistake #1 – not reviewing recent code changes) that enable/disabled animations based on whether the actor could be seen by the player. I only added this functionality when the player moved to a new cell, but not when an actor moved to a new cell. So, if an actor moved from a cell the player couldn’t see to a cell that the player could see, the animator component was still disabled and the animation didn’t play. I solved this by moving the enable/disable logic into the actor visibility property (mistake #2 – implementing logic at too high of a level in the code instead of where the property changes).

Next week, I’m fine-tuning lighting and making some UI improvements. Now that there’s a lighting system, I want to add some more light sources like luminescent fungi and crystals, if I have time.

Leave a Reply

Your email address will not be published.