跪拜 Guibai
← Back to the summary

Building a Walking 3D Little Prince with AI: 16 Days, 115 Asset Bundles, and One Inverted-Controls Bug

16 Days, He Used Opus 5.5 to Turn "The Little Prince" into a 3D Game, and the Book's Planets Are Now Walkable

On October 13th, X user @Saccc_c (named Sac, bio says "original author of the Little Prince game") posted a Chinese message: "After 16 days, I used Opus 5.5 to make the story of The Little Prince into a 3D narrative game. Combining Tripo + Blender, Opus 5.5 turned every planet from the story into an explorable 3D scene." Entry at littleprince.dev. In the same post, he promised to open-source the entire game along with a detailed production pipeline.

The key word is "explorable." B-612, the king's planet, the lamplighter's lamp; scenes that are a single page in the book are places you can walk into in the game. The post hit Hacker News the next day, and three days later 新智元 published a piece, which 36氪 republished on October 16th.

little-prince-3d-official1.jpg

Image: Official key art, the Little Prince stands on a grass-covered planet gazing at the sea of clouds

Engine and Size, the Part Chinese Reports Didn't Mention

The site's HTML contains the Unity build output: loader.js plus a Brotli-compressed framework.js.br, a pile of Addressables bundles under StreamingAssets/aa/Brotli/, plus TextMeshPro font assets and MonoScripts packages. WebGPU appears 38 times in the HTML, matching the site's "recommended to run in Chrome or Edge" and "not supported on mobile or tablets." This corresponds to the WebGPU backend Unity 6 added for the Web platform, which skips the overhead of the WebGL JavaScript bridge.

The choice itself is information. Finishing a multi-level 3D game in 16 days, the path chosen was Unity plus WebGPU. Under WebGL, Unity must go through a JS bridge to feed vertices and textures to the browser, which can choke on large scenes; WebGPU bypasses this overhead, at the cost of narrow compatibility. The site narrows its scope to Chrome and Edge, turning away mobile and tablets, in exchange for stable performance on large scenes.

little-prince-3d-official3.jpg

Image: In-game screenshot of B-612, the Little Prince stands in front of a wooden shed, interaction prompt "E pick up watering can"

The size is even more intuitive. The LPWebDecodedSizes manifest embedded in the page lists 115 asset bundles, totaling 2013.4 MB uncompressed. The single biggest is the geographer's geo_scenes_all at 163.2 MB. The manifest name includes Decoded, meaning uncompressed size; the Brotli-compressed download size will be smaller, so don't scare yourself with the 1.97 GB figure.

little-prince-3d-fig1.png

The bundle prefixes reveal the structure completely. Seven groups of levels plus one shared group: b612, earth (containing desert_valley and trainroute), king, lamp, counting, geo, theater, bar, with shared occupying 51 asset packages. Comparing to the book, the first six groups map to chapters; theater and bar have no corresponding scene in The Little Prince, the drunkard in the book is only half a page of dialogue, so these two are more like the author's own additions. Each planet also has a set of high-res assets: earth_hires_0..7, b612_hires_0..4. One Addressables group per planet, loading the package when you enter that planet, with high-res layers loaded on demand. The web page's ability to "walk around" relies on this layering, otherwise it would be a slideshow.

little-prince-3d-official2.png

Image: Journey map interface, the book's 8 planets laid out on a parchment map, first chapter B-612 unlocked

In Practice: How This Pipeline Runs

The division of labor is clear in the 新智元 piece: Tripo generates 3D models from text or images, Blender handles modeling, materials, animation and rendering, and Opus 5.5 ties the logic together. The whole pipeline can be put in one sentence, ready to copy directly:

Split levels → Tripo base model → Blender polish → Unity assembly → Claude Code ties logic → Play Mode acceptance → next level

The first step is cutting up the story. Break the book into one self-contained narrative slice per planet, so removing any level leaves the game functional. This step determines the granularity of all subsequent assets and must come before any modeling; the cuts can be rough, but boundaries must be clear. A level is a level; don't let storylines point at each other across levels.

The asset line runs next. Register on Tripo's site for an API key, install its official plugin in Blender, throw in a description or a concept image, and get a textured model in a few minutes. Generate multiple versions of the same description and pick; don't expect it to be right in one go. The book's original illustrations can be fed directly into image-to-model mode, carrying the watercolor texture into the model. Generated topology is rough, so close it manually in Blender: reduction, material tweaks, rigging, then File > Export > glTF 2.0. This line runs largely parallel to writing code across the 16 days; art quality is carried entirely by this step, AI can't replace it.

The engineering side is actually simpler. Create a new URP project in Unity 6, switch the Web build target to WebGPU in Player Settings, install Addressables (com.unity.addressables), create one group per planet, with sub-groups for high-res layers. Recall the bundles from before: shared stays resident; load the package for whichever planet you enter. Lay assets out at this granularity, and the on-demand loading comes free.

The AI line is the real main line. Claude Code into the project:

npm install -g @anthropic-ai/claude-code
cd little-prince-unity
claude

Run /init first, let it scan the project and generate CLAUDE.md, pinning conventions like "Addressables grouped by planet" and "dialogue uses the existing DialogueUI." I think this step is the most valuable: after this, every session doesn't need to re-explain, and the model won't unilaterally swap in a new dialogue system. /model switches to Opus 5.5.

Task granularity determines whether it falls apart. "Help me make a game" will surely fail. A question that can land looks like this:

Add a trigger to the lamp scene: when the player enters within 2 meters of the lamplighter, trigger dialogue, lines go through DialogueUI's queue, close it after leaving the range for 1 second. List which files you changed when done.

One small step, verifiable, rollback-able if broken. To let the model directly manipulate the editor, you can hook up a Unity MCP bridge so it can create GameObjects, add components, start Play Mode. The config shape is roughly:

{
  "mcpServers": {
    "unity-mcp": { "command": "uvx", "args": ["unity-mcp@latest"] }
  }
}

The package name and install method depend on the README of the bridge you choose; these community projects churn quickly.

Iteration rhythm goes like this: one commit per AI change, with comments saying which scene was touched; immediately enter Play Mode after the change and run through the checklist, only then is it done. If there's a real problem, when asking the model to investigate, bring along the state sequence:

The player first completes the watering task, then walks to the fountain, at which point the input direction is inverted. Look at the coupling between input axes and character orientation. First write the reproduction steps as a test, then fix it.

Let the test go red first, then green after the fix; that's how these intermittent bugs get contained.

Acceptance needs a checklist; each level passes five things: can walk in, can trigger the story, can walk out, loading doesn't time out, controls aren't broken. All five green, commit, next level. Eight levels spread across 16 days averages two days a level; that math works out.

The Pit: Inverted Direction Keys

The "controls aren't broken" line in the checklist isn't there for nothing. The 新智元 piece recorded a real pit: X user @0xLuo reported that after completing the watering task, W/S (forward/back) and A/D (left/right) all inverted, and he couldn't pin down the trigger condition himself. This kind of bug has a reproduction path that depends on "first finish A, then enter B" state sequences. Staring at the code doesn't reveal it; you only hit it by listing all the states and manually testing in sequence. The pits left by long-horizon AI projects mostly look like this.

little-prince-3d-official4.jpg

Image: The rose under the glass dome, the Little Prince carries the watering can to the flowerbed, dialogue line reads "The can is empty."

You can calculate the timeline. X post on Oct 13, counting back 16 days, work started late September. I'd guess raw C# wasn't the bulk of it; the heavy lifting was assets and scenes, with the model handling glue work like scripts, config, and wiring, then fixing things when they break. Scope is also nailed down: one chapter per planet, one level per self-contained story slice, any level can be removed and the game still plays. Long projects not falling apart isn't about persistence; it's this kind of slicing.

How Literature Becomes Space

The book's structure is naturally suited to level-ization: one planet per page, one person per planet with one obsession. The text directly gives spatial instructions: B-612's three knee-high volcanoes, 44 sunsets per day, become camera height, fog distance, and the day-night cycle duration in the engine. The lamplighter's planet becomes a non-stop light-on/light-off loop; the player stands beside him and watches him get dragged around by the rules. The businessman's planet has stars piled in disorder because he never counted them. No design doc needed; Saint-Exupéry's sentences are the requirements.

little-prince-3d-fig2.png

The geographer got the biggest asset package (163.2 MB). A character with almost no plot in the book consumes the most resources, probably because his job is recording mountains and rivers, so making the scene means building an entire landscape.

The king's planet takes a clever approach, framing every small thing the player does as "he commanded you to do it," and one UI prompt nails the book's "judge yourself" layer. This kind of change is cheap but high-yield. The real bulk of moving literature to 3D is writing prompts.

The site's language list has 8 entries: zh-CN, en, ja, ko, fr, de, es, pt. French is in there. A French fairy tale, with the original language in the switchable list—that detail is more real than the word "globalization."

Boundaries

The open source hasn't materialized yet. No corresponding repo on GitHub; the HN post's comments only mention the author's "promise" to open source, and as of Oct 27 the detailed production breakdown also hasn't been released. What you can learn now is the result and the tool division; no repo for the process, and the 16-day figure is the author's own claim without a day-by-day record to verify.

Copyright is a layer no one answers for him: Saint-Exupéry's children's book has different copyright terms in different countries, and a fan adaptation on the public web—where the boundary lies, he didn't mention it.

Mobile being locked out is the current reality of WebGPU; browser progress varies, so the site simply excludes mobile and tablets, skipping adaptation and a round of compatibility testing. That's a good trade for a personal project; players who want it have to wait.

The naming has a small quirk. The X post reads "The Little Prince: Across the Stars," the site's og:title is "The Little Prince Among the Stars," and the Chinese is 《小王子：星辰之旅》; when citing, defer to the site.

What's most worth waiting for now is the production walkthrough that was promised. How many of those 16 days were spent having Opus 5.5 fix the same piece of logic—that number is more useful than the 1.97 GB asset manifest.

Reference Links

WeChat public account: Pixel技术笔记, follow to stay tuned