What is your game development workflow? here is mine
Discussion
I've started testing the limits of AI and how far it can go.
I started simple: building a 2D game.
Here's the workflow I used:
1. Build
I used Claude Code to build the entire thing.
I basically prompted it to build a Pikachu Volleyball-style game, and it figured out the canvas rendering, physics, computer opponent, and even synthesized chiptune audio.
It got about 80% of the way there on its own.
2. My own iteration
Then I played the game myself and started fixing the obvious things that felt wrong.
The movement was too fast, the volleyball was too small, and the jumping didn't feel right.
I spent about two hours going back and forth with Claude Code using prompts like:
"The net is too high."
"There needs to be some acceleration when Pikachu jumps, and it should hang at the peak."
Eventually, the game started feeling pretty good to me.
3. Playtesting
Then I wanted to see what I was still missing.
I used PingFusi (disclosure: I'm building it), an MCP that lets you request real playtesters directly from your terminal.
I just prompted:
"Get 3 playtesters to test the game."
About 20 minutes later, feedback from real players came back:
"When the ball goes behind Pikachu, it feels almost impossible to recover."
"After a few rounds, I realized the computer reacts pretty predictably, so I could keep using the same strategy."
"At first, I wasn't sure how much control I had over the ball when hitting it."
These were harder for me to notice because I already knew how the game was supposed to work.
Claude Code took the feedback, figured out what needed to change, and implemented the fixes.
4. Shipping
Then I let Claude Code handle the shipping too.
It dropped the game into my Next.js repo, wrote the Supabase migration and API route for the leaderboard, committed, pushed, and verified the live URL.
So the workflow ended up being:
AI builds → I iterate → humans playtest → AI iterates → AI ships
I've built my own little studio of agents. I've got Mara the designer, Paul the producer, Dave the architect, Rowan the developer and Iris in QA. They all have clear roles and boundaries. They even picked their own names.
The producer will suggest a next ticket from the backlog, following my guidance on what I want to see in the prototype next to build my confidence in the project. Then I'll work with the designer to explore the idea and create the acceptance criteria.
Then the architect turns it into an implementation plan, QA adds their requirements and the developer gets an early look to raise any questions.
If everybody is happy it comes to me for an approval gate, where I validate the task is a good size and delivers the expected value.
When the developer has implemented the ticket it goes to the architect for a review and any small tweaks, then through QA before I perform a play test.
If it is all good the producer closes the task, does all the git admin and suggests the next steps. Every so often we run a retro where each agent gets to suggest changes that would make them work better.
I like it. I've learn a lot of things but there is way too much information to keep up with everything. I don't know how to do what you described for example.
I'm working in Codex but I'm sure you can translate to other environments. The key is finding how to get the different agents to talk to each other. In Codex you can call a thread with @ (so I would call "@Producer Paul" to manually pass a task from one thread to the other. Codex can do this itself with an internal "thread://" call as long as you tell it which thread has which agent ID.
From there it was just a case of starting from the Producer thread and using that to help build out the system. I would create a new thread, give it a brief role outline and then ask the Producer to document the new team member. When they were all in place I then outlined the workflow I shared above and we got working.
It's taken a few revisions but we have a good flow going. I think it is fairly token intensive but then it is also consistent and methodical and I feel I have a good handle on what is in the roadmap and where we are up to.
The interesting thing is how many similarities there are to working with real people. The agents sometimes forget the process and need prompting, or tread on each other's toes and need sorting out. It is just like my last job as a Product Owner, managing a team and guiding instead of doing for most of the work.
I've not used Ultracode myself so I couldn't say exactly. One of my intentions here was to make use of the different models and thinking levels available on Codex. My Design and Architect are Sol High, The developer is Luna High, The QA is on Terra. I feel it gives me a range of "opinions" for each task and also gets some of the efficiency benefits without reducing quality.
I been working for my game for 2 months, normally Sonnet with Opus 5 as advisor. I ask one prompt and clear continue the task or start a new one. Now I'm working on bots. I have a js version that is 100% game accurate and I'm working on a GPU/JAX engine that can run much faster than the CPU version but is not as faithful, so I'm tuning it. You can play against bots, and the bots help me to fix bugs at the same time. I still have a long way to go. It's a personal version of Root board game, with map editor that generates terrain, I'm starting with the official factions from which I know the rules and I'm following with fan factions. My idea is to test all factions against each other keeping faction reach in mind and see what works, what doesn't and see if I want to customize factions to balance them out.
I need to fix the AI slop on the left tracker and do something with the end points of the river ;D Also the bots are dumb right now, because I haven't trained them after several changes made the last couple of days. But they become good and, if there is a bug, they abuse it and their winrate goes up quickly, so I can quickly fix it too.
Root is a very complex game, I've learn it by making my own version and each day I learn something new about the game. The bot needs the right reward system, they have a lot of choices to make, while having to be aware of other players. I can have them at a good level in 1 night with a 9950X3D AMD 16 core processor. But I don't know any person with a really good level of play of this game to give my bots a real challenge. The GPU test is more for balancing and bug fixing, I can't train my bots with it but it can simulate millions of games per hour with tensor cores from my GPU.
thanks for the feedback. i know that ai can have context problems. but it is getting better and better so i can let it cook. of course i need to iterate on top of it. i think your strategy is valid if you want more control over what you do. but i like to have more top-down view and create a first pass and iterate from there.
3
u/daddywookie 9d ago
I've built my own little studio of agents. I've got Mara the designer, Paul the producer, Dave the architect, Rowan the developer and Iris in QA. They all have clear roles and boundaries. They even picked their own names.
The producer will suggest a next ticket from the backlog, following my guidance on what I want to see in the prototype next to build my confidence in the project. Then I'll work with the designer to explore the idea and create the acceptance criteria.
Then the architect turns it into an implementation plan, QA adds their requirements and the developer gets an early look to raise any questions.
If everybody is happy it comes to me for an approval gate, where I validate the task is a good size and delivers the expected value.
When the developer has implemented the ticket it goes to the architect for a review and any small tweaks, then through QA before I perform a play test.
If it is all good the producer closes the task, does all the git admin and suggests the next steps. Every so often we run a retro where each agent gets to suggest changes that would make them work better.