这两年市面上已经出现一批“零代码游戏平台”，AI 的加入进一步降低了上手门槛：从“会不会写代码”逐渐转向“能不能把需求讲清楚、把流程跑完整、把结果验出来”。
一个完全不懂编码的人，借助 如今的AI 游戏创作工具，能否把游戏“做出来”？
我的结论是：用AI游戏创作平台SOON制作小游戏、休闲游戏及轻中度游戏的原型制作不仅可行，且效率极高。经过持续打磨，这些产品完全有潜力落地为商业游戏。当然，SOON平台为游戏创作者提供了强大的赋能，工具负责控制游戏资产生成的下限，而最终游戏作品整体的上限，则取决于创作者自身的创意深度与对工具的驾驭能力。
本文使用的是国产的极逸AI游戏创作平台SOON。站在游戏开发从业者视角，通过实践与分析，尝试回答几个关于AI制作游戏的问题：
1）这类“零代码平台 + AI”到底替我们做了什么
2）哪些环节仍然是工程问题
3）它对团队真实的价值和影响的边界在哪里
4）我们能从这类AI平台的设计框架中学习到哪些？比如如何设计游戏的上下文工程，怎么约束AI的实现规范
AI游戏创作平台SOON操作界面
一、先定义问题：“零代码”指什么
“AI做游戏”常被一句话讲完，但至少有三层：
1.交互层：手写大量基础代码，设计工程规范和技术原型
2.生成层：从零搭骨架
3.产品层处理上线全链路流程
本次测试主要覆盖前两层，少部分设计到第三层，因此本文重点讨论“原型设计与开发效率”，不把它当成工业化交付能力来评价。
从后面的讲解中，我们能看到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 数值引擎意味着什么
逻辑与代码解耦：用数据（例如 JSON）描述公式与关系，由运行时解析执行，策划侧更容易参与迭代，程序侧减少「为调参而改源码」的次数。
TypeScript 优先、偏工程化：面向现代前端/全 TS 栈（含 Web、Node），强调类型与可维护性，适合做 RPG / SLG / 卡牌 等重数值品类，而不是只解决「算个表达式」。
能力组合相对完整：公开材料里提到表达式解析与求值、数学/几何工具、事件/调用一类通信抽象，以及面向战斗/角色属性的示例与架构拆分——本质是可嵌入项目的数值子引擎，而不是又一个完整游戏引擎。
体积与依赖：宣称零依赖、压缩后体量较小（README 称小于约 50KB minified），对希望轻量嵌入现有工程（例如你文章里那种 Pixi + TS 的 Web 原型）比较友好。
生态位：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 上尤其敏感）。
所以评价这类平台，不能只看“能不能生成”，要看它是否覆盖编辑—预览—导出—运行时消费的闭环。
AI游戏创作平台SOON一键生成游戏角色
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 栈）还要额外学习。很多项目不是死在创意，而是死在脚手架与管线对接把迭代周期拖垮。
AI游戏创作平台SOON这类一体化平台的现实意义，是把一部分“你必须先成为准全栈才能推进”的工作，改成“你先验证玩法闭环，再决定要不要迁出到自研工程”。它的代价也在这里：省的是时间与协调成本，换的是自由度与上限——当你的需求超出默认范式（强联机、复杂技能图、重度性能优化、长期内容赛季化），你可能还得回到传统工程能力上补课。
自测可以很简单：要更快可玩原型与可展示资产，这类工具性价比高；要可持续迭代的工业交付，平台更适合当加速器，创作者在平台的AI赋能下，实现更快打造可商业化的精品游戏。
浏览了SOON官网的游戏社区，已有用户做出不少品质不错的游戏作品。不论是玩法深度还是美术风格，都已经是能媲美商业级游戏的水准。
AI游戏创作平台SOON优秀游戏作品
比如这款回合制的肉鸽卡牌对战游戏《旧日迷城》，玩法和画面都令人眼前一亮，在以往这种完成度，难以想象这是完全靠AI配合打造出来的游戏。
AI游戏创作平台SOON优秀游戏AP4级作品《旧日迷城》
四、与原生大模型的对比
我自己用Cursor同样传入了一个视频，中间需要按照FFmepg作为视频解析（还比较费Token的）。
结果发现在没有过多约束的框架下，Cursor的能力明显还差的多。
图29：Cursor 侧提示词输入
图30：Cursor 侧生成效果
图31：Cursor 侧视频解析
图32：Cursor 侧分析结果
五、局限与建议：
目前AI游戏创作平台SOON虽然已经提供了很多功能，全面覆盖游戏开发工作流，支持AI自动生成角色动画、游戏特效、各类玩法地图、游戏UI界面、标题LOGO、游戏封面、游戏道具图标、技能图标、启动图标等全套美术资源，突破传统内容生成局限，实现包括游戏代码、数值系统在内的完整游戏项目一键生成，大幅降低游戏开发门槛和成本，但二测版本也有一定局限：
1.目前二测版本的算力获取途径有限，估计后续会通过开放付费版本来拿到更多算力资源
2.联机/服务端能力还不支持（后续版本很快会有，值得期待）
3.复杂玩法与长期版本演进仍需资深工程介入协助解决。
4.目前平台的游戏框架仍然以2D和伪3D为主
对AI开发游戏感兴趣的朋友，可以前往SOON的PC端官网体验。有游戏开发经验的创作者，还可参与官方创作者招募计划，出示过往游戏作品，有机会获得无限算力扶持。
