这项由英国布里斯托大学、上海交通大学、山东大学、南京大学和Sreal AI联合开展的研究，于2026年4月发表在预印本平台arXiv上，论文编号为arXiv:2604.19926。研究团队围绕一个听起来颇具野心的目标展开工作：让AI不只是"一次性"生成一个游戏，而是像有经验的游戏设计师那样，一版比一版更有创意地迭代改进。

说到游戏设计，绝大多数人脑海里浮现的可能是某个熬夜苦思的开发者，手边摆着咖啡，在白板上反复涂改游戏规则的场景。而现在，AI也开始尝试扮演这个角色。问题在于，以往的AI在这件事上表现并不理想——它能写出"看起来像游戏代码"的东西，但运行起来要么卡死，要么无聊得像在看一块空白屏幕。更棘手的是，你让它"做一个有创意的游戏"，它十次里有九次给你的是乒乓球或者太空射击——那种几十年前就玩烂了的模板。

CreativeGame这个系统的核心逻辑，可以用一个日常比喻来理解：把AI游戏生成过程想象成一位学徒厨师的成长历程。这位厨师不只是按食谱做菜，而是每做一道菜之后，都会认真记录哪些步骤成功了、哪些失败了，然后下次尝试时主动改变某个食材或烹饪方式。随着时间推移，这位厨师不再只会复制经典菜式，而是开始真正创造属于自己风格的新菜。整个CreativeGame系统正是以这样的逻辑设计的：从"按模板复制"走向"有规律地创新"。

一、为什么以前的AI做游戏总让人失望

要理解CreativeGame的意义，得先弄清楚之前的AI到底哪里出了问题。

以往，研究人员尝试直接让大语言模型（可以理解为ChatGPT这类会写文字和代码的AI）生成游戏代码，结果暴露出几个让人头疼的问题。第一个问题是生成的代码经常"看起来没问题，跑起来崩溃"。就像一道菜摆盘精美，结果吃进嘴里才发现根本没熟。游戏代码里会有各种隐藏的小毛病：游戏循环写了却没有真正调用，动画帧更新写了却不会自动重复，画布背景没有正确初始化……这些问题不影响代码的"外观"，却让游戏完全无法运行。

第二个问题是AI没有"记忆"。每次生成一个新游戏，AI都是从头开始，完全不记得上一次哪个设计成功了、哪个思路走进了死胡同。这就像让那位学徒厨师每天上班之前都喝一碗忘忧汤——永远在重复同样的错误，永远无法积累经验。

第三个问题最难解决：如何评价一个游戏"有没有创意"？通常的做法是让AI自己给自己打分，但研究团队发现这个方法有严重漏洞。GPT这类高水平的AI模型，不管你给它看什么游戏，它都倾向于打出"7分"左右的分数，就好像一个永远给及格分的老师，根本无法区分平庸之作和真正的创意突破。这在学术上被称为"分数饱和"问题——评分系统失去了真正的区分能力。

更深层的问题在于，就算AI打出了8分，比上一版高了1分，这个变化是真正的创意进步，还是只是运气好换了个颜色主题？没有人能说清楚。

CreativeGame的研究团队把这些问题系统地梳理出来，并针对每一个问题设计了对应的解决方案。

二、游戏的"骨架"：什么叫真正改变了游戏规则

在讨论解决方案之前，研究团队先做了一件很重要的事：给"游戏"和"游戏机制"下了精确的定义。这听起来像是绕弯子，但实际上是整个系统能够运转的基础。

研究团队把一个游戏理解为由十几个相互关联的部分组成的系统，包括：谁在做决策（玩家），游戏世界的状态是什么，玩家能做什么动作，做了动作之后世界会怎么变化，玩家能看到什么信息，有什么奖惩反馈，有哪些资源和限制，最终目标是什么，等等。

在这十几个部分里，研究团队划了一条重要的分界线：有些部分是"核心结构"，比如玩家能做的动作、动作的后果、获胜条件；而另一些部分是"表现层"，比如游戏的视觉风格、音效、背景故事。

这条分界线的意义在于：如果你只是把一个科幻主题的射击游戏改成了古装主题的射击游戏，游戏规则一字未动，那这不叫创意，叫"换皮"。CreativeGame系统被明确设计成专门奖励核心结构的改变，而不是表面的视觉翻新。

在这个框架下，"游戏机制"被定义为：一种稳定地改变游戏核心结构的规则模式。比如，"重力"是一种机制，因为它改变了物体运动的规律；"充能攻击"是一种机制，因为它改变了玩家行动的后果；"幽灵回放"是一种机制，因为它让过去的行动记录变成了可以影响当前游戏状态的实体。

理解了这个定义，就能理解为什么研究团队后来那么执着于追踪"机制的变化"——因为机制的变化，才是真正意义上的游戏创新。

三、系统的"厨房"：七个专职角色各司其职

CreativeGame系统的运作方式，可以类比成一家分工精细的餐厅后厨。不同的角色有不同的专业职责，彼此之间按固定流程配合，共同完成一道"菜"（一个游戏版本）的制作。

整个系统共有七个逻辑角色，在实际执行时展开为十个可运行的具体职位。生成游戏代码这个环节本身就被拆分成了四个连续的子阶段：骨架生成（先搭建游戏的基础框架，就像先把厨房的灶台和锅碗摆好）、功能实现（往框架里填充具体的游戏逻辑，就像开始备料和炒菜）、视觉增强（添加界面效果和动画，就像摆盘装饰）、精炼打磨（最后检查和修复细节，就像出菜前的最后调味）。

这个流程的起点是"规划者"角色。在规划者动笔之前，系统会先去查阅一个拥有774条记录的全局机制档案库——你可以把这个档案库理解成一本厨谱大全，里面记录着各种游戏机制的成功案例、使用频率，以及哪些机制已经被用烂了、哪些还有探索空间。规划者查阅这本"厨谱"之后，会明确列出本次游戏应该保留哪些机制、新增哪些机制、删除哪些机制、或者把哪些已有机制重新组合。这份明确的"机制计划"会传递给后续所有生成阶段，作为整个创作过程的指导纲领。

代码生成完成后，系统会进行验证和修复，如果发现问题会自动触发修复流程。随后是评估阶段，对照之前的机制计划，检查实际生成的游戏究竟实现了多少计划中的机制。接着是反思阶段，把这次经验总结成"成功经验"和"失败教训"写入记忆。最后是循环控制——如果这一轮结果不够好，就回到代码生成阶段重来，最多尝试三次，然后保存最终结果。

整个系统用Python编写，共6181行代码，包含了完整的流程编排、记忆管理、奖励计算、运行时验证、机制检索和血统记录功能。这个规模使得系统的每一个内部决策过程都是可追踪、可检查的。

四、打分的革命：让AI不再靠"感觉"评价创意

创意分数这个问题，是CreativeGame系统最花心思的地方之一。研究团队设计了一套他们称为"创意代理奖励"的评分机制，核心思路是：把评分的主导权从AI的主观判断手里抢过来，交给可以客观验证的程序化指标。

这套评分机制由七个加权信号组成，权重各不相同。其中最重要的是"结构性机制变化"，占25%的权重——这个指标衡量的是，相比上一版游戏，这一版新增了哪些机制、修改了哪些机制、删除了哪些机制。权重排第二和第三的是"机制实现度"（20%）和"相对机制新颖度"（20%），分别衡量计划中的机制有多少真正出现在了最终代码里，以及这些机制相对于那个774条记录的全局档案有多新鲜。这三个最重要的信号合计占到总分的65%，而且都是通过程序计算得出的，不依赖任何主观判断。

AI自己的创意评分只占15%，而且被处理成了一个辅助信号。研究团队把AI给出的原始分数（满分10分）减去3再除以7，这样做的目的是让分数分布更有区分度，而不是让AI总在7分附近徘徊。即便如此，这个信号仍然被标注为"辅助"，不会主导最终结果。

剩余的20%由两个负向信号构成：如果这一版游戏只是在视觉表现上做了修改而核心机制毫无变化，系统会扣掉15%；如果生成的代码缺少游戏运行必需的基础组件（比如画布初始化、游戏循环、输入监听），会扣掉10%。

在这七个信号之外，还有两个"门禁"条件。第一个是软性门禁：如果基础可玩性检查低于0.6分，整体奖励会直接缩减到原来的25%。第二个是硬性门禁：如果游戏代码在运行测试中失败了，无论创意分数有多高，整体奖励都会减半。这个硬性门禁的设计理念非常明确——一个在屏幕上根本跑不起来的游戏，再有创意也没有意义。

五、记忆的设计：让经验在家族内部流传

解决了"如何打分"的问题之后，另一个关键挑战是：如何让AI在多次生成游戏的过程中积累经验？

CreativeGame的答案是"血统感知记忆"系统。把一系列相关游戏版本想象成一个家族——v1是祖先，v2和v3是后代，v4是曾孙辈。这个家族内部共享一个记忆库，每个成员的生成经验都会写入这个共享记忆，后续成员可以直接读取和利用。但不同家族之间是完全隔离的——别的游戏血统的经验不会"污染"这个家族的记忆。

记忆条目被设计成包含四个元素的组合：意图（这次尝试想达成什么）、表示（用什么方式实现的）、价值估计（这个方法的历史效果有多好）、访问次数（这条记忆被使用过几次）。每次迭代结束后，系统会用一个叫做"指数移动平均"的方法更新价值估计——简单说就是，新的结果不会完全覆盖历史经验，而是把新结果和历史经验按比例混合，混合比例是0.3:0.7。这样，一次偶然的失败不会让系统彻底放弃一个曾经成功过的设计思路。

在检索记忆时，系统会同时考虑两个因素：这条记忆和当前任务的相似度，以及这条记忆在历史上的成功率。二者的平衡确保了系统既不会只顾重用"看起来相关"的经验，也不会只追逐历史上得分最高的套路。

整个记忆架构分为三个层次。最底层是每个血统独有的学习记忆；中间层是跨血统共享的资源，包括创意规则库、游戏素材库和全局机制档案；最上层是当前生成过程的临时上下文。全局机制档案不只是一个被动的参考库，规划者会主动查询它来寻找"还没被充分探索的机制"，而成功的新机制在生成之后也会被写回档案，形成一个动态更新的知识库。

六、代码体检：两层检查让游戏真正能跑起来

既然要确保生成的游戏真正能运行，光靠AI自己检查是不够的。CreativeGame设计了一套两级运行时验证系统，就像对游戏代码做一次彻底的"健康体检"。

第一级是深度静态分析，不需要任何额外工具，每次运行不超过10毫秒。这一级检查共执行九项测试：括号和花括号是否配对（就像检查每个开门都有对应的关门）、游戏循环是否真正被调用而不只是被定义（就像检查发动机不只是摆在那里而是真的启动了）、动画帧更新是否设置了递归调用（确保游戏画面会持续刷新）、画布上下文是否正确获取、输入监听器是否挂载、游戏初始化是否在页面加载完成后执行、渲染调用是否存在、状态更新是否存在。每发现一个错误，评分降低0.2；每发现一个警告，降低0.05。

第二级是浏览器执行测试，在有条件时可选启用。系统会启动一个无界面浏览器，实际加载游戏的HTML文件，等待画布绘制完成，模拟基础输入操作，然后收集所有控制台报错。如果整个过程没有报错且画布成功绘制，该游戏被标记为"可玩"。当浏览器测试不可用时，系统会自动降级到仅使用第一级静态分析。

验证结果在整个流程中承担双重角色。它既是修复的触发器——测试失败后，系统会把具体的错误信息喂给修复模块，触发专门的代码修复流程，然后重新测试；它同时也是奖励的组成部分，运行时得分作为七个代理奖励信号之一，并且触发硬性门禁条件。

研究团队在报告中特别点明了这套验证系统存在的必要性：大语言模型非常擅长生成"看起来正确"的代码，但这种代码里藏着很多只有真正运行才能暴露的问题——游戏循环函数被定义但从未被调用，这种错误如果只看代码外观根本发现不了，但游戏打开来就是一片死寂。

七、四个游戏的进化故事：从"模仿"到"重新理解"

说了这么多系统设计，不如直接看看它实际产生了什么效果。研究团队从系统运行的真实记录中，挑选了四个各自跑了四个版本的游戏进化序列，详细分析了每个游戏是如何从第一版演化到第四版的。

第一个案例是基于《火柴人和水女孩》的进化序列。这是一款经典的双人合作平台游戏，核心玩法是控制两个角色配合解谜。系统生成的第一个版本已经不是对原版的直接复制——它引入了一个"停靠供能"的设计：让一个角色停在特定位置为水晶充能，另一个角色可以继续前进。这已经比原版多了一个策略层，但整体上仍然是"操控两个角色解平台谜题"的逻辑。

真正有趣的转变发生在第二版开始，并在第三、第四版里逐渐清晰。在"中继符文神殿"版本里，角色切换不再只是控制权的转移——它会创造出一个"重放幽灵"，这个幽灵可以帮助触发传感器和开启新路线。第三版又引入了"重力符文"，使得重放记录会继承玩家设置的重力变换规则，而不只是回放动作轨迹。到了第四版"记忆中继"，游戏的核心概念已经被彻底重构：玩家要做的不是"控制两个角色穿越关卡"，而是"用停靠的角色、幽灵重放记录和重力印记，构建一个能自动运转的活体电路"。这是从"控制型玩法"到"编程型玩法"的质的飞跃。

第二个案例是基于《Flappy Bird》的进化。这个游戏的原版极其简单：一个按键，一个上升冲量，不断躲避管道。系统的第一版虽然保留了这个操作核心，但已经让管道随着节奏时机产生变化，游戏因此比原版多了一点结构感。

然而在后续版本里，系统对"穿过管道"这个动作的理解发生了根本性改变。第二版开始，完美通过管道不再只是得分，而是可以"书写"之后的管道形态——玩家的完美表现成为了塑造未来关卡的工具。死亡留下的痕迹会变成"回声幽灵"，可以帮助后续轮次的通关。节奏时机开始和"相位穿透"挂钩，特定节奏下可以让角色短暂进入无碰撞状态。到了第三、第四版，整个游戏类型的定义已经从"反应型生存"转变为"轻度规划与路线改写"——玩家的历史轨迹正在主动塑造近未来。

第三个案例是基于《Happy Glass》的进化。原版《Happy Glass》是一个经典物理解谜游戏：玩家画线引导水流进入容器。系统的第一版在此基础上加入了多种墨水材质和仪式检查点，但整体逻辑仍然是"画出物理屏障引导液体"。

关键的概念转变出现在第二版：一种特殊的"吸收笔触"被引入，这种线条可以把水滴储存起来，之后释放的同时还能改变重力方向。这一步很关键——绘制的线条不再只是几何形状，而是一个延迟触发的规则改变器。第三版进一步添加了"链式继电"机制，充能的水滴可以向周围传播行为，邻近的笔触也会跟着激活。第四版整合了这些想法，形成了更清晰的逻辑：实心墨水塑造路径，吸收墨水编程状态转换，重力旋转是有限的战略资源，仪式充能的水滴以不同方式计入容器填充量。整个游戏被重新理解为一门"可编程的迷你物理语言"，而不再只是画线引路。

第四个案例是基于《植物大战僵尸》的进化。原版的核心是"在多条车道上放置植物防御僵尸"的资源管理游戏。系统第一版的主要创新点在于：发电型植物可以物理性地挡住友方子弹，使得资源生产和射击路径之间产生了相互干扰——这在原版里是完全分离的两件事。

这个干扰在后续版本里成了核心设计理念。第二版允许整条车道被"弯折"，一次改变整条车道的子弹路径和敌人行进路线。第三版明确了"友方子弹被挡住后储存为过充电量，之后释放为更强的共鸣攻击"，把"友好伤害"变成了一种有意为之的战术准备行为。第四版进一步通过预测引导和折射窗口概念，让整个系统变得更具战略可读性。最终，这个游戏血统对"塔防"玩法的理解彻底转变：从"放置单位阻挡波次"变成"规划哪些车道直接防御、哪些车道先承受友火蓄能以便之后发动折射攻击"。

这四个案例呈现出一个共同的演化规律：在所有四个序列中，最有意思的变化都发生在机制的重新诠释上，而不是视觉风格的打磨。后期版本倾向于重新赋予现有动作以新的含义——角色切换变成了记忆书写，通过管道变成了路线编辑，画线变成了规则脚本，阻挡友方子弹变成了有意的蓄能储存。早期版本保留了源游戏的外壳，而晚期版本更清晰地暴露出这个变体游戏真正想说的隐藏规则。

八、系统的实际表现：数字背后的真实含义

研究团队在实验记录中保存了71个游戏血统，其中9个是拥有多代后代的多节点血统（最深到第四代），62个是单节点血统，共计88个保存节点。全局机制档案库里有774条记录，所有保存节点里的文字总量超过450万个词语量级的token。

从计算资源分布来看，视觉增强阶段消耗了大约34%的计算预算，因为它需要在一个已经相当完整的游戏主体上叠加大量界面细节和动画效果。评估阶段排第二，约占27%，这反映了认真评估一个游戏需要大量的分析工作。功能生成阶段约占18%，骨架生成约9%，规划阶段约8%，反思阶段约4%。

在可靠性方面，经过重试和降级恢复机制的加持，整个流程的成功率超过了98%，空输出的恢复率在三次尝试内超过95%。作为对比，研究团队提到在这套机制实施之前，管道失败率大约是10%，优化后降低到了2%以内。

在评分分布方面，所有生成游戏的平均创意分约为7.0分（满分10分），平均可玩性分约6.5分，平均综合得分约6.2分。研究团队在报告中坦诚地指出，这些评分存在前面提到的"分数饱和"问题，反映的是粗略的功能完整度而非经过验证的玩家体验，数字本身不应被过度解读。

九、这套系统和其他方案有什么本质区别

这篇论文的关联工作讨论部分，把CreativeGame放在了几个重要的相关研究方向中进行比较。

多智能体代码生成领域的代表系统包括ChatDev、MetaGPT和AgentVerse，这些系统同样使用角色分工的方式来组织AI的软件生成过程。CreativeGame遵循了类似的分工思路，但它的组织方式是围绕游戏生成、测试、评估、反思和记忆写入这个固定迭代流程构建的，而不是通用软件开发流程。

在创意评估方面，创意研究领域早就发现"谁来评判创意"是一个极其困难的问题，不同的判断者对同一个作品可能给出截然相反的评价。近年来"让AI来当评委"的研究方向也暴露出模型评判在开放性任务上的局限性。CreativeGame的回应是把AI判断压缩为一个15%权重的辅助信号，主要信号交给可程序化验证的指标——这是一种有意识的设计取舍而非技术捷径。

在记忆增强智能体领域，MemRL系统（由上海交通大学等机构提出，同样是2026年的研究，arXiv编号2601.03192）明确提出了通过情节记忆的运行时强化学习来实现自我进化智能体的思路。CreativeGame的记忆设计直接受到这一方向的启发，并做了一个特定的架构选择：使用血统级共享记忆而不是任务级隔离记忆，因为对迭代创意生成而言，跨版本的经验积累本身就是目标。

在代码生成的运行验证方面，学术界已经广泛认识到基于执行的正确性评估对代码生成系统的重要性。CreativeGame的创新在于把运行验证同时作为奖励信号和修复触发器整合进了多智能体流程，并设计了当更强验证条件不可用时的优雅降级路径。

说到底，CreativeGame这项研究讲述的是一个关于"如何让机器真正积累创意经验"的工程故事。它不是说AI突然获得了人类式的创意灵感，而是说，通过合理的系统设计——把机制当作可追踪的实体、把评分建立在可验证的指标上、把经验在版本之间真正传递——AI生成游戏的过程可以从一次性的随机输出，变成有方向感的渐进演化。

四个游戏血统的案例是最直观的证据：从第一版到第四版，每个游戏的"核心玩法概念"都经历了可以用语言描述的质变，而不只是表面的视觉翻新。这种变化被系统里的记录完整保存下来，任何人都可以打开数据文件，一步步追溯游戏设计是如何从"模仿原版"演化到"提炼出一套新规则语言"的。

当然，研究团队也坦率承认了现有的局限：当前的奖励机制仍然只是对形式创意的工程化近似，还无法真正衡量一个游戏对真实玩家的吸引力；评分系统的"分数饱和"问题没有从根本上解决，只是被边缘化了；多节点血统的数量还偏少，深层进化效果还需要更多数据支撑。这些都是未来值得继续深挖的方向。

有兴趣进一步了解这项研究的读者，可以通过arXiv编号2604.19926查找完整论文。

Q&A

Q1：CreativeGame系统是如何避免只生成"换皮游戏"的？

A：CreativeGame通过两个机制来防止这个问题。第一，系统从形式上区分了"核心规则结构"（比如玩家动作的后果、获胜条件）和"表现层"（比如视觉风格、背景故事），评分系统只奖励核心结构的改变，纯视觉改动会被扣分。第二，规划阶段要求明确列出本次版本要新增、删除或重组哪些具体机制，这个计划会贯穿整个生成过程，事后还会和实际结果对比，强迫系统在规则层面而不是外观层面做出改变。

Q2：CreativeGame的运行时验证系统具体检查哪些内容？

A：验证系统分两级。第一级静态分析不需要运行游戏就能快速完成，检查九项内容：括号是否配对、游戏循环是否被真正调用、动画帧更新是否设置了递归、画布上下文是否获取、输入监听器是否挂载、初始化是否在页面加载后执行、渲染和状态更新是否存在。第二级在有浏览器工具时启用，实际运行游戏，检测控制台报错和画布绘制状态。两级都能触发代码修复流程，运行结果也直接影响最终评分。

Q3：CreativeGame生成的游戏是什么格式的，普通人可以直接玩吗？

A：CreativeGame生成的是HTML5格式的游戏，可以直接在网页浏览器里运行，不需要安装任何软件。论文附带的项目展示页面（yiweishi-cn.github.io/CreativeEvolutionGame）展示了四个游戏血统各自四个版本的全部十六个游戏，每个游戏都带有一个自动演示机器人在跑，可以直接观看游戏运行效果。