小王子坐在椅子上，面前是缓慢翻动的云海。镜头往前，玩家可以走进他的小屋，拿起水壶，去泉边取水，再回来给玫瑰浇花。书里那个只有寥寥几笔的星球，如今有了可以行走的草地、会摇晃的花、绕着人飞的蝴蝶。
游戏开场：小王子坐在云海前。画面来源：Sac 公开作品，经优设AIGC展示。
这是一款已经能在浏览器里打开的 3D 剧情探索游戏。创作者 Sac 说，他用了 16 天，借助 Opus 5.5、Tripo、Blender 等工具，把《小王子》的星际旅程做成了可以亲自进入的场景。作品发布后，他表示全网累计浏览接近 300 万。网页目前提示使用电脑上的 Chrome 或 Edge，手机和平板暂不支持。
一个人如何在十几天里做出这样的世界？最值得看的，除了 AI 帮忙写了多少代码，还有那些看似细小、却决定玩家能否相信这个世界的制作环节。
先让一颗星球可以被走进去
游戏从小王子的家开始。开场没有急着把整本书铺开，而是把玩家放进一件很小的事里：找水壶、去泉眼、折返、浇玫瑰。任务简单，路上却有足够多的东西让人停下来。流水声在耳边，花草随风摆动，傍晚的光把草地染成暖色。原来读到“难过的时候喜欢看日落”时靠想象补足的画面，现在可以站在其中看。
B-612 家园的玫瑰浇花任务。画面来源：Sac 公开作品，经优设AIGC展示。
这种体验的关键，是玩家真的能走、能转向、能完成一个动作。它因此不只是几张风格统一的概念图，也不是一段只能从固定角度观看的视频。场景的美感需要在玩家移动时继续成立：换个方向看，建筑不能散架；走近一朵花，它仍得像属于这个星球；伸手提壶时，手和壶不能各走各的。
从小王子的家继续往后，是国王的星球、点灯人的星球。点灯人的路灯明暗变化，周围花瓣的冷暖色也跟着改变。这样的细节不会改变任务目标，却会改变玩家对这个空间的感觉。它让一个抽象的文学意象，变成可以被观察的环境。
点灯人星球的路灯与花草。画面来源：Sac 公开作品，经优设AIGC展示。
小王子的家园还有一个容易被忽略的层次：玩家为了给玫瑰浇水，必须在小屋和泉眼之间往返。同一片草地会被走过两次，来时看见的是去处，回来时看见的是玫瑰。背景音乐、流水与夕阳并非单纯贴在画面上的装饰，它们陪着这个短短的行动，把“照顾玫瑰”变成游戏里真实发生的一件事。
B-612 的落日与云海。画面来源：Sac 公开作品，经优设AIGC展示。
Sac 展示了国王与点灯人的场景，而小王子家园里的浇花旅程尤其能说明作品怎样把几个部分接在一起：玩家沿路穿过草地，听见声音，看到光线与植物的变化，最后让角色把水带到玫瑰身边。场景、角色、音效与交互在同一件事里发生，而不是各自孤立地展示。
从故事到场景，先分清每种工具做什么
Sac 公开的制作流程不是“给一个模型一句话，等游戏自动生成”。最前面，他让 Fable 5.1 写游戏 PRD，把原著里的场景、角色和剧情线拆出来。故事要去哪些星球、玩家在每处做什么、哪些物体必须能互动，先有这份清单，后面的图像、模型和代码才知道该服务什么。
接着是视觉设定。GPT Image 2.5 根据文字生成场景与角色参考图。对于一颗星球，先确定最接近目标的一张效果图，再补俯视和斜侧等角度：前者说明道路和物体怎么排，后者交代高低、体积和遮挡。只凭一张好看的正面图，3D 场景很容易出现背面空白、比例失控的问题。
B-612 星球的场景参考图：全景与局部物件放在同一张图里。画面来源：Sac 公开制作流程，经优设AIGC展示。
有了多角度参考图，AI 再把画面拆成一份资产清单。地面、房屋和大体块可以在 Blender、Unity 里搭；水壶、路灯、石雕这样造型独特的道具，则适合单独生成 3D 模型。Sac 在 Tripo 中使用 H3.1 制作这类道具，再把导出的资产交给后续环节。这里的选择很具体：不是每样东西都用同一种生成方式，而是先判断哪些物体值得花更多精力保留外形和纹理。
这个拆分也让生成结果有了清楚的验收对象。参考图负责回答“整个空间应该长什么样”，资产清单回答“哪些东西需要独立制作”，Tripo 交付的则是能放进场景的具体道具。若水壶的轮廓不符合角色动作，问题可以回到道具本身；若画面整体的层次不对，就该检查布局、镜头和光线。每一环都有自己的任务，不必把所有偏差都归到“再生成一次”上。
随后轮到 Opus 5.5。它通过脚本和工具连接操作 Blender 与 Unity，依据参考图搭地形、摆放道具、调整比例、光线与镜头里的构图。Blender 负责模型和场景处理，Unity 把这些内容组织成玩家可以进入、移动和交互的游戏。Sac 还在本地配置了 Blender CLI，以及让模型接触 Unity 编辑器的 CLI 与 MCP 桥接。
即使模型能操控软件，场景也不会一次就对。Sac 在流程里安排了独立的审查 Agent，从正面、侧面和玩家视角截图，对照参考图找差异，再把位置和光照反复调回来。多机位检查的意义很朴素：一张截图里看着对的东西，换到玩家实际走过的位置，可能完全不对。
这样看，AI 并没有把美术、建模和引擎融成一个按钮。它承担了拆解、生成、操作和修改的大量工作，而创作者需要给出目标画面、决定哪些细节重要，并让每一步的输出能进入下一步。
小王子能走路，还得能稳稳提起水壶
场景搭完，角色是另一套问题。Sac 先用 GPT Image 2.5 做小王子的标准 T-Pose 四视图，让正面、背面和侧面的发型、服装与身体比例尽量一致。Tripo 的 Smart Mesh P2.0 再依据这些视图生成角色网格。角色不是摆在画面里的雕塑，之后要弯腿、转身、抬手，网格结构能否编辑和变形，比一张静态渲染图好不好看更重要。
小王子角色的 T-Pose 四视图，用于生成可绑定骨骼的 3D 模型。画面来源：Sac 公开制作流程，经优设AIGC展示。
模型进入 Blender 后，他用付费插件 Auto-Rig Pro 完成绑骨和蒙皮，让身体表面跟着骨架运动。基础动作可以从 Mixamo 的动作库找：走路、跑步、环顾四周。下载 FBX 动作后，还要把动作数据适配到小王子这套骨骼上。Sac 让 Opus 5.5 参与这些调整，并检查抬手、弯腿时有没有变形或穿模。
四视图和角色网格之间也不是一步到位。Sac 展示的流程里，生成网格后要先看白模的形状和结构；合理了，再生成纹理，局部不对则继续改网格。这样安排是因为贴图能让模型看起来精致，却不能替一个不适合运动的身体解决关节问题。等到人物真正跑起来，先前在静态画面里看不出的拉扯、穿插，就会立刻露出来。
真正难的是浇花这样的接触动作。动作库里可能有“伸手”或“提东西”，却很难刚好符合这个角色、这个水壶和游戏里的高度。手指与把手错开一点，水壶就像悬在空中；提起时手臂轨迹不对，角色又会穿过道具。Sac 的处理方式，是先找接近的基础动作，再让 Opus 5.5 在 Blender 中调整 Auto-Rig Pro 的手臂 IK 控制器，修手掌、手指和水壶的相对位置，直到接触看起来自然。
Blender 中的角色骨骼与提水壶动作调整。画面来源：Sac 公开制作流程，经优设AIGC展示。
这也解释了为什么开头那个不起眼的浇花任务值得看。玩家感受到的“自然”，来自角色网格、骨骼、动作片段、道具位置和交互逻辑都对得上。工具能缩短每一步的制作时间，但这些步骤仍要接起来，还要通过实际游玩检查。
水壶尤其像一块小小的试金石。场景里有它，玩家才能完成任务；手里有它，角色动作才有了明确的接触点。Sac 公开的提示词要求保留基础动作中可用的部分，再修正握持、提起和手指位置，避免穿模或水壶悬空。对玩家来说，这些修补不会以“技术成果”的名字出现，只会表现为一个动作是否顺眼。
在这套分工中，Astra 被用于跟踪迭代和修 Bug；Unity 则把场景、角色和互动内容打包为可游玩的版本。Sac 计划在 GitHub 公开完整工程代码与更详细的制作配置。等工程文件放出来，外界才能进一步看清每个环节的耗时、改动和复用程度。现在公开的流程，已经足够说明这款游戏并非由单个模型直接吐出，而是一条从故事拆解、视觉设定、3D 资产、场景拼装到动作修正的连续制作链。
对创作者而言，这件事最打动人的地方仍然很简单：原先只能在脑海里走过的星球，有人把它做成了可以进去的空间。你能听到水声，看到日落，也能提着壶去照顾那朵玫瑰。Sac 用 16 天把这个世界带到了浏览器里，接下来，他还准备把搭建它的方法和工程交出来。一个藏了很久、想亲手造出来的故事，因此又近了一步。