2026年实测零代码用AI做出精品游戏：AI游戏创作平台SOON全流程实操指南

这两年市面上已经出现一批“零代码游戏平台”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把对话请求变成可执行任务链。图4Skill 触发与执行状态步骤 4加载架构约束ECS / Scene / API在写逻辑前先对齐 ECS、场景生命周期和 API 约束。他的ECS文档API Reference其实是可以下载下来的。图5ECS 与架构文档加载阶段步骤 5原型设计玩法、UI、素材先产出 MVP 最小原型设计再推进实现等价于压缩版“策划案 技术预研”。图6子技能设计阶段可以通过他的输出日志分析得出项目通过 pnpm 安装核心包 agent-gamedev1.0.8 和 agent-gamedev-plugins1.0.1说明这是 Node TypeScript Vite 的 Web 游戏工程。显式依赖 pixi.js 8.15.0、esotericsoftware/spine-pixi-v8Spine 在 Pixi v8 上的运行时、pixi/ui和文章里「骨骼/Spine Web 渲染」是对得上的。步骤 6标准流程编排流程以阶段推进设计 → 资源 → 初始化 → 实现 → 验证。会按照步骤推进图7规范流程编排步骤 7代码与资源联动改写平台做的是增量改写而非每次全量重生。图8代码增量改写图9素材与代码联动阶段步骤 8系统化构建可见工程骨架常量、组件、系统、场景、入口加载。图10系统化构建阶段步骤 9调试修复有一套执行流程和规范会在实现后自我校验和修复类型错误、API 兼容、逻辑缺陷等。图11调试与修复阶段步骤 10查 API 并收敛模型遇到不确定 API 时会回查文档再改。最终完成游戏制作虽然初版的效果和预期差的很多不过确实是一遍就过可以试玩。图12API 检索与修正图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 Skill3.1.1 ECS 在工业项目里到底解决什么从业十年以上的视角里ECSEntity-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.动画编辑解决时间轴与事件——不仅是摆姿势还要有关键帧密度、循环点、攻击判定帧、脚步落地帧等。没有这一层战斗只能停留在“看起来在动”。这三层加在一起才接近传统 DCCMaya/Blender 引擎导入的工作量的一个子集但对游戏开发确实已经够用了。图20角色骨骼动画能力图21骨骼模板/类型图22骨骼编辑界面图23动画编辑能力3.3.3 AIGC功能也支持可以看到图25他本身描述描述也支持出图功能。对应图示图24角色素材与资源组织图25素材生成能力图26素材管理视图图27骨骼动画版本效果图28角色导出预览对应本地 json/atlas/png3.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的能力明显还差的多。图29Cursor 侧提示词输入图30Cursor 侧生成效果图31Cursor 侧视频解析图32Cursor 侧分析结果五、局限与建议目前AI游戏创作平台SOON虽然已经提供了很多功能全面覆盖游戏开发工作流支持AI自动生成角色动画、游戏特效、各类玩法地图、游戏UI界面、标题LOGO、游戏封面、游戏道具图标、技能图标、启动图标等全套美术资源突破传统内容生成局限实现包括游戏代码、数值系统在内的完整游戏项目一键生成大幅降低游戏开发门槛和成本但二测版本也有一定局限1.目前二测版本的算力获取途径有限估计后续会通过开放付费版本来拿到更多算力资源2.联机/服务端能力还不支持后续版本很快会有值得期待3.复杂玩法与长期版本演进仍需资深工程介入协助解决。4.目前平台的游戏框架仍然以2D和伪3D为主对AI开发游戏感兴趣的朋友可以前往SOON的PC端官网体验。有游戏开发经验的创作者还可参与官方创作者招募计划出示过往游戏作品有机会获得无限算力扶持。