(2026-04-15) EdSpec Trace, FG Movement

Yo, managed to get regular fighting game movement back into the engine, it’s cool

Look I made so it also leaves a trace in the EdSpec viewer, gonna have to hook up the camera to it too later

Looks smart and technological therefore the new editor is a million times more advanced

Still writing the base gameplay but better, got some time before all mechanics are online but we’ll see

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