用 Agent 与 AI 开发 Steam 独立游戏：技术选型、素材流程与开发者申请

10月 7, 2026

AI 参与说明（Agent：Codex）：本文由 Codex 根据 Valve、Godot、Unity、Epic Games 与各工具维护者的一手资料辅助调研、撰写和校验，资料整理于 2026-10-07。项目类型与工具的匹配是本文的选型建议；授权条款按本文链接中的现行规则理解。运行记录：模型 gpt-6.1-sol，reasoning effort ultra，执行入口 Codex Desktop，提供方 openai，运行时 CLI 版本 0.162.0-alpha.2（不代表桌面 App 版本）。

关联阅读补充（2026-10-07，Agent：Codex）：加入 my_ai_town 的源码分析，说明 Godot、LLM 与居民生活及社交模拟的具体匹配。运行记录：模型 gpt-6.1-sol，reasoning effort ultra，执行入口 Codex Desktop，提供方 openai，运行时 CLI 版本 0.162.0-alpha.2（不代表桌面 App 版本）。

修订说明（Agent：Codex，2026-10-07）：将主线调整为 Cursor、Codex 等 Agent 承担实施、AI 提供素材与动效的开发方式；补充成为 Steam 开发者的条件、申请与发售流程，并核对当前 AI Content Survey。Godot 的文本场景与 CLI 通过 Context7 阅读官方文档；其余产品依据官方资料。运行记录：模型 gpt-6.1-sol，reasoning effort ultra，执行入口 Codex Desktop，提供方 openai，运行时 CLI 版本 0.162.0-alpha.2。

引擎对比补充（Agent：Codex，2026-10-07）：依据 Unity、Godot 官方文档与现行许可，补充两者的项目结构、Agent 工作流、素材生态、成本和同条件小样验收。通过 Context7 核对 Unity 编辑器自动化及 Godot C# 导出条件。运行记录：模型 gpt-6.1-sol，reasoning effort ultra，执行入口 Codex Desktop，提供方 openai，运行时 CLI 版本 0.162.0-alpha.2（不代表桌面 App 版本）。

如果开发方式是 人提出创意与目标体验，Agent 实现和验证游戏，AI 生成图像、音频与部分动画资源，选引擎时就应优先比较：Agent 能否修改项目、运行游戏、观察结果、修正问题，并稳定导出发行包。

对第一款范围可控的作品，本文建议优先验证这些组合：

• 规则、卡牌、解谜、放置等 2D 游戏：Phaser + TypeScript + Electron，或 Godot。
• 原生 2D、2.5D 与轻量 3D：Godot；需要 Unity 资源生态时，采用 Unity + Editor 自动化。
• 视觉小说与分支剧情：Ren’Py + AI 立绘、背景、配音。
• 以 3D 空间、灯光和角色表现为主要吸引力：Unity 或 Unreal Engine，同时建立编辑器操作和运行观测能力。

这里的排序是基于工具接口与工程流程的建议，并非不同 Agent 的开发成功率排名。成为 Steam 开发者可以以个人身份申请，无须先成立公司；发行还需要身份、银行与税务资料、每个产品的 Steam Direct 费用，以及商店页和游戏构建审核。Valve：Onboarding

先认识本文的术语

人、Agent 与生成式 AI 怎样协作

人工可以提出题材、玩法、风格参考与商业定位，也负责试玩和决定哪些方向值得继续。Agent 同样可以提出规则、关卡和视觉方案；人的作用是选择方向、给出清楚的约束，并判断实际体验。

Agents need executable feedback, not just editable source files. 能改文件只是起点；还要让 Agent 看见“这一轮修改在游戏里发生了什么”。

flowchart TB
    A["创意、风格参考与通过标准"] --> B["Agent 实现一段完整玩法"]
    B --> C["编译、运行与输入回放"]
    C --> D["状态断言、日志、截图与性能"]
    D --> E{"达到通过标准？"}
    E -- "否" --> B
    E -- "是" --> F["AI 素材生成与批量导入"]
    F --> G["真实试玩与体验反馈"]
    G --> H{"体验与发行包合格？"}
    H -- "否" --> B
    H -- "是" --> I["Steam 商店页、构建审核与发售"]

Cursor 官方 Browser 工具支持页面操作、截图以及控制台和网络观测，因此 Web 游戏容易接入可观察的迭代流程。Codex 的公开游戏开发案例也包含浏览器测试、状态观测和资源制作。应按实际环境提供终端、浏览器、引擎脚本或编辑器桥接，使 Agent 能观察并修复真实运行结果。Cursor：Browser · OpenAI：Building games with Astra

从 Agent 操作能力比较技术路线

下表关注“Agent 具体能操作什么”，类型建议不是引擎能力上限。

Phaser：容易把修改、运行与观察接起来

Phaser 使用 JavaScript / TypeScript，游戏先在浏览器运行，再通过 Electron 等方式交付桌面包。Agent 可以修改代码、启动游戏、操作输入、读控制台与截图；这对短周期迭代很有用。Phaser 文档 · Phaser：用 Electron 在 Steam 发布

但 Canvas 内的角色和卡牌不会自动成为可按名称选择的 DOM 按钮。建议提供只读调试状态，例如当前场景、回合、生命值、资源是否加载完成；再提供固定种子和可重复加载的测试场景。截图检查布局，状态断言检查结算，真实输入检查用户流程。

Playwright 的 Electron 支持仍标为 experimental，浏览器小样通过后，还要测试最终桌面包、原生模块和手柄。Playwright：Electron

Godot：Agent 可以同时维护代码、场景与资源

Godot 的 .tscn、.tres 支持文本表达，场景中的节点和资源引用可以由 Agent 维护，也可以通过引擎脚本创建。CLI 支持项目运行、导入、脚本执行与导出，因此无需把场景搭建全部留给人工拖拽。Godot：TSCN · Godot：CLI

例如已有 Godot 项目后，Agent 可以先导入，再启动；配置好 export preset 后再导出：

godot --headless --path ./my-game --import
godot --path ./my-game
godot --headless --path ./my-game --export-release "Windows Desktop" game.exe

前置条件是安装 Godot 编辑器、匹配的 export templates，并在项目中配置名为 Windows Desktop 的 preset。输出路径相对项目目录；未启用 PCK embedding 时，需一起交付 .pck。本文已核对命令，本次环境未安装 Godot，未实际导出。Godot：Exporting for Windows

Headless checks do not prove that the rendered game looks correct. 应另外运行有渲染的游戏并获取截图；资源 UID、导入结果与引用也须由引擎重新加载验证。

Unity 与 Unreal Engine：让 Agent 使用引擎 API

Unity 可以由 Agent 编写 Editor C# 脚本，批量创建 Scene、Prefab、配置导入、执行测试和构建。默认 Force Text 有助于审查变更，但复杂 GUID、fileID 与序列化数据应优先通过 Editor API 保存。Test Framework 提供 EditMode、PlayMode 和 Player 测试入口。Unity：Editor 设置 · Unity：CLI · Unity：Test Framework

Unreal Engine 也有 C++、Editor Python 和自动化测试路线。.uasset、.umap 是二进制 Asset，Blueprint 的修改应通过引擎工具或经过验证的桥接完成；普通源码编辑能力不能覆盖全部编辑器操作。Editor Python 主要用于编辑器自动化，不是打包后游戏的玩法脚本。Epic：Asset 格式 · Editor Python · Python Editor Tests

因此，这两条路线的关键投入是建立“创建资源 → 保存 → 重新加载 → 运行 → 收集证据”的自动化能力。MCP 可以作为工具调用协议，但安装一个引擎 MCP，并不能证明上述步骤、当前引擎版本和导出平台都已支持。

题材明确时，保留专用工具

Ren’Py 的脚本、界面与剧情分支适合 Agent 批量维护；CLI 能编译、lint、运行自动测试和打包。AI 立绘、背景、配音可按对白和角色清单接入。lint 与覆盖指定路径的测试有助于发现分支及资源错误，剧情节奏仍应试玩判断。Ren’Py：CLI · Automated Testing

GameMaker 的 .yyp 和 .yy 有文本资源格式，GML 与 Igor CLI 也能用于 Agent 工作流。不过 Igor 默认 RunTests 主要验证启动并在一段时间内不崩溃，应另外提供规则断言和回放。GameMaker：Project Format · CLI Build / Test

Unity 与 Godot：独立游戏应该怎样选

从零开始、范围较小、自制或 AI 素材占主导的原生 2D 游戏，可以先验证 Godot；已经有能直接复用的 Unity 项目、工具包或成熟 C# 工作流，优先验证 Unity。 3D 项目应进一步比较目标画面、角色动画、素材导入与目标设备，不能仅凭“2D 用 Godot、3D 用 Unity”决定。

两者都能让 Agent 修改代码、创建场景、导入资源、运行测试和导出游戏。下文的选择倾向是工程建议；具体能力和许可依据截至 2026-10-07 的官方资料。

能力相近，项目组织与生产路径不同

能力来源：Unity 2D · Godot 2D · Unity render pipeline · Godot renderer · Godot 核心概念 · Unity Asset Store

Godot 的 Scene 可以同时承担其他引擎中 Scene 与 Prefab 的部分职责，因此不能把两套项目结构逐词替换。同样，两者都能使用 C#，也不代表玩法脚本可以直接互换；引擎对象、生命周期和资源 API 仍然不同。

Godot C# projects require the .NET editor and the .NET SDK. In Godot 4.7, C# projects support desktop exports but cannot be exported to the Web platform. Godot C# basics · Godot C#/.NET

所以，“已经熟悉 C#”是比较 Unity 的理由，但并不排除 Godot C#。如果既要 Steam 桌面版，又想提供 Web 试玩版，语言与导出条件应在选型时一起验证；使用 GDScript 可以避免 Godot C# 这一项 Web 导出限制。

Agent 开发：比较完整改动的可靠性

对 Godot，可以让 Agent 修改 GDScript 和文本 Scene，重新导入资源，再启动游戏检查结果。这种流程便于审查小范围改动，但资源引用、导入配置与节点结构仍会出错；不能因为文件可读就跳过引擎验证。

对 Unity，可以让 Agent 编写 Editor C# 工具，使用 AssetDatabase、PrefabUtility、EditorSceneManager 等 API 修改和保存资源，再通过 batchmode 执行构建方法。Unity 的对象引用包含 GUID、fileID 等信息，建议让 Editor API 维护这些引用；在 Editor 外移动素材时，也要保留对应 .meta 文件。Unity Editor CLI · Unity 构建脚本 · Unity Asset metadata

真正需要比较的是：Agent 改完一个角色或界面后，能否保存、重新加载、运行、收集反馈并再次修改。 Godot 的文本资源与 Unity 的 Editor API 都能承载这个过程。没有实测时，不应把“Godot 一定更容易让 Agent 开发”或“Unity 只能靠鼠标操作”写成结论。

素材也应按具体需求判断。例如已经找到符合画风、可维护且兼容所选 render pipeline 的 Unity 角色控制器与动画资源，它们可能比重新制作更省时间；如果主要素材来自自己的二维图集，Godot 可作为较直接的起点。AI 生成的原始图片或模型，两边都还需要锚点、碰撞、材质和动画验证。

如果采用 Unity，应尽早确定 render pipeline，例如 URP / HDRP，再选匹配的素材与插件；Godot 也应尽早确定 renderer。切换会影响材质、灯光与效果，不能把它当成项目后期没有代价的选项。Unity 选择 render pipeline · Godot renderer

授权与后续平台：成本结构不同

Godot 的引擎采用 MIT，允许商业和闭源游戏，没有按游戏收入触发的引擎订阅门槛。随游戏分发引擎时，应保留相应版权与许可声明；插件、字体、音乐与其他素材另按各自许可处理。Godot License

Unity Personal 的资格按过去连续 12 个月的 Total Finances 不超过 200,000 美元 判断；超过时须升级到符合条件的许可层级。公司自研、个人自研、为客户提供服务的计算口径不同，不能只用当前游戏的 Steam 销售额判断资格。Unity Pro 按席位订阅，具体价格与期限应按当时计划确认。Unity Editor Software Terms：§1.1 · Unity Pro

Unity 6 and earlier versions do not carry a Runtime Fee under the current terms; applicable subscription and seat fees still apply. Unity Editor Software Terms：§2.2

如果以后计划进入封闭主机平台，还要把移植路径算进去：Unity 提供相应平台支持，但需要平台方批准和适用许可；Godot Foundation 不维护这些平台的官方移植，需要获批开发者自行移植或使用第三方服务。不能把 Godot 的免费许可等同于所有平台的移植都免费。Unity Console · Godot Console Support

Steam 接入与 Steam Deck 验收是另外的工作，两套引擎都应检查实际桌面包、手柄、存档和目标设备；引擎选择不能代替这些验收。

用同一个小样完成最终选择

如果两套方案仍难取舍，2D 项目可以按下面的方法比较。它是本文建议的选型实验，本文没有实际运行两套引擎的对照小样。

1. 固定输入：共用同一份地图、角色行走图集、音效和规则；保持目标设备、Agent 模型、工具权限与时间预算一致。首次安装与配置耗时单独记录。
2. 交付同一段体验：一个俯视角房间，包含移动、障碍碰撞、可交谈 NPC、可拾取物、暂停和保存恢复。场景组织按各引擎的惯用方式实现。
3. 完成一次真实改动：替换角色图集、修改 NPC 文本与一处碰撞区域，保存后重新加载。检查资源引用未丢失、角色尺寸与锚点正确，动画和交互仍符合预期。
4. 验收发行包：用真实输入完成拾取、交谈、保存退出与恢复；在未安装编辑器的目标环境启动桌面包，并检查日志、截图与关键状态。

目标为 3D 时，应改用同一套模型、绑定动画、材质与灯光需求的小样，验证实际画面与目标设备性能；不能用上述 2D 结果判断 3D 生产流程。

记录完成时间、人工介入、失败原因、资源重载问题与导出结果，再结合目标作品需要选择。已经有稳定 Unity 工程时，保留并完善它通常比重做更有价值；从零制作范围可控的 2D 游戏时，可先验证 Godot。AI 小镇的具体分工见my_ai_town 项目分析。

AI 图片、音频与动效如何成为游戏资源

生成资产后，还要整理、导入并在真实玩法中验证。下表的具体操作和通过标准属于本文建议。

图像 API 支持透明背景与编辑；Firefly 的 Style Reference 用于参考画风。这些能力能帮助批量生产，但不会自动保证每张图都具有统一的轮廓、比例和可读性。OpenAI：Image generation · Adobe：Style Reference

音效、对话与音乐都有可供 Agent 调用的官方 API。ElevenLabs 的音效 loop=true 只适用于文档指定的 v2 模型；输出后仍应连续播放检查循环接缝。Suno 也可以用于选择配乐，但此次核验的是官方网页生成、下载与订阅使用权，不把第三方所谓 “Suno API” 当作官方开发接口。Sound Effects API · Text to Dialogue · Music API · Suno 使用说明

动画与动态画面有不同实现方法

游戏中的动效可以大量由 Agent 写代码实现。 悬停、卡牌移动、弹簧运动、程序化水面、粒子、受击反馈与镜头动画，往往需要响应玩家操作和状态变化。生成式 AI 可以提供贴图与造型，Agent 再实现运行时控制。

角色动作则需要可用的帧序列或骨骼、蒙皮和动画数据。Aseprite CLI 可把整理好的帧导出为图集及 JSON；Meshy 提供模型、绑定与动画接口，但自动 Rigging 主要面向结构清晰的标准双足 humanoid，不能泛化到所有角色。Aseprite CLI · Meshy：Image-to-3D · Rigging · Animation

AI 视频适合过场、动态背景和宣传片。一段视频不会自动变成带碰撞、可中断动作与状态切换的角色资源；即使切帧，也要检查角色一致性、循环和判定时序。

用资产清单组织批量生产

下面是本文建议的 JSON 清单结构，字段是工程约定，不是某个供应商的 API 参数。文件可以由 Agent 维护；人工先批准参考图和少量样本，再批量制作。

{
  "id": "player-idle",
  "kind": "sprite-sheet",
  "reference": "art/player-reference.png",
  "style": "limited palette, clear silhouette",
  "frameSize": [64, 64],
  "pivot": [32, 60],
  "source": "art/player-idle.aseprite",
  "target": "assets/player-idle.png",
  "licenseRecord": "asset-license-record.json",
  "status": "needs-in-game-review"
}

清单还可记录模型、生成参数、时长、版本和失败原因，使 Agent 能重试单个资产、替换占位图、重新打包并追踪来源。API key 放在环境配置，不写入清单或游戏发行包。

收费游戏应核对所用计划与素材许可。比如 ElevenLabs 免费层不默认提供商业使用许可，音乐另有专门条款；Meshy 免费资产的 CC BY 4.0 有署名要求，付费计划另有使用规则。商业使用权也不等于独占性或版权保护保证。ElevenLabs 使用说明 · Music Terms · Meshy 许可说明

一个已公开的 Agent 游戏开发案例

OpenAI 的 Building games with Astra 描述了在 Codex 中开发游戏的过程：人给出体验方向和视觉参考，Agent 实现浏览器游戏、程序化地形、水面与着色器，并制作可编辑的 Blender 资源、优化运行时模型。由此可以看到，Agent 的工作范围能够延伸到美术技术流程和性能调优。官方案例

案例中还建立了游戏状态观测接口和可重复的测试场景。截图用于看画面，状态用于检查是否真正完成着陆、移动、登船和存档恢复；真人试玩继续提供反馈。这支持的是一种具体工作方法，并非 Steam 商业成品验证或跨引擎自动完成率。浏览器中的性能测量也不能代替目标设备实测。

第一款作品怎样推进到可发售版本

下面是一套 Agent 主导实施的工作方法，属于本文建议；每一步应留下可运行产物。

1. 定义一个完整循环。 例如“挑选卡牌 → 结算 → 胜负 → 奖励 → 下一局”。先明确输入、结果和重开行为，限制到一套玩法和少量内容。
2. 让 Agent 做带观测的原型。 使用占位素材，建立规则模块、固定测试状态、错误日志与截图入口。先验证循环能完成，再投入大量生成资源。
3. 比较一到两条技术路线。 用相同规则完成一次“改动 → 运行 → 回放 → 检查 → 导出”；记录实际阻力，而不是比较宣传演示。
4. 制作 Vertical Slice。 选一个场景和少量角色，接入最终风格的图片、音频和动效。人工完整试玩，Agent 按具体反馈修订。
5. 扩展内容并持续导出。 将关卡、卡牌、对白等放入数据表；每轮检查存档、升级兼容、分辨率、输入和性能。
6. 完成发行包与 Steam 验证。 在没有编辑器的机器上运行；通过 Steam 安装后检查启动、重开、退出、存档及选用的平台功能。

可以给 Agent 这样的首轮任务：

制作一段可在桌面发布的单人卡牌玩法，先使用占位素材。
第一轮只有三张卡、一种敌人、胜负与重开，不接入运行时 AI。

交付：
- 可执行项目、启动与导出命令；
- 规则数据和可重复的测试场景；
- 当前回合、生命值、胜负和存档状态的观测方式；
- 自动检查结果、实际操作截图、已知问题。

通过标准：
- 按真实输入完成一局，胜负与规则表一致；
- 结束后不会重复结算，重开后恢复初始状态；
- 保存并退出后可恢复；
- 修改一张卡的费用后，测试和界面都反映新规则。

Agent 可分工处理规则、素材、编辑器工具与测试，但共享同一份规则和资产清单；场景或资源文件的修改应避免互相覆盖。验收重点是本轮实际游戏行为。一次构建成功不能替代完整输入流程。

一个可执行的规则检查示例

以下最小 JavaScript 示例把规则与渲染分开：双方初始生命值为 3 和 2；玩家每次攻击造成 1 点伤害；敌人存活才反击 1 点；胜利后不能再次结算。测试中的预期状态由这些规则确定。

保存为 battle-check.mjs，用 Node.js 运行，无第三方依赖。此例用于演示 Agent 的规则反馈入口，不是完整游戏。

import assert from "node:assert/strict";

const start = () => ({ player: 3, enemy: 2, phase: "playing" });

function attack(state) {
  if (state.phase !== "playing") return state;
  const enemy = Math.max(0, state.enemy - 1);
  if (enemy === 0) return { ...state, enemy, phase: "won" };
  const player = Math.max(0, state.player - 1);
  return { player, enemy, phase: player === 0 ? "lost" : "playing" };
}

const initial = start();
const turn1 = attack(initial);
assert.deepEqual(turn1, { player: 2, enemy: 1, phase: "playing" });
assert.deepEqual(initial, { player: 3, enemy: 2, phase: "playing" });

const turn2 = attack(turn1);
assert.deepEqual(turn2, { player: 2, enemy: 0, phase: "won" });
assert.deepEqual(attack(turn2), turn2);
assert.deepEqual(start(), initial);
assert.deepEqual(
  attack({ player: 1, enemy: 2, phase: "playing" }),
  { player: 0, enemy: 1, phase: "lost" }
);

console.log("PASS: turns, victory, defeat, no duplicate settlement, restart");

node battle-check.mjs

本次已在 Node.js 24 运行并得到上述 PASS 输出。接入引擎后，还应通过真实输入确认 UI、动画、声音和存档使用的是同一套规则。更完整的验收方法见 Agent 主导开发的测试概念。

开发时使用 AI 与游戏运行时使用 AI

第一款游戏可以先在开发时生成素材，再把固定结果打包交付。 这时生成成本集中在制作阶段，游戏不必在每次游玩时请求模型。Agent 编写的粒子、地形、动画和规则也可以本地运行。

如果玩法本身依赖实时 NPC 对话、生成图像或语音，再单独设计运行时服务：响应等待、成本上限、缓存、离线行为和存档一致性都成为游戏的一部分。按 Steam 对 Live-Generated 的定义，本地与云端生成都应根据实际内容填写问卷。

这不是“AI 代码一律豁免”的断言，应按当前 Content Survey 和实际交付内容判断。Valve 仍检查内容权利与游戏是否符合营销材料。外部实时 AI 服务应由开发者管理玩家访问；向玩家收费采用 Steam 支持的支付方式，也可把服务成本计入游戏售价。Valve：Content Survey

如何成为 Steam 开发者

需要准备哪些条件

You can onboard to Steamworks as an individual. 个人可以申请；签约主体应拥有游戏或有权发行游戏。Valve：Onboarding

法定姓名要求见 Valve FAQ，银行与税务步骤见 Onboarding。不把某一张税表或某个税率写成所有开发者的统一要求；具体按实际问卷填写。Valve 也按适用制裁与贸易管制规则判断是否可与主体开展交易。Valve FAQ

Steam Direct Fee 不能退款；产品的 Steam Store 或应用内购买收入达到 1,000 USD Adjusted Gross Revenue 后，可在符合条件的后续付款中收回。它是每个产品的发行费用，与引擎授权、AI 生成费用和平台销售收入分配分别计算，可能另有当地消费税。Valve：Steam Direct Fee

从申请到发售的步骤

1. 进入 Steam Direct，完成签约、缴费及身份、银行、税务验证。
2. 在 Steamworks 建立产品，准备商店页、价格、商店素材和 Content Survey。
3. 上传可运行 build，配置启动项与支持的平台，完成 store presence 和 build 两套 checklist。
4. 通过 Mark as ready for review 提交审核；商店页先提交，之后才能提交 build，两者都需通过。
5. 发布公开的 Coming Soon 页面，满足等待与展示条件，完成最终发行包验证。
6. 条件满足后，由有权限的账户点击 Release App 发售；审核通过不会自动发布。

具体顺序及权限以 Valve：Release Process 为准。审查专页通常给出 3–5 个工作日，建议至少预留 7 个工作日提交并留出返修时间，这不是保证完成日期。Valve：Review Process

截至 2026-10-07，新开发者首批产品的等待期在官方页面中存在不一致：Onboarding 写付费后 21 天，Steam Direct 入口仍写 30 天。 实际应核对 Steamworks checklist 的发布资格，必要时向 Steam Support 确认；本文建议排期保守预留 30 天。两页都要求公开 Coming Soon 至少两周，不能把审批完成日直接当作发售日。Onboarding · Steam Direct

身份和付款验证应由实际签约人完成。Agent 可以准备资料清单、商店文案、资产检查和构建配置；它不能代替提供真实身份和税务事实。

需要先接 Steamworks SDK 吗

Steam does not require Steamworks API integration to release a game. 可以先做能发行的桌面游戏，再按需要加入成就、排行榜、好友邀请等功能。Valve：Steamworks API Overview

这些入口的维护者、版本和目标平台不同，Agent 应做真实桌面与 Steam 运行验证。GodotSteam · Valve 接入说明 · Epic：Online Subsystem Steam · Ren’Py：Steam Support · Steamworks.js

单机存档可先在本地完成，再配置 Steam Auto-Cloud；它可以按文件路径同步而不调用 Steam Cloud API。若支持 Steam Deck，应另外检查手柄全流程、文字可读性和目标性能；Windows 导出并不自动保证 Proton 兼容。Valve：Steam Cloud · Steam Deck Compatibility

怎样做出第一轮选择

如果题材还没有定，先选一个 Agent 能完整实现并验证的短玩法：Phaser 路线便于使用浏览器工具，Godot 便于维护文本场景和原生项目。题材已确定为视觉小说，就先验证 Ren’Py；需要 Unity / Unreal Engine 的 3D 表现和资源能力，就同时搭好编辑器自动化。

比较时保持同一份规则和通过标准，要求每条路线完成一次真实改动、试玩反馈修复和发行包导出。引擎许可、AI 工具与素材计划另行按当前条款核对；例如 Godot 的 MIT 允许商用，但第三方组件与素材仍有各自许可。Godot License

可以让 Agent 承担越来越多实现工作。决定项目能否继续的依据，应是可玩的循环、可追踪的资源和可重复验证的版本，以及人对玩法与成品的判断。

相关案例：AI 小镇的引擎与玩法匹配

my_ai_town 项目分析：Godot 与 AI 社会模拟是否匹配以公开源码为依据，检查 Godot 的 2D 场景、权威世界规则与 LLM 居民决策如何分工，并讨论什么时候保留引擎、什么时候调整模拟或部署方案。