Chasing Elysium Devlog - January 2026

My development cycle is shifting a little bit! Now that I have a couple of prototypes under my belt and feedback from friends, I'm shifting into a 3 month cycle for new builds.

Month 1 is new features, functionality, and refactoring. Month 2 is new content. Month 3 is assets such as graphics and eventually audio (I'm trying to learn piano and music composition! it's hard but i want to do it!). Month 3 will also include polish, any last minute bug fixes, and play testing to prepare for an alpha build to distribute to friends.

January was a very busy month, SO! Let's get started!

Developer Tools

Extended Text Labels

Godot is unfortunately lacking in the ability to add custom bbcode that specifically inserts text, e.g. placeholders that can change dynamically. The first thing I did this month was to add a node with that functionality as an extension of RichTextLabel. It's a tiny bit hacky but it works and works well so far! It should also be reasonably extensible with more tags, but for now I have a tag to insert the keyboard mapping for each input a player can make.

At some point I intend to extend this to include the option to show controller mappings instead, but that shouldn't require further adjustments to the actual in-game text. Just adding the feature and a setting in the eventual settings menu should be sufficient.

Base Tileset and Normals

Remade the base tileset to the current specifications. I am sticking with 32x16 isometric (technically dimetric). Colored the sides of the base tiles pure red, green, and blue to help distinguish which side is which for the purpose of skinning it. Also made a normal map for the tiles so they are compatible with lighting effects! Lighting won't always be used in-game, but I do want to have it ready to go for when lighting is used.

Area Triggers

A very important part of any RPG is events triggering when you enter a specific area of the map. It's not too hard to do this in Godot with Area2Ds, but I decided to build my own trigger scene off of Area2Ds to add specific functionality that will be used over and over again, namely conditioning the trigger on whether certain story flags are met etc.

Refactoring

Combat System

Oh I feel so (mildly) frustrated about this. I was really proud of how I initially wrote the combat system as it primarily used Godot's AnimationPlayer nodes to script out attacks. This felt like a great idea. It very quickly became apparent that using a timeline based editor instead of actual scripting made it very limiting.

So I needed to rewrite the combat system to rely on scripting primarily, not the animation timeline. Oh well. The process of doing this has led to several very significant improvements in the code design of the combat controllers. I elected to make this change step by tiny step, ensuring it all continued to work at each point. This also does not preclude the use of the animation timeline where appropriate, but I do need to consider how best to integrate the two. I do have some thoughts on this at the very least.

This took me nearly the first half of the month to fully complete. It should end up saving me a lot of headache in the future at least.

Dual Grid

This was a small rework to the dual grid code to make it just... better to work with. The old code was basically all reused, the main change is now the script gets attached to the world layer instead of an independent node. Leads to much easier structuring!

Cutscene Handling

I wanted to implement the ability to do something I call "walk 'n' talk" cutscenes, where you continue playing as dialogue plays out. To enable support for this and to make the way you play cutscenes feel more... "balanced"(???), I did a minor rewrite to create a new Event Manager, under which is both the AnimationPlayer for timeline-based cutscenes and the PKScenePlayer for handling dialogue trees. Over time this may lead to more restructuring and refactoring that will further improve how it's handled, but for now this is a definite improvement.

Unfortunately I am hitting a design issue with implementing walk 'n' talks regarding "how do I handle them being interrupted by a full cutscene or a battle". So while the code is significantly more ready to handle them, I am not.

Character Split

Until now, all characters, including those involved in combat, were built off of a "Character" class and scene. This was honestly a mistake. I know I'm going to have NPCs who are completely uninvolved in combat. So I had to go through the process of splitting the Character class and scene off to make a Combatant subclass and inherited scene. This was... surprisingly difficult. I ended up having to manually edit a tscn file. It would've been much easier if Godot allowed you to set a saved branch as the new scene root, effectively converting a scene into an inherited scene. I may end up putting in a feature request for that at some point. Or looking into learning enough of Godot's internals to add it myself.

Combat Controller

With the combat system rework and the character split, a lot of the purpose of the Combat Controller became redundant. As a result, I was able to take the time to eliminate the Combat Controller entirely and move any necessary functionality into the Combatant class while cleaning up leftover extraneous code. Very nice!

Prologue Cutscene

I separated out the prologue area into two separate sections of the map in order to make it easier to make tweaks to them individually. Don't know why I didn't do this initially, but...

Features

Forced Battles

Building on the area triggers, I've added Forced Battle areas where you must defeat all enemies in order to proceed. Obvious uses for this include boss battles. I'm planning on eventually adding other types of forced battles as needed, such as "survive some number of waves of enemies" or "survive for some amount of time". Forced battles are separate from Area Triggers so that other types of triggers can initiate them.

Quality of Life

Attack Input Display

The reason I added the Extended Text Labels feature was actually primarily so I could implement a commonly requested feature from my playtesters (and one I already intended to add, but their feedback told me to prioritize it heavily). That is - the Attack Input Display! At the bottom of each attack icon there is now a display of which button will activate said attack. Hopefully this makes it easier to know what to press to do what you want.

Toast Improvements

I made some improvements and adjustments to the existing tutorial toasts to hopefully make them clearer. I also converted them over to the Extended Text Labels so they can make use of the action bbcode tags.

Dialogue Box

A minor but important improvement to dialogue boxes - they now display a blinking icon when they are ready to be advanced. This icon also corresponds with the button you need to press to advance them. Just a little QoL feature.

Attack Dimming

Attack slots on the hotbar that aren't set to anything are now fully dimmed out.

Bug Fixes

• Fixed an issue where enemies would aim above the player when playing as SOL in flight mode.