(2026-04-13) Elseif, Static Strings, Before Event

I’m not sharing much these days since a lot of my improvements are editor-side and unfinished, but I did progress enough to start writing gameplay! And while I’m doing that, I’ve been adding some features. I’ve bundled enough of these in this post to share.

First off: we got some nice syntaxic sugar with handling of else if! It makes some code a lot nicer to read:

I Down:
	V MOVEMENT_StandToCrouch_Time:
		Transition(StandToCrouch)
	else
		Transition(Crouching)
	endif
else I Forward:
	Transition(WalkF)
else I Back:
	Transition(WalkB)
endif

I would have needed a whole more endifs and indentation to write that. You might also have noticed the space between the branch and the condition. It was already working due to how I’ve implemented the lexer, but now that I’ve noticed it I quite like it! The space is optional, but I recommend using it unless it’s something with just a number like F10+:, which also btw now works but it’s not exactly new lol.

Secondly, strings! We already had them in the old Castagne, but this one is different: they are all static, meaning they don’t get changed during execution. This ensures fast speed, as passing a static string is as fast as passing a regular value. This was already in the engine as I’ve been using it for all the Target.Variable stuff, but it’s now available as a proper type. I wanted to delay this implementation to avoid using strings as a crutch instead of more relevant semantic types, but it’s now done and I need stuff like file paths to work.

Finally, I’ve added a new event: Before, which executes at the start of the main phase. This is because I noticed a design flaw during a discussion about engine internals: since I only transition the state at the END of a tick, if you press a button, you’ll only start the attack on the next frame. This effectively adds one frame of input lag. This can be avoided with some tricks that are a bit complex in some cases, but not all. By making an event that allows transition, I can do an early check much more simply, and make many actions have less lag. I don’t think it’s going to be on the mind of most users. Here’s the main phase flow now:

• Before Event fires, and some of the input and transitions are handled directly.
• Early state transition, which can fire Exit and Enter. No sync point here, so it stays fast.
• Action Phase is executed, you do your actions.
• Sync point between the entities. No transition here.
• After Event is fired.

This makes the main phase a bit complex now, but I hope this ends up being manageable. We will see. In any case, there’s now less input lag so that’s good!

I’m still working on a lot of stuff at the same time, I will post other updates when I feel they show enough what I’m going for.

(2026-04-07) Game Link Improved

Little update: the game link feature of the editor, which connects to a separate game process, is now much more robust. I’ve done that by fixing two things:

• Skill issue on my part, where I forgot that streams are not cut automatically. This led to “packet drop” by virtue of the algorithm thinking it was getting weird packets.
• Speed mismatch between the game process and the editor. Funnily enough, this was an issue on the local side, as I’ve added the local test option without thinking and it was ticking at a much faster rate.

So now, it’s working as expected, at a stable framerate. As always, you can always run it directly. Very nice.

My eyes have been blessed with high framerate, which is nice, but for now I’ll keep the engine at 60 ticks per second. I might add high FPS later, but raising the physics rate itself will destroy online quality, as making it twice as fast requires the computer to be four times faster for the same result, so it would cut a large portion of the player base.

(2026-04-06) State Call Defaults

Today, I’m making updates for me. That’s right, it’s the castagne dev experience update, but CASP-side this time.

You know how sometimes you want to make a part of a state easily extensible? Like how I like having WalkF and WalkF-Movement so that you can completely change the movement if you don’t like it? It’s great for the end user, however it’s always annoying to set up: I need to create several states. That’s partially why I added hooks, so that I can “add” these without really doing work, with a simple WalkF-Anim? for example. The issue is that they don’t do anything, therefore if I want to have behavior you can change as opposed to behavior you can add, I still need to go through that process. Introducing:

!WalkF-Movement:
	Move(1000)
endif

As you might expect, it’s just like a hook, except if the hook doesn’t exist it will call on the interior code! That allows these elements to be MUCH cleaner, as all the behavior is in the same state. These have got two particularities:

• You can’t use arguments. If you want arguments, you need to define them and therefore should add them to an actual proper state.
• Call Parent works, HOWEVER it is a tricky one: the parent will ONLY exist for that specific state that calls the default. This means the same function could compile to different code, and that !!? is mandatory. Good enough imo, it’s added as the base parent so overriding the hooked state works as usual, it’s just a tricky integration that most likely won’t come up unless you start calling on hooks from several states or have several defaults.

Another update is that, since the Castagne base files are now embedded inside of the binary, well you can’t really change them. This instantly makes the lock feature of the old editor unneeded since you can’t change it, but that means that I as a dev can’t do that either, which is annoying for development. I’ve therefore added an option where you can give the path to Castagne’s source to load these dynamically!

These updates mostly affect me since I’m the one writing the base CASP files lol. I am making my work environment better so that I can do better work, and I wish to thank me for taking the time to add one of my requested features.