Hi everyone, Gabriel here, today I’m going to give you some more insight about how we are giving life to Bit. Right now, we have been testing a lot of different game features and skills that Bit have/will have, and iterated a lot on them to make them feel right, i’d say we are now at 70% from completing all of Bit’s abilities (at least the ones that are in the table right now XD).
We like to describe BitUp as an “action exploration adventure”, and that basically means that you will have fights, investigation and platformer-ness (I hope thats a real term) and for me that means that we need to handle very different states.
ENTER STATE-MACHINES
I am using a simple state machine implementation to handle all Bit code, all the states have three different functions: OnStart, OnUpdate and OnEnd. OnStart handles that specific state initialization code, things like triggering an animation, changing physics modes, applying input changes and so on. OnUpdate gets called from Tick every frame and OnEnd gets called when a new state is pushed.
Changing states is done via different events like input events, landed, take damage and others like that, when a state is pushed, first it needs to see if there’s a valid transition from the current event to the new one, if not, it is ignored, and if there is, the transition calls OnEnd from the last state and OnStart on the new one.
POINTERS!
I like to implement states as function pointers that change to the current state functions. that allow me to just call the current function from the pointer in the Tick. To be able to do that in a UCLASS I needed to use some special sauce that I extracted from this amazing (and short and easy) post from Rama (thanks a lot Rama!). That’s why in the Tick function all you need to do is this:
// Perform update based on the current state
(this->*(OnUpdateStateArray[(uint8)CurrentState]))(DeltaTime);
TO-DO:
Currently my state machine in the code matches the animation blueprint state machine almost entirely, so I think an improvement could be somehow to automatically handle both by the same code, and while I can easily control all animation from code, that doesn’t allow Josh (our animator) to see and test the animation changes and flow visually in the editor, that’s why I need keep the animation blueprint separated for now, even though that has been creating some very specific bugs about animation changes that happen in the same frame (I’m looking at you animation montages!).
So that’s it from now, I hope you all can find something useful here! FYI we have a forum post about BitUp here in the UE4 Forums so if you want to know something or ask me specifics you can do it there or in my twitter!
Thanks and see you later!
Gabriel
