AI+Godot 独立游戏开发全攻略：从想法到试玩链接

想用 AI 做独立游戏，第一句话先别写“帮我做一个开放世界”。

先写：“做一个小人，能往前走、能跳，掉下去会重来，走到旗子旁边就通关。”

这已经是一款小游戏的起点。它有操作、有失败、有目标，也能让别人从头玩到尾。

我建议第一次做游戏，就从这样的项目开始。AI 可以协助写方案、做素材、改代码，但你得替这个项目守住范围。今天加装备，明天加剧情，后天想做联机，最后很容易得到一堆半成品。

这篇就沿着一个森林跳跃小游戏，把从想法到分享试玩的步骤走清楚。目标很具体：做完一关，发出一个别人点开就能玩的链接。

AI + Godot 开发路线概览。

先选定工具，别在起步时来回换

这条路线用 Godot 做游戏，用 AI 辅助策划和开发，最后把网页版本放到 itch.io 分享。

Godot 是游戏引擎，负责组织画面、输入、碰撞、声音和游戏逻辑。它免费开源，采用 MIT 许可；发布作品时，按官方要求保留引擎相关的许可说明。AI 工具、素材和其他服务的费用另外计算。Godot 官方许可说明

第一次做二维网页游戏，建议选定 Godot 4、GDScript、Compatibility 渲染模式。GDScript 是 Godot 的脚本语言，本文按这条路线讲，不混用其他引擎代码。

记下你安装的准确版本，并把它放进每次给 AI 的项目说明。不要一会儿照旧教程，一会儿让 AI 按另一版接口改代码。

Godot 引擎示意。免费开源指引擎本身，不代表整个开发过程没有其他成本。

第一步：把想法压成一页纸

开始时不用长篇策划案。先确定六件事：玩家控制谁、能做什么、遇到什么阻碍、怎样获胜、怎样失败、这一版明确不做什么。

森林跳跃小游戏可以这样定：小狐狸向右走，越过三个坑，收集五枚金币，碰到终点旗子通关。掉出地图就回到起点。只做键盘操作、一张地图，不做背包、战斗、剧情和存档。

把这段需求发给 AI，再加一句：

请把这个想法整理成一页制作说明，列出操作、胜负条件、必需素材和开发顺序。不要增加新系统。第一版只需要完整玩完一关。

图里的世界观、角色、场景、界面和文档，是扩展方向，不是首作必须填满的清单。

先把一关做顺，比给十个还没出现的角色写背景更值得花时间。角色设定以后能补，第一关都走不完，后面的内容也无处安放。

游戏概念设计的完整方向。首作先落实核心操作和胜负条件，再逐步扩展。

第二步：先用方块，把这一关跑通

新建项目后，先别忙着生成美术。

用一个方块代表狐狸，用长条代表地面，用圆点代表金币。角色移动和碰撞出问题时，简单图形反而容易看出原因。

让 AI 分四次交付：先做左右移动，再做跳跃和落地，然后加金币，最后接上通关、失败和重新开始。每次只加一项，运行确认之后再往下走。

给 AI 的要求要带上工程信息。可以直接这样写，把版本号换成你自己的：

我使用 Godot〔准确版本〕，脚本用 GDScript，目标是二维网页游戏。现在只实现左右移动、跳跃和地面碰撞，使用占位图。请给出场景节点结构、脚本挂载位置、输入动作配置和检查步骤，不添加敌人或其他系统。

节点可以理解为组成场景的零件。角色、碰撞区域、镜头各有自己的位置和职责。AI 只给一段脚本，还不算交付完整；你要知道它挂在哪个节点上，需要哪些输入和场景配置。

出现报错时，把完整错误信息、相关脚本、节点结构和引擎版本一起给它。别只说“运行不了”，也别让它每次都重写整个项目。

做完这一阶段，要亲手确认：左右都能走，能跳上平台，落地不会穿透，掉出地图能重来，金币不会重复计分，通关后能重新开始。保存一份可运行版本，再继续加内容。

AI 协助制作的概念插画。图中代码使用 Python/Pygame，仅作协作示意，不能复制进 Godot；正文统一使用 GDScript。

第三步：现在就导出一次网页版本

很多人习惯等游戏全部做完再导出。我建议把这一步提前：占位图能玩的时候，就试一次浏览器运行。

原因很实际。编辑器里正常，不代表交给别人打开也正常。越早检查发布路径，越早知道后面该避开什么。

安装与编辑器版本匹配的导出模板，添加 Web 导出预设，把入口文件直接导出为 index.html。按当前 Godot 文档，Godot 4 网页导出使用 Compatibility 渲染；这篇的小项目采用 GDScript 和单线程方案。当前文档仍列有 Godot 4 C# 项目不能导出 Web 的限制，不要让 AI 换成 C# 后才发现路线走不通。Godot Web 导出文档

使用编辑器的 Web 测试功能，或者通过本地 Web 服务器打开导出目录，不要只双击 HTML 文件判断成败。

这一次只检查三件事：页面能加载、角色能操作、一局能结束。不必等正式图片和音效齐了再做。

早一点拿到可分享的版本，也能约束后续开发：新增功能都要继续通过这条发布路径。

第四步：让 AI 按素材清单出图

玩法跑通之后，再把方块换成狐狸、平台换成草地。

先列最小素材清单：一个主角、一套地面、金币、终点旗子、一张背景，以及收集、失败、通关三种短音效。首版先满足这些，没用到的角色和道具不要生成。

给 AI 出图时，写清用途和规格。比如：

生成一张用于二维横版游戏的狐狸待机素材。侧面视角，像素风，透明背景，单个角色完整居中，画布 64×64 像素。保持轮廓清楚，不带地面、文字和投影。以我提供的角色参考图为准。

这是一份制作要求，输出后仍要逐项检查。透明背景是否真的透明？导入后是否太大？连续动作里的角色有没有变形？不能把一张好看的概念图直接当成可用的动画素材。

整套素材统一视角、比例和像素颗粒。缩到游戏里的实际大小再看一遍，确保狐狸不会被背景淹没，金币一眼能找到。

音效同样需要实际试听。图上的波形只展示素材类别，并不是可以播放的声音文件。选择工具或素材库后，导出真实音频，接到游戏事件上再检查。

为下载或生成的资产记下来源、工具、获取日期和使用条款。打算公开发布前，把许可和署名要求核对清楚。

素材类型示意。先按一关的实际需求制作，不把整张素材清单变成开发任务。

第五步：先调手感，再加第二关

人物会跳，不等于玩家觉得好控制。

找一段平台反复试：起跳有没有迟钝，落地是否容易滑出去，按住跳跃会不会连续乱跳，失败后要等多久才能重来。

把这些问题描述给 AI，一次只改一个参数或机制。比如“角色松开方向键后滑得太远，缩短停下来的距离，其他行为不动”。改完再玩相同的一段，才能判断修改有没有帮助。

接着补反馈：吃到金币时数字变化，失败时有明确提示，通关时告诉玩家已经完成。声音和动画配合规则使用，不要把特效铺满整个屏幕。

我会优先处理“玩家明明按了，却不知道发生了什么”。这个问题没解决，再加几张地图也只是重复不顺手的体验。

如果你更喜欢图里的飞机射击，也可以用同样的做法：先做一架飞机、一种敌人、一种子弹和一轮结束条件。第一版不做图中完整的 Boss、僚机、道具和成长系统。

飞机射击画面概念示意，非实机截图。换题材时保留同样的小范围制作方法。

第六步：发到 itch.io，让别人完整玩一局

先在网页版本里完成一轮检查：能开始、能失败、能通关、能重来；画面不被裁切，声音有开关。首版只支持键盘，就在说明里明确写“电脑浏览器游玩”，别提前承诺手机支持。

然后再上传。itch.io 的 HTML5 游戏可以在浏览器里运行；多文件项目需要把入口 index.html 和全部运行资源打成一个 ZIP，文件名大小写与资源路径保持一致。itch.io 官方上传说明

实际操作按这个顺序：创建项目，游戏类型选 HTML；上传 Web 导出文件组成的 ZIP，设置该文件在浏览器中运行；配置显示尺寸或全屏方式，保存后先看预览。

打包的是导出的运行文件，别把整个 Godot 工程当成网页游戏上传。index.html 放在压缩包根目录，关联文件一起保留，不临时改名。

项目页先写明操作按键、游戏目标和当前支持的设备，配几张真正从游戏中截取的图片。图里“发布成功”的卡片只是效果示意，实际要以你的项目页和访问结果为准。

最后，在退出作者账号的浏览器里打开公开页面，再找一个人点开链接试玩。作者自己能打开，还不够证明玩家也能顺利进入。

实际项目请使用自己的游戏截图与说明。

第一批反馈，盯住卡住的地方

分享链接后，别只问“好不好玩”。先找三位愿意试玩的人，不解释操作，看他们能不能自行开始。

记录三件事：哪里不知道该做什么，哪里连续失败，结束后有没有主动再玩一次。

这些观察比一句“挺好的”更有用。玩家看不懂按键，就改开场说明；同一个坑反复失误，就检查跳跃距离和提示；通关后直接关掉页面，再问他还想不想挑战下一关。

一次集中改一个最明显的问题，保留旧版本，再请人试。不要每收到一句建议，就往项目里加一个系统。

对第一次做游戏，我更看重这件事：有人不靠你指导，点开链接，完整玩了一局。

做到这里，你就经历了需求取舍、代码实现、素材整合、调试和发布。下一款游戏该做大一点，还是把这一关打磨得更好，也有了实际依据。

今天开始，就先做那个能走、能跳、能到终点的小人。等别人真的玩完第一关，再决定第二关长什么样。