嘿 r/aigamedev,

在 7 月，我决定为 Steam 的 Pins & Pegs Fest 2026 制作一款游戏。没有合适的项目准备好，我便与 Claude 共同讨论了许多想法。

我们选择的概念是：如果匹配-3 板也变成弹子机板呢？

这就变成了 Matchinko。首先，你需要在匹配-3 板上将符文石融合成更强大的石头。然后，你需要释放一批精灵，让它们通过同一板子，碰到石头时会根据你建造的内容获得奖励。游玩之间，你可以购买改变物理和计分规则的棋子和精灵。

节日的约束帮助了我。相比于要求 AI “发明一款游戏”，我可以问一个具体的问题：如何让针和钉子支持一个不是仅仅是另一个 Peggle 克隆的机制？

到 Steam 的十六天

第一份设计提交是 7 月 8 日。第一份成功的 Matchinko SteamPipe 上传是在 7 月 24 日：从初步设计到 Steam 的 16 天和大约三小时。

单独的 16 步演示 App ID 在 7 月 31 日上传，约为 23 天后。8 月份，我继续重建艺术和打磨演示，但没有花费 41 天才能到达 Steam。

第一版可玩的 JavaScript/Canvas 原型在第一天就存在。到 7 月 15 日，它已经可以在 Rust 中运行。到 7 月 23 日，所有三个平台包都存在。后续的大部分工作都是重新设计和发布硬化。

我、Claude 和 Codex

我使用 Claude 和 OpenAI Codex 来交替使用，当我耗尽令牌或想要一个新的尝试时。

我负责项目的指导，做出设计决策，审查工作，并进行测试。Claude 和 Codex 构建了代码库：游戏玩法、定制弹子机物理、渲染、程序化艺术、UI、音频、测试、模拟、平台打包、Steam 集成和发布保护。

Matchinko 是 没有使用游戏引擎的——没有 Unity、Unreal、Godot 或 GameMaker。

不使用引擎并不意味着不依赖任何库。它使用了较低层级的库，包括 wgpu、winit 和 egui。我们仍然需要自己构建游戏架构、帧循环、物理、渲染器、场景组合和平台管道。

视觉效果中 没有使用 AI 生成的图像资产。房屋、雪、雕刻、精灵、板子和界面都是通过自定义程序化木刻渲染器生成的。AI 帮助编写了该渲染器，但没有使用图像模型生成图片。AI 被用于代码、音乐、创意和一些 Steam 复制。

DOD 技能

架构由可重用的 数据导向设计技能 指导，基于我在书籍 高性能 Unity 游戏开发 中提出的原则并延伸至 Unity 之外。

这给了两个代理相同的持久规则：静态 Balance 数据、平行数组中的可变 GameData、纯逻辑函数、只读的呈现层、种子随机数和热路径中的无分配。

这种分离使得不使用引擎的方法成为可行的，并允许游戏的大部分在没有窗口、GPU、音频设备或 Steam 客户端的情况下运行。

AI 加速了什么——以及它没有做到

AI 在产生一个明确的界限内的完整系统的第一版中表现出色。这是我们在第一天就能实现可玩原型并快速构建 Steam 本机版本的原因。

弱点是 全局一致性。我们仍然能够：

  • 让 JavaScript 和 Rust 实现分开
  • 上传了一个过时的旧演示
  • 展示了 32 步的演示，而应该是 16 步
  • 几乎将过时的 Windows 构建与更新的 Mac 和 Linux 构建组合在一起
  • 让物品描述与其真实行为分离
  • 生成了可通过测试的但仍然看起来被裁剪或不连续的胶囊艺术

这些并不是语法错误。这些是集成、产品和真实性源错误。

我们通过以下方式修复了它们：退役了重复的 JavaScript 游戏、制作了一个编译时的演示构建风味、嵌入并验证了 Steam App ID、在准备它们之前扫描二进制文件、从活跃的平衡数据派生描述、并添加了到达每个精灵和棋子的可达性测试。

现在，游戏有超过 900 个测试，包括一个种子无头玩家来跑数百个完整游戏来平衡。然而，既没有取代人类测试，也没有取代视觉判断。

四个可重用的技能

我将最有用的工作流程提取到公共的、MIT 许可的技能：

我的最大收获是，AI 可以显著缩短到达一个工作系统的路径，但它也会增加需要指导和验证的输出量。对 AI 助手错误的最佳回应不是“下次更小心”。而是添加一个使相同错误无法发生的保护措施。

结果是 Matchinko，具有 16 步的演示：

Steam： https://store.steampowered.com/app/4994610/Matchinko/

对于使用多个编码代理的开发者：是否有共同的技能或项目规则让他们保持一致？还是说模型仍然会将你的项目拉向不同的方向？