Witch Hunted Devlog #3 - Procedural Generation & Player Needs

Hey again, thanks for reading! This week, I ended up working on the procedural forest a little more even though I said I wouldn’t, but I also made significant progress on player stats and a placeholder UI for them. Below is a detailed breakdown of the technical aspects of these implementations.

Refining Procedural Generation: Halls and Rooms

Why I Implemented Room-Based Generation

Previously, the forest relied on a random walker algorithm, which created an organic, cave-like layout. While this approach worked well for natural-looking environments, I wanted to experiment with a more structured procedural style, adding hallways and rooms to see how it would impact navigation and overall level design. This experiment also gave me a foundation to test different room styles and layouts for potential future enhancements.

How the System Works

To make structured layouts possible, I introduced an enum that allows switching between different procedural generation styles. Instead of the walker moving randomly in all directions, the new system constrains movement to a chosen direction for a set distance before changing paths. This change ensures that corridors feel intentional rather than purely random.

Rooms are generated at key points—either when a hallway stops or changes direction. The size of each room is randomized but follows constraints to maintain a balanced layout. The implementation uses a nested loop system to carve rooms into the grid, ensuring that every new hallway connects seamlessly with the explorable space.

Experimenting with Different Room Types

One of the main reasons I implemented this system was to experiment with different styles of room generation. While the current system creates rooms of varying sizes in a relatively uniform manner, I want to refine it further. In the future, I might develop a custom variation of the algorithm that prioritizes certain types of rooms based on environmental factors, allowing for more curated procedural generation.

Optimizations & Enhancements

To make the system more efficient and modular, I extracted frequently used logic into dedicated functions:

• Random room generation
• Hallway extension and connectivity checks
• Floor list validation to prevent overlapping rooms

Additionally, I implemented probability-based room placement, allowing rooms to spawn with varied densities instead of appearing at every turn. I also added an optional winding hallway mechanic, where some corridors continue uninterrupted instead of always leading to a room, adding variety to the generated maps. By adjusting these probabilities, I can fine-tune how structured or open-ended the forest feels.

Implementing Player Stats & UI

Player Needs System

After refining the procedural generation, I moved on to implementing a player needs system and a placeholder UI to track stats. Since the game features both a normal mode (which tracks health and magic) and a hard mode (which adds hunger and stamina), I structured the system to be flexible and modular.

I created a PlayerNeeds script that manages core attributes using a Need class, which includes:

• curValue – The current value of the stat.
• maxValue – The maximum possible value.
• startValue – The initial value when the game starts.
• regenRate – How quickly the stat regenerates over time.
• decayRate – How fast the stat depletes.
• UI Bar Reference – A connection to the corresponding visual element in the UI.

How Stats Behave in Game

Each stat updates dynamically based on player actions. For example:

• Health decays if hunger or stamina reach zero (hard mode only).
• Time.deltaTime is used to ensure gradual depletion instead of abrupt drops.
• Mathf.Min() and Mathf.Max() enforce logical limits on stat values.

Since survival mechanics play a role in the game, I designed the system to allow needs to interact—meaning that letting one stat drop too low can have cascading effects on others.

UI Implementation

To visualize player stats, I set up bar indicators that dynamically adjust based on the player's current values. These bars update in real-time using Unity’s UI Image fill amount property, ensuring smooth visual transitions when stats change.

Since my game is 2D, I avoided 3D-specific UI methods from the tutorial I referenced, ensuring that the UI integrates well with my existing canvas-based setup.

Next Steps

Now that the procedural generation and player stats systems are functional, my next focus will be inventory management and object interactions. This will involve:

• Item pickups/interactions – Allowing players to interact with, collect and store objects.
• Integrating the needs system – Items like food or potions will restore specific stats.
• Environmental interactions – Implementing interactable objects such as doors, chests, and other world elements.

That’s it for this update! Next time, I’ll share progress on inventory handling, item interactions, and further refinements.