(2026-05-19) Base State / Helper System

Quick update: the base state warning is coming back, this time a bit improved and with proper metadata! Also since at the moment warnings are treated as errors and stop compilation you have to live with it.

So quick refresher, Castagne is very flexible and allows you to call upon other states to add code. This is great, but can result in issues when being careless: you could execute some base code twice, or not at all, which makes for all sorts of cursed bugs, but it’s not something Castagne can just guess. Some states are meant to be used as simple snippets of code to a bigger state, so it is only known to the writer. The previous version had a little failsafe I added a bit later in dev: states could either be marked as helper with _Helper(), or as a base state with _BaseState(), or could inherit from a base state (which unfortunatly didn’t go through the whole tree for various reasons. If not in one of these three cases, a warning would be raised.

In the new version, this helper / game state dichotomy is enshrined: Helper states have a () after their name. This already handles half of the problem, then I’ve also added the new BaseState metadata for the other half. This works much better than before:

• The property does propagate properly, meaning the only base states currently are Common and Init. NeutralState for example just takes it from Common.
• The engine now properly detects when a base state is called twice or more, and can tell you which calls it’s taking it from.
• States can’t be both base and helper anymore, which reduces some edge cases.

I’ve added 4 different warnings with explanations, although here’s the most likely one:

This should result in much cleaner code and more guidance for beginners, and a bit more stability for your own games. When in the last update I talked about doing things properly and taking a bit more time, this is the kind of feature I meant: while not mandatory, implementing it when I feel it’s starting to be needed allows the whole codebase to be more harmonious and stable, and allows me to handle pain points early. I notice a lot of problems when coding the engine, so by the time it gets in your hands the main usage at least should be fairly efficient. Having a strong base also means that bug reports get integrated and treated better, and don’t come back as often.

The hidden news behind this one is that the attack type system is back and better than before, as well as the new attack duration management, but it’s hard to see the whole picture in its current state. Still some big areas to work on systems-wise, but bit by bit they are getting done.

See you next update! I’m mostly building and fixing the whole attack flow right now. Forum and videos are still on my mind too.

(2026-05-17) Two Characters

NO FELIX LOOK BEHIND YOU!!!!

Update is what it says on the tin, you could already do several entities but I’ve properly implemented the Battle Init Data support for variable overrides, which allows them to start on opposing sides.

A lot of updates these days are not super interesting to show in my opinion. From experience people tend to prefer stuff that is relevant to them, so “I fixed the editor having issues with helper states” when you never used the editor is kinda whatever. This has been the bulk of progress these days, small stuff like “input events now delay their consumption so that branches are more coherent in niche cases” that will save a headache to a few people in the future. That’s just programmer life.

Doing stuff properly takes time with very little visibility. The next big step is handling hitstun for example, and while the concept is simple, doing a proper hitstun state that is robust enough to handle various animations and states is much trickier than it seems. Most of the choices will sound like ramblings unless you have a dozen examples on hand lol

Anyway see you soon!

(2026-05-13) New Error System

I’ve spent two days to make this, but hopefully it’s worth it. Remember when I talked about making the compiler more robust and the engine more learnable? Take a look at the new errors:

As you can see, errors now are much more verbose. They have categories, and since there’s no space limit anymore they tell you a lot more detail on how it happened. This is already more advanced and useful than the previous version, and the display is nice.

A new thing however, that I added just now, is the ability to ask for a deeper explanation by clicking on the error itself. This adds the little blurb below that can be as verbose as it wants to that you can understand better why the errors happens, and how you can fix it.

This system is not just for compiler errors: it also handles compiler warnings, runtime errors, and the runtime logs. That also means all those can have more information given to them. One such information is the context, which you can see on the compiler error. This helps trace each of these back to the exact line it happened. This is definitely not something that will come up in a later update.

For the record, I have not written error codes for each error yet: there’s a lot and I got annoyed halfway through. Some are a bit context-specific and would require a bigger refactoring to work, and if I’m honest this has been already pretty long and I want to focus on other things. There are currently 38 error codes in the engine for compiler errors specifically, and I’ve written a message and explanation for each one, but there’s probably about as many of them to write on top of it. Now that the system is in place however it will be usable for new errors.

There’s a lot of work still to be done before a release. My tracker says 56 tasks before the first gate, which is not even the beta release. Not all of them are two days mind-numbing endeavors however. This biggest one still remaining is the attack system, including cancels and hitstun and the like. This is a core engine concept now so you have a lot of moving parts to design and handle, but bit by bit it’s going to be done.

There’s also all the surrounding parts I need to get back to: you might have noticed update videos have dried up, because they are pretty long to make even with the tools. Just communicating is taking quite a while, and even a casual update like this one takes 40 minutes to write, and another 20 to post. The forum is also still down, and I’m going to make the config a bit more robust because the website is hosing more and more features now. Anyway, that’s going to be it for today, see you next update!