FSM for the dummies
When it comes to prototyping, you’ll want to create fast but robust games too. A way to manage efficiently the behaviors of your components is by using a Finite state machine (FSM) either by coding one yourself or, for speed purpose, by using tools like playmaker.
A FSM is a model containing a certain number of states(i.e run, walk), and change from a state to another given some conditions. It’s commonly used to organize your code, define and make transitions between your game states (game over, menu, ingame..), it’s used for AI behavior implementation (when the ennemy walk, follow, attacks..).
They are used to organize execution flow, and are mostly represented by a diagram. Your game object can have only one active state at a given time, and go from one state to another via transitions. Meaning it’s relatively easy to see at a glance the how the behavior of your game object are composed.
Usually starting from an idle state, and changing to various other states by checking some if some conditions are either true or false (is the player visible? if so follow him. If not continue walking).
Playmaker refers itself as a visual scripting component, meaning that you can make a full game without hard coding into classes, just by relying on the little snaps of visual codes that playmaker provides.But believe me, it’s bad. As bad as crossing the streams in ghostbuster.
While using wisely Playmaker’s FSM you’ll shorten the time passed on your project, as it’ll be easier to see which function is called, and when. At least if you don’t overuse it (as displayed above).