Course of Temptation Dev Diary #116 (Patreon)

Hello friends! It's Friday dev diary time.

We're currently on version 0.7.7h, with some bugfix updates having gone out through the week. If you're not current, it's a good idea to update!

Secondly, apologies if you experienced a somewhat rough update launch on Saturday. Friday was a long marathon session where I was getting the new art creation systems into shape ("the last 20% takes 80% of the effort" rule strikes again), with the result that the Saturday update contained a lot of hot code. It was mostly sorted out within 24 hours, but even so, that isn't how I like things to go. The lesson for me here is to try to manage my time better with these updates.

But, moving on, I've been doing work on 0.8 this week. This has been in the works for a while, and my general goal for this month is to rein in scope and get myself on the home stretch so I can deliver this before too much longer. I'll likely dedicate next week's dev diary to an accounting of where the update is now and how much is left to do.

In the meantime, I've been working on finishing up the NPC-to-NPC relationship simulation. Building up relationships (romantic ones as well as friends and rivals) has been done for a while, but romantic relationships call for more simulation — rough patches, fights, cheating, and breakups. A lot of players have asked for the experience of breaking up NPC couples or getting them to cheat and having that affect the relationship, so it's important.

Now, in building up relationships I relied on something called the "NPC association factor." This comes from an algorithm that considers mostly demographic type information for two NPCs, like what major cohort they're from (student, townie, or faculty), which archetype they are, where they work, and so on, and returns a value between 0 and 1. This value is basically meant to reflect how much you'd expect their social circles to overlap. Originally conceived for the sole purpose of determining which NPCs would be sitting together at dining halls and the River Rat, it serves as a rough approximation of how likely two NPCs are to encounter each other day to day.

The problem is I was leaning on this a bit too much for the simulation. For example, friendship might require an association factor of 0.4, while a romantic relationship requires 0.6. But conceptually, this doesn't really make much sense — whether two NPCs run into each other a lot doesn't correlate with how much they like each other once they've met.

Also, when it comes to rough patches and breakups, what then? Nothing really causes association factor to ever drop, so that no longer factors into the simulation at this stage. It could be just random chance, but seeing a perfect couple fall apart because of pure RNG, or seeing an unsuited couple last forever, isn't very satisfying. Some other value is required to make sense of where a relationship is going.

I hit on the concept of a relationship health value — all couples fight sooner or later, and you can envision that as dropping the health of the relationship. But if their relationship is otherwise strong, they talk it out and make up, repairing the relationship. Or maybe they're just not that stable as a couple, so they keep fighting, relationship health keeps dropping, and then they break up. And this can be used similarly in non-romantic relationships too.

For clarity, I've created this graph using the latest data visualization technologies:

That's all fine, but now we've got the problem of storing thousands (NPC count x NPC count) of relationship health values, and the overhead of tracking lots of events that keep these values fluctuating. But this problem can be solved... and all we have to do is invert causality.

See, whether the player witnesses an argument between two NPCs that causes their relationship health to drop, or whether dropping relationship health spawns an argument event that the player can witness... it looks exactly the same to the player. But one of those is a complex system with a lot of overhead, and the other is relatively simple. You might even say it's... simplex. Well, you definitely wouldn't, but what I'm trying to say is I used simplex noise.

Semi-random events that drive a health value up and down will, over time, make the health value look like noise, and another thing that looks like noise is noise, so why not start there? I first implemented simplex noise into the project a few updates back to simulate weather, which is a system where you want relatively smooth long term trends and some shorter term jitter, and this is the same.

Rather than storing a relationship health value, we algorithmically determine the current day's health value. Tomorrow's health value will always look relatively similar to today's, but over time, highs and lows emerge. By flagging the inflection points, we can simulate a relationship's rough patches. We also want a bias factor: some couples are just more stable than others, and by looking at the NPC association factor and assessing inclination compatibility, we can come up with variation over time that should ring true.

As the keen-eyed will see, there's also an amplitude value which I'll expose to the player as a slider. Call it the drama slider. Greater amplitude means bigger swings, and hitting inflection points is more likely. A lower amplitude will tend to keep relationships stable.

So, that's been my project for this week! The relationship health algorithm itself was actually very quick to write — as you can see, it's not a long method — and most of the work has been adding simulation events at the inflection points and writing content around that. This is important for more than just flavor, too, as a rough patch can prime an NPC to be willing to cheat, so if you're looking to break somebody up... that's your chance!

As you can see, I do still need to add in the inclination compatibility factor, but that isn't a huge project and I'll get it in there before the week is through. In fact, by next week I should be able to move on to other 0.8 tasks with the relationship simulator complete enough for now.

Anyway, we got pretty deep into programming stuff this week, so I'll leave it there before I ramble even more. Thank you for reading, and I hope you found it interesting. And as always... thank you for your generous support, it means a lot! Please have a good weekend and I will be back next Friday with another dev diary.