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

(2026-03-11) Vectors in the compiler

Incredible, but true! I’ve added structures to the compiler, the first of which is the humble Vector! It’s always a 3D vector, even in the 2D settings. You can use them either as a structure, or as individual components:

var V vec() = [0, 0, 0]

# As a component
Set(V.X, 5)

# As a structure
Add(V, [1, 2, 3])

At the moment, this is the extent of the system, but I’m planning on having 3 types of structures:

• Vectors: 3D int vectors with support in math functions.
• Arrays: Arrays of a single type, which can be iterated on in an upcoming A branch.
• Custom: User-defined structs, which you’ll be able to declare from CASP on in modules.

Vectors are meant to be used in many places in the engine, especially for anything involving Physics or Graphics. I’ve still got design concerns for the other two, namely if the Arrays should have a fixed length (most likely yes), and how Custom structures are meant to be used (just organisation is a bit weak, but I’m thinking it has great potential to replace Specblock structs). Please note that all structures are just in the compiler, and not an actual type in the runtime itself.

I’ve done a lot of design work for the next parts of the engine, as they link a lot with the upcoming systems for top-tier integration in the Castagne engine: Varspec, a second language in the engine for editors, and MechMods, a simple composable way to add mechanics and system mechanics to your game. Combined with the upcoming State Calls with parameters, this will enable tremendous flexibility. That and a basic implementation of Physics, Attacks, and Graphics is my current objective, as this is where I can start porting projects to it.

Also, the forum is almost ready. I’m still testing out the rollout and managed to put myself on a spamlist thanks to a technical error. I guess it happens lol.

(2026-03-02) New Landing Page!

I’m really not a webdev dude and it shows lol, but we got a new landing page now! The previous one looked “unique” (better on my screen in my defence) to the point I’m being cited as a part of the “anti-design” movement. You can’t take the artist out of me it seems.

This solves a few problems around communication, the first being that most progress was not really accessible unless you were already in the community. This shows how active the project is a bit better! It was also a bit tricky to keep up with the weekly video, and until its quality improves I believe it’s not currently worth the effort of translating them. So instead of having to spend big time every week, this style of short update is probably better? I was already doing it before, so it’s not like it takes much. Might be able to rig it to videos too, once I improve my pipeline a bit.

One of my next objectives is to move the Castagne community towards this website. Discord was a useful crutch there, but information easily gets lost, and it becomes more walled over time. This is going to happen slowly, as I also want to develop the engine, and being currently mostly a solo thing that means I’m already pressed for time lol. But this is a priority, as my gambit to develop a full engine in 3 months didn’t pan out as fast as I hoped so I’ll need to switch gears into more paced and clear development instead of a short intense period. I’m still very satisfied with the project’s progress, and you can see how many features are already in on the page.

This doesn’t change much my plans, except that March might be filled with more “admin” and “surrounding” work rather than pure programming, but it might make more people aware of the engine, which is nice! My next programming steps are going to be structured types (especially vectors) and either the physics or graphics module. Input already works, so this is some of the last steps to make the engine usable. Knowing the extra features coming, I can’t wait to port my own games to it!