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.
