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给出的结果是否正确。

Karpathy提出这一概念时，正值大语言模型的编程能力经历质的飞跃。2024年底到2025年初，Claude 3.5 Sonnet、GPT-4o等模型在SWE-bench（软件工程基准测试）上的表现已经能够解决相当比例的真实GitHub issue。Karpathy本人在社交媒体上描述自己的编程状态是「完全沉浸在氛围中，拥抱指数级增长，忘记代码的存在」。这种开发范式的转变不仅仅是效率工具的升级，更代表了软件开发角色的根本性重构：开发者从「代码的生产者」转变为「意图的表达者和质量的把关者」。

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

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

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

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

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

美术风格方面，初期采用极简多边形风格，后续可以考虑用AI生成素材替换。这种策略非常聪明——先跑通玩法，再打磨视觉，避免在早期陷入美术资源的泥潭。这也是独立游戏开发中常说的「Prototype First」原则：用最低保真度的视觉表现验证核心玩法是否有趣，确认方向正确后再投入美术资源。

为什么用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生成的代码更少出现「看起来对但运行时行为不符预期」的问题。

Godot引擎由阿根廷开发者Juan Linietsky和Ariel Manzur于2014年开源发布，采用MIT许可证，这意味着开发者可以完全免费使用且无需支付任何版税。2023年Unity宣布按安装量收费的Runtime Fee政策后，大量独立开发者和中小工作室转向Godot，使其GitHub星标数在短短数月内翻倍。Godot 4.0版本引入了全新的Vulkan渲染器、改进的GDScript 2.0语法、以及更强大的3D能力，标志着引擎从「轻量级2D工具」向「全能型游戏引擎」的转型。这一背景也解释了为什么越来越多的AI辅助开发项目选择Godot作为目标引擎。

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

工具链搭建：Git + Cursor + Godot

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

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

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

游戏项目与普通软件项目在版本控制上还有一个显著差异：游戏项目通常包含大量二进制资源文件（贴图、音频、3D模型等），这些文件无法被Git有效地差异化比较和压缩。业界常用的解决方案包括Git LFS（Large File Storage）来处理大文件，以及.gitignore配置来排除引擎生成的缓存文件。Godot在这方面的优势在于其.import目录下的缓存文件可以安全地排除在版本控制之外，引擎会在打开项目时自动重新生成这些文件，大幅减少了仓库体积。

具体操作流程：

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

这里提到的GDScript是Godot引擎的原生脚本语言，语法深受Python影响，采用缩进式代码块和动态类型（同时支持可选的静态类型注解）。它与引擎深度集成，提供了对节点系统、信号机制、场景树的原生支持。相比C#或C++，GDScript的学习曲线更平缓，代码量更少，且由于其语法简洁、结构清晰，对AI大模型来说也更容易生成和理解。Godot 4.0中的GDScript 2.0还引入了lambda表达式、await关键字等现代语言特性，进一步提升了开发效率。

这里老李顺便讲解了一个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，如果能完整走完，将是一个极有价值的参考案例

关于上架目标，将游戏上架Steam需要支付100美元的Steamworks注册费（每款游戏），之后需要完成商店页面搭建（包括游戏描述、截图、预告片、系统需求等）、构建上传、审核等流程。Steam对独立游戏开发者的分成比例为70/30（开发者/平台），销售额超过一定阈值后分成比例会提升。itch.io则是一个更加开放的平台，开发者可以自定义分成比例甚至免费发布，门槛更低，常被用作独立游戏的早期测试和社区建设渠道。从零到上架的完整流程记录，本身就具有极高的参考价值。

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

核心要点