用同一份需求比较四种 AI 游戏制作工具

选择游戏制作工具时，应看你能玩到什么游戏、能够进行什么修改，以及最终能保留什么项目，而不是只看截图。公平比较应从同一份小型需求开始，在评价外观前检查相同的玩家操作规则，同时记录手工操作、套餐限制和导出内容。本拟议测试涵盖原比较文章中提到的四种工具：SEELE AI、Rosebud AI、GDevelop 和 Buildbox。撰写本稿时没有受控运行或导出检查记录，因此结果和推荐仍无法确定：没有评分、实际观察到的能力差距或胜出者。下文定义需要运行和保留的材料，以便后续比较能够如实回答选择问题。

共同需求与控制条件

每次运行使用桌面浏览器、固定视口和相同输入设备。打开工具前，声明允许使用的套餐、支出上限、人工干预上限和停止条件。记录账号等级、日期、可见的工具版本和实际费用。如果一种工作流需要可视化编辑，不要假定提示次数相同就代表投入相同。

创建 Lantern Delivery，一个单屏、2D 俯视角浏览器游戏。使用原创邮差和简单的原创场景。通过 WASD 或方向键移动。一边躲避一个移动障碍，一边收集五个灯笼。显示收集数量和 45 秒计时器。接触障碍或超时结束本次尝试；集齐五个灯笼获胜。显示操作说明和重新开始按钮。全程保持同一邮差和美术方向。不要使用授权角色或下载的受版权保护美术素材。

把它视为规格，而不是已经生成的结果。测试时，从首次移动开始计时，在两种结局中都停止输入，重新开始时恢复全部状态。如果界面不能直接接受这份需求，应记录如何通过其原生工作流实现。不要悄悄给某个候选工具额外配置时间，也不要替换成更完整的模板。

需要完成的四份候选工具记录

SEELE AI：提示后核实交接内容

SEELE 介绍了使用自然语言创建游戏场景、素材和玩法代码的能力。本次比较要回答的是：该工作流能否生成符合规格的 Lantern Delivery 循环，并支持在同一项目中进行受控修改。通过可用的创建流程提交不变的需求，保留原始请求、回复历史、第一个可以访问的版本和账号条件。

不要从产品定位推断一定能访问源文件、兼容特定引擎或成功在本地启动。检查实际交付物并记录格式。如果在增加护盾前需要额外澄清或修复，应计数并保留这些操作。有用的后续推荐应把实际观察到的可玩性、修改成本和可复现性与读者需求联系起来。目前这些观察尚不存在，因此不能为该候选工具评分或指定优势。

Rosebud AI：记录实际创建与修改路径

使用受测 Rosebud AI 账号中可用的工作流执行共同需求。记录初始输入格式、必要配置，以及获得可访问版本所需的每一次干预。查阅当前官方文档了解套餐条件，但要区分文档中的说法和评估者实际观察到的结果。本稿未确认当前有哪些功能或导出格式。

基线能够游玩后，先保存，再提交完全相同的护盾请求。记录修改是否作用于现有项目，以及邮差、规则和地图是否保留。对于交接，应检查受测工作流实际提供的产物；不要把在线链接改称为“源代码”。某个账号无法访问一项功能，是该套餐下的观察结果，不代表产品从不提供这项能力。本文尚未运行 Rosebud 的生成、修改或导出。

GDevelop：明确记录编辑器中的工作

按测试者实际看到的当前 GDevelop 工作流评估，不要假定它与对话式生成器完全相同。记录实现需求所需的场景搭建、事件编辑、素材准备或模板选择。如果工作流提供辅助创建，应将输入和输出与人工操作一并保存。本文尚未验证这些当前选项及其套餐条件。

对于可视化编辑器用户，可编辑的事件结构可能是重要交付物，不应仅因为它不同于手写脚本目录就被忽视。反过来，只有编辑器项目也不能证明共享的浏览器版本能够运行。分别记录基线、受控的事件或项目修改、可玩性检查和实际导出内容。后续比较应展示该工作流的投入和结果，而不是根据“无代码”标签加分或扣分。目前没有可用的 GDevelop 测试结果。

Buildbox：区分项目编辑与发布产物

使用受测 Buildbox 账号的实际工作流实现 Lantern Delivery，记录必要配置和来自模板的行为。在描述发布或导出选项前，核实当前文档与账号条件。不要假定其他工具的提示界面、文件组织或本地运行说明也适用于它。保留第一个可以评估的项目版本，包括任何手工准备。

对于护盾修改，记录实现保护功能的可编辑逻辑或项目差异，并提供基线规则仍然成立的证据。准确标明最终交付物：它可能是编辑器项目、在线版本、编译产物或源文件，具体取决于实际提供的内容。如果某个目标或导出无法访问，说明受测套餐和实际观察到的限制，方便后续读者结合自身需求判断。目前尚未检查任何 Buildbox 版本、修改或交付物，因此没有依据作出能力结论。

执行相同的游玩、修改和交接检查

首先测试说明、两套移动操作、一次性收集、障碍接触、集齐五个灯笼后的胜利、超时，以及每种结局后的重新开始。重新加载后再重复。将每项标为通过、失败或未测试，并附上版本号。保留包括失败在内的不间断录屏。页面有响应或场景漂亮，不等于游戏循环已经完成检查。

然后应用一项受控修改：增加一个护盾拾取物，收集时拾取物消失，护盾恰好吸收一次障碍接触。显示保护是否生效。保持邮差美术、地图、操作、灯笼计数、计时器和重新开始规则不变；明确重新开始之前不会出现第二个护盾。测试拾取、第一次受保护接触、下一次未受保护接触、保护状态下超时，以及重新开始后的恢复。重新运行所有基线检查。保存原生版本差异，无论它是代码、事件还是其他可检查的项目产物。

最后，区分可玩链接、编译版本、可编辑项目和人类可读源代码。保存并检查实际提供的导出物，在干净目录中使用文档所述工具打开或运行，记录实际命令、版本、缺失素材和手工修复。下载成功本身不能证明项目可复现。将当前文档与观察记录放在一起，但不要用文档代替测试。

比较同类结果：第一个可访问结果与第一个可访问结果比较；修复后的结果与修复后的结果比较，并披露干预。初学者可能更重视易懂的迭代和可运行循环；开发者可能更重视可复现的源代码；编辑器用户可能更喜欢可检查的事件。只有在产物存在后才报告这些取舍。时间和点数数据需要预先记录开始与结束规则，不能看过结果后再估计。单次运行可以支持范围有限的案例比较，不能证明普遍可靠性。

证据清单：目前没有完成的结果项

• 每个候选工具的账号等级、测试日期、可见版本、浏览器、预算和实际干预历史。
• 原始需求、基线项目或版本，以及完整的验收检查录屏。
• 确切的护盾请求、修改前后版本、可检查的修改和回归观察记录。
• 实际导出或交付产物、干净环境中的配置记录及观察到的启动结果。
• 支持任何套餐或格式描述的当前官方文档。
• 只有完成这些检查后，才撰写各工具发现和有条件的推荐。

本文涉及的四个候选工具测试均尚未执行。这份清单是收集计划，不是结果表。目前没有经过测试的排名、最快工具、成本最低的成品或经验证的最佳导出工具可供报告。

结语：有证据之后再给出推荐

有用的比较不是哪个工具听起来功能最完整，而是哪个经过测试的工作流适合你希望继续开发的项目。保留共同需求，披露额外协助，并把可玩行为与可检查的交付物分开。本稿不能选出胜出者：四次受控运行、修改和导出仍然缺失。取得访问权限并在必要时获得预算授权后，可在 SEELE 使用共同的 Lantern Delivery 需求，再在其他候选工具中原样重复。保留失败和限制记录；只有这样，才能根据实际观察到的可玩性、编辑投入和项目访问方式缩小选择范围，而不是依赖假定的排名。

常见问题

有导出按钮就意味着能取得可编辑源代码吗？

不一定。导出物可能是编译版本，也可能是供特定编辑器使用的项目。下载并检查实际产物，再使用文档所述工具打开或运行。记录受测套餐和格式，避免把特定账号下的有限观察误当作产品的普遍能力。

官方文档能代替实际操作比较吗？

不能。文档可以支持对当前功能或套餐的描述，却不能证明这个具体游戏运行正确，也不能证明护盾修改后原有功能仍然正常。将文档与实际观察分开记录。未运行的情境应标为未测试，而不是从宣传案例或功能清单借用信心。

每个候选工具必须收到完全相同次数的提示吗？

使用相同的初始需求和修改规格，但应披露所有额外协助与手工操作。不同界面可能需要不同操作，因此仅靠提示次数无法公平衡量投入。提前设定干预与预算上限，并保留操作历史，不要在看到结果后调整规则。