“开源AI模型OpenGame炫技”！港中文姜一雷：如何用自然语言做Web游戏 ？

【GameLook专稿，禁止转载！】

GameLook报道/随着AI从风口到实用技术的落地，越来越多的同行开始将AI融入到自己的研发工作流当中。不过，如今的AI大模型和工具，绝大多数都只能在特定研发环节帮助同行提升效率，真正能够一句话生成可玩游戏的模型，仍在探索中。

最近，在5月23日举行的”出海文娱增长闭门会“上，来自港中大MMLab的姜一雷作了题为“OpenGame：从自然语言到端到端可玩的Web游戏”的演讲。他分享了LLM如今做游戏的难点，并介绍了他参与的codeagent项目OpenGame的“解题思路”。

通过OpenGame，你只需要自然语言，就能指挥agent写代码帮你研发游戏。据姜一雷介绍，如果是做2D网页游戏，在该模型的模板基础上，大概一周时间就能做出可玩的产品。

开源地址：https://github.com/leigest519/OpenGame

那么，如今的code agent能做成什么样的游戏？还面临哪些挑战，以及未来会走向何方？

以下是Gamelook整理的完整演讲内容：

姜一雷：

今天很荣幸能向前面的各位学习，然后能去分享我们最近做的一个开源项目，叫做OpenGame，它相当于是面向game coding开发的Agentic框架。

在此之前先介绍一下我自己，我叫姜一雷，目前是港中文MMLab博一的学生，同时是在某大厂的基座团队做LLM的强化学习预训练的工作。我个人的研究领域也是Agent，以及怎么针对Agent能力的提升去设计一些框架和底层算法，相当于是通过强化学习去提升基模的能力。

今天的内容目录大概是这样的：

为什么我们要做这个工作，这个工作里面大概包含什么，以及怎么评估的。然后我也想讨论一下，从技术方面来讲，想要做成现在这样Web Game Coding的Agent有哪些技术上的难点，以及未来可能去怎么发展。

首先，为什么游戏code agent是比较难做的？我们这个东西相当于做了一个类似于首个开源的整体框架，能够把输入的一句话，就是自然语言，一句你对游戏的想法或者游戏设计，能够把它变成一个完整口，在这样一个2D的网页游戏。是一个端到端以及全自动这样的一个框架。

我们做了三个主体：一个是我们搭了整个agent，相当于现在用的词叫harness，相当于是为了针对这个任务去创造出一个比较好的harness；另外我们也去训练一个中等模型的基模，是27B的一个基模；然后相对应提出一个怎么样做评估的方法。

为什么游戏对LLM特别难？

为什么说游戏创作对大模型来说，尤其是对现阶段的LLM来说是比较难的东西，因为一个真正可玩的游戏其实是一个实时系统，它包含了一些主循环物理事件的处理，也包含了很多像美术、音频这样一些资源的管线，它是一个非常非常庞大的、相对来说非常复杂的系统，product system。

然后它中间跨文件的一些，无论是导入或者调用，其实耦合都是非常紧密的。现在LLM，比如说它在解一些coding题目，或者去底下的单个文件代码上面其实表现得会非常不错。但是，如果让它去写一些非常复杂的工程，尤其是从零开始写，比如说我想搭一个可能是二三十个文件的项目，你让它从头开始写，其实现在的通用Agent做的非常Bug。

从我们最开始的实验中，我们发现有3类失败模式，第一个是逻辑不自洽，比如说整个全局状态在主循环里一直漂移。另一个是对于你想用的这个游戏引擎，它对这方面的知识感知不是很好，比如说引擎里面已经实现了一些功能，但它不知道有这个功能，然后它自己想要从头写一遍代码，而不是去调用引擎里的某一个功能。第三个就是跨文件不一致。相当于它在创建project level项目的时候，跨文件调用非常差。

目前想到了一个方法，我们想把这个coding agent，在它的基础上把它专业化成为Gamedev的专家。

然后我们做出来大概是这样一个效果：

比如无论是个人的创作者或者甚至是教育领域，比如说老师现在想要把课堂变得更有趣，还是一些自媒体的创作者都可以根据他们想要的话题或者知识去构建出来一些更有意思的内容。

我们整个游戏的涵盖类型也非常多，无论是像马里奥这种平台游戏，还是保卫萝卜、植物大战僵尸这种类似塔防的游戏，亦或是UI heavy类似影游那种的，其实也都是可以做的。

因为时间限制，我这边就大概过一下我们这个东西是怎么做的。

首先是代码模型训练，我们在Phaser上面的宇宙上做三阶段的训练，首先是CPT，然后是SFT，然后再加上RL，这是一个比较常规的过程。

主要还是搭了一个agent harness，这里有6个阶段，首先分类就是针对每个游戏的类型去维持一个最小化和功能化的一个code agent，便于它在写游戏代码的时候能直接调用它，而不是从头开始写。所以第一步要有一个分类，比如说物理引擎，他可能是一个平台游戏，也可能是一个上帝视角游戏，这种类型就不需要考虑重力因素。

之后就是GDD生成，文档生成，资源生成，到最后相当于提取中间这个模板，然后直接把里面的hook给填上，最后是一个验证。中间的话就是训练的过程，以及我们管线的过程。

最后就是相当于Agent在过程中会不断演化自己，比如说我们首先会维护一个meta campaign，它是一个非常原始的母模板，针对任何游戏都可以调用这个模板。随着给他一些真实认知的任务过程中，比如说建一个马里奥式的游戏，那它建完之后，我会让他把这种游戏所需要的模板提取出来，放到我们的模板库。

这样，在下次遇到比较类似的游戏的时候，就可以按图索骥，直接提取出来比较类似的模板去用，往里面填充hook就可以了，就不用从头开始写。

device skill也是针对容易出现的bug，相当于每天的一个MD file，无论是在验证过程中还是下一次从头开始生成过程中，能让它把这个东西debug好。

接下来也比较困难，也就是这个游戏怎么玩？它和普通的代码其实还不一样，普通代码你可能有compile（编译）成功、test通过就OK了。

但是游戏不一样，游戏也有三个阶段，第一个阶段是这个东西能不能编译成功，如果都不能编译成功那肯定不行。第二个阶段就是里面有没有bug，比如有些游戏做出来它可能有bug，比如我们用SOTA模型去做马里奥游戏的时候，它完全不知道这个游戏角色的身高和它能跳跃的阶梯高度之间的关系，导致这个游戏永远无法通关。

第三步，游戏最重要的是好玩，那这个趣味性又怎么衡量？这不是更难了？所以说这个东西本身衡量起来是非常非常困难的。我觉得在我们这个工作里面，现在这个阶段只能尽力做的好一些，但是我们承认肯定不是完美。我们衡量三个阶段，也就是三项，第一个是build，能不能渲染，能不能编译；第二是游戏画面怎么样，就是我们从中间截图然后给他打分。

第三是和用户意图是否一致，就是比如说我在游戏里想做几个功能，我想要这个游戏有3个关卡，某个人物有什么功能，或者我想要交互技能是WASD还是上下左右，也就是你做出来的游戏是否和用户需求一致。

从结果上看，我们这个模型和harness都取得了非常好的效果。

Web Gamedev的痛点

最后想讨论的是web gamedev目前的几个痛点以及未来的几个方向。

第一个就是LLM和Code Agent的3D空间理解问题。当然，我们的OpenGame主要聚焦的还是2D游戏，下一个我们已经在做的相当于是OpenGame 3D吧，我们已经在做了。

从我们最开始做的时候就发现有几个比较重要的问题。第一个是3D的问题，比如说，LLM通过Unity或者Unreal的MCP去用或者调用API生成一些3D资产，但生成之后，比如说我想搭一个赛车的跑道，然后我跟它说要搭一个赛车道，旁边要有一堆树。然后这个agent会调用一些API来生成3D的资产，但是它不知道怎么摆，它心里面没有这个东西。比如常规我们应该是中间一条路，树是在两边，这是比较正常思维的一个场景。

但很有可能，他会把一棵树垒到另一棵树的上面，或者说它把树就种到路的中央。就是说，它不知道怎么去管理3D布局，这是非常重要的一个问题。然后像其他的一些比如说穿模，比如说你生成了一些NPC，一生成直接就卡墙里了。

从我们看，这是相当重要的一个问题，我们觉得模型本身是缺乏3D空间先验的，它在text token序列里面推理没有空间的理解能力。一些可能的方向，比如说符号化的空间表示，或者动态闭环，或者物理碰撞信号，这i可能是一些解决的思路。

至于我们是怎么解决，如果大家感兴趣的话，我们会在七八月份的时候会发布出来OpenGame 3D，我们也给出了一些解决方案实现了一些比较好的效果，到时候大家可以关注一下。

第二个点，我认为是非常重要的一个点，就是这个Game Agent怎么去eval，也就是怎么去“玩”到“体验”。这个也不是我说的，之前我跟Unity交流，他们在Gemini 3之后就大力发展AI业务，大家交流认为eval是最痛点的一个阶段，无论是你的agent group里怎么给验证反馈，还是说用RL训练的时候怎么给reward，其实都是非常非常中国要的。

我们大概分两条思路，大概是这么想的：第一个是黑盒的，相当于Game-VLA，就是我们input实时有一句话，就是完全模仿人，因为我不知道游戏的源码怎么搞，只知道这个游戏相当于是一个SDK，直接就用。那就是看这个游戏的画面然后输出动作，相当于像玩家一样把整个游戏玩一遍。

但是我们目前尝试有几个问题，首先这个路线，也就是Game-VLA路线，用现在的仿真模型，在zero-shot情况下走不通，也就是如果是他没见过的游戏让它直接玩，基本上它就是不会玩，效果很差。一个可能的解决方案是用few-shot去做，就是你把比较像的给他做一个in-context-learning（情景学习），或者把这个游戏一些比较重要的交互生成一些技能给他塞到这个context里面让它知道。

这个还有个问题是，比如你真的用Game-VLA去做的话，你想要检验这个游戏中的功能，比如说这个游戏有3关，我想测试第2关，那就必须把第一关玩完之后才能玩第二关。但有一个很大的问题，就是它能不能玩到第二关都不一定。

而且如果一个游戏有50关，我想要测试第49或者第50关，那非要把前面所有关都玩完吗？这个就太慢了，这就完全不可行，无论是agent loop还是rollout都太长了，完全没法做，可能训一个step就要好几天，完全没办法训练。

所以权宜侧可能就是白盒这样的东西，因为LLM、code agent生成的游戏，它的源码是完全accessable的，知道它代码是怎么写的，那么我们可以做一些白盒runtime state injection。核心洞见就是，把玩到某个状态，直接pass到某个状态。

因为游戏它其实就是一个state machine，原先的Game-VLA黑盒玩法是通过一个agent去玩到某个状态。这个state injection就是直接不玩，把参数改到对应state就行。

大概说一下白盒方案的一些思路，比如说直接抽调keypoint，这当然也需要LLM去帮我们，然后往里面注入，再去执行。这个比较快比较稳，但局限就是仅限于白盒自生成游戏，我觉得如果将来技术发展到更好的话，我觉得还是有一个流式的黑盒Game-VLA，也就是它能像人那样实时去玩这个游戏。但是这个需要大模型那块把仿真人模型训练好才可以。

未来方向

未来的方向，当然是从2D到3D。OpenGame是一个偏学术性的，我看到不少创业公司也在做类似的东西了。我感觉2D的技术门槛已经没有那么高了。如果想做的人，直接在OpenGame上改一改，一周就做出来了。技术门槛可能在3D，但是对于产品我可能不是太懂，我只是从技术上来说，所以只是提供技术参考。

今天的分享就这些，谢谢大家。