C++ Migration and more Optimisations!

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

We have hired someone new to help us create cutscenes, and we’re revisiting the ones from the Fallen Temple era that need updates. Now, most of them are done, and we have begun working on the opening sequence for that era as well.

There are 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 issues such as clothes clipping or characters' chests popping out of their outfits when the mesh is clipped!

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 program 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:

Steam post imageIt 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.

Steam post imageThis 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 are quite advanced in 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.