这是【游戏开发那些事】第69篇原创

这两年市面上已经出现一批“零代码游戏平台”，AI 的加入进一步降低了上手门槛：从“会不会写代码”逐渐转向“能不能把需求讲清楚、把流程跑完整、把结果验出来”。

一个完全不懂编码的人，借助 如今的AI 游戏创作工具，能否把游戏“做出来”？

我的结论是：小游戏、休闲游戏及轻中度游戏的原型制作不仅可行，且效率极高。经过持续打磨，这些产品完全有潜力落地为商业游戏。当然，他的类型也受平台限制，和我们想象中的AAA大作还有很远的距离。

本文使用的是国产的AI游戏创作平台——极逸Soon。站在游戏开发从业者视角，通过实践与分析，尝试回答几个关于AI制作游戏的问题：

1）这类“零代码平台 + AI”到底替我们做了什么

2）哪些环节仍然是工程问题

3）它对团队真实的价值和影响的边界在哪里

4）我们能从这类AI平台的设计框架中学习到哪些？比如如何设计游戏的上下文工程，怎么约束AI的实现规范

一、先定义问题：“零代码”指什么

“AI做游戏”常被一句话讲完，但至少有三层：

本次测试主要覆盖前两层，少部分设计到第三层，因此本文重点讨论“原型设计与开发效率”，不把它当成工业化交付能力来评价。

从后面的讲解中，我们能看到AI Soon如何通过增加Skill和约束构建规范来快速生成可执行游戏，不仅对零代码开发者有着实践意义，也对各个游戏开发团队有一定的参考价值。

二、流程分析（总览）：从输入到构建的完整步骤

进⼊到主界⾯之后，就是⾮常简洁的对话框，⽀持上传视频或者通过描述直接⽣成游戏。首创的视频解析能⼒确实不错，我这⾥直接把热⾎⾜球的⼀段视频扔给了他，⼏乎没有加任何描述，看看他是怎样直接通过⼀个视频不间断的⽣成最终的游戏的。

下面把“流程分析”作为主线，按顺序列出。

步骤 1：进入工作台

平台先把需求放进统一工作台：对话区、素材区、代码目录、构建入口。

图1：工作台总览（项目状态、素材与代码入口）

步骤 2：多模态输入（视频）

视频输入后，平台先做图像解析，再进⼊⽣成流程，不是直接“照画⾯拷⻉逻辑”。（这⾥补充⼀下：首次截图⾥⾯的解析结果不是很理想，我在后⾯他们版本更新再试⼀次，发现效果好了很多，看来官方版本迭代很快

图2：视频输入生成入口

图3：视频解析结果（结构化描述）

步骤 3：调用 Skill 进入工作流

通过平台内置的 `game-builder` Skill把对话请求变成可执行任务链。

图4：Skill 触发与执行状态

步骤 4：加载架构约束（ECS / Scene / API）

在写逻辑前先对齐 ECS、场景生命周期和 API 约束。他的ECS文档，API Reference其实是可以下载下来的。

图5：ECS 与架构文档加载阶段

步骤 5：原型设计（玩法、UI、素材）

先产出 MVP （最小原型）设计，再推进实现，等价于压缩版“策划案 + 技术预研”。

图6：子技能设计阶段

可以通过他的输出日志，分析得出：项目通过 pnpm 安装核心包 agent-gamedev（1.0.8） 和 agent-gamedev-plugins（1.0.1），说明这是 Node + TypeScript + Vite 的 Web 游戏工程。显式依赖 pixi.js 8.15.0、@esotericsoftware/spine-pixi-v8（Spine 在 Pixi v8 上的运行时）、@pixi/ui，和文章里「骨骼/Spine + Web 渲染」是对得上的。

步骤 6：标准流程编排

流程以阶段推进：设计 → 资源 → 初始化 → 实现 → 验证。会按照步骤推进，

图7：规范流程编排

步骤 7：代码与资源联动改写

平台做的是增量改写，而非每次全量重生。

图8：代码增量改写

图9：素材与代码联动阶段

步骤 8：系统化构建

可见工程骨架：常量、组件、系统、场景、入口加载。

图10：系统化构建阶段

步骤 9：调试修复

有一套执行流程和规范，会在实现后自我校验和修复：类型错误、API 兼容、逻辑缺陷等。

图11：调试与修复阶段

步骤 10：查 API 并收敛

模型遇到不确定 API 时，会回查文档再改。最终完成游戏制作，虽然初版的效果和预期差的很多，不过确实是一遍就过，可以试玩。

图12：API 检索与修正

图13：阶段完成状态

图14：后续设计调整入口

三、看清流程后，重点能力展开：

有了上面的流程分析，我们接下来可以从架构、数据流、工业化差距等多个维度，进一部分析他的设计：这些链路以及流程为什么这样设计，它们各自解决什么问题、默认隐含了哪些工程假设、在什么规模上会撞到天花板。

先给出一个框架分析，本质上就是一个H5的web游戏，当然不能因为是H5就觉得太简单。页游也可以很复杂，复杂到一定程度就需要通过软件工程的思想去解决，

3.0 从流程反推：技术架构与「按规范推进」的Agent

把第二节的十步串起来，其实能读出他们在工程上刻意做的几件事：把生成空间收窄，让模型只在少数范式里改代码；把不确定性外置到文档，用 API Reference 当“可检索的真理源”；把迭代做成阶段闸门，失败就回到查文档与增量修补，而不是全量重生。

更具体一点：

• 视频并不是直接“拷贝像素变逻辑”：更合理的工程解释是，视频先被规整成结构化意图（对象、规则草案、交互密度、镜头与节奏线索），再进入后续 Skill。没有这一步，生成空间太大，模型几乎必发散。

• ECS / Scene / API 的显式加载是在给 agent 冻结世界模型与调用边界：哪些组件存在、系统如何更新、哪些 API 允许使用——这等价于给代码生成器一份施工图纸。当然，也是给用户的一个参考。

• 「查 API → 对照 Reference → 再改」这类收敛步骤，和通用 IDE 里“随便写”不同：它更像 RAG + 受限语法 的组合——模型被鼓励在标准库里检索、对齐签名，而不是发明不存在的接口。样本里若将 Claude 作为编排侧 agent（哪怕对用户半隐），其角色也更接近 读文档、拆任务、增量改仓库、失败回退，而不是一次性端到端黑箱。

• 多 agent如何编排？页面上往往只看到“阶段推进”，我感觉形态上接近 Agent Game Studio：规划→资源/初始化→实现（编码与素材联动）→构建调试→迭代；差别是这些分工常被封装成同一条流水线队列，而不是用户手动点名的多个 bot，这条agent的编排他们肯定是在持续迭代的。

「一个视频生成游戏」更可信的工程解释是：视频提供目标态的可视化约束，系统在预置模板与参数空间里检索与拼装，再走 ECS/数值/动画等默认链路落地——本质是强规范 + 强模板 + 约束合成，不是无边界即兴；因此能快，也更容易在复杂耦合处顶到平台边界。

3.1 ECS + Skill：

3.1.1 ECS 在工业项目里到底解决什么

从业十年以上的视角里，ECS（Entity-Component-System）是一组非常具体的工程约束：

• Entity（实体）：在多数实现里就是一个稳定 ID（或句柄）。它不“自带行为”，避免 `Player` 继承 `Character` 再继承 `Actor` 那种层级爆炸。

• Component（组件）：只放数据（位置、速度、血量、阵营、技能冷却剩余帧数）。理想形态接近 POD/结构化数据，便于序列化、对比、批处理。

• System（系统）：只写规则（移动积分、碰撞响应、AI 决策、技能结算）。它按“每帧/每固定步长”对一批实体做同类运算。

这套分工的直接好处是：逻辑与数据解耦、迭代时改系统不必动实体类型树、批量遍历对缓存更友好。对 AI 生成代码来说，还有一层隐性价值——模式固定、边界清晰，模型不容易写出“上帝类”。

3.1.2 本次样本里，Skill 流程和 ECS 是怎么咬合的

从流程截图与生成日志可以还原一条典型链路：先加载 ECS / Scene / API 约束（对齐世界如何更新、实体如何创建销毁），再按子技能把玩法拆成 输入 / AI / 物理或球体逻辑 等系统，最后在复杂度失控时 合并系统 以保证可运行。

这在工程上等价于：

1. 先冻结世界模型（有哪些 Component、生命周期钩子是什么）； 2. 再冻结系统拆分粒度（粗粒度更快出 Demo，细粒度更易维护）； 3. 用 Skill 把“设计—实现—验证”缩成可执行流水线。

• 单机回合/轻量实时：通常够用；

• 强同步联机、预测回滚、服务器权威：需要额外定义 哪些组件可复制、复制频率、权威源，默认 ECS 往往不够；

• 复杂技能图（多段、打断、标签、免疫）：往往需要 技能图/行为树 + 事件总线，纯 System 线性顺序会吃紧。

虽然省掉了“从零搭⼀致架构”的成本，但是省不掉“为你的玩法选择合适的计算模型与事务模型”。对于⼩⽩来说，随着项⽬复杂程度增⾼，他想理解项⽬的成本也会越⾼，后期如果AI改不好或者出现幻觉，那还是需要专业技术人员来支援。

3.2 数值框架：

目前我的Demo里面没有真整的使用他的数值框架，但是通过分析他的开源Git仓库以及介绍视频，大致能理解一些。

3.2.1 为什么数值是原型效率的杠杆

很多团队以为数值工作就是 Excel 里改几个格子。实际上工业化数值至少有三层：

1. 语义层：攻击、防御、穿甲、暴击、期望 DPS——这些不是浮点数，而是带约束的语义变量； 

2. 关系层：公式、曲线、分段、上限下限、舍入规则——决定平衡是否可解释、可回归； 

3. 工具链层：谁生成、谁审核、谁进包、谁能在运行时热调——决定迭代是否可追溯。

零代码平台若只提供“能改数字”，价值有限；若提供 元数据 → 运算 → 实例绑定 → 运行时观测 → 外部表格回流，它就把数值从“策划私货”拉进了工程化闭环。

3.2.2 TypeScript 数值引擎意味着什么

1. 逻辑与代码解耦
   用数据（例如 JSON）描述公式与关系，由运行时解析执行，策划侧更容易参与迭代，程序侧减少「为调参而改源码」的次数。

2. TypeScript 优先、偏工程化
   面向现代前端/全 TS 栈（含 Web、Node），强调类型与可维护性，适合做 RPG / SLG / 卡牌 等重数值品类，而不是只解决「算个表达式」。

3. 能力组合相对完整
   公开材料里提到：表达式解析与求值、数学/几何工具、事件/调用一类通信抽象，以及面向战斗/角色属性的示例与架构拆分——本质是可嵌入项目的数值子引擎，而不是又一个完整游戏引擎。

4. 体积与依赖
   宣称零依赖、压缩后体量较小（README 称小于约 50KB minified），对希望轻量嵌入现有工程（例如你文章里那种 Pixi + TS 的 Web 原型）比较友好。

5. 生态位：Runtime +（可选）Editor
   完整体验往往是：可视化编辑器里配表/连线 → 导出配置 → Runtime 加载执行。单独用 Runtime 也能做表达式与数学工具，但产品叙事上「配表 + 执行」更贴工业化协作。

对应图示（分层、表格互通、编辑器交互、调试过程、与工程关系）：

图15：数值引擎分层结构

图16：数值系统与表格互通

图17：数值编辑器交互

图18：数值调试过程

图19：数值框架与工程侧关系（git开源）

3.3 动画编辑与角色资源：骨骼管线为什么很重要

3.3.1 工业级角色管线在解决什么问题

行业内同学都清楚：角色不是 PNG，而是一条流水线：

• 网格/贴图（分辨率、压缩、alpha 边缘、色域一致性）；

• 骨骼绑定（权重、骨骼命名规范、是否支持换装/局部附件）；

• 动画数据（关键帧、曲线切线、事件帧、根运动 root motion）；

• 运行时状态机逻辑（idle/run/attack/hit 的切换、混合、打断规则）；

• 渲染与批次（图集打包、材质变体、draw call 预算，Web 上尤其敏感）。

所以评价这类平台，不能只看“能不能生成”，要看它是否覆盖 编辑—预览—导出—运行时消费 的闭环。

3.3.2 骨骼模板、骨骼编辑、动画编辑在做什么

结合平台的素材，可以把它理解成三层能力：

1. 骨骼类型 / 模板：在约束拓扑（几套通用骨架、兼容多少附件点）。模板越强，生成越稳；模板越死，风格与表演自由度越低。 

2. 骨骼编辑：解决 rig 修正——生成再强也会出肩肘膝权重问题；能否在工具里修，决定你是“可用资产”还是“废稿”。 

3. 动画编辑：解决 时间轴与事件——不仅是摆姿势，还要有关键帧密度、循环点、攻击判定帧、脚步落地帧等。没有这一层，战斗只能停留在“看起来在动”。

这三层加在一起，才勉强接近传统 DCC（Maya/Blender）+ 引擎导入的工作量的一个子集，但对小型游戏确实已经够用了。

图20：角色骨骼动画能力

图21：骨骼模板/类型

图22：骨骼编辑界面

图23：动画编辑能力

3.3.3  AIGC功能也支持

可以看到图25，他本身描述描述也支持出图功能。

对应图示：

图24：角色素材与资源组织

图25：素材生成能力

图26：素材管理视图

图27：骨骼动画版本效果

图28：角色导出预览（对应本地 json/atlas/png）

3.4 这些能力对开发者意味着什么?

把上面几条能力放回“成本”里看，会更直观：ECS 规范 + Skill 流程优化的是程序设计“架构试错与返工”；数值引擎 + 表格互通压缩的是程序与策划之间的往返；骨骼/动画/导出链路压缩的是“从图到可运行角色”的管线摩擦。三者叠加基本上覆盖最基础的“策划—程序—美术”，本质是把传统团队里分散在多个岗位、多个工具上的前置成本，收敛成平台的基本能力。

独立游戏开发者（或小团队）以往常见路径其实很“重”：先选引擎（Unity/Godot 等），自己搭目录与框架；美术侧要接 Spine/Aseprite/Blender 等工作流；数值往往落在 Excel/Google Sheet，再手写导入或半自动管线；遇到不熟悉领域（物理、寻路、UI 栈）还要额外学习。很多项目不是死在创意，而是死在脚手架与管线对接把迭代周期拖垮。

这类一体化平台的现实意义，是把一部分“你必须先成为准全栈才能推进”的工作，改成“你先验证玩法闭环，再决定要不要迁出到自研工程”。它的代价也在这里：省的是时间与协调成本，换的是自由度与上限——当你的需求超出默认范式（强联机、复杂技能图、重度性能优化、长期内容赛季化），你可能还得回到传统工程能力上补课。

自测可以很简单：要更快可玩原型与可展示资产，这类工具性价比高；要可持续迭代的工业交付，平台更适合当加速器而非终点站。

浏览了SOON官网的游戏社区，已有用户做出不少品质不错的游戏作品。不论是玩法深度还是美术风格，都不能算是小游戏的水平。

比如这款回合制的肉鸽卡牌对战游戏《旧日迷城》，玩法和画面都令人眼前一亮，在以往这种完成度，难以想象这是完全靠AI配合打造出来的游戏。

比如这款回合制的肉鸽卡牌对战游戏《旧日迷城》，玩法和画面都令人眼前一亮，如此高的完成度，实在难以想象这是完全靠AI打造出来的游戏。

四、与原生大模型的对比

我自己用Cursor同样传入了一个视频，中间需要按照FFmepg作为视频解析（还比较费Token的）。

结果发现在没有过多约束的框架下，他的能力明显还差的多

图29：Cursor 侧提示词输入

图30：Cursor 侧生成效果

图31：Cursor 侧视频解析

图32：Cursor 侧分析结果

五、局限与建议：

目前Soon平台虽然已经提供了很多功能，但是局限也很明显

1.目前二测算力获取途径有限，估计后续会通过开放付费版本来拿到更多算力资源

2.联机/服务端能力还不支持（据说未来会有，值得期待）

3.复杂玩法与长期版本演进仍需资深工程介入。

4.“零代码”不等于“零调试”，只是把调试门槛后移。

5.目前平台的游戏框架仍然以2D和伪3D为主

对AI开发游戏感兴趣的朋友，可以前往SOON的PC端官网体验。有游戏开发经验的创作者，还可参与官方创作者招募计划，出示过往游戏作品，有机会获得无限算力扶持。