请 Claude“做一个类似《Populous: The Beginning》的东西”后已过去 3 周。回顾 57 次提交的开发历程【阶段性进展】

前言

通过 Unity MCP 向 Claude 请求“做一个像 Populous: The Beginning 的游戏”是在9月29日。
从那之后3周里，我几乎每天都和 Claude 对话并不断完善，加入了标题画面、关卡选择以及结局等内容，已经相当像一款游戏了。

作为一款游戏，它还没有完成。不过，做过的事情已经积累了不少，所以我想在这里回顾一次。

本文会一边回看提交历史，一边总结以下内容。

第1次提示词做到了什么程度
3周内添加了哪些东西
交给AI做的事、由人决定的事、以及人推翻AI答案的事

「试着用生成AI做了个游戏」这类文章有很多，不过我希望大家能把它当作一份过程记录来读——记录的是从最初的试作再往下深入打磨时会发生什么。

用数字看这3周

項目	数値
期間	2026/9/29 〜 10/19（約3週間）
提交次数	57
C#	55个文件・约21,600行
着色器（.shader / .hlsl）	23 个文件・约 3,200 行
最初一次生成时的 C#	約4,700行
AI 持续编写的设计笔记（README）	696 行・44 章

第一次就约 4,700 行，之后通过多轮对话增至约 4.6 倍。

開発環境

用途	使用的工具
游戏引擎	Unity 6.3 / URP
代码、着色器、编辑器扩展	Claude（桌面应用）+ Unity MCP
角色设计、三视图	ChatGPT
三视图 → 3D模型	Tripo
部落色彩的面具	Blender（仅此处为手动操作）
BGM、音效、动画	在 Unity Asset Store 购买的素材
角色的语音	VOICEVOX

没有使用 Claude Code（终端或编辑器扩展）。而是通过 Claude 的桌面应用，经由 Unity MCP 让 Unity 编辑器执行操作。

第一次尝试就做出来的东西

发送的提示词只有这些。

以前有一款叫 PopulusTheBegining 的游戏，希望你能做一个类似那种感觉的、可以在球形星球上到处走动的 RTS 游戏。你可以随意操作当前打开的 Unity 项目，想怎么改都行。

游戏名的拼写也错了（正确写法是 Populous: The Beginning），但意思还是准确传达出来了。没有写任何具体的规格。只要说一句“像某款现有游戏”，提示词就能缩短到这种程度。

Populous: The Beginning（PTB）是 1998 年的一款 RTS，玩家在圆形星球上操控萨满，一边用咒语改变地形，一边与敌方部族战斗。之所以选它作为题材，是因为与平面游戏不同，它包含许多困难的要素。

因为地面是球体，所以“下”的方向会因位置而异
用咒语实时改变地形
必须在球面上进行路径寻路

说实话，我原本以为能有一半左右能跑起来就已经很不错了。然而，在第一次提交的时点，就已经能运行到这种程度了。

※此时还没有BGM和音效（静音）。

用Cube Sphere制作的可变形星球（Planet.cs）。重力朝向星球中心
球面上的A*寻路（PlanetNav.cs）。地形变化时路径也会重新计算
咒文：隆起・沉降・整地・闪电・改宗・地震。把敌人脚下沉降使其落入海中就会溺水
Brave会自动砍树，聚集到建设预定地建造建筑物
敌方AI：建造、训练、让野人改宗、定期袭击。填海造陆来进攻
即使萨满倒下，只要有转生之地，15秒后就会复活

外观完全是原型的样子，但我认为可以说游戏的骨架在第一次就基本成型了。

令我惊讶的是，Claude 并没有做完就撒手不管。据其回复，它还把玩家一侧也交给AI、以快进方式让双方对战，确认了从建立据点、训练战士、袭击到摧毁据点的整套流程都能跑通。此外，它还实际操作鼠标和键盘，尝试了咏唱咒文和建造，甚至测量了帧率（等速下约80FPS）。反过来，它也坦率地写道，左键拖拽的框选没能成功测试。

3周的历程

把提交历史按时期划分，大致分成了4个阶段。

時期	主题	主要提交
9/29〜10/2	制作视觉表现	地形与海洋的着色器、大气与天空、树木、角色的3D模型、BGM与音效、HUD、竖穴式住居、避开建筑物行走
10/6〜10/11	做成游戏形态	部族配色、战士、行星编辑器、第2关、标题画面、结算画面与结局、关卡选择
10/12〜10/15	向原作靠拢	法术与法力的设定、Stonehead、石之神殿、传道师、壁画风 UI
10/16〜10/19	收尾	Blast、法术特效、语音、祈祷动画、exe 化的问题修复

外观：零纹理图片的地形与海

最初委托制作的是占据画面大半的地面与海。Claude 给出的方法是完全不使用任何一张纹理图片，而是在着色器中计算噪声来生成质感。从岸边的泡沫、波浪，到随深度变化的海水颜色，全部用数学公式绘制。

在游戏中按 F3 就能切换改进前和改进后的效果，所以我可以一边对比一边调整。

游戏形态：行星编辑器与关卡

要让它变成可以游玩的形式，就需要有制作关卡的手段。于是，我请 Claude 做了一个用于编辑行星的 Unity 编辑器扩展。堆高或削平地形、放置树木和建筑后保存，就能直接在游戏里游玩。

标题画面、关卡选择（选择漂浮在宇宙中的行星的画面）、结算、结局、存档与读档也都是在这个时期加入的。

向原作靠拢：石像头与咒语

PTB 的核心特色在于：让信徒向石像头（巨大的石头头像）祈祷，从而获得新的咒语。祈祷中途停止计量条就会下降、战士也能参与祈祷、必须从正面祈祷等细节规格，都是在对话中逐步确定下来的。

人类做出的决定、推翻 AI 答案的时刻

这是本文最想写的地方。代码几乎全部由 Claude 编写，但做什么、在哪里停下，每次都由人类决定。

1. 舍弃了物理上正确的天空

请它做天空和大气时，Claude 做出了逐像素计算瑞利散射和米氏散射的物理上正确的天空。蓝天、地平线的亮度、行星边缘的光环、晚霞，全都出自同一个物理公式，相当出色。

但作为游戏画面，总觉得哪里不对劲。

于是我告诉它「不用那么严格。只要有普通的蓝天白云就行」，让它重做成直接指定天顶颜色、地平线颜色、雾霭颜色并加以混合的外观优先版。最终落定为在包裹相机的巨大球体内侧涂上蓝天的天空穹顶。

AI 擅长制作“正确的东西”。不过，游戏所需要的并不是正确，而是“像那么回事”。我感到划清这条线是人的工作。

2. 将世界观从“波普”重新调整为“荒凉”

最初的角色和地面，是玩具般波普风格的外观。那固然也很可爱，但与 PTB 原始而粗犷的世界并不相同。

于是，把地面改成荒地、把海改成暗浊的颜色、把角色改成脏污版本，连打光方式在内把外观全部重做了一遍。

3. “分不清敌我”是手工修好的

改成荒凉的外观之后，这次又变得分不清敌我了。最初是靠自动遮罩来应对的——按色相判定纹理中蓝色的部分并重新涂色，但脏污版本的服装却无法很好地识别出来。

只有这一处，是我自己用 Blender 的纹理绘制 把衣服部分涂白，做成遮罩图像，并让 Claude 构建了读取它的机制。也有比起全部交给 AI，人类花 5 分钟涂一下更快、更可靠的场景。

4. 手感上的违和感，只有人类才能察觉

回看提交历史，会发现有很多用于修正细微违和感的指示。

村民被房子卡住而动弹不得 → 改为把建筑物当作障碍物避开行走
会穿过建筑物的墙壁进出 → 改为从出入口通过
从 Stone Head 的侧面或后方祈祷 → 改为从正面祈祷
萨满在扭头看向别处时施放咒语 → 改为朝向瞄准的方向

这些都是实际玩过之后，才会察觉到“好像有点不对劲”的问题。只要告诉 Claude，它就会立刻修正。不过，察觉到问题则是人类的职责。

5. 中途终止了验证

中途还做了一个实验，比较安装 Unity 官方插件和不安装插件两种情况下爆裂（爆炸咒语）的实现方式。不过，由于没能形成当初想做的比较，所以就在那里中止，并采用了无插件版本。

如果试过之后发现没有意义，就不要深究，及时退回。我认为这也是与 AI 一起开发时，人类应当具备的判断。

不过，安装插件这件事本身并没有白费。正如后文会写到的，在让 AI 重新审视此前成果物的过程中，得以提前发现了构建时的问题。

用生成式AI制作角色和声音

角色：ChatGPT → Tripo → Claude

角色是通过三个生成式AI接力制作出来的。

用 ChatGPT 提出设计方案
用 ChatGPT 制作成三视图
用 Tripo 从三视图进行3D模型化（重拓扑、人型骨骼绑定、FBX 输出）
把 FBX 放进 Unity，Claude 将其导入并设置动画和部族配色

为了写这篇文章回头查看代码时，有一件事让我很惊讶。不知不觉中，AI 已经修复了 AI 制作的模型的缺陷。

Tripo 的自动绑定有时会把萨满大帽子的帽檐也绑定到肩膀和手臂的骨骼上。这样一来，抬起手臂时帽子就会被拉扯而变形。

Claude 在导入模型的同一个提交中，还写了一个名为 HeadFix.cs 的类。这个处理会把从脖颈根部稍上方一直到头部的顶点所绑定的骨骼，平滑地重新绑定到头部骨骼上。查看日志可以发现，萨满的 17,021 个顶点中有 5,111 个被重新绑定。

// 首〜あごの高さで、なめらかに頭の骨へ付け替える
float t = Mathf.InverseLerp(lo, hiT, Vector3.Dot(verts[i], up));
if (t <= 0f) continue;
t = t * t * (3f - 2f * t);   // smoothstep
w[i] = Blend(w[i], hi, t);

我甚至都没有注意到帽子变形了。提交信息里也没有写。我不知道它是怎么发现的，但大概是通过近距离拍摄角色进行检查的机制，自己发现的。也就是说，它不仅做了我要求的事，连我没有要求的质量也替我照看到了。

在让角色握住斧头或法杖时，也会从道具的网格计算出柄的朝向和握持位置，再配合手部骨骼让角色握住。

声音：用 VOICEVOX 批量生成

单位的语音是用 VOICEVOX 制作的。我请 Claude 帮忙，准备了一个从 CSV 剧本批量生成语音的 PowerShell 工具。

units.csv: 每个单位的声音（说话人、音高、语速、语调）
presets.csv: 说话方式预设（询问、命令、尖叫、濒死、念经…）
lines.csv: 剧本（单位、种类、台词）

每一行都会生成音高和长度略有变化的变体，因此同一句台词的重复听起来不容易显得机械。

提前处理的地方、踩坑的地方

Claude 事先察觉到“做成 exe 后可能会变成粉色”

在 Claude 桌面应用里安装 Unity 官方插件时，我做了一项验证。我让 Claude 重新检查安装插件之前做好的东西，试试它能否发现尚未暴露出来的问题。

在那次复查中，它提出了这样的指摘：“如果就这样构建，地形、海洋和天空可能会变成粉色。”

原因是这样的。代码中像 Shader.Find("PlanetRTS/Terrain") 这样只按名字查找的着色器，如果没有被材质引用，构建时就会被当作不需要的东西剔除掉。因为在编辑器里运行没有问题，所以直到构建之前都不会察觉。

我并没有实际确认过它真的变成了粉色。但这个指摘是有道理的，所以我就让它提前做了修复。做法是把运行时用到的着色器引用汇总到一个资源里，并在构建前自动更新。

// Shader.Find の代わりに、ビルドに必ず含まれるアセットから探す
var shader = ShaderLib.Find("PlanetRTS/Terrain");

如果完全交给生成式 AI，往往就变成只在编辑器上确认能运行的状态。让 AI事后审查做出来的东西，有时能发现尚未发生的问题。我明白了，不只是让它做，让它复查的用法也很有效。

回顾：与 AI 一起制作 3 周后明白的事

交给 AI 后顺利推进的事

像球面路径搜索、地形变形这类算法上困难的部分
不使用纹理的着色器、树木网格的程序化生成
编辑器扩展、数据导入、构建设置等周边机制的制作
像修正3D模型缺陷这类不起眼却很麻烦的工作

本应由人类完成的事

决定世界观与方向性（是活泼明快还是荒凉寂寥）
看穿“正确但无趣”并及时叫停
通过试玩察觉不协调感
判断何时终止已尝试的方案

做了之后觉得正确的做法

让 AI 持续撰写 README。 每次添加功能时，都请它把机制和调整点追加记录到 README 里。最终变成了 696 行、44 章的设计笔记，即使会话变了，Claude 也能重新阅读过去的经过并继续工作。

让 AI 制作了能够自行确认的机制。 让它准备了将编译结果和日志输出到文件的机制，以及将相机靠近特定场景并截取屏幕截图的调试命令。例如执行 blasttest 时，会从爆炸瞬间开始，在 0.05 秒后、0.3 秒后……连续拍摄图像。这样一来，Claude 就能运转起自己查看结果并修正的循环，我不必每次都确认的场景也增多了。

进行了细粒度的提交。 57 次提交的历史直接成为了开发记录。这篇文章也是以提交历史和发布到 X 的开发日志为素材写成的。

结语

由于规格与 Populous: The Beginning 完全相同，所以没有销售这款游戏的计划。这终究只是一项实验，用来尝试用生成式 AI 能把游戏做到多大程度符合意图。

到目前为止做了3周的感受是：“AI能做出令人惊讶的东西。但持续决定要做什么的是人类。”

作为游戏还在制作途中，后续也会继续打磨。我希望将来能在 itch.io 等平台，以免费可玩的形式公开。等告一段落后，我打算再写一篇回顾文章。

接下来，我在尝试用一次提示词能把FC名作还原到什么程度。第一弹是吃豆人。

开发的情况正在 X 上以“PTB风RTS 开发日志”的形式每天发布。想知道后续的人请务必关注。

■ 语音
Brave : VOICEVOX:玄野武宏(CV:ガロ)
Warrior : VOICEVOX:剣崎雌雄
Preacher : VOICEVOX:麒ヶ島宗麟(CV:レオブラック)
Shaman : VOICEVOX:冥鳴ひまり