Scripting Simple AI Opponents in Browser Games
Most browser game opponents are not learning anything. Here is how finite state machines and simple heuristics create convincing enemy behavior without machine learning.
When people hear "AI opponent" in a video game context, many picture something closer to machine learning — an opponent that studies the player and adapts. Almost none of the enemies in a typical browser game work that way. The tank that chases the player in a top-down shooter, the guard that patrols a stealth level, the racer that takes the corners smoothly — nearly all of them run on much older and far simpler techniques that have nothing to do with training data or neural networks, and understanding those techniques explains both why browser game enemies sometimes feel eerily competent and why they sometimes get stuck walking into a wall.
The Finite State Machine: The Workhorse of Game AI
The dominant technique behind the overwhelming majority of enemy behavior in browser games is the finite state machine, a structure where an enemy exists in exactly one of a small number of named states — patrol, chase, attack, flee — and switches between them based on simple conditions. A patrolling guard switches to chasing when the player enters its line of sight; a chasing enemy switches to attacking once it gets within range; an enemy at low health might switch to fleeing. Each state has its own simple logic for what the enemy does while in it, and the entire apparent intelligence of the opponent is really just this small set of states and the rules for moving between them, evaluated fresh every frame.
Why State Machines Feel Convincing Despite Being Simple
A well-designed state machine with only four or five states can produce enemy behavior that feels surprisingly reactive, because the transitions themselves, not the number of states, are what create the illusion of decision-making. An enemy that notices the player, closes distance, attacks, and then breaks off to regroup when reinforcements arrive is running through the same four or five states as a much dumber enemy that just walks in a straight line, but the added transition logic around noticing, regrouping, and coordinating with nearby enemies is what separates AI that feels engaging from AI that feels like a moving obstacle. Much of what separates a good browser game's combat encounters from a mediocre one is not more sophisticated AI technology but more carefully tuned transition conditions on the same underlying state machine structure.
Pathfinding Is a Separate Problem From Decision-Making
Deciding to chase the player is different from actually finding a route to reach them around obstacles, and browser games handle this second problem with pathfinding algorithms, most commonly A*, which searches a grid or node graph for the shortest walkable path while accounting for walls and terrain. A* is computationally cheap enough to run in real time inside a browser tab for reasonably sized levels, which is why it remains the standard choice decades after its introduction rather than being replaced by something more elaborate; the decision-making layer built with a state machine tells an enemy what it wants to do, and pathfinding separately tells it how to physically get there.
Difficulty Tuning Without Rewriting the AI
Because state machine behavior is governed by numeric parameters — detection radius, reaction delay, attack frequency — adjusting difficulty rarely means writing smarter logic at all. An "easy" enemy typically runs the identical state machine as a "hard" one, just with a shorter sight range, a longer pause before reacting, and less accurate aim, the same pattern discussed in how browser chess and checkers engines scale difficulty, where handicapping an existing system is almost always cheaper and more reliable than building a genuinely separate, weaker one from scratch.
Why Machine Learning Rarely Shows Up in Browser Game Enemies
Training a genuine machine learning model requires data, compute, and a level of unpredictability that most game designers actively do not want, since an enemy that behaves unpredictably is harder to balance and harder for a player to learn to beat fairly. A finite state machine is not a limitation developers are working around; for the vast majority of browser game genres it is a better tool than a learned model would be, because it is predictable, cheap to run on any device, and easy for a designer to tune by hand until the encounter feels exactly right.