Indie Game Lab

My Indie Game Dev Journey: Lessons From Shipping KuBi

By Haitao Pan · Game Developer & Studio Owner · 9 min read

TL;DR: I'm a studio owner and working developer based in Hangzhou. I build original mini-games — most recently "Super Miserable Adventurer" (KuBi), a survival/crafting game on Cocos Creator 3.8 for the WeChat platform — and I started Indie Game Lab to write down exactly how the builds actually went. Not "how to make a game" theory, but the real constraints, the dead ends, and the rebuilds. This is the story behind the posts.

1. Where I started

I came up through web and front-end development, where the feedback loop is short: change a line, refresh, see the result. Games looked like the opposite end of the spectrum — long production cycles, huge teams, and a lot of talk about "vision." What pulled me in was realizing that a small, focused game is actually closer to a web app than to a AAA studio: one person can own the loop, the build, and the ship.

The decision that shaped everything was to build original games rather than contract work. Original means I make the calls on scope, art, and monetization myself — which also means I eat the consequences of every call. That's the part most "how to make a game" content skips, and it's the part I find worth writing about.

Web & front-end short feedback loop Learn Cocos 3.8 TS, small runtime Ship KuBi WeChat mini-game Go global EN site + 2 subs Same person owns the loop, the build, and the ship at every step.
The through-line: I never stopped being the one who makes the calls. The platform changed; the ownership didn't.

2. Building KuBi under real constraints

The game is a 750×1334 portrait survival/crafting loop — gather, craft, fight, dive dungeons. The interesting part wasn't the design, it was the ceiling. WeChat's mini-game runtime is unforgiving about package size, and low-end phones are unforgiving about frame time. Those two constraints drove almost every technical decision, and they're the reason this site has a whole cluster of teardown posts:

The through-line across all of those: measure before you optimize, and optimize the package before the frame rate — size blocks the install, frame rate only blocks retention. I learned that the expensive way.

3. What shipping taught me

A few lessons that didn't fit neatly into a technical post but shaped how I work now:

Ship games KuBi · Cocos 3.8 Write it down post-mortems, public Build tools Sign Renderer · 3D Indie Game Lab real builds → real lessons for other devs
How I actually spend the week: shipping, documenting, and tooling all feed the same output. The writing isn't a side project — it's the part that compounds.

4. Why I write it down in public

Most game-dev content online is either conference talks paraphrased into a blog, or "I made $X in 30 days" growth porn. Neither helped me when a build failed at 2am because the engine subpackage didn't load. So I write the opposite: the specific, the unglamorous, the "here's the number I measured." If a post doesn't contain a real figure or a real mistake, it doesn't ship here.

Writing it publicly also forces honesty. A private note can hand-wave; a published teardown gets read by people who've hit the same wall, and they'll tell you where you're wrong. That feedback loop is worth more than any tutorial I've followed.

5. What's next

The next move is going global. The games and the writing are increasingly in English, aimed at overseas developers who face the same constraints I do. Two sub-projects are already live under the same domain:

And the content keeps coming — more Cocos runtime teardowns, more scope/retention lessons, and the occasional honest roundup of games worth studying. If you build games (or want to), the best place to start is the post-mortem of the game that started this site: How I Built "Super Miserable Adventurer". After that, the engine comparison explains why Cocos was the call, and the idle-loop piece covers the design side that the tech posts don't.

6. Related reads

← Back to all field notes