(2026-05-22) Hitstun

Yo, hitstun is properly back. There’s a couple changes compared to the last iteration, some coming from experience, some from the philosophy change, and some from the engine changes themselves.

First, Hitstun is now a single state, as opposed to a few. This enables more fluid transitions between ground and air. You can still do special Hitstun states, the order of inheritance is Hitstun -> HitstunState -> StunState -> Common. Blockstun works in the same way.

Another change is that the stun is now stored in a variable that changes, as opposed to being fixed and using the frame counter. This allows more control for advanced changes.

A key change is the number of hooks available. Thanks to the new engine design, it’s very easy to add extra hooks, so ALL BEHAVIOR (or almost all) CAN BE REPLACED EASILY. Each meaningful block is within a hook or separate state, so you just need to find the proper one. Don’t like how the character exits automatically after a time? Change it. Don’t like how stun decreases over time and want to be able to pause it for your weird special move? Go ahead, no need to copy and change, all is done much more directly (and in the future, shown in the editor too). This is something that’s going to be common accross the engine by the way.

Another change that will be explained more when the anim system is more fleshed out, is the different hitstun animations and their system. It is common to want to have multiple basic hitstun animations for various hits, depending both on the character state itself (standing, crouching, airborne), strength, or direction (I do this one a lot). Previous Castagne shyed away from that since it would be very specific to your animations and game, but in an effort to raise the quality of your games this is now planned to be in engine.

A big part of the switch, is the upcoming animation fallback system, which allows animation data to be used from another animation if missing. This allows me to add animation slots with full confidence that it won’t add extra workload on the cases you don’t have it, and therefore I can put as many meaningful ones as I want. This means that the auto-chooser can also know what to work with, as I can make it so you both can choose an animation or let the engine choose the one it deems most appropriate. An example is from Void Fury’s launchers: if the launcher is also a low, it chooses the trip animation, otherwise it chooses the upwards air hit animation. This heuristic works really well and you’ld not notice it often as a user, it’s quite natural in practice.

Some polish is going to be needed, as the editor currently can’t do frame by frame well so I can’t check if everything is showing up properly, and we’re a bit too far from the final test character to autotest it. Will happen with time.

Next up is going to be attack cancels and general linking to the system, then blocking, and then physics enveloppes, which I might need a shorter name for but is going to be very important. And finally, T branches / rich animations and that will be all the main systems for this gate.

(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!