Shipping a WeChat Mini Game With Zero Gamedev Experience, Using AI as a Full Team
A few days ago, my first WeChat Mini Game, "English Word Storage Box," officially launched.
The gameplay can be summed up in one sentence: put English word cards into the correct classification boxes. See APPLE, put it into FOOD; see RAIN, put it into WEATHER. The first version has 150 main levels, over 800 words, plus basic features like daily review and progress tracking.
The game itself isn't big, but the process validated something I've been curious about: Can a person with no game development experience, with deep involvement from AI, independently take a game from idea to actual launch?
The answer is yes. But after actually finishing it, I discovered something more important and more sobering—
AI has indeed drastically lowered the difficulty of "building something," but it hasn't made "making a good product" any easier. In some ways, the latter has even become harder.
This post will talk about the pitfalls I encountered and the things I figured out along the way.
Why "Words + Classification"
The reason is simple: I wanted to find a lightweight gameplay mechanic so that memorizing words isn't always the routine of "see English → see Chinese → memorize → do exercises." Especially for kids, this process turns back into learning software after just a couple of rounds.
Then I thought of the "classification" action. Seeing Apple isn't just knowing it's called an apple; you also have to judge that it belongs to food. Seeing Pencil, you have to react that it's related to a learning scenario. This way, words are no longer isolated "English-to-Chinese" translations but are linked to specific semantic scenarios.
The "word card + classification box" gameplay was set, and I casually named it "English Word Storage Box."
For the first version, I deliberately kept my ambitions very low: no nurturing systems, no equipment, no storyline, just validating one thing—whether using classification to learn and review words is a viable path. 150 levels stringing together the complete chain of "first encounter → in-game judgment → repeated appearance → subsequent review" was enough.
Looking back now, the decision to "first turn the core hypothesis into something playable" was the right one. Many problems only surface when you actually play it; you can't figure them out just by sitting there thinking.
This Time, AI Wasn't Just "Writing Code for Me"
If I just said "this game was developed using AI," it wouldn't be anything special now. What I wanted to try this time was something else: not treating AI as a code generator, but letting it participate in the entire product lifecycle, from idea to launch.
In practice, AI played at least five roles in this project.
Product Manager. The earliest questions weren't code questions: How much is enough for the first version? At which level should daily review unlock? How to mix new words and review words? How many classifications per level before it just becomes an exercise? These product logic questions had to be clarified before development even started.
Game Designer. Manually configuring 150 levels is not only a huge workload, but the overall difficulty is also easy to lose control of. After I structured the word bank, classifications, introduction order, and review ratios, I had AI check against the rules: which category this word should belong to, which classifications are suitable to appear on the same screen, whether the difficulty jumps between previous and next levels, and whether there is any content unsuitable for children. What was originally a purely manual organization task became "rules + data + AI review."
UI/UX Design Assistant. How to arrange the main line and review entrance on the homepage, what data to display after clearing a level, how to make a child feel "I really accomplished something" instead of a dry pop-up saying "Level Cleared"—these interfaces went through many rounds of revision. I had AI propose solutions, generate prototypes, and then took them back into the game for actual verification.
Programmer. The game was developed using Cocos Creator. From game logic, save files, and interface states to WeChat Mini Game adaptation and various build scripts, a large amount of the implementation work was written by AI. My role became: raise requirements → see results → playtest → find problems → adjust constraints → do another version. The biggest change is that I didn't have to spend months learning the engine before writing a demo; I could start from "what I want to do" and understand the technology backwards within a real project.
Tester. This is the most easily overlooked role, but personally, I think it's the most valuable one. In the later stages of development, I spent more and more time on testing: unit tests, data validity checks, level configuration checks, browser automation, pre-release verification... many checks were eventually turned into one-click scripts. In other words, AI not only had to "help me write features" but also "help me prove that this feature didn't break anything else." The value of these two things is not on the same order of magnitude.
The Hardest Part Was Never Writing Code
At this stage, a very subtle feeling emerged.
Before, when I couldn't develop, I always thought, "As long as I can write code, I can build this thing." Now that AI has solved most of the "how to build it" part, you suddenly see the much bigger mountain behind it: Is this thing actually fun?
The most typical example is level difficulty. From a rules perspective, everything in the first version was very reasonable: there were levels, a step limit, more and more words, and increasingly complex classifications. But after I played continuously for a dozen or twenty levels, I found it—too easy. Some levels could be cleared with a ton of steps left over.
From a programmatic perspective, this system was flawless: no bugs, correct win/loss judgments, valid data. But from a game perspective, it created no pressure and no decision points.
At that moment, I had a strong realization: Program correctness and game experience are two completely different evaluation systems. AI can tell me if a piece of logic is right or wrong, and can batch-generate 150 levels according to rules, but a question like "will the player be bored by level 20" can only be figured out by a real person testing it over and over.
A similar issue was user positioning. I initially wrote "6 years+." A friend reminded me after playtesting: for young children, the interface mainly relies on text, meaning they have to be able to read before they can start playing. If the font is even a little smaller, the barrier is even more obvious. This problem is laughably simple, but when you're focused on features during development, you just don't see it. So I started agonizing again: Should I add pictures to the words? Should the font be bigger? After adding pictures, will the child only look at the pictures and not the English?—These are no longer programmer's questions. There are no standard answers, only constant trade-offs.
Should a Learning Game Be More Like "Learning" or More Like a "Game"
This is what I now think is the most worthwhile question to ponder.
If an educational mini-game just puts a layer of animation over exercises, it's still essentially an exercise. The player puts a card into the correct box, it disappears with a "pop," and the next one comes along—the function is complete, but the game feel is near zero.
Mature games use countless tiny feedbacks to constantly tell the player "you just did something awesome": the animation of the card being sucked into the box, particles scattering, stars flying into the progress bar, the pitch climbing slightly on consecutive correct answers, combos, the small climax when clearing a level... Individually, each is a small detail, but combined, they determine whether the player is "completing a problem" or "playing a game."
So I increasingly agree with a line of thinking: Instead of trying to make learning seem fun, it's better to first make the game itself fun, and let learning happen naturally during the gameplay. These two sentences look similar, but executing them are two completely different paths.
From "Runnable" to "Launched," a River Lies Between
Another previously underestimated part is the launch itself. The game running on a computer is at best half done. Actually releasing it on the WeChat Mini Game platform involves a long list of things: official Cocos build, platform adaptation, package size checks, real device testing, different screen size adaptation, name, logo, cover image, sharing image, review materials, submission, handling review rejections, official release...
After fully walking through it for the first time, my biggest feeling is: The distance between making a Demo and making a product that can be handed to real users is far longer than imagined. When developing alone, it's easy to focus all your attention on features, but design, content, testing, review, data, and operations are all part of the product.
Until the day it passed review and could actually be opened by anyone on WeChat, that feeling was completely different from playtesting on my own computer. Anyone can come in and play, find it fun, or quit in a minute, or even directly drop a "not fun." Projects you keep to yourself can constantly find excuses for problems, but after launch, all problems eventually converge into one: Is the user willing to keep playing? This can't be solved by explanation.
Launching Is Not the End, It's the Beginning of a Bunch of New Problems
Honestly, launching didn't give me the relief of "finally finished." Instead, it raised even more questions: After players come in, will they actually start the first level? At which level do they start to drop off? Which words are most easily misclassified? Does anyone click on the daily review? After adding pictures, will younger children be more receptive?
So in the next phase, I don't plan to aggressively add features. Instead, I'll first build up the data and feedback system, letting real data decide what to do next. The level difficulty curve, elimination feedback, picture experiments, and review mechanisms will all follow the data.
The first version also taught me one thing: A product isn't written out step-by-step following a Roadmap; it grows bit by bit from real user feedback.
Final Words
After finishing this version, if I had to summarize the gains, I wouldn't say "AI writes code so fast"—that point is becoming less and less important.
I think what's truly important is: For the first time, AI allows a single person to, at a very low cost, simultaneously mobilize capabilities that previously required an entire team to cover—product, design, development, testing, data analysis. This doesn't mean AI can replace professionals; quite the opposite, after actually doing it, you see the value of professional skills even more clearly. But in the past, an individual might never even reach the stage of needing to think about these problems, as just building the thing exhausted all their energy. Now that the implementation cost has dropped, we can finally spend more time on "what exactly should I do" instead of "how do I write this feature."
As for "what is worth doing," "what counts as fun," "what do users really need"—no prompt can directly answer these questions. This might just be the most interesting part of making products.
The first version of "English Word Storage Box" is now live on WeChat Mini Games. If you have elementary school-aged children at home, you can search for "英语单词收纳盒" on WeChat to try it out.
More than a "well done," what I want to hear more is: Which level is boring? Where is it confusing? Is the child willing to play another level? Which parts make you feel it's more like studying and less like a game? This feedback might very well directly determine what the next version looks like.
I will continue to document how the subsequent levels are adjusted, how the data is viewed, and how AI participates in testing. If you're interested, feel free to follow.
This article was first published on my personal blog