FSM Debugger
The FSM Debugger is a tool that allows you to visualize your machines in real time. It allows you to monitor the current state of a machine, view the current data of any fields of any state in the machine, track and analyse how the machine has changed state historically, and see the machine change state as it changes state.
The debugger is an editor-only feature. It is currently not possible to use the debugger for runtime applications. It also imposes no overhead to runtime applications.
Open the debugger window via Window/Analysis/FSM Debugger
Outside of play mode, you'll see an empty window. For the purpose of demonstration, go ahead and in the window check Options > Show Editor Machines
This will display the state machine that controls the debugger window.
The window consists of 4 different panels, each of which is explained in detail below.
Here you can see all machines that exists in your environment. They appear in a tree-like list fashion. Selecting a graph will bring it up in the other views.
Some machines are nested under others. This means that the machine is in some way managed by the machine above it. Nesting machines is one way to build complex behaviours, and they are grouped in the view in this fashion as it makes it less cluttered.
The graph view is the graphical representation of your machine. It is generated from the machine you defined in code, and will show you the current state of the machine as it executes. Selecting a state will reveal it in the State Inspector.
This is the reminder for what the different colors for the graph view means. These colors allows you to determine which state is active, which state it came from, and which transitions are fired.
Hovering on the legend shows it in full opacity.
The state inspector view allows you to monitor the variables of any state in the machine. By default the currently active state is shown, but you can show any state by selecting it in the graph view. Use this view to check the state of variables the state operates on, to see if the state is acting on these variables as expected.
The history view is a list of changes that have occured in the machine during its' lifespan. It allows you to track the path the machine has taken through transitions and states to get where it is right now, allowing you to get an idea what happened when an unexpected sequence of behaviours occur.
The utility of the debugger vary greatly depending on your preference and scenario. Some common usages are listed below.
It can be difficult to intuit the graph you're building as you code. Viewing the graph view for the machine allows you to see if the layout of your states and the connections make sense.
Say you identify your boss monster getting stuck after a special attack, you can take a look at the boss' machine in the graph view. Is the state it's in a dead end? What transitions are possible? With this you can narrow down unexpected issues after they've occured. You can also note down the history of states to see how it can feasably be replicated.
You can use the graph view along with the state inspector to test features that have yet to gain any game world representation. Sometimes checking that a counter increments is sufficient to test that boss behaviour pattern!
As previously stated, it's currently not possible to debug runtime applications. Viewing machines is limited as an editor-only feature.
It is also not possible to view a machine before it has been created. This means if you want to check how your machine looks, you likely have to hit play mode first.