Developer Diary Week 8 – NPC Conversations, Overtime, Test Scene Setup

Another week is done, so I'm here with another update! Last week, I set a few goals, some of which I met, and some of which I ended up scrapping due to lack of use. Notably, I scrapped the degrading affinity feature each day the player doesn’t talk to an NPC. The other two goals; overtime minutes and NPC-NPC conversation, I did implement however, as well as a few other key tasks! Overall, I managed to get a lot done in terms of the project’s stability and presentation, as well as the integration of a few new features.

I tried to keep my goals for this week small compared to previous weekly goals, since I anticipated a lot of this week would be bug-fixing. The NPC-initiated conversation behavior ended up introducing a lot of room for error, so I wanted to spend enough time taking a fuller look back at it and problems it may have introduced in the larger project.

So to start, I made note of a variety of bugs I had noticed the prior week, and did some experimentation to look for more. There were quite a few, and I managed to resolve those I noticed. These bug fixes included the following:

1. Extra response is no longer generated at the end of NPC-Player interaction.

2. NPCs go to bed if they reach bedtime in the middle of the conversation.

3. NPCs can not start talking to the player if they are already in a conversation.

4. Affinity is adjusted appropriately when talking about coworkers.

5. NPCs no longer keep talking when low energy or bad mood.

6. NPCs no longer keep playing talking animation while going to work

7. NPCs no longer initiate conversation if their player affinity is in the low region.

After addressing these fixes, I moved on to fully implementing NPC-initiated conversation with other NPCs. As I mentioned in my last blog post, I wanted to implement a different style of conversation when they’re talking to another NPC versus talking to the player. In the case of NPC interaction, instead of generating a certain number of responses, NPCS will stay in the talking state for a certain period of time. They talk to each other until this period is exceeded, or one or both villagers can no longer talk. This is actually fairly similar to the hobby system, and I had performed a first pass at it when experimenting the previous week. As a result, it actually took much less time to implement than the prior bug fixing.

As shown in the video above, this week wrapped up the full implementation! For now, the villagers do not gain or lose affinity with each other, so this is primarily to add a more realistic element to their behavior. Instead of ignoring each other entirely, they can now appear to talk to each other in the world, which while mainly cosmetic, adds another element of randomness.

The next behavior I worked on was overtime. As I had outlined the previous week, I wanted to implement this as minutes in overtime that a villager needs to work whenever they are within the job’s active period and not in the Working state.

The OvertimeMinutes size_t variable, which I added to the BasicVillager class, is incremented each minute spent not working. It is zeroed once the villager stops work for the day. Up to this point, it is simply incremented on each minute-triggered Job check where the villager is in a state that isn’t working. This was just as simple as it sounded, which I wasn’t fully expecting. I spent a lot of time playing with the system, and noted that even trying to break it, I wasn’t able to. This was a very welcome change from previous system implementations!

But just using this to adjust the time spent working didn’t seem engaging enough. As mentioned last week, I tied special behavior to any villager that is working past the anticipated end of the job due to overtime. During this period, they receive a random negative mood addition, as well as a random positive mood reduction for each minute spent working.

With that, all of the major features I planned to implement within the system were now in! That is, there are no wholly new systems that I planned on implementing to adjust NPC behavior. Of course, my work wasn’t done. I still had a lot of things to work on, which I started on this week. I wanted to focus on making the system as easy to use and well-documented as possible. Additionally, I wanted to finish adding villagers that made use of the full extent of models, personalities, animations, and careers that I had defined for the demo scene.

On that note, I started by going through my largest file, that for the villagers themselves, organizing different sections and variables that I had added. This took a surprising amount of time, but overall, it made it much cleaner to navigate! I think it will greatly benefit users who want to dive in and create new behaviors, so it had to be an essential part of my work. While I intended to create self-documenting code through the use of good naming conventions, I don’t want to solely rely on this to explain my thought process. Documentation and good use of whitespace is something I commonly feel becomes a problem when looking at other people’s codebases. It’s not easy to maintain readability as a codebase grows larger and larger, but I feel as though it would be incredibly negligent of me to be aware of the issue without doing anything to resolve it in my own codebase.

Moving out of the code, I started performing setup for all the villagers within the larger demonstration. I started this by creating 8 new villager animation blueprints, in addition to Viola and Lucia. Some of the animations, due to the sole number of them, I had forgotten to port to all the models I planned to use. This meant I needed to spend some time getting each animation applied to all of the new skeletons. It was a bit of a repetitive process, but I’m glad it’s all done now!

After that, I was able to create all 10 villagers. As I had anticipated, it wasn’t difficult due to the blocks I had defined! I made folders for each villager and their unique block and actor data.

Along with these villagers, I did a bit of “redecorating” in the test scene! I wanted a layout that made a bit more sense instead of having some hobby spots haphazardly thrown around. While they don’t have proper models, I added a few differently sized and placed spaces that made sense based on what hobby should take place. They go around the outside of the mock village, with workplaces mostly in the center area. The beds are all in their own separate section as well, with a sort of hut surrounding each. I think this will make it a bit easier to tell what’s going on in the scene with as little explanation as possible.

At the end of this week, the project is getting close to being in a much more presentable state. But I still have some work to do in terms of usability, as well as a LOT of testing to make sure I’m not missing any major bugs. I already noticed a few just when integrating the fuller village, so I know I have my work cut out for me in that regard!

For this project, part of what aiding usability entails is the creation of an additional application that allows the user to make NPCs in an incredibly easy and fast way. While the villager creation currently doesn’t require a lot of steps, I don’t want the user to have to go through this process each time. Additionally, with a lot of these blocks being links to actors, it is an occasionally error-prone process. I’d like to find a way to maintain a link between them more easily in a way that doesn’t require the user to always manually establish it.

Instead, I’d like to create an additional application to go along, a different kind of executable within the project, which works as a sort of “Character Creator”. In this mode, users can focus on creating the exact NPC they want in a more accessible, drag and drop mode that lets them easily choose from defined hobbies, personalities, and jobs to customize all attributes at once. They would also be able to enter the NPC’s name and gift preferences. After wrapping up this creation process, the villager and their components should be exported to a new folder as a game object that can be dropped within the scene.

This is something I have never experimented with doing before, and I anticipate it will take me quite a bit of time to execute the way I plan. The majority of next week is thus going to be focused on looking into and implementing this system specifically. If I manage to get it done next week with time to spare, I’ll continue with the external file input for NPC dialog, which I would still like to complete if possible. Finally, I’ll devote some more time to some much-needed bug fixing.

I hope you enjoyed this update! Again, I’d like to encourage you to check out the project’s repository at the GitHub link below if you want to play around with the system yourself. I’m excited to see it coming together so well this week, and think this is a great time to jump in to seeing how it works. Regardless, I hope you will look forward to next week’s update as well! Thank you for reading!

GitHub Link: https://github.com/grist-maker/NPCVillagers