[控场AI]
· 9 分钟阅读· 4,501 字

8个AI组队做游戏:VibeGame如何啃下AI编程最难的骨头

8个AI组队做游戏:VibeGame如何啃下AI编程最难的骨头

南大与南洋理工开源VibeGame,用8个AI角色对抗协作将一句话变成可玩2D游戏。

VibeGame(论文称 Prompt-to-Game)是南京大学与南洋理工大学联合开源的系统,能将一句自然语言描述转化为完整可玩、可继续修改的2D网页游戏。其核心设计分三层:以Phaser为基础的AI原生引擎将实时游戏改造为可暂停、单步推进、语义注入的同步验证环境;8个AI角色分工协作并严格对抗——生产者不给自己批卷子,能检测出2帧级的时序bug;验收通过的游戏被蒸馏为骨架、模块、契约三件套,无需重训模型即可积累跨项目经验。系统支持纯文本或图文混合输入,具备IP转移、类型转移、规则转移三层编辑能力,但目前仅限2D网页游戏,缺乏定量评测,生产落地门槛仍高。

输入一句自然语言——“做一个只狼风格的弹反boss战,要有架势条,要有处决”,几十分钟后,一个能在浏览器里直接玩的2D网页游戏就摆在面前:弹反有真实判定窗口,架势条满了能触发处决,boss的重攻击带明显起手前摇。这不是概念演示视频,而是南京大学与南洋理工大学团队开源的系统 What Game?(论文中称之为 Prompt-to-Game 开发)。

它的输入是自然语言加一张可选参考图,输出是一个完整、可继续修改的2D游戏项目。团队把这套方法叫做对抗式开发:8个AI角色分工协作、互相挑刺,直到游戏通过验收才交付。这篇文章拆解它的三层设计,也顺带说清一个问题——为什么游戏是AI编程里最难啃的骨头之一。

为什么游戏对AI来说格外难

论文开篇有一句话很直接:在所有软件里,游戏大概是要求最高的一种。它要实时撑起一个交互世界,视觉要统一、规则要平衡、手感还要跟手。现有的两条AI路线都够不着这个目标。

世界模型路线(如 Genie 类系统)能从视频里学出可交互体验,但产出是神经网络里的隐式表示——没有源码、没有项目结构。你想把跳跃调低一点,它没有任何可以精确修改的抓手。另一条路线是把大模型接到虚幻这样的商业引擎上,可引擎是给人设计的,项目状态散落在图形界面和二进制资产里,智能体根本摸不到全貌。

更麻烦的是验证。一个游戏结构上完全合法,跑起来照样可能崩,因为玩家输入、物理、动画和游戏逻辑在毫秒级时间里相互作用。游戏是实时系统,而智能体的思考速度比它慢好几个数量级——等你看完日志,角色已经摔死8回了。

等你看完日志

还有一件被普遍忽视的事:现有系统都把“第一个能玩的版本”当终点,而真实开发里,交付才是开始。用户会要求加机制、改视觉、调平衡。VibeGame 针对这三个难题各配了一套解法。

第一层:一个AI原生的游戏引擎

底子选了 Phaser,一个 JavaScript 的2D网页游戏框架,项目天然全是文本文件。但团队没有停在“把智能体接上现成引擎”,而是在 Phaser 之上定义了AI原生引擎的三个性质。

不依赖图形界面:项目组织成场景、节点、资产三层结构,全部是类型化的JSON文本。模式校验会在运行前就抓住无效引用——比如用了一张不存在的图,错误提前暴露,不会拖到游戏跑起来才炸。

运行时可访问:这是最妙的一笔。引擎暴露了一个针对同步的程序接口,智能体可以暂停游戏、单步推进、快进50帧,可以读写节点的位置和速度,可以注入“按跳跃”这样的语义动作,还能随时截图。一句话,它把一个异步的实时系统变成了可以同步验证的过程——相当于给智能体一台带暂停键的游戏机,节奏由它定。

源码可见:引擎的完整源码在项目初始化时拷进目录。文档说不清的时候,智能体直接翻源码看实现。文档会过时,源码不会。对人这边,项目配了网页工作台,四个视图分别用来聊天、调素材、配对象、直接开玩。

Phaser 是一个基于 HTML5 Canvas/WebGL 的开源2D游戏框架,以 JavaScript 编写,生态成熟,社区积累了大量插件与示例。选择它而非 Unity 或 Godot 的核心原因在于"全文本项目结构":Unity 项目中存在大量二进制的 .meta 文件和场景序列化格式,Godot 虽然更接近文本,但依然有图形编辑器高度依赖的节点配置。Phaser 项目本质上只需要 HTML、JavaScript 和 JSON,整个项目可以被语言模型直接读写,无需任何中间转换层。这一特性在 AI 辅助开发中至关重要——当模型需要理解"当前游戏状态"时,它可以直接扫描目录中的所有文件,而不必依赖截图或日志的二手信息。

第二层:一支会互相拆台的团队

八个角色分工明确:指挥官协调全局,设计师把想法展开成游戏设计文档,美术用生图模型产出概念图和资产,架构师规划,程序员写码,审计员做静态检查,试玩员实机测试,评审员最终把关。

流程分三段:意图对齐阶段,指挥官先追问澄清,设计师和美术并行产出设计文档和概念图交用户确认,确认过的文档成为所有后续开发和评估的基准;并行开发阶段,美术、设计、代码三条工作流同时推进,复杂任务再拆成架构师规划、程序员实现、审计员静态把关、试玩员实机验证的四角色流水线;对抗修正阶段,评审员从功能、视觉、可玩性三个维度审查完整项目,任何一条不过就转成修复任务打回,循环到通过为止。

并行开发阶段

关键设计在于:干活的和挑刺的分成两波。审计、试玩、评审不生产任何代码,专职找茬——逻辑很简单,学生不能给自己批卷子。官网工作台里有个真实案例:审计员发现 boss 的地面砸击技能,伤害判定比警告动画的结束早了两帧,玩家看到落地提示时以为在闪避,其实已经挨打。问题打回,程序员修完复审,最后试玩员跑了12个场景全过才交付。两帧的时序bug,人眼几乎不可能发现。

模型分工也有讲究:默认配置里指挥官、美术、架构师用最贵的旗舰模型,设计师和程序员用中档,审计用轻量,试玩和终审用另一家厂商的模型——贵模型当大脑和裁判,便宜模型跑流水线,两家厂商混编。报告还诚实地记了一笔:试过 GLM 和 MiniMax,但因为缺视觉能力,要看画面的岗位顶不住。

多智能体系统(Multi-Agent System)中的"角色分离"并非 VibeGame 的首创,但在游戏生成领域的落地方式较为独特。常见的单体大模型对话流中,同一个模型既负责生成代码又负责检查——这类似于让程序员自己做代码审查,已被软件工程实践证明容易产生确认偏误(confirmation bias)。AutoGen、CrewAI 等多智能体框架虽然提供了角色分工的脚手架,但具体到"实时游戏验证"这一场景,多数框架并未内置可交互的运行时探针接口。VibeGame 的试玩员角色之所以能发现两帧级时序偏差,依赖的正是引擎暴露的逐帧步进 API——这是把运行时环境设计为"可编程测试台"的直接收益,而非单纯依靠模型推理能力。

第三层:让每个游戏成为下一个的起点

第三层机制叫“免训练自进化”——不碰模型权重,只攒项目经验。验收通过的游戏被蒸馏成三件东西。

骨架(Skeleton):游戏类型的可运行模板,保留代码架构,调参数值和美术即可复用。每个骨架附一本错误笔记,记录这类游戏反复出现的坑和验证过的修法。

模块(Module):封装好的功能脚本,跨类型复用,还带自检逻辑,把以前踩过的运行时崩溃变成启动前的静态检查——同一个坑摔一次就够。

变成启动前的静态检查

契约(Contract):把某类特性的协作流程写成规程。比如地图契约会规定设计怎么提需求、程序怎么表示、美术怎么供图、审计试玩怎么验收。下个项目启动时,系统检索匹配的骨架、模块和契约,从更高的起点出发。但经验不会无脑套用,每个项目都要重新验证适配。

本质上,这与“从反馈里学习的闭环”“跨智能体统一记忆”是同一件事:把经验变成文件,不重训也能长记性。

这套"骨架-模块-契约"的经验复用机制,在概念上接近软件工程中的"检索增强生成(RAG)+少样本提示(few-shot prompting)"的结合体,但刻意绕开了模型微调(fine-tuning)。微调需要高质量标注数据集和算力,周期长且对普通开发者不友好;而将经验存储为结构化文件、在新任务启动时按语义检索注入上下文,则无需触碰模型权重。这一思路与 MemGPT(现 Letta)等"外部记忆"方案同源:把"记忆"从模型参数中解耦出来,变成可读写、可审计、可删除的文件系统。VibeGame 额外强调的"每个项目重新验证适配"是一个重要工程约束——防止陈旧或错误的经验条目被无条件复用,相当于在 RAG 管道中加入了运行时验证关卡。

成品:从像素之狼到角色互换

项目给出多个案例。纯文本的《像素之狼》,一句话描述狼蛛boss战系统,从横版动作骨架起步,但只狼的弹反加架势系统跟骨架的血量战斗完全是两回事,战斗从零搭建,最终交付12个脚本、两套角色素材、11个特效实体,弹反分普通格挡和精确弹反,架势调满触发多阶段处决。

多模态的空洞骑士boss战,则用文字定规则、一张概念图锚定视觉,生成的废墟教堂贴着概念图的剪影、语言和冷色调走。

编辑侧展示了三个层次的能力。最浅的是IP转移:把做好的boss战整个换成功夫熊猫主题,全部美术重新生成,战斗逻辑一行不改,验证了引擎的代码与资产解耦。中间是类型转移:把回合制卡牌改成实时动作,玩法整个换掉,赛博朋克视觉保留,系统自己判断什么该留、什么该重写。最深是规则转移:把空洞骑士的玩家和boss角色互换,小骑士变成AI驱动的boss,鹿角boss变成玩家操控,输入重绑、胜负重映射,全程不加新美术。

小骑士变成AI驱动的boss

项目页还放了9个演示:文明原型、街机格斗、地牢探险、水果忍者、跑酷、AI狼人杀等,全部能在浏览器直接开玩。

三点值得借鉴,三盆冷水照泼

第一,用接口验证而非直觉。 把“游戏好不好”从人的主观感受,变成智能体可执行的动作序列:暂停、单步、注入输入、截图、生成指示图。验得住才算交付。所有做生成式系统的团队都该学这一点。

第二,实现与评估分离。 多智能体的价值不在人多力量大,而在角色之间有对抗——生产者不给自己批卷子。这条原则比任何提示词技巧都值钱。

第三,经验三件套。 骨架、模块、契约构成免训练的自进化,普通开发者今天就能在自己的工作流里抄这个结构。

冷水也要泼。报告自己承认,全部能力靠定性描述支撑,没有对照实验和定量评测,基准测试留给未来;系统只支持2D网页游戏,3D的空间物理和相机能不能保持全文本表示,作者自己说不知道;验证本身也不完美,视觉判断会出错,自进化有污染风险——一条错误经验入库会带偏后面的项目,所以用户确认环节不能省。

项目现状是 226 颗星、两位贡献者,还没有正式发布版,想跑起来要自备 Claude Code 或 Codex,再配生图模型的密钥,长线门槛不低。当研究看成色很足,当生产工具用还早。项目采用 Apache 2.0 协议开源。

最后一句话:游戏的门槛从来不只是写代码,还有美术、调参、测试一整套手艺。VibeGame 的意思不是这些手艺消失了,而是它们被拆开、分给了一支不知疲倦的团队。你的工作变成把想象讲清楚——下一支独立游戏的主角,可能真的就是一个会说故事的人。

分享:

相关推荐