允中 发自 凹非寺
量子位 | 公众号 QbitAI
给AI一句“生成一款坦克大战游戏”，代码很快跑了起来。
敌方坦克出现在屏幕上，炮管锁定玩家，战斗看似已经开始。但靠近敌人后，坦克没有发射炮弹，反而挥起炮管开始近身攻击。
第一眼看上去，这像是一次典型的AI抽风。继续玩下去却会发现，移动、碰撞、攻击和伤害判定都能正常工作。
它偏离了常见设计，却意外形成了一套可以成立的新玩法。
△坦克挥动炮管近身攻击
这也是AI生成游戏最容易被忽略的问题：代码能运行，只是第一步。真正困难的是让游戏成为一个能够持续交互的系统
代码能跑，游戏为什么还是不能玩？
过去一年，大模型已经生成了大量贪吃蛇、平台跳跃和射击游戏。
页面能打开、角色能移动，并不等于玩家能够完成一局游戏。
平台可能高于跳跃极限，敌人有动画却没有攻击判定，障碍物的刷新频率也可能叠成一条无法通过的“必死路”。
修改同样可能带来连锁反应。
用户只想把角色跳跃调高一点，系统却同时改变重力和其他物体的运动轨迹；代码勉强完成后，素材又可能缺失或风格不一致。
每个局部看起来都对，组合起来却不能玩，这就是AI游戏生成中的“可玩性黑洞”。
它比编译报错更难处理。代码报错通常能定位到具体文件和行数，但游戏“不好玩”可能同时涉及数值、地图、反馈和玩家操作。
只有把这些因素放回同一个运行过程里检查，系统才知道问题究竟出在哪里。
Spellcaster生成的不是一段孤立代码
Spellcaster的做法，是先把用户描述整理成游戏规则、角色能力、关卡目标、胜负条件、敌人行为和关键数值，再交给多个专用Agent协同处理。
- Rule Agent负责规则，Level Agent负责关卡，Asset Agent负责素材；
- Playability Agent和Simulation Agent检查关键路径是否可达、核心交互是否有效、游戏是否存在必死局；
- 发现问题后，Repair Agent再定位问题属于规则、数值、关卡、素材还是代码，并进行局部修复。
这套流程并不追求一次生成就结束，而是形成“生成—运行—检查—修复”的循环。
用户拿到结果后仍可以继续对话：调整角色速度、增加敌人、修改关卡，或者更换视觉风格。
系统根据修改意图处理对应部分，不必每次都从头生成。
从一句话到可玩原型
整个创作过程可以概括成四步：先把想法变成能够运行的游戏，再通过对话迭代玩法和数值，接着结合运行结果修复问题，最后完成素材匹配和视觉装配。
输入“生成一个星空背景的弹幕射击游戏”，大约15分钟后便能拿到可以试玩的原型。
目前，平台跳跃、塔防、跑酷、地牢肉鸽和弹幕射击等常见类型，都可以通过这套流程生成并继续修改。
△十二款游戏原型同屏展示
这套流程也改变了原型的使用方式。
独立开发者可以先验证一个玩法值不值得继续投入，内容创作者可以把互动故事或网络热梗变成可操作的版本，普通用户则不必先掌握编程和游戏引擎。
第一版不符合预期时，还可以继续要求系统调整规则、难度和画面，而不是从一份陌生代码重新开始。
回到文章开头那个例子，在只关注代码的流程里，它很容易被当成错误删除；在可玩性验证之后，它也可能被识别为一条逻辑自洽的玩法路径。
对游戏原型来说，价值有时不仅来自准确复现，也来自那些没有被提前设计、但确实可以玩的意外。
下一阶段：世界模型直接生成游戏画面
今天的Spellcaster，采用的仍是“AI生成代码和美术素材，再由游戏引擎运行”的实现路径。
AI改变了游戏的生产方式，但代码依然是连接创意与最终画面的中间层。
团队已经把下一阶段的方向指向世界模型：
玩家的移动、攻击和选择会与当前画面、角色状态、交互历史一起成为模型输入，由模型实时预测世界接下来会发生什么，并直接生成下一刻的画面与反馈，不再以传统代码和引擎渲染管线作为核心中间环节。
这意味着，AI游戏将从“自动生成一个可以运行的项目”，进一步走向“实时推演一个能够响应玩家的世界”。
支撑这次技术跨越的，是团队在智能体和世界模型方向的长期积累。
Spellcaster背后的DarwinMind（杭州达迩文智能），长期布局多智能体系统与世界模型方向，核心成员来自浙江大学、南京大学和澳大利亚国立大学。其联合创始人中多位是来自浙江大学的博士生导师，他们长期从事世界模型、多模态大模型和智能体系统研究。
内测申请：https://www.spellcaster.world/releaseplan
Don't Code. Just Cast.
*本文系量子位获授权刊载，观点仅为原作者所有。
热门跟贴