AI 多模型协作游戏开发全流程实战笔记

AI 多模型协作游戏开发全流程实战笔记

本视频展示了作者如何使用多款 AI 模型分工协作，从一张 Pinterest 图片出发，完整构建一个雪地生存风格游戏原型的过程；其核心理念是“不要用一个提示词生成整个游戏”，而是让每个任务独立使用一次干净的会话，逐步完成场景、角色、机制与光影。

一、核心要点

1.1 视频性质说明

• 本视频区别于常见的单提示词生成演示，完整展示作者如何构建整个游戏。
• 游戏在 Garard 引擎中制作。
• 明确强调：这并非一次提示词所能完成的结果。
• 内容目标：展示作者平时与 AI 模型协作的完整工作方式。

1.2 使用的 AI 模型与分工

1.3 核心工作哲学

• 不要在一个提示词中请求整个游戏。
• 让最强的模型先写出整体计划。
• 每个任务（job）获得一个独立的全新会话。
• 每个任务结束时都进行一次测试。
• 测试失败时，只将该任务退回重做，而不是推翻整个游戏。

二、详细解析：工作方法

2.1 启动项目

• 作者承认“开始是最难的部分”。
• 过去曾有过数个类似项目，但都没有完成——外观看起来正确，但没有任何一个具备完整的游戏循环（gameplay loop）。
• 本次项目的起点：在 Pinterest 上浏览时看到一张图片，被深深吸引，强烈希望将其制作为游戏。
• 使用该图片作为参考图——目的不是复制它，而是捕捉同样的感觉。

2.2 色彩圣经（Color Bible）

• 项目启动的第一步是创建“色彩圣经”（color bible）。
• 由于参考图是日光场景，而作者想要表现同一地点在入夜后的效果，每一个颜色都需首先经过转换。
• 规则：从此刻起，游戏中任何元素若不遵循色彩圣经，就不能放入游戏。

2.3 任务会话管理

• 流程：每个任务（job）独立启动一个全新的聊天会话。
• 每个任务以一次测试结束。
• 失败时，仅将这一任务退回修改，而不是影响整个游戏开发。
• 优势分析：
• 每个模型不需要同时承担其他九个任务，因此“记忆负担更轻”，出错更少。
• 因为上下文更短，消耗的 token 也更少。

三、方法与步骤：逐任务构建游戏

3.1 任务一：地面系统

• 需求：某些地方积雪很深，另一些地方雪很薄。
• 执行：Fable 制定计划，Opus 编写代码。

技术原理

• 地面以完全平坦的状态起步。
• 地面上每一个顶点（corner）每秒钟被询问六十次同一个问题：“你有多高？”
• 回答范围：100、10、0 或介于两者之间的任意值。
• 该高度值不会被保存，因为高度不断变化。
• 风（系统）会将雪压实，从而形成雪堆/漂移（drift）的视觉效果。
• 地图并非无限大：只有 120 米的范围，该范围会跟随角色滑动。

雪对移动的影响

• 积雪会减慢角色速度。
• 深雪中角色只能“跋涉”前进，薄雪处可以奔跑。

脚印系统

• 功能：玩家可以看到自己走过的路径。
• 意义：这是小细节，但能让世界显得有生命力。

脚印的幕后机制

• 每一步都绘制到一张固定大小的图片中，另一份列表存储所有脚印数据。
• 这套系统如何工作：
• 雪系统读取该图片；
• 风系统会擦除它（脚印逐渐消失）；
• 敌人也读取同一张图片。
• 性能优势：一千个脚印的成本与一个脚印相同（将数据合并为一张图片处理）。

3.2 任务二：替换占位模型

• 初始场景中放置了房屋、树木和车辆，这些都是占位符（placeholders），后续替换为真实 Blender 模型。

程序化建模流程

• 房屋并非任何人手工建模。
• 工作流程：

1. AI 模型编写一个脚本；
2. Blender 执行该脚本；
3. 脚本中每一行代码添加一个组件；
4. 当屋顶出错时，不需要直接修改网格（mesh），而是修复一行代码后重新运行。

• 随后将新的房屋模型加入场景，效果明显改善。
• 同样的流程用于树木和车辆。

3.3 建模经验法则

• 不要向 AI 索要写实（realistic）效果——AI 无法交付。
• 但简单形状（simple shapes） 它能做得很好。
• 这座房屋本质上只是几个盒子和一个屋顶的组合，其余效果由灯光完成。

3.4 任务三：角色

• 流程分两步：

1. 首先用 GPT 生成角色概念图。
2. 将生成的概念图像输入 Mesh AI（meshy）——作者偏爱的角色网格生成工具。

角色技术数据

• 角色多边形数量：1200 个多边形（eight zero polygons，原文疑似口误，上下文推断为约 1200），作者认为对主角来说完全足够。
• 对角色进行测试拉伸（text straight），结果正常。
• 使用 Meshy 直接提供的动画资源。
• 后续会将颜色映射到色彩圣经规定的色板上。

角色外观差异说明

• 直接生成的角色看起来更简单、细节更少、颜色略有不同。
• 作者表示会在后续修正，最终在游戏中效果良好。

3.5 任务四：灯光系统

• 灯光对场景氛围影响极大。

灯光控制面板

• 建议做法：让 AI 模型生成一个灯光控制面板，带滑杆供实时调节。
• 如果游戏引擎（如 Godot）直接支持，也可以直接在引擎内操作。

预设场景

• 作者强调：灯光设置可以影响整个游戏的氛围（game blood / mood）。

3.6 任务五：敌人系统

• 设计原则：敌人数量很少，但每一次相遇都应能立刻杀死玩家。
• 敌人类型：
• 饥饿的人（a starving man）——视觉察觉玩家（“看到你”）。
• 熊（bears）——通过气味感知玩家（“闻到你的风向”）。

熊的模型来源

• 在 Sketchfab 上找到带 CC Attribution（CC 署名）许可的熊模型，附带大量动画。
• 该熊模型是写实风格，与游戏低多边形风格不匹配。
• 于是要求 AI 在 Blender 中进行减面（decimation）处理。

减面（Decimation）过程

• 展示减面的四个阶段。
• 减面本质上就是降低多边形数量。

战斗机制（目前为原型）

• 按 F 键，枪械会锁定目标。
• 熊是永远无法被跑赢的。
• 熊的行为：先发出警告，然后冲锋，将玩家扑倒。
• 目前阶段：玩家被扑倒后只能重新开始（lighter，原文表述不明确）。

3.7 任务六：房屋内部

• 关键设计：房屋内部不是独立关卡/位置，与外部是同一个场景。
• 玩家可以看到屋外存在的危险。

技术实现原理

• 当玩家踏入房屋的瞬间：
• 屋顶和正面墙壁自动消失。
• 另有配套系统：角色走到某些物体（如树）后方时，该物体整体淡出（透明化）。
• 摄像机始终以环绕视角（aerial rat / camera orbits） 观察角色。

四、限制与待确认问题

• 游戏循环尚未最终确认：作者明确提到过去的项目“看起来对但都没有游戏循环”，本视频中展示的敌人战斗机制和角色移动是否构成完整的核心循环，视频中未给出明确结论。
• “six”模型身份不明：原文提到 “four fablefive, opus five, GPT five, six soul, and kimik three”，其中 “six soul” 的具体归属（是哪个公司的第六代模型）没有明确说明，但根据分工推断其职责为 Blender 相关工作。
• 角色多边形数量存在歧义：原文 “eight zero polygons” 表述模糊，可能为 “1200 polygons（twelve hundred）” 的口误，也可能指 80 或 800，无法确定。
• “you just lighter”含义不明：在熊将玩家扑倒后的行为描述，原文为 “for now, you just lighter”，可能指玩家只是轻伤或重新开始，原文没有明确解释。
• 地图 120 米的边界机制：视频说明地图只有 120 米且跟随角色滑动，但未说明边界外的空间如何生成或过渡。

五、行动清单（视频中的实操建议）

1. 从参考图开始，抓住“感觉”而非复制内容。
2. 先创建色彩圣经，将所有视觉元素统一转换到目标色调（如白昼转夜晚）。
3. 让最强模型（如 Fable）先写整体计划，不要直接请求整个游戏。
4. 每个任务单独开启新的会话；任务完成后立刻测试；失败只回退该任务。
5. 地面和脚印等系统用程序化方式构建，充分利用 AI 写代码脚本的能力。
6. 建模时向 AI 索要简单形状而非写实模型，复杂细节交给灯光完成。
7. 让 AI 生成灯光控制面板，用滑杆实时调试多种时段预设。
8. 需要减面时，要求 AI 在 Blender 中执行 decimation 流程。
9. 门内与门外使用同一个场景，通过隐藏墙壁/屋顶切换视角，而不是新建关卡。
10. 使用带 CC 署名许可的现成模型，保证合规。

六、总结

本视频呈现了一种结构化的 AI 辅助游戏开发方法论，其核心创新点包括：

• 多模型各司其职：决策（Fable）、代码（Opus）、美术概念（GPT）、Blender 美学与建模（Kimi K3）分开处理，避免互相干扰。
• 单任务会话隔离：每个任务独立会话、独立测试，降低模型出错率并减少 token 消耗。
• 程序化生成：从雪地高度、脚印系统到房屋建模，全部依赖 AI 生成代码+引擎/Blender 执行，而非手工处理。
• 同一场景的“室内外”设计：通过模型隐藏而非切换场景来实现室内视角，是一个极简而有效的技术方案。
• 低多边形美术风格统一：不追求写实而注重光影氛围，使整个项目在低资源下也能达到一致的视觉表现。

从 Pinterest 参考图到可游玩的雪夜场景，整个流程体现了“用 AI 做计划、用代码做结构、用美术做氛围”的分层协作思路，对希望用 AI 辅助进行独立游戏开发的人有较强的参考价值。