From Runnable to Replayable: The Full AI-Assisted Production Pipeline of PaperRoute

Don't Talk Style First — Make the Gameplay Stand

The author's first step was to rewrite the game idea into a brief, using a classic paper-delivery mechanic as reference but not requiring the model to copy it. The priority was solving hard mechanical problems: camera placement, bike movement, newspaper trajectory prediction, delivery scoring, and level completion. Art direction was deliberately suppressed because early style demands often distract the model from making the game playable.

On the first night, a deterministic browser simulation emerged: newspapers flew along parabolic paths shown by dashed lines, mailbox deliveries scored points, and the route ended in a park training area. Crucially, the model wrote tests alongside mechanics, ensuring every later change — camera, characters, assets — could be regressed against a stable baseline. Many "one-shot generation" demos fail not because they don't run, but because they aren't designed to be continuously improvable .

Separate Game Direction from Art Direction to Let Each Improve

The author split work into two tracks: game direction (controls, throwing, hostile agents, collisions, level pacing) and art direction (camera feel, environment, materials, characters, overall mood). Mechanics and visuals influence each other but must not compete for the same feedback channel — when a house looks wrong, the newspaper physics shouldn't be rewritten; when dog chase logic breaks, the art spec shouldn't be overwritten.

For style, the author didn't feed a popular tag to the model. He built concept art and a mood board from a few reference images, then used actionable descriptions like "painterly texture, Japanese summer breeze cinematic feel" to iteratively lock color, lighting, and materials. Tags borrow someone else's finish; descriptions build constraints for your own picture. The efficient pattern is giving the model clear, non-conflicting subtasks while the project stays playable and the human retains directional control.

3D Assets Are Not a Single Image but a Reproducible Pipeline

Scene assets — houses, trees, fences, mailboxes — were generated via scripts in Blender's headless mode and exported as GLB files. The author first completed summer-style research, house silhouettes, tree shapes, and street props independently; by the second morning, seven house types existed. This makes assets a repeatable process, not just a result: when the neighborhood needs more density or a building proportion is off, modifying the script is easier than remodeling by hand. For AI collaboration, reproducibility is critical because model outputs vary, but scripts, parameters, and review standards persist.

Characters are harder. A rider with face, hair, clothing folds, and correct bike contact is far more complex than a house. Pure prompting didn't yield good results. The pragmatic switch: use image generation for concept, feed that to an external 3D generator for mesh, then bring it back for retopology, bike fitting, and rigging. The external tool cost about $8 for 300 image-generation credits (a personal usage note, not a universal quote). This illustrates that mature workflows know when to switch tools and break a hard problem into smaller, verifiable sub-problems.

Most Time Is Spent Not on Generation but on Review

About 80% of actual session time and agent turns went into polishing, fixing broken meshes, and detailing — not building the core game. The rider needed preserved face, hair strands, hat brim, fixed arm-sleeve intersections, kept shorts hem, calibrated handlebar position, and 23 bones including hair and coat tails. These seemingly trivial demands are exactly the gap between a "playable prototype" and a "shippable character."

The author realized 3D review must look at rendered output, not model claims. He built a capture script that posed the Three.js rider in turning, throwing, dashing, falling states and regularly rendered front, side, back, and gray-model turntables. Human inspection of images — e.g., "hat doesn't cover hair" — became the most reliable input for the next prompt round. This feedback design lets the model propose and execute fixes while the human specifies "what's wrong" precisely and judges whether the change moves the work forward. Taste here isn't mystical; it's a continuous loop of looking, deleting, keeping, and deciding when to stop.

What Makes a Game Memorable Are the Small Details in Independent Branches

With mechanics, scene, and character in place, the game still wasn't whole. The window-smash effect and rain system were built as independent experiments: separate branches, separate camera and effect tests, merged back only after passing. Changes included a dedicated smash camera that pulls in and swings back, an extended skate park at the route end so the level doesn't stop abruptly, puddle splashes and tire tracks, full rain, more personality-rich street NPCs, and richer mansions. These aren't core gameplay but decide whether the neighborhood feels like a world.

The author's verdict: AI rapidly compresses the time to "make it work," but it won't automatically know which non-essential details are worth doing. Great products come from restraint on redundancy and obsession over a few experience nodes. The same logic extended to the project website — not just a launch button, but a landing page, result page, and leaderboard unified in newspaper language. Only when the game, its interaction results, and its narrative wrapper speak the same voice does a web prototype become a complete "morning paper."

How to Interpret Those Staggering Numbers

The author's late-stage archive shows striking but carefully qualified numbers: tracking span July 1 to September 12; 39 hours of recorded coverage, with 25.2 hours marked human and 13.8 hours agent-only; 90 commits across 11 active days; 15.6 billion total tokens, of which ~15.3 billion were cache reads. The corresponding $2,175.36 is not an extra bill but a system back-calculation at later API prices. Agent runtime and coverage overlap, so they can't be summed. Human presence tracking only started September 6; before that the system assumed human attendance. The project also admits real-phone sustained 60fps hasn't been fully validated — one test hit 60fps, another averaged 58fps — and the rider mesh is ~88,550 triangles.

These limitations don't weaken the project; they make it more credible than a "fully automatic" marketing image because they expose the real costs of AI collaboration: cache and compute, review and rework, performance and compatibility, packaging and launch — none can be skipped.

Conclusion: AI Shortens the Middle Process, Not the Final Destination

Compressed into a reusable method, the record yields:

Write the brief in your own words to define gameplay boundaries first.

Establish direction with the closest reference, but don't surface-copy.

Build playable mechanics first, then layer in art direction.

Split engine logic and visual assets into separate workflows.

Make assets as scripted and reproducible as possible.

For high-difficulty objects like characters, don't force a single tool; bring in the right external step promptly.

Every change leaves a reviewable render and a regressable test.

Put weather, camera, event ideas into independent branches for trial.

Keep honest accounting of hours, tokens, and performance; don't treat a demo as a conclusion.

AI is compressing the repetitive, cross-tool, fragmented labor of indie creation into shorter cycles. But it hasn't removed creative judgment — it forces judgment to appear earlier and more often: which mechanic first, which visual to discard, which problem must be seen in the render, which small detail deserves its own branch. A game goes from "runnable" to "worth playing again" not through a single generation, but because someone is willing to put every generation back into the work and look at it seriously.

Translated from: builtbysketch article