Course of Temptation Dev Diary #126 (Patreon)

Hello friends! Vacation is over, and I've been back at work this week.

Our current version is 0.8.0i, which I think might be up there with the most bugfix updates we've ever had for one content update. We've fixed hundreds of bugs in the past month, which I think may be a new record as well. There were many issues with the new systems, of course, though all told it wasn't really that bad — I've certainly had rougher update launches — and many issues were older, simply found as a result of having more eyes on the game this month.

So I want to thank everyone who has diligently reported the issues they've found! I know it can be a pain, going to the Discord, typing out your issue, attaching your save, so I really appreciate everyone who takes the time to do it. I appreciate everyone's patience as we address the issues that get found. I pay attention to every bug report, and everything I haven't fixed yet is generally because I haven't been able to yet, because I couldn't reproduce it or didn't have enough information.

All of that is to say... the current version is, I think, quite stable, but certainly there are still some issues to be found, and some lingering ones we haven't solved yet. So please keep reporting your bugs, and remember to please provide a save if at all possible — having that easily reproducible case helps unimaginably. As it is, I think this current version will hold until the July update.

Which is, of course, coming right up! Bugs have still occupied a good portion of my attention, but as said above, we're beginning to stabilize, so I've had time to work on new things as well. Specifically, I've completed some extensions regarding turnons and turnoffs that have long been requested:

With cheats enabled, you can now edit an NPC's turnons and turnoffs. If there's an NPC you just really want to be attracted to you... well, here you go!

In the process of this, I've also established a way for NPCs to have static turnons/turnoffs (as opposed to always being procedurally generated, which they were before), which means that perhaps the background simulation system can start affecting them. Perhaps some event makes an NPC acquire a turnon that matches the PC? I'll have to give some thought to what this could look like and how to keep it realistic. And if you have any ideas, let me know!

Speaking of procedurally generated turnons, I also addressed something which, while functional, was a bit of a longstanding issue: NPCs might generate with turnons that had nothing to do with their orientation. For example, a straight girl might have the "big tits" turnon. I didn't really consider this broken, as they still impacted how much that NPC liked the player and therefore could have a mechanical effect regardless, but on balance, I think it made more sense to fix this.

Then, as a somewhat larger project, I've also refactored how player turnons and turnoffs work:

A few things to notice here. First of all, the limit of five each of turnons and turnoffs is gone! You can select as many as you want.

Next to each selected turnon/turnoff is now a priority that you can cycle through: "important" gives it a normal impact on an NPC's perceived attractiveness, while "not important" gives it a lesser impact and "very important" a greater one. These are all added up and scaled to "score" an NPC. For the purposes of attractiveness, this score is normalized between -5 and 5, and from there it works as before.

There are also two special priorities. A turnon can be a "must-have," which is slightly more valuable than "very important" in terms of score, but more importantly, it means any NPC who lacks your must-have can never be found attractive. They're not necessarily unattractive either, but they're unlikely to become crush targets or anything like that.

For turnoffs, the equivalent priority is "dealbreaker." Any NPC possessing a dealbreaker turnoff will immediately be found maximally unattractive, short-circuiting all other turnon/turnoff scoring.

Scoring also takes into account what's actually possible. For example, if your PC loves "big tits" but also likes cis men, the men won't be scored lower for lacking that turnon.

This refactor also solves the problem of the PC never finding an NPC hot unless they take at least four turnons. Since the score is now normalized and compared to what's actually possible, one or two turnons can be sufficient to find an NPC hot, especially if they're high priority ones. The counter to this is now a deliberate design decision: if you have only mild likes or dislikes, your character's reaction to any NPC will be muted at best, avoiding the opposite problem of finding a third of the population utterly hot because they match your one mild preference for blonde hair.

All of this should make it much easier to control what kind of characters your PC finds attractive and ends up crushing on! I'm also thinking of tweaking the person picker algorithm to slightly prefer NPCs that match your preferences, though that has some optimization concerns so it may take a bit of tinkering.

Somewhat less glamorously, I've also done some work on the main algorithm for the background NPC simulation. I don't recall if I've explained this before, but it works like this: once per day, the simulation assembles a list of possible events based on the conditions of the world, and since each simulation event is based around a primary NPC, it also has to find an NPC matching certain conditions. More important events are prioritized (we don't want an NPC skipping finding out they're pregnant because their sim event that day was an Elkbook post), and some sim events are allowed to have multiple instances in one day.

That's fine as far as it goes, but some events also need pairs of NPCs, such as the one where two NPCs become friends. Previously, this would first find an NPC who was ready to be friends with somebody, and then pick a second NPC who was close to them who was also ready to be friends. If no such second NPC existed, well, then the entire event was discarded for the day rather than attempting to find a different primary NPC. This is not ideal, but not a disaster either: we would find a valid pair eventually, so it effectively just made sim events more random than intended, and more rare than they should be in a way that's difficult to predict or analyze.

Now, my solution to this isn't particularly fancy: we now just have another innermost loop where the algorithm is allowed to make multiple attempts at finding paired NPCs, performing instantly what previously required successive days to play out. The end result is that it should mostly succeed in finding pairs when they exist and execute at least one instance of the event rather than discarding it, making events involving multiple NPCs more frequent and more reliable. In testing, I didn't see much of a hit to optimization for doing this.

For the time remaining in the week, I want to begin to tackle the Soft Dom and Brat inclinations. Pre-0.8 content generally isn't taking these into account, so we'll need new dialogue lines, new event branches, and ideally whole new events just for them. The early access changelog may be a bit short initially, but I'll be going through my post-0.8 todo list and starting to check things off, and everything I get done before the 7th will be added to early access as I do it.

So, that's where we are! Again, I greatly appreciate your support, and it really does mean a lot, to this project and to me personally. You will hear from me again as we push the July update into early access, and until then, I hope you have a good weekend!