This one is one of the more user-facing additions: MechMods! I’ve finally added the multiple file inheritance. The compiler-side was working, but it wasn’t yet searching for files by itself. ‘Bit more robust than before too. So, what is the general order of files?

1. Base CASP: These are fundamental files that are included with their specific module. These are mandatory, and define some key concepts for the engine.
2. MechMods (Mechanics Modules) !NEW!: These are optional files that define game mechanics. You can enable and disable them as you wish from the editor.
3. Common Skeleton: This is a file YOU make that holds all your common behavior, such as system mechanics.
4. Fighter: This is the character you make! It holds all your character specific behavior.

The common skeleton and fighter are self-explanatory and were already present before. The difference is in the Base CASP and MechMods, which solve an organizational problem much more elegantly than before, and are one of the most impactful new features in my opinion.

If you remember, Castagne is surprisingly game-agnostic: it just assumes you have entities directed by state machines. In practice, you have a lot of common behavior that got put in the Base CASP, and from there you could rewrite what you didn’t want. As time went on, I’ve added more integration of that base behavior, including visualisations and interfaces (the SpecBlock system), which improves the common usecase but makes the other ones a bit clunkier.

This new organisation goes both ways: on one hand, it makes Castagne more knowledgeable about some game concepts, and on the other hand the other game concepts become much more malleable. I’ve selected some concepts to become core components, for example the dichotomy of Grounded / Airborne, the concept of a combo, hitstun and blockstun, the difference between a neutral state and a comitted state… There’s not that many, but each allows the engine to do a lot more, while also not restricting the ideas you can do much (e.g. you can ignore the Airborne concept if your game has no jump). Many of them are also linked to their module, so for example if you change the physics module you won’t have the Airborne concept.

This allows the MechMods to know much better what they can rely on, and thus focus on key elements. This allows me to separate many common behaviors, such as:

• The Movement MechMod, which has never-before seen elements such as Walking Forward, but if your game has no use for that you can disable it. (Standing is part of the Base CASP, hence the title of this update)
• The Dashes MechMod, which adds many fan favorites such as Airdash or Running.
• The Combo Proration MechMod, which adds limits on your combos by reducing their damage and hitstun over the hits.
• The Combo Escape MechMod, which adds a burst to your system mechanics.
• And many others of course. The full list is still being built, and the granularity might change, but you get the idea.

Just based on that, you can see how much more powerful the flow just became. If you want a mechanic in your game, you just enable it and get it immediately, and the interface allows easy access to them. I’m also thinking of allowing MechMods for characters on top of the skeleton, so you could surgically add an airdash to a character.

MechMods are what makes a lot of the new additions I’ve made make sense: the state call hooks (!!? especially) allow extension of behavior without requirement, the helper functions allow definition of new tools like !StandardAnim(Standing), and especially the upcoming VarSpec system. This is the last missing piece for my full vision: a system to allow additional editor integration of CASP tools in a simple way. A big element of the SpecBlocks in the editor was how they allowed very strong integration in-engine through buttons and graphs, and this is now comming to CASP itself! This will push Castagne to new heights, and I can’t wait to be able to use it!