AI零代码复刻《杀戮尖塔》：从架构到美术的完整实践

当AI遇上独立游戏开发：零代码能走多远

一款涉及状态机、卡牌系统、肉鸽机制等复杂专业知识的游戏，能否在完全不写代码的情况下完成开发？B站UP主用Godot引擎配合AI工具链，从零复刻了经典卡牌肉鸽游戏《杀戮尖塔》，全程没有手写一行代码，并且已将项目完整开源。

这里有必要解释一下这些术语的技术含量。**状态机（State Machine）**是游戏开发中管理对象行为的核心设计模式，它将角色或系统的行为划分为多个离散状态（如待机、攻击、防御、死亡），并定义状态之间的转换条件。在《杀戮尖塔》中，战斗流程、回合管理、敌人AI意图切换等都依赖状态机来驱动。卡牌系统则涉及牌库构建、抽牌/弃牌/消耗的牌堆管理、卡牌效果的解析与执行等一系列相互关联的子系统。肉鸽（Roguelike）机制的核心特征包括程序化生成的关卡地图、永久死亡（Permadeath）、随机掉落与构建策略，这要求开发者实现随机地图生成算法、种子系统以及大量可组合的游戏元素。这三者的交叉使得项目复杂度远超一般的小型游戏——这也是为什么这个"零代码"案例格外引人注目。

这个案例展示了AI辅助游戏开发的一种极端但有效的工作流：让AI负责代码架构和实现，让AI绘图工具负责全部美术资产，开发者只需扮演"产品经理"和"质量检测员"的角色。

代码开发：架构文档先行，迭代式推进

为什么选择Godot引擎

值得一提的是引擎的选择。Godot是一款完全免费且开源的跨平台游戏引擎，采用MIT许可证发布，开发者可以自由使用而无需支付任何费用或版税——这与Unity近年来引发争议的运行时费用政策形成鲜明对比。Godot使用自研的GDScript脚本语言（语法类似Python，学习曲线平缓），同时也支持C#和C++。其场景系统采用节点树（Node Tree）架构，所有游戏对象都是节点的组合，这种设计天然适合模块化开发。Godot的轻量级特性（编辑器本身仅约40MB）和活跃的社区生态，使其成为独立游戏开发者的热门选择，也因其代码结构清晰、文档完善，成为AI辅助编程的理想目标引擎。

先输出架构文档，再动手开发

作者强调了一个很多AI编程新手容易踩的坑：直接让AI开始写代码。正确的做法是先让AI输出一份完整的架构文档。对于《杀戮尖塔》这样涉及卡牌系统、状态机、战斗逻辑等多个复杂模块的项目，没有清晰的架构规划，后期必然陷入混乱和bug泥潭。

为什么架构文档在AI编程中如此关键？在传统软件工程中，架构文档用于描述系统的高层结构、模块划分、数据流和接口定义。但在AI辅助编程的语境下，它的作用被进一步放大：架构文档本质上充当了AI的"长期记忆"和"全局上下文"。大语言模型的上下文窗口是有限的，当项目代码量增长到数千行时，AI无法同时"看到"所有代码。架构文档提供了一个压缩的全局视图，让AI在处理任何单个模块时都能理解它在整体系统中的位置和职责。没有这份文档，AI在后期开发中容易产生模块间的接口冲突、命名不一致、重复实现等问题，最终导致项目陷入"越改越乱"的恶性循环。

具体流程如下：

1. 向AI提问"如何从零开始复刻一个杀戮尖塔项目"
2. AI给出完整的架构规划
3. 让AI将规划沉淀为架构文档
4. 再根据文档逐步开发

接受不完美，多轮迭代修复

作者坦言，不要幻想AI能一遍跑通。初始版本往往界面简陋、功能缺失、满是bug，甚至无法启动——这都是正常的。开发者的核心工作是"查缺补漏"：发现问题、描述问题、让AI修复问题，经过多轮对话最终得到一个具备完整玩法循环的原型版本。

这里提到的"玩法循环（Gameplay Loop）"是游戏设计中的基础概念，指玩家在游戏中反复经历的核心行为链条。在《杀戮尖塔》中，微观层面的玩法循环是"抽牌→出牌→结束回合→敌人行动"的战斗回合循环；宏观层面则是"选择路径→进入战斗/事件→获得奖励→强化牌组→挑战下一层"的探索循环。一个原型版本只要跑通了核心玩法循环，即使画面粗糙、内容匮乏，也已经具备了验证游戏性的基本条件。这也是游戏行业常说的"先做好玩的，再做好看的"开发理念的体现。

这个"毛坯房"虽然画面粗糙，但已经实现了卡牌抽取、战斗回合、敌人AI等核心机制，为后续的美术"装修"打下了坚实基础。

美术制作：AI绘图工具的系统化运用

主菜单设计流程

美术环节使用了Hallopix的自由画布功能。作者将主菜单拆解为三类元素：背景图、游戏Logo、按钮组。

• 背景图：直接让AI生成提示词，一键生图
• 游戏Logo：使用"游戏Logo设计"模板，填写名称信息，用背景图作为风格参考保证视觉一致性
• 按钮：以Logo为风格参考，提示词写"同风格设计游戏按钮"

生成后的素材通过一键抠图去除背景，多张图片建立分组后可一起导出为压缩包，大幅提升了资产管理效率。

界面设计的三步转换法

角色选择页面的设计展示了一套高效的工作流：

1. 截图→交互图：将原版页面截图作为参考，使用"界面转交互图"模板生成线框图
2. 交互图→界面图：交互图为参考图1，主菜单背景为参考图2，使用"交互图转界面图"模板，确保风格统一
3. 界面图→精灵图：将结果作为参考图，选择"UI界面空间"模板拆分为可用的精灵图，最后一键抠图

这里需要解释一下**精灵图（Sprite）**的概念。精灵图是2D游戏中最基本的视觉单元，指从完整画面中裁切出的、带有透明背景的独立图像元素。在游戏引擎中，每个UI按钮、角色立绘、卡牌图标都是一张独立的精灵图，引擎通过代码控制它们的位置、缩放、层级和交互行为。传统的游戏美术管线需要美术师在Photoshop中逐个切图、命名、导出，再由程序员在引擎中手动配置坐标和锚点——这是一个繁琐且容易出错的过程。

更巧妙的是，作者并没有自己处理精灵图的导入和定位，而是将界面图和精灵图一起发给AI，让AI直接在代码中实现界面布局。这本质上是用AI自动化了"设计稿→切图→引擎集成"的传统管线，将原本需要美术和程序紧密协作的环节压缩为一个人与AI的对话过程。虽然大概率不会一次成功，但多改几轮依然比手动处理快得多。

角色与卡牌的批量生成

战斗页面的核心资产是角色和卡牌。为保证画风一致性，作者采用了批量化策略：

• 角色：先用AI批量产出所有角色的生图提示词，再批量完成生图
• 卡牌：使用统一模板的提示词和参考图，参考图是保证细节一致性的关键

关于风格一致性控制，这是AI图像生成领域的一个核心挑战。由于扩散模型（Diffusion Model）每次生成都包含随机噪声采样过程，即使使用完全相同的提示词，生成结果也会存在色调、笔触、细节风格上的差异。作者采用的"参考图"策略，本质上是利用了图像到图像（Image-to-Image）生成技术：将已有的风格统一的图片作为视觉锚点输入模型，约束生成结果的风格空间。这种方法比单纯依赖文字提示词更有效，因为视觉特征（如配色方案、光影风格、线条粗细）很难用语言精确描述，但可以通过参考图直接传递。批量生成时统一使用同一张参考图和模板，是目前AI美术工作流中保证资产一致性的最佳实践之一。

生成完成后，通过分组导出压缩包，解压后将文件夹直接拖入Godot资源目录，把文件路径复制给AI让它完成资源替换。整个流程形成了从生成到集成的完整闭环。

关键方法论总结

开发者角色的转变

在这个项目中，开发者的角色从"程序员+美术"转变为四个方向：

• 架构师：把控整体方向和模块划分
• 质量检测员：发现bug并精确描述问题
• 产品经理：拆解需求、规划工作流
• 素材管理员：组织和集成AI生成的资产

可复用的工作流模式

1. 架构文档先行，避免后期混乱
2. 接受迭代，不追求一次成功
3. 美术素材遵循拆解→批量生成→统一风格→自动集成的流程
4. 尽可能让AI完成"最后一公里"，比如精灵图导入、路径替换等重复性工作

结语

这个项目证明了一个趋势：AI工具链正在让独立游戏开发的门槛急剧降低。当然，"零代码"并不意味着"零技能"——开发者仍需具备架构思维、问题拆解能力和对游戏设计的理解。AI替代的是执行层面的编码和绘图工作，但设计决策和质量把控仍然需要人类智慧。

项目已完整开源，感兴趣的开发者可以参考这套工作流，尝试用AI复刻自己喜欢的游戏。