June 25, 2026

[Devlog] C++ and old code migration!

Hello everyone!

We're so caught up in the work that, once again, we missed posting here about the progress on what we've been cooking!

Most of the cutscenes for the dungeon are done. Now we only have some tweaks left for the side ones, such as Nemesis and perhaps the scene where Kalyskah meets the goblin.

Optimisations, C++ and New Combat and World Manager

The combat rework and NPC work were really good tasks for us to tackle because they helped us uncover many of the reasons why the game has had issues with performance, as well as inconsistencies in how characters moved, teleported, or behaved. This also includes things like clothes clipping, or female characters' chests popping out of their outfits by clipping through the mesh!

It turns out that, since many programmers have worked on our project over the years, they often worked on their own sections of the game without creating the correct centralised framework to tie everything together. So we picked something important to tackle earlier this month: bringing a good chunk of the code to C++.

For those of you who are not familiar with the programming side of game development, Unreal Engine offers two main ways to programme the game.

One of them is Blueprints. They look roughly like this:

It's very visual and easy to look at (when done right), but slower to compute. Not the C++ code that looks more like this:

So, what have we been doing so far?

First, we decided to fix our documentation by creating spreadsheets and mapping the MVP of the features we have planned so far, alongside their current state of development. We also mapped how deprecated code from the old architecture is still affecting us.

There are tons of documents, but I think the easiest one to read is this:

It does not represent the full implementation inside Unreal Engine yet. It represents the state of the C++ code compared to what we have planned. We are moving things that used to be handled mostly by Blueprints into the new architecture we have set up.

How does this affect the way the game plays?

A LOT. Once we are done with this migration, not only will the time that it takes to load an NPC improve, like we had already planned, but the whole game will end up performing better.

Why?

Because many of the old systems were too spread out. Some things were duplicated, some were coupled together in ways that made them harder to optimise, and some logic was living in places where it was not supposed to be. This made the game harder to maintain and also made performance worse than it needed to be.

By moving the heavier systems to C++, we can make them more centralised, more predictable, and easier for the engine to process. Instead of several Blueprints doing similar work in different places, the game can rely on cleaner shared systems that handle combat, NPC behaviour, world data, equipment, animation rules, and other important features in a more organised way.

This should reduce unnecessary CPU usage, reduce wasted memory, and make it easier for us to know exactly where problems are coming from when something breaks.

And that is great news, because performance was one of the biggest bottlenecks preventing us from using other features that could improve the graphics and the overall presentation of the game. A lot of the FPS was being lost to bad memory allocation, old code, and systems that were too tightly coupled together, instead of being spent on the things you actually want to see on screen.

I hesitated a bit about posting all this earlier because this kind of work isn't always very flashy, but it's one of the most important steps toward making Kalyskah more stable, better optimised, and easier for us to keep improving!

As you can see from the checklist I showed earlier, we're nearly done with the skeleton and quite advanced in terms of implementation. We'll get you something playable as soon as possible, since we don't want to keep you waiting until everything is 100% done before we release a new demo.

Comments (9)

g
ghost · June 27, 2026

This might be a stupid question but I'm considering subscribing to the patreon here but I can't seem to find the answer in any of the posts here. I saw a post from early April (I think it was the 5th) that said there should be a demo release within a few weeks. It seems like every post after that is either the post that said it was being delayed again or a devlog. Is there a recent demo that's actually available for download or is it just being delayed right now? I want to check before I do anything since I'm only going to be able to subscribe every other month right now. I'd appreciate any clarification you can give since I'm really not sure what kind of state the game is in right now.

K
Kalyskah · June 27, 2026

What happened is that we started to roll out the new combat and found out a hundred other things we can improve because while writing the new combat, which is fully in c++, the solutions to a lot of problems we had, arised. So if you want to subscribe only to get a demo, I'd say you could wait until it's ready because its going to be our biggest refactor until the current date. But if you'd to subscribe now to support us and help us get there, because we do need an steady budget to keep the freelancers that have been helping us on adding content and refactoring the game, it will be greatly appreciated!

K
Katsuragi · June 25, 2026

I'm on my own UE and C++ enjoying journey, so I love to read technical stuff. Keep bringing it on! Honestly, I think at least half of the actual reason I follow so many nsfw game projects is because of the charm of how open they are in their progress, relatively speaking.

K
Kalyskah · June 25, 2026

Thank you! And I'd love to see what you are making too! Feel free to share on our discord, we have an "i did this" channel meant for people to post their creative work

B
Blue Sammy · June 25, 2026

Fascinating! Let me see if I can dust off the old C++ cobwebs. It looks like a class called UBiteResolver. Two methods are displayed, GetWorld and IsEligibleTarget. GetWorld returns a const UWorld pointer that is obtained via the Owner variable (most likely defined in one of those .h files, KalyTags.h maybe?) IsEligibleTarget has to pull a valid AActor target (Kalyskah’s victim during the bite prompt), and answer if they are either stunned or knocked down, and verify that they are not a bite target already and that they are not already dead to confirm that they can be bitten. C++ is renowned for being speedy. Here’s to better performance and maybe a slightly more sane code base!

K
Kalyskah · June 25, 2026

Exactly! And it also checks the gameplay tags of the target instead of just booleans. Since gameplay tags are much faster to access than us needing to make a cast to a class and then grabing its data!

J
Jibon Khan · June 25, 2026

Good

B
BananaHammock · June 25, 2026

Well done, I love these kind of posts and I wish you the best of luck with the migration and refactoring, I recently completely gave up on BP and even do as much of the UI as I can in code...I find it feels more explicit of exactly what I want and when and what order easier

K
Kalyskah · June 25, 2026

Thank you! It's always scary to show whats behind the curtain