i created a unity mobile game prototype in 72 hours using ai tools and here is the hour by hour honest breakdown
I gave myself a challenge: take a game idea from concept to playable Android prototype in 72 hours using AI tools to handle as much of the work as possible. No prior assets prepared, no existing code reused. Starting from an empty Unity project. This is the hour by hour honest account of what I built, which AI tools did which parts, where I hit walls, and whether the final prototype was actually playable.
Priya Nair
June 26, 2026
The result: a playable Android puzzle platformer prototype with 5 levels, a main menu, level select, a simple scoring system, basic enemy AI, and a working Android build that installed and ran on my test device. Total hours across 3 days: not 72 continuous hours but 24 hours of actual working time spread across 3 days. Tools used: Claude for design, Cursor for all code, Muse Chat for Unity questions, Muse Texture for placeholder materials, Poly Haven for HDRIs and test textures. Could I have done this in 24 hours without AI tools? No. My estimate is 80 to 100 hours minimum.
Day 1: Hours 1 to 8
- Hour 1, Claude game design session: I described a simple mechanic concept to Claude: a puzzle platformer where the player controls gravity direction instead of the character. Claude helped me work out the core loop, win and fail conditions, the minimum viable feature set for a prototype, and a basic level progression structure. Came out of hour 1 with a clear plan before opening Unity.
- Hour 2 to 3, project setup and Cursor integration: New Unity project, target platform Android, Package Manager installs for TextMeshPro and new Input System. Opened the project folder in Cursor. Created the GameManager singleton using Cursor, GameManager was done in 35 minutes.
- Hour 4 to 5, player controller: Described the gravity flip mechanic to Cursor. Player is a rigid body, pressing space flips the gravity direction between up and down, the player sprite rotates to match. Cursor built the core mechanic. First test in the Editor: worked. Ten minutes adjusting feel variables.
- Hour 6 to 7, level design with basic geometry: Built the first level using Unity's 2D tilemap tools. Used Muse Texture for a rough stone tile texture and a dirt tile texture. Not beautiful. Readable.
- Hour 8, first enemy: Described a simple patrol enemy to Cursor that reverses direction at the ends of a platform and damages the player on contact. Cursor produced it cleanly. Added it to level 1.
Day 2: Hours 9 to 16
- Hour 9 to 11, levels 2 through 4: Added the gravity flip mechanic to the level design. Level 2 introduced a gap the player needed to gravity flip over. Level 3 added an enemy the player needed to flip past. Level 4 combined both. Building levels went faster than building systems. Claude had given me a progression structure that made each level build naturally on the previous one.
- Hour 12 to 13, UI: Created a main menu, level select screen, pause menu, and game over screen. Cursor wrote the UIManager to handle all of them. The UI was functional. I used TextMeshPro text and Unity's built in UI Image components. No custom art. Placeholder UI that communicated clearly.
- Hour 14, score system: Asked Cursor to add a score system that tracks completion time and death count per level and stores a best score using PlayerPrefs. Working in 40 minutes.
- Hour 15 to 16, level 5 and playtest: Built level 5. Played through all 5 levels twice. Found two bugs. A gravity flip at a specific tile corner caused the player to clip through the floor. Fixed in Cursor by adjusting the physics layer collision matrix. A level restart was not resetting the timer. One line fix.
Day 3: Hours 17 to 24
- Hour 17 to 19, Android build setup: This was the most frustrating part. Android SDK setup, keystore creation, build settings configuration. Muse Chat helped with Unity specific Android build settings. The first build failed due to a package compatibility issue. Muse Chat identified the conflicting package version and the fix.
- Hour 20 to 21, Android specific input: The new Input System works differently on touch screens. The gravity flip needed to respond to screen tap rather than keyboard space. Asked Muse Chat for the correct Unity 6 touch input implementation. It gave me the current API. Cursor integrated it into the PlayerController.
- Hour 22 to 23, final polish: Added screen shake on player death using a Cursor generated camera shake coroutine. Added simple particle effects on the gravity flip using Unity's built in particle system. Added audio for jump, gravity flip, and death using free sound effects from freesound.org.
- Hour 24, final test build: Installed on Android test device. All five levels completed. Score system tracking correctly. No crashes in 30 minutes of testing.
What the AI Tools Each Contributed
- Claude contributed: the game concept structure, the minimum viable feature list, the level progression design. One hour at the start. Saved me from scope creep that would have eaten 10 hours.
- Cursor contributed: all C# code across all systems. GameManager, PlayerController, EnemyController, UIManager, ScoreSystem, camera shake. Estimated 14 of the 24 working hours had Cursor open and actively producing code.
- Muse Chat contributed: Android specific Unity settings, Unity 6 touch input API, fixing the Android build failure. Specific Unity knowledge that would have taken significant forum searching.
- Muse Texture contributed: placeholder materials for the tilemap. Not production quality but functional for a prototype.
What I Would Do Differently
- Set up Android build settings on day one not day three: The Android build setup took 3 hours on day three. If I had set the build target and confirmed the Android SDK was working in hour one it would have been 30 minutes and would not have caused day three stress.
- Use Poly Haven assets from the start instead of Muse Texture: Poly Haven CC0 textures look better than Muse Texture output and are free. I added them on day three for the final build and wished I had used them from the start.
- Give Claude more context about mobile game constraints in the design session: The design session in hour one did not specify that the controls needed to be one touch only for mobile. I designed a two touch control scheme that I had to redesign in hour 20. Specify platform constraints in the first design session.
Final Thoughts
A playable 5 level Android prototype with menu, scoring, and enemies in 24 hours of actual work time. The same project without AI tools would have taken 80 to 100 hours based on comparable past projects. The AI tools did not make the game design decisions or the creative work. They eliminated the implementation friction that would have stretched 24 hours of creative work into 100 hours of creative work plus implementation work. That is the honest value of the AI workflow.