(2026-03-29) Editor CodeView

Hey! I’ve been restarting work on the editor, and the first job is just a straight quality of life update:

As you can see, there’s now syntax highlighting for Castagne Script itself! The previous one was just coasting off its similarity to GDScript, but this one actually uses the Castagne Script syntax. I didn’t do much, that’s thanks to the Godot team’s efforts mostly, I just told it a couple symbols. Still, that’s a great improvement.

The second one you can see is that the Documentation panel looks a bit different. While that is still a WIP, this one actually adapts to the type of line you’ve selected, with the interface being able to change in the future. Since it doesn’t just read functions anymore, it will be very helpful for beginners as it can remind you what basic elements do, and in general its ability to display more info will be helpful.

Stealth addition that will pay dividends, but the docs here isn’t isolated: there is now a proper Documentation system in the editor, and the panel reflects its contents. This means there is now a centralized location for the docs in-engine, which can be exported on the website. It works off with internal paths, so you can refer to a concept immediately, such as language/branch/input will give you all the detail you need on input branches. This ensures the static part of the documentation is referred properly, and will allow an up-to-date version on the website.

My next editor step is the navigation panel, although the VarSpec system is another key implementation I’ll need to do sooner than later. The roadmap here is a bit less defined, as the editor is still in flux and there are a LOT of systems to make work together.

(2026-03-28) Walking is now optional, but Standing is not (MechMods!)

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!

(2026-03-26) Battle Init Data

Yo! Another update to a structure you know (and love?): BattleInitData, which as the name implies, holds the data needed to initialize a Castagne fight! Most probably didn’t use it much, but it’s been a cornerstone internally.

There is not much to talk about to be quite honest with you, as the ideas work the exact same, the interface is just better. It used to be an unwieldy JSON dictionary with a weirdo format, now it’s a properly reified object with a functional interface. Here’s an example where I create two players and their character, both have a 100 meter but the second one only has 1 HP.

// Assume we got config, player_1_scripts, and player_2_scripts properly handled before
let mut bid = BattleInitData::new(config);
let character_1 = bid.player().entity(player_1_scripts);
let mut character_2 = bid.player().entity(player_2_scripts);
character_2.entity_override("HP", MemoryEntry::Int(1));
bid.entity_override("Meter", MemoryEntry::Int(100));

As you’ve seen, it is simpler to build, and the previously available functions are there. Overrides allow you to change a variable from the character at creation, and you can set them up to be inherited. As such, the Meter override here was set at the root, so it applied to all entities defined in this BID, while the HP one was only done to a single entity. You can override global, player, and entity variables, as well as create entities with no player parent.

This is still a work in progress, as I’m focusing first on key functionality there. The new idea is that known data can be set more easily in general when the engine knows about it, with simple functions. Here’s an example of a new functionality: instancing subentities directly:

bid.player().entity(scripts).subscript(fireball_subscript_id)

This is honestly fairly low priority compared to other tasks once that the basic functionality is there (some overrides don’t currently work because there’s no player memory yet for instance). It’s needed to set up fights in the editor and game, but at the moment only the first is needed to get started with the engine (as you remember with my priority list). Still, are some planned / potential functionalities:

• First of all, there is going to be a host engine interface. That example was in Rust, but you’ll be able to have a very similar interface from within Godot.
• The flow module will be able to handle “standard” variations of this. An example you already know is the fighting variation, which just gives you a 1v1 with potentially multiple characters.
• An idea I’m evaluating, is the ability to save a state to a BattleInitData, which would allow to store state on disk. This could be REALLY strong for editor tools.
• Another idea in a similar way, is the ability to add BattleInitData DURING a fight. With proper management (keyword: proper), this could allow complex worlds and situations, which would be quite interesting for the more platforming focused cases.
• Another one that’s linked to both, is the ability to reference existing HostStructs or similar from within. I’m not sure yet of what this would imply, but the idea is to be able to integrate Castagne into game flows better, like starting a fight from an RPG overworld seamlessly. We’ll see when I need it I guess lol, that’s real low prio compared to actually making stuff work.

Next up is multiple file loading for CASP files, as well as Editor control there. It’s time for the Base CASP to get a tune up, and that would already cover most of the prerequisites for the engine!