So.

This is embarrassing.

While working on a personal project, I discovered a pretty major flaw with TrueState. This isn't just a bug that I can fix and release an update for, it is a fundamental issue with my approach for defining and switching between states using TrueState 3.0. It would appear on the surface to make using 3.0 easier than 2.3 or earlier... but that isn't necessarily the case.  Let me explain so you can get an idea of what the problem is and how I plan to fix it.

Currently in 3.0, your state is basically a function. The function serves as the primary identifier for any state as well as the logic that drives the state. When I did this, I decided that I no longer needed to provide a unique identifier for that state... or really even "define" a state at all. You just say "this is the state/function I want to start in, and I'll trust that that state is capable of moving between states as necessary."

Again, on the surface, this seems great. You no longer needed to define a state, which was something I often forgot to do when adding a new state; it was very annoying and I was excited to not have to do it anymore. 

But by doing this, I made something else much, much more difficult.

Let's say I have a parent object - my objActor- that implements TrueState and has 10 or so generic state scripts. So the default state might be stateActorIdle. That function can swap to stateActorAttack or stateActorJump or stateActorWalk based on input from the player or the AI. It could even detect that the object took damage and switch to stateActorHitReact or stateActorDeath.

This is great, right? I just define the state machine with an entry point: stateActorIdle and it just handles swapping between all the different states without the need to define them.

But what happens if I add a new monster to my game. And its attack is very, very different from the generic actor's attack. It's not just swinging a weapon, but it's shooting a projectile, or doing a complicated movement sequence as part of its attack. Everything else continues to work the same... I just need that one state to behave differently.

But that's the problem. If I start at stateActorIdle and press attack, that function is ALWAYS going to go to stateActorAttack. The only way to get it to go to stateSpitterAttack and execute that unique, complicated state, I would need a new stateSpitterIdle. And stateActorWalk goes back to stateActorIdle when I'm no longer walking, so now I need a unique stateSpitterWalk that knows to go back to stateSpitterIdle when I stop holding a direction.

Essentially, if you want to change one state you have to rebuild ALL states from scratch. You could do some copying and pasting, sure. You could try to make generic functions that each state could use to share common behavior... and you should be doing that anyway... but you will still need a unique function for every state that object can use just because you wanted one to be slightly different.

To me, that is unacceptable. And it's embarrassing I didn't see the issue sooner.

So what's the fix?

The return of state definitions with labels. You add states to a state layer using a unique function, passing the state function and a unique identifier for that state.  You will use that identifier to switch to that state... just like TrueState 2.3. This means that you can overwrite the function that is associated with a specific unique state ID for a specific object, and every other state will continue to work just fine.

It's tedious, yes. But the advantages it provides are just too important to how I feel TrueState should be used. So I'll be updating TrueState 3.0 to work like this, updating the documentation, and then will upload it the source when ready.

I'm still actively in the process of making this change. I'm hoping that I can continue supporting the current method as well to allow you to use the definition-less state approach... but I'm not 100% sure that's possible I'll let ya know when it's all up and running again.