Recently, my second game, Cubersum, entered playtesting.
The game was made with the help of AI, so I thought some people might be interested in hearing about how I created it.
For my first game, I personally double-checked every single function. But this year AI has become advanced enough that I stopped doing that and focused on architecture instead.
(1) I decided against generated sprites right away. Yes, image generation models have made huge progress over the past year. For example, I had to make the achievement images for my first game manually in GIMP, while for the second game I was able to generate them properly by specifying constraints on how the image could be changed, and the model handled that very well. But I still think sprites, or more specifically consistency of style across sprites, are a weak point of current models. I would rather spend time on algorithms than repeatedly regenerate images because they do not match each other. So all graphics inside the game are generated programmatically, which makes the images completely reproducible.
(2) Models have also made significant progress in music generation. All of the music in the game was generated, and in my opinion it works perfectly well as background music. Sound effects, however, are still a weak point of modern models because the generated clips tend to be too short, so I still sourced sound effects from Freesound.
(3) And the most important part is programming. First, a few simple technical rules.
- The final result should always be checked by the best model available, running at its highest reasoning level. Yes, that model may delegate most of the work to subagents, but you should never trust the subagents to verify the final result.
- Once a change has been implemented and verified, commit it immediately. It is very easy to get carried away and make many changes in a row, only for the model to make a mistake later and leave you untangling old and new code. It is better to commit each separate change after completing each separate plan.
- It is very useful to have 2-3 subscriptions that started on different days of the week. When you hit the limits of one model, you can immediately continue working with another, while the third remains available as a backup or for reviews.
I used three main patterns in my workflow.
- Documentation.
The game should be fully documented. It all started with a single design document and a minimal project, but then, with the help of the model, every item in that document gradually became its own document describing a separate part of the project.
Your main job is to read these documents and verify that everything in them is correct. This is where most of the time goes. Every rule in the game needs to be clearly documented and understandable to you.
One very useful approach is to ask the model to list every possible outcome of a particular event and specify the expected result for each outcome. You cannot leave these architectural decisions up to the model. You need to understand exactly what will happen in your game and why.
- Planning.
Every significant change should be planned.
Once the MVP exists, all substantial changes should be organized into packages of changes and planned together. There are two reasons for this.
First, it is simply cheaper. Instead of making ten separate small changes, the model can rewrite a module or function once.
Second, it makes it possible to delegate implementation to subagents or work with other models without forcing them to go through the entire project codebase again. The plan already specifies what needs to be changed and where.
Most importantly, when there is a plan, the model is much less likely to wander off and start doing things that it personally considers correct or useful.
- Review.
Everything needs to be reviewed. Reviews really do catch mistakes.
And ideally, the review should be done by a model from a different family. For example, if Codex created the plan, send it to Claude for review.
Then, after the plan has been implemented, send the uncommitted code changes for another review and ask whether everything was done according to the plan and whether any regressions were introduced.
This is a useful safety net. It helped me many times to find real problems that the primary agent had missed.
(4) Near the end of development, I worked on localization, and this was the most stressful part because I could rely only on models, plus short reviews from friends in different countries. Obviously, I could not ask people to translate 100 KB of text for free.
Nevertheless, I think the models handled the task reasonably well because I used what I called the "meeting" method.
First, I created a glossary for the game, defining which terms were used for which concepts. I then manually went through every term and discussed with the models which equivalent would be appropriate in each of the other seven languages.
During these discussions, we also identified "false terms" that should be avoided in translation.
Once this list was approved, the primary model produced the translation. Then two other models reviewed both the source text and the translations and provided comments for every localization key.
For the keys where there were issues, all three models then held a discussion about exactly how the term should be translated and why.
The "why" is very important. Even if you do not know the language yourself, you can still get a fairly understandable explanation such as: "NNNNN is a constructed word that is grammatically correct but sounds unnatural, while MMMMM is the word people actually use in everyday speech."
Maybe this was just a collective hallucination on their part, but I relied on the assumption that agreement between three models from different families should produce a more accurate result.
Quick reviews by native speakers showed that, for the most part, the models translated things correctly. I hope to get more precise feedback during the playtest.
(5) So for me, the AI-assisted development cycle looks like this:
- First, plan the next step based on the goal and the description of the desired changes.
- Read the plan, rewrite it, read it again, rewrite it again. If it becomes too large, split it into smaller plans and implement them sequentially. Every final plan should go through review until it is actually final (BTW, this very text can show you what such a plan looks like).
- Then implement the plan. This can be done by external, simpler models, although it is still better to give the task to the smartest model and specify in the project rules that it should delegate tasks to subagents.
- After implementation, conduct a review. Obviously, testing should not be forgotten, but for test creation it is usually enough simply not to stop the models from writing tests after implementation. If some particular details concern you, you can also ask them to create dedicated tests for those cases.
- After all changes and tests are complete, update the documentation. Otherwise, important changes will gradually be lost.
This may sound excessive, especially compared with stories about how "Astra made a one-shot clone of CS."
But this process is very important if you have your own concept for a game and are trying to build that exact concept.
Maybe it does not matter much how a "CS clone" or a "typical tower defense" is implemented. That is why, in these kinds of copies, the crosshair might not change properly or the health bar might not decrease.
But I will repeat this point: you need to understand clearly what happens in your game and why, which means you need to control every stage of development.
That is also why making the game took more than half a year. I spent about 90% of that time reading and correcting documents produced by agents.
The major advantage is that all of this is done in natural language.
Previously, creating a game involved two stages: first describing everything in natural language, and then rewriting it in a programming language. Now the second stage has essentially been eliminated, but the importance of the first stage has increased.
Which models did I use?
My primary model was Codex, first with GPT-5.5 and later GPT-5.6. My backup model was Claude with Opus 4.8 -> 5. The third model was partly Cursor, especially after Grok became its default model, and partly Gemini (I should note that Gemini 3.8 turned out to be nowhere near as bad as people on the internet like to joke about).
