Likely still won’t work with fastpath, but you’d need to try it out.
Either way, almost all states are mutually exclusive.
Programmatically a switch/case statement would therefore be faster than individualized booleans.
However individualized booleans allow you to play with states too.
Meaning you can gate something up so that it is only avaliable but still toggled from within a different state.
(Example case, dash - locked into sprint, as a ground slide).
And the only reason you have never questioned it at all is that literally all engine examples do it the wrong way.
And yes, it’s wrong.
You double up the memory footprint of the project for no reason at all.
Sure, a PC won’t care. Try doing something like that on a Gameboy game or something with equally insignificant resources…
There’s one thing to consider, and that is the cost of fetching a variable that isn’t directly part of the character from the character for value checking.
Yes, using a localized boolean would be “faster” in theory.
But looking up a boolean (or anything else) has a near insignificant cost regardless of how you have to access it.
Surely, it’s less of a cost to performance than having to keep 2 booleans of the same exact thing in sync across 2 different systems (requiring a lot of calls from one to the other).
So it’s, as always, a give and take.
Except for in this case, since you do calls manually only when needed, there is almost no take, and just sheer performance optimization to do it the “correct” (and fastpath approved) way…
One possible exception would be updating the speed variables. Because they happen on a per tick basis and not in an “alacarte” style.
I have several things running that way. (Updating the animbp speed variable, checking against it, and updating it again)
Never noticed much of a difference.