Changes done due to Performance Issues (Ecrazeus Castle)

As much as I love RPG Developer Bakin, I will say that trying to debug the performance issues was quite a daunting task.

For one, making an Action RPG like I did, not using an overhead view but a 3D third-person view, is a lot more burdensome in the amount of things to handle, like jumping, falling, and everything in between that has to be handled with parallel events and lots of conditional checks. This is a CPU burden on it's own.

But also, there was another burden, and that came to Engine bugs. Just because RPG Developer Bakin entered 1.0 in mid 2025, does not mean it's bug free, and to my personal shock, there were several export-only performance bugs. This led to some major design changes in some cases.

Slopes got removed (temporarily)

The most devastating export-only performance bug was tied to the engine's own... slope tiles (and by extension, stair tiles).

It thankfully got fixed, but that took a bit of time, and unfortunately this came at a horrible time for the game: Steam Next Fest. Before it went live, I had to scrap ALL the slopes in the game from the levels, because on top of taking an absurd amount of draw calls, these draw calls persisted in memory, even when the level is preloaded, and even after switching levels. I wouldn't be surprised if this was the reason why the original Ecrazeus got so laggy by the time you entered the dungeon.

As a result, the Steam Next Fest demo was stripped entirely of slopes. All beginner course levels were modified in that way, and even Advanced course levels were being actively adjusted for the lack of slopes. They're all back in the game, but I did have to redo the levels in some aspects, while some parts of the level had their post-slope related changes kept in place.

Fever Generation got removed and changed how Fever operated

The Fever mechanic was a bit different than what it is today. Originally, it was intended to be a copy of Yakuza's Heat mechanic: attack builds it up, being hit tanks it, and not attacking targets eventually starts draining the meter. And unfortunately, that last part was causing an issue on export.

The issue stems from the constant adjusting/checking of stats, which, for some mysterious reason, on export play, ignores the hand defined "wait for next frame" instruction and somehow, tanks the performance because it thinks it should repeat the task as many times as possible within each frame. And for some reason, I don't think the engine devs fixed it.

As a result, Fever couldn't drain automatically anymore. The entire "Fever Generation" powerup was made to both slow down the drain rate, and reduce the fever lost on hit. With one aspect being impossible, and the fever lost on hit becoming too overpowered, the upgrade was scrapped in two times. First, in the Steam Next Fest demo, the stat existed and was still being dropped as a powerup. However, it mostly did nothing. And then later, after Next Fest ended, the powerup was scrapped entirely in favor of a new powerup: Move Speed.

In hindsight, it was probably for the better that it got scrapped for move speed. Already from feedback, a lot of people didn't seem to understand what the powerup really meant. It also caused some confusion with Fever Power, so in a roundabout way I'm glad the bug occured.

One thing that also changed with Fever: earlier on, the score multiplier was tied to Fever, so if it dropped from the red, it would reset the multiplier. The score multiplier got changed into what it is now as a result.

The UI got modified

This might sound strange, but indeed, the UI for the game took a non neglieable amount of CPU. And more specifically, some elements took an absurdly large amount of processing to handle every frame, like fetching an image stored in a cast, which was the method I used to load in the character portrait. Unfortunately, this meant I couldn't add different portraits per outfit, as now in the UI it's only consists of 4 images, with the character specific one being shown when relevant, instead of a single UI element that fetches the player portrait image it's been assigned.

This bug also affected the weapon icons, which also fetch the icon from their database slot. As a result, I had to make a "icon" font and use that to fake icons. This meant the icons did lose their color, which is a shame and has made the game a bit too minimalist to my own liking, but it was necessary.

Arena Walls

A minor but recent change: previously, the walls of any arena event where purely solid. However, due to a performance issue with the size of the collider, it seemed to be a source of additional lag.

To improve performance, I used Bakin's enemy map distribution regions (or whatever it's called in engine), to basically define regions of the map. Normally, this is used to determine random encounter regions for, you know, a turn-based RPG, what the engine was designed for, but the engine supports reading the player's presence in said regions. Outside regions of an arena are labelled, and the minute the player attempts to flee, it'll warp them back in. Weirdly enough, I had to implement in C# the same behaviour for enemies (or other events), because the only event related check is just tied to the player.

Sadly, it hasn't fully eliminated the issue of poor performance in arena, but it helped in some especially bad areas. It... unfortunately can still be pretty bad at times. :(