A finite state machine (FSM) is the classic way to control a game character’s behavior. The character is always in exactly one of a small number of named states - patrol, chase, attack, flee - and transitions between them when certain conditions become true. Each state runs its own code while active. FSMs are easy to understand, cheap to run, and were for decades the default for non-player-character AI in games.
Jeff Orkin’s GDC 2006 paper on F.E.A.R. states the conventional wisdom plainly: if you polled developers for the most common AI techniques, “undoubtedly the top two answers would be A* and Finite State Machines (FSMs). Nearly every game that exhibits any A.I. at all uses some form of an FSM to control character behavior, and A* to plan paths.” The FSM’s weakness is scale. As designers pile on behaviors, the number of states and the transitions between them explodes, and the machine becomes a tangle that is hard to extend or debug.
Two influential responses to that complexity both came out of the mid-2000s. Damian Isla’s Halo 2 work pushed toward hierarchical state machines and behavior trees, which keep complexity local in a tree structure. F.E.A.R. went the other direction, shrinking the FSM to just three states (Goto, Animate, UseSmartObject) and moving all the sequencing logic into a separate planning system. Both kept the FSM as a foundation but added structure on top to manage growth.
Why business readers should care: the FSM story is a textbook case of a simple, beloved tool that scales badly. The fixes - hierarchy on one hand, declarative planning on the other - mirror the choices teams face whenever hand-written rules start outgrowing what a person can maintain.