Godot+Cursor打造类幸存者游戏：从零到Steam上架全记录

引言：一场AI辅助游戏开发的实验

这是一个颇具野心的系列项目——B站UP主「老李游戏学院」决定用Vibe Coding的方式，借助Cursor（AI辅助编程工具）和Godot游戏引擎，从零开始制作一款类幸存者（Survivors-like）游戏，并最终上架Steam或itch.io。

所谓Vibe Coding（氛围编程），是由前OpenAI联合创始人、特斯拉前AI总监Andrej Karpathy在2025年初提出的概念。其核心理念是：开发者不再逐行编写代码，而是通过自然语言向AI描述需求，由AI生成代码，开发者更多扮演「导演」和「审稿人」的角色。这种开发方式正在重新定义「编程」的边界——你不需要精通每一行语法，但需要清晰地知道自己想要什么，以及如何判断AI给出的结果是否正确。

这个系列最大的特点是实况形式：UP主并没有提前完整做一遍，而是和观众一起遇到问题、解决问题，逐步推进项目。第一期的内容聚焦于项目初始化，虽然看似基础，但其中涉及的工具选型思路、工作流搭建和Godot基础知识，对于想入门AI游戏开发的同学来说非常有参考价值。

为什么选择「类幸存者」品类？

在众多游戏类型中，老李最终选择了类幸存者这个品类，理由非常务实：

• 项目体量可控：不会像RPG那样庞大到难以完成，也不会像小游戏那样过于简单，无法充分展示AI编程的能力
• 玩法框架清晰：类幸存者游戏有成熟的设计范式（自动攻击、升级选择、怪物波次等），适合作为AI辅助开发的实验项目
• 可扩展性强：先做2D版本，后续可以演进为3D版本

类幸存者（Survivors-like）这个品类的爆发，可以追溯到2022年意大利独立开发者Luca Galante制作的《Vampire Survivors》。这款售价仅几美元、画面极其简陋的小游戏，凭借极度上瘾的核心循环——「击杀怪物→获取经验→升级选择武器/被动→面对更强的怪物波次」——在Steam上卖出了数百万份，并催生了一个全新的游戏子品类。此后，《弹壳特攻队》《Brotato》《Soulstone Survivors》等大量同类作品涌现，证明了这套玩法框架的强大生命力。对于AI辅助开发而言，类幸存者品类的优势在于其系统模块化程度高：武器系统、升级系统、怪物生成系统、经验/掉落系统等都可以相对独立地开发和测试，非常适合逐步迭代。

美术风格方面，初期采用极简多边形风格，后续可以考虑用AI生成素材替换。这种策略非常聪明——先跑通玩法，再打磨视觉，避免在早期陷入美术资源的泥潭。

为什么用Godot而不是Unity或Unreal？

这是很多开发者关心的问题，老李给出了几个关键理由：

第一，文本化的文件格式。 Godot从设计之初就考虑了版本控制的需求，无论是脚本文件（.gd）、场景文件（.tscn）还是资源文件，绝大部分都是纯文本格式。这不仅方便Git管理，更重要的是——AI可以直接生成和修改这些文件。

具体来说，Godot的.tscn（Text Scene）文件采用类似INI的纯文本结构，用[node]标签描述节点层级关系，用[ext_resource]引用外部资源。例如一个简单的场景文件可能长这样：节点名称、类型、父节点关系、属性值全部以可读文本呈现。而.tres（Text Resource）文件同样是纯文本，用于存储材质、主题、动画等资源数据。相比之下，Unity的.unity场景文件虽然也是YAML格式的文本，但其中包含大量GUID引用和序列化的二进制数据引用，可读性远不如Godot；Unreal的.umap和.uasset则是完全的二进制格式，人类和AI都无法直接阅读或编辑。这意味着在Vibe Coding场景下，AI不仅能生成GDScript代码，还能直接「写出」完整的场景文件和资源文件，实现真正的全流程自动化。

第二，开源带来的「白盒」优势。 Godot是完全开源的游戏引擎，对于AI大模型来说，它的内部实现是透明的。而Unity和Unreal对AI来说更像是「黑盒」，很多底层机制AI并不了解，这会直接影响代码生成的质量。

这个「白盒」优势值得进一步展开。当前主流AI大模型（如GPT-4、Claude等）的编程能力来源于训练数据中的海量代码。Godot引擎的完整源代码托管在GitHub上，拥有超过90,000颗星标，其C++底层实现、GDScript解释器逻辑、渲染管线代码全部公开可索引。这意味着AI模型在训练阶段就「阅读」过Godot的内部实现，理解其API背后的真实行为。而Unity的核心运行时（C++层）是闭源的，开发者和AI只能通过官方文档和C#层的API来推测底层行为；Unreal虽然提供源码访问，但需要签署协议且代码库极其庞大（数百万行C++），AI对其理解的深度和准确度远不如体量更小、结构更清晰的Godot。在实际开发中，这种差异会体现为：AI为Godot生成的代码更少出现「看起来对但运行时行为不符预期」的问题。

这个观点值得深思。在AI辅助编程的时代，工具的「AI友好度」正在成为一个重要的选型维度。

工具链搭建：Git + Cursor + Godot

版本控制：AI编程不可或缺的安全网

老李特别强调，使用AI辅助编程时，版本控制工具尤其重要。AI生成的代码可能引入意想不到的问题，有了Git就可以随时回滚。

这一点在Vibe Coding的实践中尤为关键。与传统开发中程序员逐行编写、逐步调试不同，AI往往会一次性生成大量代码甚至修改多个文件。如果生成的代码引入了隐蔽的Bug，或者AI「好心」地重构了你不想改动的部分，没有版本控制就意味着灾难性的后果——你可能根本不记得哪些文件被改过、改了什么。Git的分支和回滚机制在这里充当了「时间机器」的角色：每次让AI执行一个较大的任务前先commit，如果结果不满意，一条git checkout就能回到安全状态。

具体操作流程：

1. 在Godot创建项目时选择Git作为版本控制元数据
2. 使用TortoiseGit（小乌龟）或命令行初始化Git仓库
3. 在Gitee上创建私有远程仓库（避免GitHub的网络问题）
4. 配置远端地址并完成首次推送

选择Gitee而非GitHub是一个接地气的决策——对于国内开发者来说，网络稳定性是实实在在的痛点。

Cursor AI编程工具的配置选择

在AI编程工具的选择上，老李对比了几个方案：

工具	优势	劣势
Cursor Pro	生态成熟，模型自动分配	需要订阅费用
Claude Code	能力强大	官方模型较贵，有封号风险
MiniMax Agent	免费可用	功能相对有限

老李最终选择了Cursor Pro版本，使用自动模型分配模式，同时配置了MiniMax M2.7作为备选模型。他也提到，如果使用Claude Code，可以配置国产模型来降低成本。

Cursor本质上是Visual Studio Code的一个深度定制分支（fork），在保留VS Code完整编辑器功能的基础上，深度集成了AI能力。它的核心功能包括：Tab自动补全（根据上下文预测你接下来要写的代码）、Cmd+K内联编辑（选中一段代码后用自然语言描述修改意图）、以及Agent模式（通过对话让AI自主完成跨文件的复杂任务，包括创建文件、运行终端命令等）。Cursor Pro的「自动模型分配」是指系统会根据任务复杂度自动选择合适的底层模型——简单的补全任务可能使用轻量模型以提高响应速度，复杂的架构级任务则调用更强大的模型。这种策略在控制API成本的同时保证了使用体验。

一个实用的小技巧：安装Godot Tools这个VS Code扩展后，Cursor就能识别Godot项目结构，实现脚本间的跳转和方法调用追踪。这个扩展为Cursor提供了GDScript的语法高亮、自动补全、错误检查等功能，更重要的是它让AI在分析项目代码时能够理解Godot特有的节点引用关系和信号连接机制，从而生成更准确的代码。

第一个AI生成的Hello World

项目搭建完成后，老李让AI生成了一个Hello World来验证整个工作流。AI自动完成了以下工作：

1. 创建Main.gd脚本：继承自Control，在_ready()方法中打印Hello World
2. 创建Main.tscn场景：包含一个全屏Control根节点和一个Label子节点
3. 修改project.godot：将主场景设置为Main.tscn

这里老李顺便讲解了一个Godot的重要知识点：节点的_ready()调用顺序是从子节点到父节点。也就是说，子节点先准备好，父节点才会收到_ready()回调。这个看似简单的细节，在复杂项目中经常是Bug的来源。

要理解这个知识点，需要先了解Godot独特的节点-场景树（SceneTree）架构。与Unity采用的「GameObject + Component」扁平化组件模式不同，Godot的一切都是节点（Node），节点通过父子关系组成树形结构。每个节点都有明确的生命周期回调：_enter_tree()（进入场景树时）、_ready()（自身及所有子节点都准备好时）、_process()（每帧调用）、_exit_tree()（离开场景树时）。而**场景（Scene）**本质上就是一棵预配置好的节点子树，可以被实例化并挂载到主场景树的任意位置。这种设计带来了极高的复用性——一个「敌人」场景可以包含Sprite（显示）、CollisionShape（碰撞）、AI脚本等子节点，作为一个整体被反复实例化。_ready()的「子先父后」调用顺序保证了父节点在执行初始化逻辑时，可以安全地访问所有子节点的属性和方法，这是Godot场景组合模式的基石。

整个过程中，开发者完全没有手动编写代码，AI根据需求描述自动生成了所有文件。虽然只是一个Hello World，但它验证了从「自然语言描述需求」到「Godot项目可运行」的完整链路。

这个系列值得关注的几个看点

从第一期的内容来看，这个系列有几个值得持续关注的点：

1. 真实性：实况形式意味着我们能看到AI辅助编程的真实表现，包括它犯的错误和需要人工干预的地方
2. 教学性：老李承诺会对AI生成的代码进行Review，并讲解Godot基础知识，这对新手非常友好
3. 完整性：从项目初始化到最终上架Steam，如果能完整走完，将是一个极有价值的参考案例

对于独立游戏开发者来说，AI辅助编程到底能走多远？一个人加上AI，能不能做出一款可以上架的游戏？这个系列或许能给出一个真实的答案。

核心要点