I was vaguely aware of the concept of a state machine before this jam but hadn't really seen the significance. A thing moves between different states? So what? But my collaborator @ruruie had their eye on it and pointed out that the mechanic in our game (https://ldjam.com/events/ludum-dare/55/witch-courtier) where the cursor is variously a wand, a paintbrush, painted different colours, etc., would be a perfect use case. This turned out to be a fantastic idea.

I followed the tutorial here: https://gdscript.com/solutions/godot-state-machine/ and pulled the logic managing entry, exit and behaviour for each cursor type into self-contained classes that the 'cursor' class could swap out as needed. What would previously have produced a byzantine, bloated and bug-prone mess of tracking variables and conditional branches split into a handful of easily manageable files. Whole new behaviours could be plugged easily into place. My only regret is I didn't use more of them and that I wasn't architecturally stricter once the pattern was laid down (I say that part after every jam).

If your code is full of conditionals, state variables and bloated classes, ask your doctor if state machines are right for you.