Quick update: the base state warning is coming back, this time a bit improved and with proper metadata! Also since at the moment warnings are treated as errors and stop compilation you have to live with it.

So quick refresher, Castagne is very flexible and allows you to call upon other states to add code. This is great, but can result in issues when being careless: you could execute some base code twice, or not at all, which makes for all sorts of cursed bugs, but it’s not something Castagne can just guess. Some states are meant to be used as simple snippets of code to a bigger state, so it is only known to the writer. The previous version had a little failsafe I added a bit later in dev: states could either be marked as helper with _Helper(), or as a base state with _BaseState(), or could inherit from a base state (which unfortunatly didn’t go through the whole tree for various reasons. If not in one of these three cases, a warning would be raised.

In the new version, this helper / game state dichotomy is enshrined: Helper states have a () after their name. This already handles half of the problem, then I’ve also added the new BaseState metadata for the other half. This works much better than before:

• The property does propagate properly, meaning the only base states currently are Common and Init. NeutralState for example just takes it from Common.
• The engine now properly detects when a base state is called twice or more, and can tell you which calls it’s taking it from.
• States can’t be both base and helper anymore, which reduces some edge cases.

I’ve added 4 different warnings with explanations, although here’s the most likely one:

This should result in much cleaner code and more guidance for beginners, and a bit more stability for your own games. When in the last update I talked about doing things properly and taking a bit more time, this is the kind of feature I meant: while not mandatory, implementing it when I feel it’s starting to be needed allows the whole codebase to be more harmonious and stable, and allows me to handle pain points early. I notice a lot of problems when coding the engine, so by the time it gets in your hands the main usage at least should be fairly efficient. Having a strong base also means that bug reports get integrated and treated better, and don’t come back as often.

The hidden news behind this one is that the attack type system is back and better than before, as well as the new attack duration management, but it’s hard to see the whole picture in its current state. Still some big areas to work on systems-wise, but bit by bit they are getting done.

See you next update! I’m mostly building and fixing the whole attack flow right now. Forum and videos are still on my mind too.