Every game we build teaches us something we didn't know we needed to learn. With Path Runner, the lesson was about procedural generation — specifically, how much a system you didn't design can shape the entire feel of a game.

The brief was simple: an endless runner with a 3D perspective. Run forward, dodge obstacles, don't fall off. Classic genre, well-understood mechanics. We expected the hard parts to be the 3D rendering (no game engine, just a browser canvas) and the obstacle timing. Those were hard. But the thing that took the most iteration — and produced the most interesting surprises — was the procedural generation system the AI built without being asked to.

The Initial Brief

The prompt was roughly: a 3D endless runner. Three lanes. The player runs forward, obstacles appear ahead, you dodge them. Collect something along the way. That was it — no specifics about how far it should go, what the progression looked like, or how the world should be structured.

What came back was more architecturally complete than we expected. The AI chose a segmented track model: the game world isn't one continuous environment, it's a series of procedurally generated segments that get created ahead of you and destroyed behind you as you move. At any moment, only a fixed number of segments exist in memory. New ones spawn at the front; old ones despawn at the back.

This is a standard approach for endless runners — but we hadn't specified it. The AI arrived there independently because it's the right solution to the "endless world in a browser" problem.

The 3D Rendering Approach

Path Runner renders 3D entirely in a browser canvas — no WebGL, no Three.js, no external library. The AI used a technique sometimes called "pseudo-3D" or "Mode 7" style rendering: objects are drawn from back to front with scaling applied based on their Z position. Things further away are drawn smaller; things close to the player are drawn larger. The track floor is drawn as converging trapezoids. Combined with movement speed, it produces a convincing sense of forward motion through a 3D space.

The limitation of this approach is that it's not true 3D — you can't freely rotate the camera or do anything that would break the projection. But for an endless runner where the camera always faces forward, it works well and runs at full frame rate in any modern browser with no dependencies.

We spent a few iterations adjusting the perspective — the initial output had a vanishing point that felt too high, making the track look like you were always running downhill. Bringing the horizon down fixed it. That kind of visual calibration required actually playing the game rather than reading the code.

Three Obstacle Types, Each Requiring a Different Response

The three obstacle types came out of the initial generation, but the logic behind them was deliberately designed. Each requires a different physical response from the player:

• Barriers block the path at waist height — you jump over them
• Archways are low overhead structures — you slide underneath
• Rocks sit in a single lane — you switch lanes to avoid them

What makes this interesting from a design standpoint is that each obstacle type engages a different control. You can't develop a single reflex pattern for all obstacles — you have to identify the type and respond appropriately. Barriers and Archways are particularly easy to confuse in split-second situations, which creates the tension that makes longer runs feel like genuine skill expression.

The procedural generation distributes these across segments in ways that occasionally create compound challenges — a Rock in the center lane forcing you to one side just as a Barrier appears there. These combinations weren't pre-designed. They emerge from the distribution algorithm, and the best ones feel genuinely surprising.

The Gem Economy: An Unexpected Addition

Gems were in the original brief as "collect something along the way." What we didn't specify was what you'd do with them. The AI added an in-game store — accessible between levels — where you can spend gems on extra lives and score boosts.

This was one of those cases where an unasked-for addition genuinely improved the game. Without the store, gems are just score. With the store, every run has a secondary objective: bank enough gems to buy back a life before the next segment. Players who are struggling to survive have a meaningful way to extend their runs. Players who are already surviving well can skip the store and just push their score.

The gem spawn system is also procedurally generated, distributed across segments in patterns that reward center-lane running (the most dangerous line, since all three obstacle types appear there). High-risk lanes have higher gem density. That balance emerged from the generation parameters — we didn't specify it.

Three Visual Themes and How They Work

The three visual themes — Forest, Ice, and Cyberpunk — were one of the first things we asked for after seeing the initial output. The game mechanics worked. The presentation needed more variety.

What the AI built was a theme system that swaps the entire color palette, sky, and environment geometry on level transition. Forest uses warm earth tones with tree silhouettes and a daytime sky. Ice shifts to cold blues with sparse geometry that suggests frozen terrain. Cyberpunk goes dark, replacing organic shapes with hard geometric corridors and neon-tinted edges.

The same obstacle patterns and segment generation run under all three themes — the procedural logic is theme-agnostic. This meant adding a new theme was a matter of writing a new color configuration, not redesigning the generator. The architecture supported variation correctly from the start.

Players who complete level one get Forest. Level two: Ice. Level three and beyond: Cyberpunk. The themes add visual novelty to what would otherwise be an identical environment across sessions, which matters for replay durability.

What We Had to Fix

The first version had a collision detection issue: obstacles registered hits from slightly outside their visible geometry, which felt unfair — you'd appear to clear an obstacle and still lose a life. The hitboxes needed shrinking, particularly on Archways where the visual arch left significant open space that the collision volume was filling incorrectly.

The gem magnetism was also off initially. Gems would appear briefly, then despawn before players could reach them. The despawn timing was tied to segment removal rather than a fixed duration, which caused segments at higher speeds to have gems that were effectively uncollectable. Decoupling gem lifetime from segment lifetime fixed it.

Mobile touch controls needed a second pass. The initial implementation was swipe-based but didn't clearly distinguish between a swipe intended as a directional input and an accidental drag. Adding a minimum velocity threshold for swipe detection eliminated most false triggers — the same problem Neon Snake had, and the same solution.

What Makes Path Runner Different

The endless runner genre has well-established conventions. What the procedural generation adds to those conventions is genuine session-to-session variety — not cosmetic variety (different skins on the same patterns) but structural variety in obstacle placement and gem distribution. Every run is built from the same components but assembled uniquely.

That's harder to appreciate in a screenshot than to feel while playing. The best way to understand it is to play two runs back to back and notice how different the opening sequences feel despite using the same three obstacle types.

The Rebuild (and the Rebuild Before That)

Most of this post describes the architecture that shipped at the end of 2025. Several months later, that code stopped working. Not in a small way — Path Runner went from running cleanly to refusing to start, with cascading symptoms: an AudioContext crash that took out the start button, missing methods that should have existed, a full black screen on first frame. We spent a day chasing fixes through the existing code (defensive resize, delayed first frame, removing redundant black fills, aggressive cache busting). None of them stuck.

The next morning we made the call to throw the architecture out. The first rebuild went the other direction — back to a clean 2D lane runner, no pseudo-3D at all. That worked, but it gave up everything that made the original Path Runner feel distinctive.

Two days later we threw that out and rebuilt the 3D version from scratch as the premium perspective renderer that's live today. Over roughly two and a half hours that evening, fifteen documented iterations shipped in sequence — combos, milestone levels, screen shake, four power-ups, four environment themes, an upgrade store with five upgrades, near-miss scoring, daily challenges, four character skins, a first-time tutorial, gem trail patterns, motion trails, boss encounters, in-game achievements, a styled HUD with vignette and glass blur, premium character art with twenty-plus draw calls per frame, faceted gems, atmospheric environment effects, and a deeper sky with moon, planet, clouds, and silhouette layers. The fifteenth iteration was the final one.

A separate single-morning burst the next day rebuilt the runner character from the ground up — a complete chibi redesign — and added a 360-degree sprite turntable for the upgrade-store skin preview. The turntable went through about ten iterations in two hours: 8-frame, then 16-frame, then 32-frame, then trig-computed orbital properties to keep ears and trims rotating in sync with the body, then mutually-exclusive front-and-back details to avoid double-rendering. By the end of that morning there were four distinctive skins in the store: Ninja, Astro, Gorilla, and Cowboy.

A few days after that, an adaptive quality tier system landed for low-end tablets — the renderer now disables the more expensive effects when the frame budget is tight, so older devices get the same gameplay at a lower visual fidelity rather than a stutter at high fidelity.

The current shipping version of Path Runner is the result of those compressed bursts plus a steady cadence of smaller fixes since. The original procedural-track architecture and gem-economy logic from the December ship still hold — those parts didn't need rebuilding. The renderer, the character, the skin system, and the performance scaling are all post-rebuild work.

Related: Path Runner Tips: How to Survive Long Runs and Maximize Your Gem Score · Free Online Endless Runner Game – Play Path Runner in Your Browser · What Is Vibe Coding? · Vibe Coding Tools: From Chatbots to AI IDEs