i created a full unity 6 game loop using cursor composer in one afternoon and here is the honest breakdown of every step
Cursor has a feature called Composer that lets you describe a multi-file task and have it execute across your entire codebase at once. I decided to use it to create a complete game loop from scratch in one afternoon. Start screen, main gameplay, death screen, win condition, scene transitions. All the plumbing a real game needs before it is a game. Here is every step I gave it, what it produced, what I had to fix, and whether this is actually a useful way to prototype.
Alex Chen
June 26, 2026
What Cursor Composer is: a mode inside Cursor where you describe a task in plain language and it reads your project, plans the changes across multiple files, shows you what it intends to do, and executes on your approval. It is not chat. It is agentic. It plans and acts across your codebase. I used it to build a game loop prototype in one afternoon. The afternoon was four hours and twenty minutes. The result was a buildable Unity project with a working start screen, gameplay scene, death and win states, and scene transitions. Here is every step.
Why I Decided to Try This
Every game prototype I build has the same friction at the start. Setting up the game loop plumbing. GameManager singleton. Scene transition logic. UI for start, pause, death, and win states. Score tracking. It is the same fifteen to twenty scripts every time and I write them slightly differently each time because I am improvising. I wanted to know whether Cursor Composer could produce a reusable game loop foundation in one session that I could then build a game on top of. This was not a test of whether AI can make games. It was a test of whether it could eliminate the setup friction I experience at the start of every project.
Every Composer Prompt I Used and What It Produced
- Composer prompt 1: Create a GameManager singleton in Unity 6 that persists across scenes, tracks score as an integer and lives as an integer starting at 3, exposes events for OnScoreChanged and OnLivesChanged, and handles game state as an enum with MainMenu Playing Paused Dead and Win states. Cursor planned changes across one new script and showed me the plan before executing. I approved. The GameManager that came out was clean and matched the Unity 6 singleton pattern correctly.
- Composer prompt 2: Create a SceneLoader script that handles async scene loading with a simple fade transition using a UI Canvas. It should be called by the GameManager and support loading MainMenu, Gameplay, and GameOver scenes by name. Cursor created SceneLoader.cs and a Unity scene setup comment describing where to place the Canvas. The async loading and the fade coroutine worked correctly in the first test.
- Composer prompt 3: Create a PlayerController for a 2D platformer in Unity 6 using the new Input System. It should handle left and right movement with variable speed, a jump with coyote time of 0.15 seconds, and call GameManager.Instance.LoseLife when the player falls below y minus 10. Cursor referenced my existing GameManager.Instance pattern correctly because it had already built the GameManager.
- Composer prompt 4: Create a UIManager that listens to GameManager events and updates a score text element and a lives display. Also create a PauseMenu that activates on Escape key and calls GameManager.Instance.PauseGame. Cursor created UIManager.cs with the correct event subscription pattern using the events it had defined in prompt 1.
- Composer prompt 5: Create a simple enemy that moves left and right between two waypoints, damages the player on contact by calling the player's TakeDamage method, and is destroyed by a GroundStomp method that awards 100 points via GameManager.Instance.AddScore. Cursor looked at the PlayerController it had written and connected the TakeDamage method correctly.
What Broke and What I Fixed
- The Input System package was not in my project: Cursor generated the new Input System code assuming I had the package installed. I did not. First compile error was 12 missing references. Added the package through Unity Package Manager and everything compiled. This is not a Cursor mistake. It assumed a standard Unity 6 project setup. I should have specified my package list in the first prompt.
- The coyote time implementation had a logic error: The coyote time variable was being reset before the grounded check ran in one specific frame order. The player could not always jump from the edge of a platform. I described the behavior to Cursor in chat and it identified the frame order issue and fixed it. Twenty minutes.
- UIManager events were being subscribed before GameManager initialized: Awake order dependency problem. UIManager was subscribing to GameManager events in its own Awake before GameManager had finished its Awake. Fixed by moving subscriptions to Start. Classic Unity initialization order issue. Cursor caught it when I described the null reference error.
- The SceneLoader fade was blocking input after a scene loaded: The Canvas used for fading was not being disabled after the fade completed, just made transparent. It was sitting invisibly over the UI and blocking clicks. One line fix. Cursor suggested it immediately when I described clicks not working after scene load.
The Final Working Architecture After One Afternoon
- GameManager.cs: Singleton, scene-persistent, handles all game state transitions, score, and lives. Exposes clean events.
- SceneLoader.cs: Async scene loading with canvas fade. Called only through GameManager.
- PlayerController.cs: New Input System movement with coyote time jump and fall death detection.
- UIManager.cs: Listens to GameManager events, updates score and lives display, handles pause menu.
- EnemyController.cs: Simple waypoint patrol with player contact damage and stomp kill.
- Total scripts: 5. Total working: 5. Total new projects I have started on top of this foundation since the experiment: 2. Time to set up this same foundation without Cursor on my previous project: approximately 9 hours across three sessions.
What I Learned About Using Cursor Composer Effectively
- Order matters: Build dependencies before the things that depend on them. I built GameManager first, then SceneLoader and UIManager which reference it. If I had built UIManager first it would have had no GameManager to reference.
- Always review the plan before approving: Composer shows you what it intends to do across which files before executing. I read every plan. Once it planned to modify a file I had not mentioned and I wanted to understand why before approving. The reason was valid. The habit of reading is essential.
- Specify your Unity version and packages in the first prompt: My Input System problem in this session would not have happened if I had started with: this project uses Unity 6 LTS with the New Input System package and TextMeshPro installed. Save yourself the compile errors.
- Keep Composer tasks focused on one system at a time: When I tried to combine the PlayerController and UIManager in one prompt the output was a single script that tried to do both. Separated them and both came out cleaner. One system per Composer session.
Final Thoughts
Four hours and twenty minutes to a working five script game loop foundation. The same setup took me nine hours spread across three sessions on my previous project. The two hours of that afternoon I spent debugging and fixing Cursor's output were honestly more productive than most debugging sessions I have had, because Cursor was helping trace through its own code while I fixed it. I have started two new projects on top of this session's foundation. The game loop plumbing problem is solved.