Intelligent non-player characters bring a game world to life. In a farming simulation, villagers who walk purposefully between buildings, animals that graze realistically across pastures, and delivery NPCs who find the shortest route through your farm all depend on solid AI and pathfinding systems. Building these systems for the browser means working within tight performance budgets, but the algorithms themselves are well-understood and surprisingly efficient when implemented correctly.
This guide covers the four pillars of browser game AI: pathfinding with A*, navigation meshes for complex terrain, steering behaviors for natural movement, and decision trees for believable NPC behavior. Each section includes practical patterns you can apply to your own projects.
A* (A-star) is the workhorse algorithm for game pathfinding. It finds the shortest path between two points on a graph by combining the actual cost of reaching each node with a heuristic estimate of the remaining distance to the goal. This combination makes it both optimal (it always finds the shortest path) and efficient (it explores far fewer nodes than a brute-force search).
For a tile-based game, each tile is a node in the graph. Walkable tiles connect to their neighbors (four directions for cardinal movement, eight for diagonal). The cost to move between adjacent tiles is typically 1 for cardinal and 1.414 for diagonal moves. The heuristic is usually the Manhattan distance (for four-direction movement) or the octile distance (for eight-direction movement).
The naive implementation of A* uses an array for the open set, which requires scanning the entire list to find the lowest-cost node on each iteration. This becomes the bottleneck on large maps. Replace it with a binary heap (priority queue), which reduces the lookup from O(n) to O(log n). For a 200x200 tile map, this single change can cut pathfinding time from 15ms to under 1ms.
Other critical optimizations include:
Tile-based pathfinding works well for simple grid maps, but many browser games feature irregular terrain, curved rivers, winding roads, and open fields. Navigation meshes (navmeshes) represent walkable space as a set of convex polygons. NPCs can move freely within any polygon and traverse edges shared between adjacent polygons.
The advantages of navmeshes over grids are significant. A navmesh for a complex farm map might contain 200 polygons where a grid representation would need 40,000 tiles. Pathfinding on the navmesh graph is orders of magnitude faster because there are far fewer nodes. Movement within polygons is free-form and looks natural rather than snapping to a grid.
You can generate navmeshes from your world geometry using a process inspired by the Recast library. The basic steps are: voxelize the walkable surfaces, filter out areas that are too steep or too narrow for an NPC, build a contour of the walkable regions, and triangulate the contours into convex polygons. For 2D browser games, you can simplify this significantly by defining walkable areas as polygons in your level editor and running a constrained Delaunay triangulation.
| Approach | Best For | Node Count (typical) | Path Quality |
|---|---|---|---|
| Tile Grid | Simple grid-based games | 10,000 - 100,000 | Grid-locked movement |
| Waypoint Graph | Fixed-path NPCs | 50 - 500 | Limited to placed points |
| Navigation Mesh | Open-world / irregular terrain | 100 - 2,000 | Smooth, natural paths |
| Visibility Graph | Obstacle avoidance | Varies with obstacles | Optimal shortest path |
Pathfinding gives you a sequence of waypoints. Steering behaviors turn those waypoints into smooth, natural-looking movement. Craig Reynolds' classic steering behaviors, published in 1987, remain the standard approach and work beautifully in browser games.
The core idea is simple: each behavior produces a steering force vector. You combine multiple behaviors by weighted addition to get the final force applied to the NPC each frame. The fundamental behaviors are:
Pathfinding and steering handle the "how" of NPC movement. Decision systems handle the "what" and "why." A villager needs to decide whether to work in the field, eat lunch, visit the shop, or go home for the night. These decisions make NPCs feel alive.
The simplest decision system is a finite state machine (FSM). Each NPC has a current state (idle, working, eating, sleeping) and a set of transitions triggered by conditions (time of day, hunger level, task completion). FSMs are easy to implement, debug, and understand. For NPCs with fewer than ten states, they are the right choice.
When NPCs need more complex behavior, behavior trees offer a modular, composable alternative. A behavior tree is a directed acyclic graph of nodes that evaluate from root to leaf. The key node types are:
Behavior trees excel because you can build complex behaviors by composing simple, reusable subtrees. A "daily routine" tree might contain a selector that prioritizes urgent needs (hunger, danger) over scheduled activities (work, socializing), which in turn contain sequences of specific actions. Adding new behaviors means plugging in new subtrees without rewriting existing logic.
For the most organic NPC behavior, utility AI scores every possible action based on the NPC's current state and environment. Each action has a utility function that returns a value from 0 to 1. The NPC picks the action with the highest score, with optional randomization to avoid robotic behavior.
In a farming simulation, a villager's utility functions might evaluate: work (high when crops need tending, low when none are ready), eat (scales with hunger), socialize (increases with time since last conversation, higher when near friends), rest (scales with fatigue), and shop (triggered by low supplies). This creates emergent behavior that feels surprisingly lifelike without scripting specific routines.
A browser game running at 60 FPS has 16.6ms per frame for everything: rendering, physics, input, audio, and AI. Aim to keep your AI update under 2ms. Strategies to hit that budget include updating AI decisions at a lower frequency (every 500ms is fine for most NPCs), staggering updates so only a fraction of NPCs think each frame, and caching expensive calculations like line-of-sight checks.
Web Workers can offload heavy pathfinding to a separate thread. Post the map data and start/end positions to the worker, and it returns the computed path without blocking the main thread. This is especially valuable when many NPCs request paths simultaneously, such as when the player restructures their farm layout and all NPCs need to recalculate routes.
A well-implemented AI system transforms a farming game from a solo gardening tool into a living world. Animals that graze, sleep, and react to the player's presence. Villagers with daily routines, preferences, and relationships. Delivery NPCs that navigate around fences and through gates. Each of these uses the same building blocks: A* or navmesh pathfinding for route planning, steering behaviors for smooth movement, and behavior trees or utility AI for decision-making. The magic is in the combination.