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 for that first build: the game world wasn't one continuous environment, it was a series of procedurally generated segments created ahead of you and destroyed behind you as you moved. At any moment, only a fixed number of segments existed in memory. New ones spawned at the front; old ones despawned at the back. (The rebuilt version live today reaches the same place a simpler way — see the last section.)

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.

Six Obstacle Types, Each Requiring a Different Response

The obstacle set came out of the initial generation, but the logic behind it was deliberately designed. Six types ship today, the last three unlocking as you climb the levels, and each asks for a different physical response:

• Barriers are holographic walls at waist height — you jump over them
• Crates are solid boxes a jump will not clear — you switch lanes
• Laser beams cut across the road at knee height — you slide underneath
• Moving barriers (level 3+) oscillate between lanes, with an arrow showing which way
• Double crates (level 4+) block two adjacent lanes at once
• Road gaps (level 5+) are holes in the surface — you jump 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 crates are particularly easy to confuse in split-second situations — they look alike and want opposite answers — which creates the tension that makes longer runs feel like genuine skill expression.

The procedural generation distributes these down the road in ways that occasionally create compound challenges — a crate in the centre 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 upgrade store — reachable from the main menu and from the game-over screen — where gems buy seven permanent upgrades at 300 to 800 apiece: extra lives, a score multiplier, gem value, a head start, magnet range, shield hits, and a higher power-up spawn rate.

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 for the next upgrade tier — or for the 200-gem revive that buys back one life when your last one goes. 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 procedurally generated too. Single gems drop into a random lane; every fifteen to twenty-five seconds a scheduled pattern fires instead — five gems in a line, five zigzagging between two lanes, or a three-gem arch whose middle gem floats high enough that you have to jump for it. There is no lane weighting: the risk you take is whichever lane the pattern happens to run through.

Four Visual Themes and How They Work

The visual themes were one of the first things we asked for after seeing the initial output. The game mechanics worked. The presentation needed more variety. Four themes ship today: Cyber City, Neon Forest, Space Station, and Volcano.

What the AI built was a theme system that swaps the colour palette, sky gradient, rail colours and ambient sky particles on level transition. Cyber City is the default — near-black sky, cyan-and-magenta rails, drifting flares and floating signs. Neon Forest goes green on green. Space Station shifts to violet and deep blue with comets crossing the sky. Volcano burns orange, with embers instead of comets.

The same obstacle patterns and spawn logic run under all four 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.

Cyber City runs from level one. Neon Forest takes over at level three, Space Station at five, and Volcano at seven. 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 so the collision volume matched the drawn geometry rather than the bounding box around it.

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 swipe distance — thirty pixels of travel before a touch counts as a direction — 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 being built from the same handful of 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 seven 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 new skins in the store: Shadow Ninja, Astro, Cyber Gorilla, and Neon Cowboy. The roster stands at eight today, counting the free Neon Runner you start with.

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 gem economy survived the rebuilds intact. The segmented track did not: the version live today has no segment model at all — obstacles and gems are pooled objects that spawn at the far end of the road in a random lane and get recycled once they pass you. The renderer, the character, the skin system, and the performance scaling are all post-rebuild work too.

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