更直观的，就是钱。

游戏团队开发一款能让人们记住并且爱玩儿的大作，预算动不动就要超过1亿美元。

要不然怎么说，游戏制作算是一种用爱发电呢。

现在，情况有变！

有研究人员开发了一个叫GameGPT的模型，GameGPT可以整合多个AI智能体（agent）来自动完成游戏开发中的部分流程。

而不同的智能体各司其职，工作起来井井有条。

有智能体负责审查游戏的设计计划，并进行相应的修改和调整；有的负责将任务转化为具体的代码；有的负责对上一步生成的代码进行检查，对运行结果进行审核；还有智能体负责验证全部的工作是否符合初始预期。

如此这般，通过细化分解工作流程，GameGPT就可以简化AI智能体的工作。这种各司其职会更加有效率，实现起来也比一个全能型的智能体完成一切要简单得多。

研究人员表示，GameGPT可以简化传统游戏开发流程中一些重复和死板的内容，比如代码测试。

大量开发人员就可以从繁杂的检验工作中解放出来，专注于AI所不能替代的，更有挑战性的设计环节。

当然，这篇论文目前还处于一个比较初步的阶段。目前还没有任何具体的结果或者实验来证明性能上的提高。

换句话说，还没人用GameGPT真的开发过游戏，这个模型目前还处在概念形成阶段，在有具体的应用结果以及可量化的数据之前，咱也不好评估。

不过，总归是个努力的方向。

有网友表示，人们对LLM的想法是有一定偏差的。现在，研究人员有了一种能够100%解决NLP问题的工具，而人们却只关心如何实现某些工作流程的自动化。

举例来说，想象一下如果游戏世界对你的决定做出的反应，要比你在五分钟内判断出基于规则的硬编码引擎的反应更正常，那将会是怎样的情景。

再想象一下，如果一款游戏能根据你做出的决定（比如在路上随机屠杀你看到的敌人等），为你临时安排一些支线任务，那会是什么场景。

而开发者在创建这样一个系统时，会使用提示工程来指导LLM，而不是编码这些东西。

但是，这样做的目的不是为了节省成本，而是为了在以前无法制作更多游戏的阶段制作游戏（是不是有点拗口）。

GameGPT

首先，让我们来看看GameGPT模型的大框架——全流程。

可以看到，作者将每个智能体拟人化，更生动地展示了他们是如何各司其职的。

流程最左侧是用户端，向GameGPT输入prompt，然后开发经理和审核进行初步计划。

接着，再把需求发送给开发工程师，以及游戏引擎工程师，来执行具体的任务，生成代码。

最后检查一下有没有遗漏，有的话发回左侧，再跑一遍。没有就继续向右，由负责检查的工程师来进行testing。

AI开发游戏？？

实际上，AI开发游戏历史的雏形也许可以追溯到更早。

AI在游戏开发中的应用可以追溯到「星际争霸」和「暗黑破坏神」等经典游戏。在当时，开发人员需要用AI系统来制作交互式的虚拟世界和角色。

而这些系统已成为此类互动平台开发的标准配置。

早期和游戏开发AI相关的研究强调控制非玩家的角色（NPC），而随着自然语言处理（NLP）技术的发展，出现了一些利用深度学习技术生成关卡的开创性工作。

其中代表作是MarioGPT，它通过微调的GPT-2模型成功生成了「超级马里奥兄弟」中的部分关卡。

而众所周知，LLM又在今年取得了巨大进步，在NLP和计算机视觉（CV）领域都取得了不错的成绩。

我们知道，LLM的训练是一个多阶段的过程。初始阶段包括在广泛的语料库中训练这些模型，促进基本语言能力的获得。

随后就是更重要的阶段了，通过指令（instruction）生成各种NLP任务的数据对模型进行微调。这种指令调整，增强了模型在广泛应用中的泛化能力，从而可以让LLM能够在之前训练中没有执行过的任务中取得零误差的性能。

最后，人类反馈强化学习（RLHF）阶段保证了模型的结构完整性和可靠性。

这里还有一点需要注意——RLHF阶段能让模型生成模仿人类风格的内容，从而增强其作为智能体的多功能性。

此外，LLM的进步还促进了智能体在软件开发过程中的自动化。许多研究都曾经把目光放在过这个问题上——如何开发一个基于LLM的智能体，用来执行不同的任务。

比方说AutoGPT就曾经采用LLM智能体来处理现实世界中的某些决策任务，而HuggingGPT则采用的是单个LLM作为一种控制器，来协调完成更加复杂的AI任务。

虽说这些方法都依赖于唯一的LLM智能体，但它们都加入了一个审核者（就是上面流程图里的reviewer）来完善决策。

还是拿AutoGPT举例，模型会从监督学习器中获取一些辅助性的意见来提高自身性能，HuggingGPT也可以接入GPT-4，弄成一个reviewer，来评估决策的准确性。

还有一些别的例子，比方说MetaGPT就引入了一个多智能体框架，可以用于各种软件的自动化开发。

而回到我们今天讨论的游戏开发，我们要知道，与一般的软件开发不同，游戏开发行业的运作需要紧跟潮流，因此整个开发过程必须更加精确和简洁，以达到最佳效率。

此外，在没有幻觉和高精度的情况下，调整和使用单个LLM来服务于游戏开发的整个开发周期是不切实际的，而且成本高昂。

因此，游戏开发AI的框架需要多个reviewer参与，这样就能有效缓解语言模型所固有的幻觉倾向。

研究人员还发现，在游戏开发中，语言模型还有另一个局限性——冗余性。LLM在游戏生成时，可能会生成不必要的、无信息量的任务或代码片段。

为了有效解决幻觉和冗余问题，今天的主角——GameGPT战略性地采用了多种方法来解决这个问题，包括双重协作、通过内部词汇库进行指令调整以及代码的解耦。

值得我们关注的是，双重协作涉及到LLM与小型深度学习模型之间的互动，以及负责执行的智能体与reviewer智能体之间的协作参与。

研究人员表示，这些协同作用已被证明，在减轻GameGPT的幻觉和冗余方面是有效的。

方法介绍

接下来，研究人员从全流程剖析一下GameGPT的创新。

首先，在游戏设计阶段，在收到用户请求后，GameGPT的任务包括生成整个游戏的开发计划。这个计划阶段是关键步骤之一，极大地影响了整个开发过程的无缝进展。

这个阶段由基于LLM的游戏开发经理策划，先提出一个初始计划，随后分解成任务列表。

值得注意的是，由于LLM固有的局限性，这个初始计划经常会出现幻觉，从而产生意想不到的任务，包括没有信息或不必要的冗余任务。

为了应对这些问题，研究人员提出了四项可以减轻这些难题的策略，这四种策略相互正交的，并且可以分层执行以获得更好的效果。

方案一：对传入请求进行分类，目的是辨别游戏的类型。目前，GameGPT框架支持五种不同游戏类型的开发，即:动作、策略、角色扮演、模拟和冒险。

对于每种类型，研究人员都会提供标准化的计划模板，指导游戏开发经理智能体使用相关信息完成模板。

通过采用这种方法，冗余任务的频率显著降低，同时减少了幻觉发生的可能性。

策略二：涉及计划审查员智能体的参与，这是另一个基于LLM的代理。这个智能体通过精心设计的prompt进行操作，以此来对任务计划进行全面的审查。

它的主要目标是尽量减少幻觉和冗余的发生。该智能体评估计划并提供反馈，旨在改进并提高其准确性、效率和简洁性。

同时，这一部分生成的指令可以作为游戏开发经理智能体的新输入，使任务计划更加准确和完善。

策略三：通过专门的指令来调整游戏开发经理智能体的LLM本身，以便更好的进行游戏开发层面的规划。这个微调过程的目的就是让模型能生成一个既准确又简洁的计划。

为了方便起见，研究团队收集并整合了一个内部数据集，其中包括许多输入输出的搭配。虽然这些组合在长度或结构上不符合标准格式，但它们都围绕着游戏开发的要求。

这部分固定搭配由业内的开发人员提供。

通过采用这种方法，研究人员有效地弥合了LLM的一般语言能力与游戏开发规划能力之间的差距。

策略四：规划阶段的「安全网」。在整个计划过程中，游戏开发经理智能体始终在前端界面上与用户分享中期结果，使其余的智能体能够随时了解正在进行的开发是什么。

为了增强这一点，研究人员集成了一种交互式方法，使用户能够根据他们的期望积极地审查、纠正和增强计划。这种方法也保证了设计计划和用户需求之间的一致性。

说完了这些策略，我们来看看GameGPT的优越性。

首先，这个模型中的任务分类过程要求在识别任务类型及其对应参数方面具有很高的准确性。

因此，研究人员为了确保这一阶段的准确性，创建了一个名为游戏开发工程师的智能体。该智能体由两个模型共同组成，它们协同参与任务分类的流程。

这种协作方法提高了任务识别的准确性和有效性。同时为了避免LLM幻觉的出现，提高任务分类的准确性，研究人员提供了游戏开发中可能出现的任务类型列表。

为了对此进行更好的分类，他们采用了BERT模型。

BERT模型已经用内部数据集进行了完整的训练。该数据集包含针对游戏开发任务所量身定制的各项数据条目。而输入则是从预定列表中绘制任务，而输出对应的则是任务的指定类别。

任务类型和参数的审阅都在这个阶段进行，引入一个叫做任务审阅人员的智能体，主要负责每个类别的识别和参数是否合理。

评审（review）的过程包括审核任务类型是否在预定范围内，是否是最适合的任务。同时，它还会检查参数列表，看看它是否与任务一致。

某些场景下，比如一些基于上下文任务信息的，或者用户请求无法推断参数的情况，GameGPT采用了一种主动的方法来解决。

Reviewer通过在前端界面上启动提示，并请求参数所需的附加信息来吸引用户注意。

这种交互方法的好处在于，即使在自动推理不足的情况下也能确保论证细节的完整性。

此外，还有另一个智能体负责识别任务之间的依赖关系，并构造一个封装这些关系的图表。在建立该图之后，再采用算法来对该图进行遍历筛选，由此产生一个确定的任务执行顺序。

这个过程确保了模型可以按照任务的依赖关系有序和系统地执行，从而产生连贯和结构化的开发流程。

另一个问题是，使用LLM生成冗长的代码会带来更大的幻觉和出现冗余的风险。为了解决这个问题，研究人员引入了一种新的方法来解耦游戏设计中出现的代码，简化了LLM的推理过程，从而极大程度减轻了幻觉和冗余。

这个方法也并不难理解——研究人员会将预期的脚本划分为许多长度更短的代码片段，以供LLM处理。这种解耦方法大大简化了LLM的工作。

还有一种叫做上下文学习的有效推理方法，也可以有效地减轻幻觉。

此外，GameGPT中应用的另一种消除幻觉的技术，包括为每个任务生成一组K个代码的代码片段。

这些代码片段随后会在虚拟环境中进行测试，并同时呈现给用户。测试过程和用户反馈都被用来识别和消除有问题的代码片段，最终只留下最可行的选项来执行。这种方法同样有助于进一步减少幻觉的发生。

此外，研究人员还有一个内部的库，包含为游戏开发设计的大量代码片段。每一个代码片段都由标签器进行了注释，提供了明确说明其预期目的的说明。

概括一下就是，为了让代码不冗余，不幻觉，开发人员做了两手准备，事前的和事中的。

同时，上面提到的这个库也是对模型进行微调的宝贵资源。代码审查和改进在游戏引擎智能体生成代码之后，代码审查智能体会对代码库进行彻底的审查和检查。

该智能体会进行全面的评估，努力找出任何可能会偏离原始请求的实例，或代码中出现的意外幻觉。

经过彻底的审查，智能体不仅能标记出潜在的差异，而且还能据此提供改进代码的建议，最终产生更为合理的版本。

在审查过程之后，修改后的代码以及智能体的反馈都将通过前端界面与游戏引擎工程师智能体和用户共享。如果用户认为有必要，可以直接通过前端界面提供代码修改建议。

之后这些建议会继续传递给代码审查智能体，它会进行评估，并有选择性的合并这些建议，从而进一步生成一种协作和迭代的方法来增强代码。

最后，一旦代码生成完毕，该干的也都干完了，责任就落到了游戏引擎测试智能体的身上，由这个智能体来负责执行生成的代码。

在这一阶段，该智能体还会遵循在前一阶段所制定的执行顺序。

具体的执行过程包括将每个单独任务的代码发送到游戏引擎，进行执行，并在执行期间持续跟踪，生成日志。

在完成执行序列中指定的所有任务后，智能体会合并整个执行过程中生成的所有日志。

最终，这种编译生成了一个简洁而全面的摘要，再通过前端界面呈现给用户。

此外，测试工程师智能体还会识别并报告在执行过程中观察到的任何回溯情况的出现。这些回溯会作为关键的指示器，指示AI对执行流程或代码进行更进一步的调整，使整个过程得以细化，并有助于生成一个完美的最终产品。

最后，再来看下多个代理同时工作的框架公式：

首先，在GameGPT中，每个代理都有一个私有的记忆系统，并且它们可以访问共享的公共内容，以获取必要的信息来指导其决策过程。

对于时间步长为t的代理i来说，这一过程可表示为：

其中pθi对应的是和代理i相关的LLM或专家模型，Oit表示代理i在时间步长为t时的产出或可交付成果，Mit和Pt分别指截至时间步长t内，所有的私人记忆和必要的公共记录。

由于游戏开发行业的特殊性和大语言模型的局限性，在GameGPT中，具有不同角色的多个代理的存在至关重要。

鉴于游戏开发周期通常长达数月，如果只依赖一个拥有全面记忆和上下文信息的单个代理，语言模型（包括LLM）的效率将大打折扣。

而随着时间的推移，项目变得越来越复杂，这种方法也会带来可扩展性方面的挑战。此外，考虑到LLM所处理的标记数量的限制，在大型游戏开发项目中使用具有全面内存的单独代理并不实用。

还有，在LLMs中观察到的幻觉和冗余等固有问题凸显了多个代理之间协作的重要性，尤其是那些具有批判性角色的代理。

这种协作对于减轻LLM幻觉和冗余带来的挑战意义重大。

因此，GameGPT才利用一系列不同的角色来促进其运作，包括整个游戏开发周期的职责。

这些角色包括上文提到的游戏内容设计师、游戏开发经理、计划审核员、游戏开发工程师、任务审核员，还有游戏引擎工程师、代码审核员和游戏引擎测试工程师。

在整个游戏开发过程中，每个角色都承担着不同的任务。

参考资料：

https://arxiv.org/pdf/2310.08067.pdf