Devlog: This week's work!

Hello everyone!

If you are a patron or boost our Discord, you already have access to seeing, in real time, every time we push new work to our GitHub:

So, you might already be aware of our little experiments with Unreal 5.8, which will only become our main branch once we are further along with our current plan, since that engine version will speed up our level design and animation process. You might also have noticed that we have been doing a lot of housekeeping.

During that housekeeping, I realised that there were at least 20 erotic animations, from group scenes to new poses and interactions, that we have not actually released yet!

So, while preparing to roll out the massive work I did to fix the game’s rig into the main branch, I used the opportunity to track every animation we had made but, for some reason, had not yet added to the game. Whether because of deadlines, deferred tasks, or things that simply had to wait until later, several animations were still sitting outside the build. Now, I have added them.

In the meantime, the programmers have been working on migrating a lot of the systems that used to rely on Enums over to Gameplay Tags.

In very simple terms, Enums are limited lists of predefined options. We used them as an “index” for things such as character states, character types, and other fixed categories. Gameplay Tags, on the other hand, are a much more flexible system that Unreal provides for handling hierarchies and relationships. They can describe everything from “what a character is” to “what a character has” or “what state they are currently in”.

It has been a very laborious week, but we are quite advanced!

Most of the new architecture is now in place. We are revisiting the way our erotic scenes play, how we handle and centralise the state machines during those encounters, and, as a plus, we have also started creating new editor tools to help us better track the animations and how they connect to each other:

Every node of that Graph is an animation we have, and the floating "satellites" are interactions.

On top of that, we have also revisited how combat reads weapons that should cause damage from both hands. This was related to an issue where Kalyskah would sometimes grab her sword with her left hand instead of her right.

Essentially, the issue was that we had a one-handed weapon “claw”, used for collision detection, and when Kalyskah attacked, that weapon would switch the hand it was attached to so the collision could work. The problem was that, due to programming inconsistencies, the weapon claw could sometimes remain on the left hand. This then cascaded into issues with swords and other weapons.

Now we have revisited that system so it works in a smarter way. Everything is more data-driven, and the game now knows when a weapon is an edge case that should behave as “dual-wielding” This makes the collision system much more reliable when deciding how and when to switch hands.

On the storyline and animation end, our animator has been making progress on the scene between Kalyskah and James:

Thank you so much for your support and patience. We're taking our time now to do our best to fix and address, once and for all, most of the feedback you've been providing us throughout the years but we never had time to work on it before!