Directing AI Game Development from a Phone: A Programmer Couple Builds a Complete RPG with AI Coding

A Unique Two-Person Game Development Challenge

A programmer couple — together for 18 years, married for 13 — did something remarkably experimental: without any gameplay communication, they took turns developing a game using only a single phone. The only thing they were allowed to say when handing off was: "I'm done, your turn." Building on whatever came to mind, they ultimately created a complete RPG from scratch.

What makes this worth paying attention to isn't just the charm of "couple synergy" — it's how clearly it demonstrates the real workflow of AI-assisted programming today. Programmers no longer write code line by line. Instead, they use a mobile AI workbench to direct an AI Agent to execute development tasks — even while watching TV shows. The AI Agent here is fundamentally different from traditional code completion tools (like GitHub Copilot's inline suggestions). An Agent can autonomously execute multi-step tasks: it understands natural language requirements, plans implementation steps, writes code, runs tests, and self-corrects. The developer's role shifts from "writing code line by line" to "task scheduling and quality review." This reflects a profound transformation happening in the software development paradigm.

From Environment Setup to an Animated Character: Humans Still Control the Core Logic

The project started with the most basic environment setup: downloading Python and installing Pygame. Pygame is a Python game development framework built on the SDL (Simple DirectMedia Layer) library. Born in 2000, it provides fundamental features like graphics rendering, sound playback, and event handling. While it can't match the performance of commercial engines like Unity or Unreal, its extremely low learning curve and clear API semantics make it ideal for rapid prototyping — especially in AI-assisted programming scenarios, where Pygame's code structure serves as an excellent target framework for AI-generated code.

Next came a personified breakdown of team roles — "the designer dreams it up, the programmer makes it real, the artist makes it pretty" — a vivid summary of the three pillars of game development.

On the technical implementation side, the author demonstrated a clear progression path:

From Static Block to Animated Character

Step one: create a window and draw a stationary block. Step two: set velocity and handle keyboard up/down/left/right events to get a moving block. Step three: use AI to generate character sprite sheets, replacing the original block with a walking character. Step four: use AI to generate walking animations for each direction, store each frame sequence, and render the corresponding sequence frame based on an animation timer and player direction — resulting in a fully animated character.

The Sprite Sheet mentioned here is a core concept in 2D game development — multiple animation frames of a character are arranged on a single image, and the program crops different regions to play the animation. This technique originated in the era of early console hardware limitations, but remains widely used today due to its memory efficiency and fast loading speeds. The animation timer controls the frame switch rate, typically playing walk animations at 8-12 frames per second. Combined with selecting the correct frame row based on the player's facing direction, this produces smooth character movement.

The key takeaway from this process: AI handled the heavy lifting of image asset generation and animation frame creation, while the programmer retained control over the core architecture — rendering logic, event handling, and system design.

Building the RPG World: Scenes, Collision Detection, and Render Order

The wife, taking over development, decided to make an RPG. She first laid grass tiles for a full-screen scene, then added trees as obstacles.

Camera Follow: Keeping the Player Centered

By moving the scene in the opposite direction, the player always stays at the center of the screen — a classic RPG technique. In 2D RPGs, "camera follow" is essentially a visual trick: the player character's screen coordinates are fixed at the center, and what actually moves is the entire world coordinate system. This simplifies UI element positioning and makes it easy to implement map boundary restrictions.

Smooth camera easing was then added to make movement feel silky — "the code changes are minimal, very high cost-effectiveness." The easing effect relies on a linear interpolation formula: camera_pos += (target_pos - camera_pos) * smoothing_factor, where a smaller smoothing_factor makes the camera smoother but increases follow delay. This technique has built-in implementations in various game engines, such as Unity's Cinemachine and Godot's Camera2D component.

Classic Problems: Collision Detection and Rendering

Two typical graphics programming problems emerged during development. First, collision detection: since collision was based on the full image rectangle, objects would visually appear separated while their hitboxes were already overlapping. The solution was to shrink the collision box, using only the lower half of the player and tree for detection. This "separating collision body from visual body" approach is extremely common in 2D games — character images often contain large transparent areas (like headspace or flowing cloth edges), and using the full image rectangle for collision makes players feel "I clearly didn't touch it but got blocked," severely hurting the gameplay experience.

Second was the render order problem — the bizarre phenomenon of "the character walking on top of trees." The author's solution is highly representative: sort the character and trees by Y-coordinate, drawing smaller Y values first and larger Y values later, naturally achieving proper front-back occlusion. This is the standard approach for handling pseudo-3D layering in 2D games, commonly called a simplified version of the "Painter's Algorithm" — just like a painter draws distant mountains first and nearby trees later, later-drawn content covers earlier-drawn content. A larger Y-coordinate means "closer to the bottom of the screen," i.e., "closer to the observer," and should therefore be drawn last.

Monster System: The Trade-offs Between BFS Pathfinding and Direct Pursuit

Core gameplay requires enemies. The author progressively added monsters, monster movement, and monster pathfinding.

Three Pitfalls with BFS Pathfinding

The pathfinding phase was the technical highlight of the entire project, with three classic pitfalls:

BFS (Breadth-First Search) is one of the most fundamental graph search algorithms. In grid-based maps, it guarantees finding the shortest path. It works by starting from the origin, adding adjacent nodes to a queue, and expanding layer by layer until reaching the target. In commercial game development, A* is more commonly used — it adds a heuristic function (like Manhattan distance) on top of BFS to prioritize searching directions more likely to be near the target, dramatically reducing the number of nodes searched.

Infinite Loop Bug: The program froze completely — not even a traceback. The author's years of experience told him "this is an infinite loop, not a performance issue." The root cause: when the player's grid cell itself was an obstacle, the bat's pathfinding could never find the destination, causing an infinite loop. The fix was to have bats pathfind to a non-obstacle cell near the player. This type of bug is extremely hard to reproduce in automated testing because it depends on specific spatial state combinations — precisely the scenario requiring developer experience and intuition to diagnose.

Performance Bottleneck: 5 monsters means 5 BFS runs; 50 monsters means 50 BFS runs — linear growth. The author's optimization was brilliantly clever: invert the pathfinding logic. Instead of each monster finding the player, compute the path once from the player and reverse it, letting all monsters share the result — compressing N BFS calls into one. This is essentially the Dijkstra algorithm concept — computing a Distance Field from the target point to all reachable cells, where each cell records "steps to the player" and "which direction to move next." Regardless of how many enemies exist, each only needs to query the direction information at its own cell. This optimization is extremely common in RTS (real-time strategy) and tower defense games, known as "Flow Field Pathfinding."

The Final "Dimension Reduction" Decision

Interestingly, after accidentally deleting code, the author simply abandoned pathfinding entirely and had monsters chase the player in a straight line. The reasoning was pragmatic: "Bats can fly. There are no obstacles in the sky — just go in a straight line." This reflects the wisdom of real-world development trade-offs — not every feature needs an optimal solution. In game design, this "rationalizing simplified implementation through lore" approach is everywhere: flying enemies in The Legend of Zelda don't need ground pathfinding; ghosts in Diablo can pass through walls. These are all elegant compromises between design and engineering.

From Combat Systems to Level Design: Polishing Gameplay Layer by Layer

Subsequent development entered the gameplay polish phase: adding weapons (using orbital revolution and rotation formulas to circle around the player), kill feedback (hit stop, flash white, floating damage numbers), health bars for monsters and players, automatic monster spawning, item drops, and more.

The kill feedback design involves what game developers call "Game Feel" or "Juice." Hit Stop means the game pauses for 2-5 frames at the moment of impact, letting players feel the weight of their attacks — a technique popularized by the fighting game Street Fighter II. Flash White conveys hit information by replacing all sprite pixels with pure white for 1-2 frames. Floating damage numbers provide instant numerical feedback through eased animation (quickly rising then slowly falling while fading out). These seemingly tiny visual feedbacks have a far greater impact on player experience than one might imagine — indie studio Vlambeer systematically demonstrated in their 2013 GDC talk "The Art of Screenshake" that adding complete hit feedback to the same game can improve player satisfaction by over 40%.

The author's understanding of game design was quite solid: automatic monster spawning creates "something from nothing," giving players reaction time and strategic space; item pickups add variance and risk-reward gameplay; the level system progresses from easy to hard; a stamina system prevents marathon sessions and creates a gameplay loop; invincibility items are like Super Mario's star power-up, delivering a satisfying rush. These design details demonstrate that even though AI can write code, whether a game is "fun" still depends on human design expertise.

Core Insight: AI Is a Cognitive Amplifier, Not a Replacement

The most valuable insight of the entire project appears at the end. The author poses a question that cuts to the heart of the matter: if AI is this advanced, why bother teaching people to build from the ground up?

His answer deserves deep reflection from every developer:

"If you have AI directly produce a finished product without understanding the underlying principles, you'll know the 'what' but not the 'why.' When you want to add new features or fix bugs, if the AI doesn't understand what you mean, it could cost enormous amounts of time."

In other words, understanding collision detection, rendering logic, animation systems, pathfinding algorithms, and other foundational principles makes your communication with AI smoother. When problems arise, you can provide more professional prompts and locate issues faster. This aligns closely with the "Law of Leaky Abstractions" in software engineering — proposed by Joel Spolsky in 2002, stating that all non-trivial abstractions are leaky to some degree. When the abstraction layer breaks down, you must understand the underlying layer to fix it. AI, as a new layer of abstraction, follows the same rule. The author's conclusion is powerful:

"In the end, it all comes down to the person. AI's ceiling is determined by the person's ceiling. AI cannot generate anything beyond your cognition. It won't make what you've learned in the past worthless — it's an amplifier for everything you've ever learned. The better your foundational knowledge, the more powerful you become when using AI."

This can be understood through information theory: the quality of AI model output is limited by the information content of the input prompt. When developers can describe problems using precise technical terminology (e.g., "Y-axis sorted rendering" rather than "the character display is wrong"), the AI can more accurately understand intent and generate correct code. Foundational knowledge essentially increases the bandwidth and precision of human-machine communication.

A New Development Experience in the Mobile AI Programming Era

This project leveraged a mobile AI workbench to achieve a development experience of "directing an Agent to execute tasks while watching TV shows," supporting cross-window operations and mobile PRD writing, prototype design, and demo development. This would have been unimaginable just a few years ago.

The emergence of mobile AI programming workbenches represents a new stage in development tool evolution. From early command-line editors (vi/emacs), to desktop IDEs (Visual Studio/IntelliJ), to cloud IDEs (GitHub Codespaces/Replit), development environments have consistently evolved toward "lower barriers, less local dependency." Mobile workbenches push this trend to its extreme — developers only need clear requirement expression ability to advance projects in any context. However, this also demands higher standards for structured and precise requirement descriptions, since the experience of reviewing code line by line on a phone is far inferior to desktop.

But the real message isn't "AI replaces programmers" — it's a transformation of the developer's role: from code writer to system designer and AI conductor. And this ability to conduct effectively is built precisely on solid foundational knowledge. For all technologists worried about being replaced by AI, this is perhaps the best reassurance and the most practical action guide: foundational principles still need to be learned.

Key Takeaways