It’s one of those conversations that starts politely and ends with everyone drawing diagrams on napkins. Let’s have it properly.
The case for blend trees
Blend trees give you beautiful, continuous, organic transitions. When they work, they really work — smooth weight shifts, natural speed-to-stride matching, satisfying directional blending. They’re expressive in a way that feels close to hand-animating every frame. For character locomotion with lots of directional variety, blend trees can produce results that feel remarkably natural.
The downside? They get complicated fast. A sprawling blend tree with dozens of parameters starts to feel like debugging spaghetti. And when something breaks at runtime, good luck narrowing it down.
The case for state machines
State machines are explicit. Every state, every transition, every condition — it’s all documented in the graph. They’re easier to reason about, easier to debug, and easier to hand off to a gameplay programmer who’s never touched animation before. In large teams, that clarity matters a lot.
The criticism is that they can feel mechanical or snappy if you’re not careful about your transition logic. But a well-designed state machine with solid transition blending and careful timing can feel incredibly natural.
Where it gets interesting
Most modern engines let you nest these — blend trees inside state machines. Which gives you the expressiveness of blending where you want it, and the legibility of state logic everywhere else. Is that the answer? Or is it just the worst of both worlds if you’re not disciplined about it?
Where do you land on this? Do you have a strong preference? Has a project ever forced you to rethink your default approach? Drop your take below — I genuinely want to know how different people are solving this. 