What Robber Games Actually Are and How They Work

Robber Games is a loose category that covers any game where the core loop involves planning a heist, sneaking past guards, stealing loot, and escaping. That's it. Some are serious simulation games like Dishonored or Hitman where every frame matters. Others are quick casual browser games where you tap buttons to pick locks and dodge cameras. The term shows up everywhere from indie dev portfolios to app store search results, and the quality gap between the two extremes is massive. I built a simple browser-based thief game a few years back for a prototype competition. What I learned was not at all what I expected going in.

How to Design Robber Games That Actually Feel Good

The first thing people get wrong is the pacing. You need the tension of almost getting caught and the release of getting away clean. Most beginner implementations swing too far one direction — either the guard sees you every four seconds (frustrating) or they never spot you (boring). The sweet spot is a detection radius that covers maybe 60 percent of the play area, with a cone-of-vision mechanic rather than a simple distance check. That means a guard can be two feet away but still not see you if you're behind them. For movement, give the player three states: walk, run, and crouch. Walk is quiet but slow. Run triggers noise alerts and movement detection but covers ground fast. Crouch reduces detection radius by about half and lets you hide in shadows, but you move painfully slowly. The tradeoff between speed and stealth is where the actual gameplay lives. If you can always run everywhere without consequence, the game becomes trivial. If you have to crouch-walk the entire level, it becomes tedious. AI pathing for guards needs a system. Here's a basic one that works:

State machine approach: Each guard cycles through PATROL, ALERT, SEARCH, and RETURN states. In PATROL, they follow a waypoint route with random pauses. When they spot the player, they shift to ALERT, move toward the last known position, then enter SEARCH mode where they check nearby areas with a limited timer before returning to patrol if they fail to find anything.

The SEARCH timer is critical. Set it too high and guards never go back to normal — the whole map feels hostile. Set it too low and they forget you immediately, making the game pointless. I found 8 to 12 seconds to be the right window for most level sizes.

A Real Problem I Hit and How I Fixed It

During testing of my prototype, I ran into a specific issue where players would exploit guard turn-around timing. The AI would patrol back and forth along a corridor, and if a player timed their movement to start walking the moment a guard turned away, they could clip through the detection cone without actually being inside it. This happened because my distance-based detection wasn't checking whether the guard was facing the player. The fix was straightforward but easy to miss: add a dot-product check between the guard's forward vector and the vector to the player. Only register a detection if the player is within the cone angle AND the guard is roughly facing them. I used a 70-degree cone half-angle which felt natural — wide enough to catch distracted players, narrow enough that flanking actually worked. Another edge case that took me longer to solve involved the line-of-sight check. I was using simple raycasting from the guard's eyes to the player, but the ray would sometimes pass through a thin wall corner and register a false detection. This made guards seem paranoid in corner-heavy level designs. I solved it by adding a small buffer zone — the raycast origin offset by 0.3 meters in the guard's forward direction before checking. That tiny adjustment eliminated the corner peek false positives and made guard behavior feel much more believable.

Common Pitfalls in Robber Games Development

The biggest mistake is giving the player too much information upfront. Beginners often put guard vision cones on screen or show patrol routes clearly because they want the player to feel smart when they figure things out. Instead, keep that information hidden until the player discovers it through repeated failures. When a guard catches you, only then reveal a brief outline of where they were looking. Let the player earn the knowledge rather than handing it over. Audio design matters more than most people think. Footstep sounds should change based on surface type — carpet muffles, metal clanks, wood creaks. Give the player subtle audio cues when they're about to be heard. I added a soft warning chirp when a guard's attention angle was within 15 degrees of the player's position. It was enough to make experienced players tense up without being so obvious it ruined the surprise. Level design for these games follows a specific pattern that works reliably: start with a single room and one guard to teach the basics, add a second guard with overlapping patrol routes to introduce timing, then expand to multiple rooms with doors and windows as escape routes. By the time you reach the final area, the player should already understand the systems and just need to apply them under pressure.

Tools and Platforms for Building Robber Games

Unity and Godot are the standard choices. Unity gives you more asset store options and a larger community for tutorials. Godot is lighter and simpler if you're working solo. For a basic project, either one will get you to a playable prototype in about two weekends if you already know the engine. If you want something faster, Construct 3 or GameMaker let you skip coding entirely and focus on level design and logic flow. The tradeoff is less flexibility down the line, but for a first robber game project that speed advantage is real. I've seen complete prototypes ship in under a week using Construct 3. For AI specifically, you don't need anything fancy. A state machine with 4-5 states is sufficient for 90 percent of robber games. If you find yourself reaching for behavior trees or utility AI, step back and ask if a simpler system would work — it probably will. These games are about player expression within constrained spaces, not complex AI simulations.

Robber Games as a category thrive on repetition with escalating difficulty. Each level should reuse the same core mechanics but introduce one new variable — a motion sensor, a second guard floor, a locked door requiring a key pick, a camera that rotates on a schedule. That pattern of familiarity plus one twist is what keeps players coming back without feeling like they're doing the same thing over and over.