(2026-05-24) Hitstop / Freeze / Halt

Quick update: hitstop is back in the engine. Here’s how you currently set it:

Set(Attack.Stop, 6)

In fact, at the moment that’s how you set all attack parameters. I’ll be adding functions over time for easier use, but this is the generic way. Some parameters that used to have different names depending on hit / block, namely hitstun / blockstun and hitstop / blockstop now are unified under their single banner of Stun and Stop respectively.

Fighting games have a lot of names for stuff that is player facing, and players also give it their own name, so I’m making up less ambiguous, less overlapping, technical terminology as I go. That’s why the default button names are LMHU, as it doesn’t overlap any common button name on controllers, that’s why “teching” out of a combo is “recovery” and “teching” out of a throw is “breaking” the throw. I try to link concepts that are conceptually similar. There’s no unified fighting game lexicon that all games use, so players tend to come with different names, and some names reappear like “high” attacks meaning different things for 2D and 3D fighters for example, or “stun” which could also refer to the “dizzy” mechanics of some games. I need to give names to concepts in the engine that speak both to the technical reality and face the user, so it’s a big matter of taste. I’m making the engine so we’re using my taste, which is also the correct one (obviously).

Anyway, Freeze phase and Halt phase work just as they worked previously, mostly. I have yet to implement collider coherence over several frames, so for now I took the shortcut of just removing frozen entities from the physics computation. I worry a bit about the more state I keep outside of the CASP memory stack as its additional rollback headaches. There’s a bit of play with the Before and After events: Frozen or Halted entities only execute their respective phase without the Before and After events, and they are executed at the same point as the Main phase, meaning you can use active entities’ After event to access data from the frozen / halted entities.

Cool bonus of the compiler being an actual compiler instead of a spaghetti parser is that phases / events are properly handled now, and hit animation now plays as expected without needing fancy tricks.

Summer heat is starting here and it’s frying me so I’ll probably be less efficient. I should probably either figure out blocking or physics enveloppes next, hopefully I’m out of those big core features by the end of the week.

(2026-05-23) Attack Cancels

Alright, new system is still in development, but it already works at the level of the previous one so let me share some early info!

The old AttackCancel system was just syntaxic sugar over an InputTransition. Works well enough, but there’s many cases where you need to do some extra work, namely for when an attack has prerequisites. Not really an issue, but still something you had to keep in mind often.

The new AttackCancel system has two major differences. The main one is that an AttackCancel now holds much more information inside, such as its motion or potential conditions for the cancel, which allows much simpler use. The second is the interface through metadata (which in fact shaped a lot of that system).

The base function is now just AttackCancel(State), with the state holding all the relevant info inside. That means you don’t need to specify an additional motion or check for meter cost and the like, that’s all inside of that little call. As I’m expanding the system, I’ll add more options to override the default values, such as adding an alternative motion for cases like a followup you can also do from neutral. These are not really new capacities, just a new simpler interface for that.

The way you actually use the system is simple: just put some metadata at the top and most of it happens automatically. A lot of the attack system now goes through that. Let’s take a look at a simple attack using an F branch:

+AttackType Light
+AttackDuration 60

F12-15:
	Hitbox(10000, 5000)
endif

Let’s break down some of the parts:

• +AttackType is a metadata line, and is the equivalent of AttackRegister from the previous version. It mostly works the same, but the new compiler features allow some extra conveniences, such as easier specification of attack types and the compiler warnings guiding you in the proper direction to make new ones. It will call AttackState and AttackType-[TYPE] (hook) for you.
• +AttackDuration is another metadata line. This time, instead of waiting until runtime to see the duration of the attack, it now will get it from the metadata, which is going to be relevant for frame advantage computations. The upcoming T branches will set this automatically.
• +AttackMotion can be used to add as many motions as you want. It is not present here, so it defaults to the state name if it is a motion.
• Then it’s buisiness as usual. I’m assuming you already used Castagne if you follow these updates lol

Planned upcoming metadata elements are +AttackCost and +AttackRequires, which make the cancel unavailable if the conditions are not met.

Next up here is going to be blocking, and how the attack cancel system will interact with this hitconfirming system. The remaining tasks for this gate are mostly related to the attack system, improving physics, or improving the editor.

Also, forum is back online. If it goes down again I’ll cry. I’ve improved the server config to host additional services in the future (in fact, I’ve already added one two months ago but it’s not ready for public use yet).

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