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.