到首个原型为止，3D 资产 100% 由 AI 生成的游戏：Bloom Garden
没有动用任何现成素材，一直到做出可以试玩的首个原型，3D 资产全部由 PicoBerry 生成。 这一段花了大约两周。之后才是游戏系统与 UI 的实现，以及优化。这个过程中究竟需要什么，包括 AI 没能替我们解决的部分，都写在这里。
只用 AI 生成的 3D 资产，能做出真正的手机游戏吗？
Bloom Garden 已经在 Google Play 上线，游戏里出现的花朵、道具和场景物件，全部由 PicoBerry 生成，而推进这件事的是一位没有绘画背景的开发者。到可以试玩的首个原型为止，没有动用任何现成素材，3D 资产 100% 由 AI 生成，这一段大约两周。再往后，答案就得更具体一些：做资产和把游戏做完，是两件不同的事。UI 需要人反复给出反馈；而在场景里反复摆放的物件，面数最后成了性能问题——只能靠美术方向和优化来解。资产环节确实有很大一部分可以交给生成，但场景预算、UI，以及最后那段完成度，仍然是人的工作。
Bloom Garden 是一款怎样的游戏？
一款花园经营游戏：在一片空旷的原野上，一点点经营出兴旺的花卉生意。
种下、养大、收获
种下各种花并把它们养大，看着花园重新有了生气，然后收获。
制作商品、处理订单
把收获的花做成商品，完成村民的订单，再用奖励为下一次扩张做准备。
清理、修缮、扩张
割掉疯长的杂草，修好损坏的机器和建筑，让花园复苏并不断向外扩展。
开发是怎么推进的？
从立项到发行，按实际走过的顺序梳理。
- 开发人数
- 1 人UModeler 的一位游戏开发者
- 周期
- 约 4 周20 个工作日 · 每天 8 小时左右
- 原型达成
- 约 2 周生产、销售、升级、任务、过场
- 现成素材
- 没有3D 资产尽可能都用 PicoBerry 生成
目标很明确：不动用任何现成素材，把一款经营模拟游戏从头做到尾。
那么，剩下的两周用在了什么上？
- 指标追踪的接入 — 接上并配置 SDK，让 Google Play 上线所需的数据真正可见。
- 守住 60 FPS — 重新划定面数与纹理预算，让入门级设备上的帧率不至于垮掉。
- UI/UX 打磨 — 图标、间距、对齐这些从来不会一次到位的东西，反复调整。
- 测试 — 在真机上跑构建，把剩下的问题一个个清掉。
做到原型只是一半，另一半是把它发出去。
立项与原型
在一个被验证过的品类上，试探生成资产的可用边界。
要做的是一款经营模拟：生产 → 销售 → 把收益再投入以生产更多 → 走向自动化。这是近年在手游市场里稳稳站住的品类，所以在已被验证的乐趣结构之上做试探，是合适的。团队调研了同类游戏，参考了它们的核心循环与系统。
原型所需的资产没有任何事先准备，全部由 PicoBerry 提供。因此大约两周就到达了一个真正能玩的原型，生产、销售、升级、任务、过场系统都已具备。
搭建资产管线
不直接生成 3D，先从图像把流程理顺。
因为所有模型都由 PicoBerry 生成，前期最大的难点其实是把流程本身理顺。做法是：先按概念把功能所需的物件生成为图像，在图像阶段反复调整方向，直到看起来确实能用进游戏，再转入 3D。
- 踩过的坑 — 有些角色仅凭一张图像立不住形。此后针对这类物件，会一并生成背面与侧面图像，让模型拿到多个角度再去生成。
- 面数原则 — 默认按尽量低的面数生成，只有形体确实复杂时才略微提高。
游戏实现与 UI
系统逻辑可以交出去，UI 则完全是另一回事。
游戏系统与 UI 的实现用了编程 AI（Claude Code）。其中 HUD 是用 Unity UI Toolkit 做的，而恰恰在这里，AI 在看懂参考图像、把要求准确落到 UI 上这两件事上意外地弱。
即使给了参考图像，各个元素之间的比例也总在第一遍落不准，只能反复提供 UI 图像和反馈，直到出现想要的结果。这一段目前仍然是需要人来定方向、把要求说具体的领域。
发行与外部测试
把优化往后拖的代价，在最后一段全额付清。
最后拖住进度的是 SDK 接入和优化。开发期间测试用的设备性能较好，所以由 PicoBerry 生成的数千面数量级的网格，一直没有暴露成问题。
到了真机环境，这份负担立刻显现，又叠加上 SDK 接入的问题，工作只能全部堆到发行与外部测试之前的最后一段。
3D 资产是怎么做出来的？
这是产出游戏里所有花朵、道具与场景物件的那一套反复流程。
先生成花形图像
在做网格之前，先用图像生成做出多个花形候选来比较挑选。游戏里要把花攒成花束，所以花和花束的形体必须自然衔接。
生成花束图像
以选定的花朵图像为参考，生成花束图像。颜色和形体在进入 3D 之前，就在这一步定下来。
网格 + 纹理
把定下来的花束图像在 PicoBerry 里转成 3D，网格生成与纹理同时进行。与其一次求完美，不如反复地生成、比较、挑选。
在 Unity 中组装
导入、摆放，并接进游戏系统。场景预算真正定下来的地方，就在这一步。
生成出来的资产是打磨的起点，不是做好的游戏内容。上面这些道具，也都是经过筛选和修正之后，才在场景里拿到位置的。
① 花形候选 A
细枝上开满小花的形体候选。
② 花形候选 B — 采用
轮廓更清晰的花形。这张最后定为参考图像。
③ 生成花束图像
以选定的花朵为参考生成的花束图像。
④ 网格 + 纹理
用这张图像同时做出网格与纹理的结果。
用新模型直接生成低模资产
项目后期启用的新生成模型，在结果质量和低模生成质量上都有改善。它意味着不必先做高模再减面，而是可以从一开始就按目标面数生成 — 所以这一段是本页最实用的部分。
本页反复出现的花束就是这个例子。它是游戏里摆得最多的道具，面数负担也因此最重。
最初的做法是按约 5,000 面生成模型，再直接重拓扑到 1,000 面。可是一次减得太狠，形体就垮了：包装纸和缎带塌陷，花朵糊成一团。
换个方向之后，不再先做高模再减面，而是在 image-to-3D 阶段就把面数设低来生成。结果即便是低模也保住了形体，之后再用 UModeler X 稍微修整细节，整理成游戏能用的样子。
生成反复了很多次，但等待并不构成负担。一次生成大约两分钟，改一改面数设置再比较、挑选，这样的循环在现实里是跑得动的。
用 AI 开发游戏，有哪些心得？
想走同一条路的人，可以直接带走的实操判断。
亲手做下来，留下最深的感觉只有一个：AI 的生成结果，靠“把参考资料丢给它、它自会领会”是拿不到想要的东西的。先把风格、职能和结构说清楚，生成多张来比较，再真的跑起来验证 — 把这套反复当作前提，才会有能用的结果。
3D 资产生成心得
不直接生成 3D。图像在先。
先生成图像，再用那张图像做出 3D 物件。把图像风格保持一致，3D 结果也能落在相近的调子上。正因如此，为整个游戏定下一张共用的参考图像、或者一行共用的提示词，就变得很关键。
没有考虑超休闲的风格，只是让它“画一台机器”，结果出来的机器过于复杂，看上去真的能运转。
去掉机械化的细节，把超休闲的调性写进提示词。之后做其他机器时复用这条提示词，要求“不要表现运转，只体现职能差异”，返工次数明显减少。
纹理与风格的统一
把生成模型固定成一个，是第一个前提条件。
- 固定模型 比较多个模型，挑出最接近目标风格的那一个，然后一直用到最后。
- 用参考图像收住波动 即使用同一个模型，结果也会有波动，这时就用参考图像把它收住。与其只说“建筑”“物件”，不如说“这个角色会住的建筑”“这个角色会用的物件” — 把事先定好的参考图像和提示词组合起来，给出上下文。
编程 AI 工具的用法
给它数字，代码就会变好。UI 不吃这一套。
系统开发大部分是用编程 AI 工具推进的。不过既然网格全部由 AI 生成，优化就是必做项。
- 优化 — 走得通的方式 把性能分析的结果原样交给 AI 工具，让它以这些数字为依据定位原因、改进代码，然后再测一次确认。如此反复。
- UI — 走不通的方式 游戏内的 HUD 用 UI Toolkit 做，但布局比例和对齐从来没有一次到位。即使补上参考图像和大致说明，也拿不到想要的构成，往往只能反复重来、直接改 USS 与 UXML，或者亲自指出错在哪里。
人必须亲自过目的地方
“有这些资料它应该能做好吧”，这个念头就是失误本身。
- 先说清职能与结构 回头看，UI 上的失误正是这样交出去造成的。本该先让它准确理解每个元素的职能和结构，再开始动手。
- 运行环境 算法上看不出问题的代码，放到真实的运行环境、放到 Unity 应用的特性之下，仍可能出问题。这部分终究离不开亲自跑测试、发现了再补的过程。
如果再做一次同样的东西
- 会在起步阶段就准确判断运行性能，并据此定下面数与资产标准。 这一次没有做准确的测量就往前走，结果是后期回头改资产，还遇到了没预料到的卡顿。
- 会在最终阶段留出足够时间，用性能分析和构建测试把优化跑透。 细碎的场景物件只能在开发后期才摆上，此前并不存在的物件一下子全冒出来，负担因此暴露得太晚。
- 图像不会一张一张地出，而是一次出 2~4 张来比较。 AI 的生成结果常常不会一次就给到想要的东西，光是改成这样，工作就轻松了不少。
AI 做到了哪里，又在哪里停下？
这个案例里真正有用的不是成功故事，而是这条边界线。
AI 生成能覆盖的范围
- 在没有专职美术的情况下，拿到了够一款游戏用的道具体量。没有绘画背景的开发者也能推进。
- 把原型和外部测试版本，做到了真正能玩的状态。
- 可以快速试各种观感。不必被一件费工夫的资产绑住，而是生成多个候选来比较、挑选。
- 后期启用的新模型，在结果质量和低模生成质量上都有肉眼可见的改善。
仍然需要人手的范围
- UI 的设计与布局需要人反复给反馈。意图、参考图像和游戏上下文，并不会一次就被准确反映出来。
- 场景层面的预算 — 面数、阴影、纹理，以及不断堆积的物件，生成并不会替你决定。
- 玩家真正会感受到的那段完成度上的美术方向。
- 性能审视。编程 AI 会优先让功能出现在画面上，所以性能结构得由人、或由一条独立的复查流程在早期就明确下来。
- 为了配合游戏内演出所做的最小限度网格与纹理修改，是人在 UModeler X 里直接动手完成的。
面数预算教会了我们什么？
这是本项目里最值得推广的一条教训，以及它在 PicoBerry 里是怎么解的。
重复摆放会悄悄变成乘法
单看一束花，面数再高也不像有问题。可随着游戏推进、数量堆起来，同一件资产就要同时绘制几十万面。变糟的不是资产，是场景。
与其重拓扑，不如“直接生成低模”
先做高模再用重拓扑减面，形体被破坏的风险很大，耗时也忽长忽短。真正起决定作用的，是 PicoBerry 新增的一个生成模型，它擅长直接做低模网格。用它从一开始就以低面数生成，面数降到原来的十分之一以下仍能保住形体，比先做网格再减面的路子好。
看起来小，就可以画得省一点
在画面上小而重复的物件，没必要保留完整的 3D 复杂度。先比较基于纹理的表现、更简单的网格，或者切换成广告牌，再决定要不要坚持用精细版本。
预算要在动手之前定
优化被挤到了临近截止的位置，留给阴影、纹理和堆积物件的调整余地就不够了。解法是在项目启动时就定好面数与性能预算，并把性能分析放在中途，而不是放在收尾。
测试设备是入门级 Android 机型 Galaxy A16（分辨率 2340×1080）。优化前部分场景会掉到 10~30 FPS，做完下列处理之后稳定在 60 FPS。
| 对象 | 处理前 | 处理后 |
|---|---|---|
| 仓库中的 36 束花 | 约 400,000 面 | 约 18,000 面 |
| 玫瑰田的生长与收获（玫瑰 25×6 = 150 株） | 约 750,000 面 | 约 75,000 面 |
| 纹理（合并为一张调色板） | 2048 尺寸数十张 | 512 尺寸 1 张 |
同一个物件，只要在场景里堆到几十上百个，面数就会成倍膨胀。把单件资产的面数降下来，再把多张纹理合并成一张调色板之后，入门级设备上的帧率也稳住了。
① 用重拓扑减面的最初做法
把约 5,000 面的模型一次重拓扑到 1,000 面之后，包装纸和花形都垮掉了。
② 从一开始就生成低模
在 image-to-3D 阶段把面数设低来生成，即便是低模也保住了形体。
③ 用 UModeler X 整理
把生成结果在 UModeler X 里稍作修整，收成游戏能用的样子。
在编辑器里做了哪些工作
把生成好的资产放进 Unity 场景、再接到系统上 — 这是人手介入的那一段。
在编辑器里的工作
在 Unity 编辑器里为市政厅相关物件设置 Inspector 数值的工作画面。
实际跑起来是什么样？
这是已上线版本的实机画面。生成的资产就这样在 Unity 里运行着。
常见问题
Bloom Garden 是一款怎样的游戏？
一款已在 Google Play 上线的花园经营游戏，开发方是 UModeler。你会种花、收获，把它们做成村民订单需要的商品，同时清理杂草、修缮设施，让花园不断扩张。3D 资产由 PicoBerry 生成，游戏本体则用 Unity 制作。
制作资产时用到了 PicoBerry 的哪些功能？
先用图像生成定下参考调性，再拿这些图像生成 3D 模型，最后给结果做纹理。项目后期还额外用了一个低模效果更好的新模型。
做完游戏全部资产花了多少积分？
合计 82,280 积分。不过请不要把这个数字直接当成报价 — 它不是真正进入游戏的那部分，而是把没有用上的候选也全部算了进去。期间做了 514 张图像和 153 个 3D 模型，平均每个模型出了三张以上的图像。本页一再推荐的那种“不要一次求完美，多出几张来比较”的做法，成本正是这个数字。换个尺度看：一位开发者在大约一个月里，把一款游戏所需的全部 3D 资产，控制在一个月订阅的额度之内解决了。这还是第一次搭这条管线、试错占比很大的情况；流程稳定之后会更低。
是 AI 做出了整款游戏吗？
不是。PicoBerry 产出的是 3D 资产。游戏的系统与 UI、场景组装和性能相关的工作，都由团队在 Unity 里亲自完成。若把生成结果当作做好的游戏内容来读，就会读错这个案例。
要用这种方式，必须是美术出身吗？
如果只做到原型或测试版本，并不需要。没有绘画背景的开发者，用这种方式做出了够一款游戏用的道具体量。但在玩家真正会感受到的那段完成度上，美术方向是必要的。它降低的是入门的门槛，并不会替你省掉眼光和复查 — 这是诚实的回答。
怎样才能让 AI 生成的资产不拖垮性能？
把面数预算定在生成之前，而不是生成之后。硬把高模用重拓扑减面，形体可能被破坏，所以更稳妥的做法是按目标面数生成，或者选一个低模质量好的模型。另外，重复摆放的物件必须当作场景问题来处理：屏幕占比与数量、阴影、纹理，以及 LOD 或广告牌的切换，都要一起设计。
把高模减面不就行了吗？
有时可行，但在这个项目里很难依赖它。削减幅度一大，剪影就有被破坏的风险，耗时又忽长忽短，排进日程很困难。从一开始就按目标密度生成，效率更高。
下一个项目会做哪些改变？
在项目立项时就定好性能与资产标准，并把性能分析和构建测试放在中途，而不是收尾。为发行前的优化与 QA 单独留出时间；UI 与玩法代码不只看画面上呈现的结果，也要连同更新开销与性能一起复查。