It’s monday again#

Hello everyone,

It has already been two weeks since I wrote my last blog post. So I’d like to tell you what I’ve been working on during that time.

In my last blog, I mentioned that I had started working on NPC behavior / AI. However, I couldn’t continue immediately because Wastl had some additional feature requests.

Here’s an overview of the requested features and changes:

  • The “Door” class was able to either load the player into another level or teleport them to another “Door” within the same level. It should now also be possible to actively select the travel destination via a GUI that opens when the player interacts with the door—for example, to simulate a taxi ride or traveling by another vehicle. Additionally, dialogue nodes should be able to unlock new travel destinations.
  • Wastl wants a signpost to provide immersive location hints for the player.
  • Animated objects: objects that either continuously play an animation or start playing one once the player interacts with them.

The “Door” Class#

I started by extending the door functionality. First, I designed the GUI. Wastl wanted it to look like the player is sitting inside a boat, car, or similar vehicle from a first-person perspective—depending on what they interact with.

In our test scene, the main vehicle is currently a boat. So I drew a boat from a first-person perspective. Since I was motivated, I also created additional UI elements. For example, our inventory is currently represented as an old-fashioned tablet. I added two hands holding the tablet, which significantly improved the overall UI feeling.

Implementing the logic was relatively straightforward. Unlocking travel destinations was also quick to implement.

After finishing the Door class changes, I moved on to the next feature: the signpost.

The Signpost#

At first, I wasn’t sure how to implement the signpost. Should a speech bubble appear when the player interacts with it? The issue would be limited space, requiring the descriptions to be displayed sequentially after pressing the action button. Or should I use a modal window?

In the end, I chose a solution similar to the Door class. When the player clicks the signpost, a first-person UI appears. The player sees a classic wooden signpost with arrow-shaped wooden signs nailed onto it, displaying location names.

Implementation#

I drew a wooden pole and wooden signs. The class simply receives a list of location names along with their directions (left, right, up, down). The signs are generated dynamically and automatically placed on the pole.

Goodbye Door Class#

Later, while designing the level, Wastl realized that we don’t actually have a real door in the game—which is ironic, considering we literally had a class named “Door.” The problem was that our Door class functioned more like a portal that teleports the player.

What we actually needed was an object that physically blocks a path and only stops blocking it once it has been “opened.”

Initially, I considered adding this logic to the Door class, but that would have made the code messy. Instead, I created a new class called “Barrier” and reused much of the logic from the Door class.

I named it “Barrier” because not only doors can block paths—large objects like a massive rock or a fallen tree after a storm could do the same. I also renamed the “Door” class to “Portal,” since that term better reflects its functionality.

Eventually, I forced myself to refactor the code. Both classes shared too much logic—about 60% of the Barrier class was copy-pasted from the old Door class.

So I introduced a new base class called “Gate.” All shared functionality was moved into this base class. “Barrier” and “Portal” now inherit from “Gate” and share the common behavior.

The animated objects feature was implemented quickly, so there’s not much to say about that.

NPC AI#

Today, I finally finished implementing what I mentioned in my last blog post: NPC AI / patrolling—at least the core mechanics.

You can define areas where an NPC patrols from one PatrolNode to the next. Pathfinding is not used within a single area. It is only triggered when an area change occurs due to a predefined in-game time condition, at which point pathfinding navigates the NPC to the next area.

This currently works surprisingly well. However, I still need to test it with multiple NPCs. Collision handling between NPCs has not yet been implemented.

The patrol groups, which act as containers for areas, are also functional. During initialization, the system checks which group is active. Currently, you can define in which months and on which weekdays a group is active. However, dynamic switching between groups is not yet implemented.

My next step is to implement a developer console for cheat commands so I can modify the in-game time, day, or month via command input.

I hope you enjoyed this dev log entry.

Best regards,
Nflaus