(2026-03-14) Host Engine Structures

Remember that Castagne can be run independantly? It handles all the gameplay on its own, but needs to be hosted by another engine to actually poll input or display anything, which in most cases is Godot. This also means that some data has to be shared, which is the subject of today’s update!

Introducing two new types of data structure to Castagne: ModStructs and HostStructs. ModStructs are an extension of the structures that already exist, they store another Memory Stack and thus can be rolled back if needed. They are separate from the main memory, and live inside of the engine itself, which allows additional abilities where needed.

Currently, this covers the AttackData structure, and you can guess what it’s used for based on the name. The interesting part of ModStructs is that they are also accessible from CASP directly. As such, AttackParam is a thing of the past, you can now directly use Set(Attack.Damage, 1000) for example. It’s also much more flexible than before, as you will be able to declare any type of attack parameter using the declare variable syntax: declare Attack.MyCoolParameter vec() = [0,0,0] creates a new MyCoolParameter attack parameter of type vector. This will still be compatible with the Attack Overrides system, so it’s quite strong!

HostStructs are an extension of ModStructs, as they are one ModStruct plus an additional data structure on the host side. The most direct application is the ModelData structure, which holds the parameters for the model. This is stronger than before on the Castagne side, as you can do Model.Position for example instead of having the whole ModelMove functions. On the host engine side, HostStructs recieve callbacks at key points in the process, such as the graphics update step for models, which are used to handle data while keeping rollback in mind. Since HostStructs have access to this managed memory stack, they can read the correct values and update accordingly, which works better if you use an immediate update structure (meaning, you are not dependant on previous state). The responsability of data lifecycle during rollback will mostly be handled by Castagne, while the responsability of acting on the data is on the HostStruct. This effectively replaces the InstanceData system, which worked in a similar way but was less structured.

Anyway, that’s mostly internal stuff which is going to be useful for engine devs or those that go really far. On your end, it’s most likely buisiness as usual, as you just make your Godot scene and it gets loaded as expected. Or, you use Sprites which are handled for you.

One change that will be coming however as a result is the fusion of the 2.5D fighter and 2D fighter genre into one. This was a big mark of using Godot specifically, and it brought a lot of issues because Godot’s pure 2D engine doesn’t handle 3D models (duh), and as such a lot of default behavior couldn’t be used. Using Godot’s 2D engine won’t be off the table however, as it will become a config option, that way if you want to use pure 2D sprites and background you will be able to set it up.

This change will make the beginner experience much less brittle, and will cause less confusion around some features of the engine which are not available when using the pure 2D renderer as it will be opt-in AFTER the initial approach and ensure you actually know what you’re getting into. Many people think “2D Fighter” refered only to the characters, which is not the case but it’s not something you can “fix”, especially in the first 3 minutes someone has with Castagne. It also prevented the default characters from being used, so the choice most beginners made would cut them off from learning! Won’t happen as much now.

(2026-03-14) States as functions?!

This is a pure banger feature, one of the best usability improvements of the new Castagne. State Calls were a huge feature in the previous version, and you could use it to create behavior either by extending a state or through composition. Interally both were the same, but I added warnings and _Helper() to distinguish between the two. You could alter internal defines, but it was a bit janky.

First off, there’s a new syntax for state names, which immediately distinguishes between the two: StateName is a regular state, while StateName() is a helper state. Both can be called without issues by using !StateName (equivalent to Call(StateName) in the old version), that part doesn’t change. What is new is that you can now add parameters to that, which are treated as local variables! Here’s a long snippet showcasing the new abilities:

:HelperState(var X int(), var Y bool() = true):
# You have access to both X and Y here.

# A is a local variable that you can't set from the outside.
var A int() = 10

V Y:
	Add(A, X)
	!OtherHelper(A)
endif


:OtherHelper(var Z int = 5):
# This has only got access to Z, even when called from HelperState.
# These are copies, so even if called through !OtherHelper(X), it can't change X

# You can call parent with arguments too
!!(10)


:RegularState:
# You can specify parameters with or without defaults
!HelperState(5)
!HelperState(5, false)

# If there are no parameters, these are equivalent
!OtherHelper
!OtherHelper()

# Hooks also work! The parameter list will resolve when needed.
!SuperState?(10, true)

So now you’re either super hype or super confused. This is a core feature of the engine that allows many mechanics and tools to be made inside of CASP in an efficient manner. Let me illustrate the difference with the old Castagne with some examples:

• Kronian Titans has a lot of dashes, but internally there are only a few types with specific values. This can be replaced with a simple !AirStep(5000) to make the behavior easily readable and contained!
• Molten Winds has levels and some characters might have custom behavior when a levul up happens. In this case, use the hook syntax: !OnLevelUp?. Compared to before, you don’t need to create the state immediately, it will only be used in the characters that want it.
• Kronian Titans again has IMPACT moves, which launch a cinematic under specific circumstances, and requires a couple lines to set up with a hitstun that could differ. A simple !IMPACT or !IMPACT(120) can now take care of everything!
• Molten Winds has Aster who has overdrive version of some moves which can be done by holding the button for the first X frames. Instead of rewriting it each time, how about a !TransitionIfHeld(M, 6, OverdriveMove) to automatically handle moving to OverdriveMove if M is held for the first 6 frames? Easy QoL on something that’s a bit too niche for the modules!
• If you made custom modules in general, this is a way to make new CASP functions in a rollback-safe way, without leaving the editor. Take FlagCarryover(F) for example, it’s just FlagNext(F) in an L branch. You could make functions like that for your own use in minutes! It’s not as optimized, but that’s easily done later, and you can get started with it faster.

This is already super useful, but when you’ll combine it with the upcoming MechMods (!!? is specifically superb in this context, as it allows needed modularity) and Varspec (which can understand when it’s seen from a state call), it will be incredible. These three features are the ones that will bring the editor to a new level and I can’t wait for that!

Slight design musings to finish, since this post is already super long:

• I thought about adding persistant variables to states, potentially allowing a Transition(CoolState(500)) or something, but I think it would be a bit overkill in complexity and we can hold variables in memory for that. Maybe I could add a variable tag for that.
• Speaking of, the variable syntax is now lighter: var X int is valid. The variable tags are optional (the () in int(), which isn’t used for anything right now nor was it before, always a planned feature), and you don’t need to specify a default. In fact, some variable types don’t accept defaults, such as state or flag (semantic types in general), but you may use them in state calls.
• Some modules have functions that are basically just syntaxic sugar and could be made as CASP states now. The Attack module is a prime example, as it’s mostly functions that call AttackParam internally. I don’t think this would be for the best however, as it would complexify the docs and make it more confusing to follow. Allowing the ! to become optional would fix that but introduce confusion instead. Making them as CASP functions would allow overriding module functions, which is another can of worms. I’m probably going to introduce module functions as macros to implement that.

What’s next is a bit tricky to choose, but I think I’ll start working on the modules again. Logically, I won’t be actually able to implement the MechMods without having something to put in them! Varspec will probably be the very last core feature to be added, since it’s so dependant on the rest.

(2026-03-12) Local Variables!

New feature alert! Whereas before you could only declare constants in your state, now you can declare variables!

These variables are only available for the state (or most likely, scope, due to how I’ve implemented it but I haven’t tested it at the moment), and get reset when going through it again. This means they are volatile: you can’t store state from one frame to another, and you also can’t reference them from the outside.

For the technical detail, it’s a per-entity memory stack that doesn’t get saved or rolled back. It has no upper limit, but it might need to reallocate. It starts at a reasonable size so it probably won’t come up unless you push it explicitely. Its volatility allows it to not bog down the implementation, as it gets “reset” every time you try to execute CASC code.

While it might not sound like a huge thing in the context of the previous versions, it actually enables a lot of future behavior. If you looked at the Base CASP I already used a proxy for them using the RegA/B/C/D variables you might have seen at times. They are usually used in intermediary computations. One such example that I’ll need to convert is F branches, which use it to handle modulos.

The main usefulness however is coming soon: using State Calls as functions, with their own local variables. Previous versions of this were limited and hard to parse, but this time it will be much clearer and integrated. Another benefit that is already in, is shorter compilation times: helpers don’t get compiled anymore so it removes like 80%+ of states. Unsure how needed that was since the compiler is in a compiled language now, but we’ll see when it gets to a higher level. This will be tricky to implement, but I’ve got a fairly clear idea of how I want to do it.