论文导读 · 2026-07-22
Johnson 等人：嵌入大型语言模型后，游戏会发生怎样的变化 — Fukai 解读
嵌入 LLM 的游戏开发，与游戏玩法、可玩性、玩家体验
一段总结
加拿大卡尔加里大学的 Johnson 等人制作了两款游戏，将大型语言模型(LLM，即通过学习海量文本、能够生成文章或回答问题的 AI)不是作为「事后添加的装饰」，而是嵌入到游戏结构本身之中，并记录、分析了这一开发过程的体验。他们提出的问题非常简单——嵌入 LLM 之后，游戏玩法、可玩性、玩家体验会发生怎样的变化？
结论一言以蔽之：LLM 一方面能产生「每次都不同的内容」与「因人而异的体验」，另一方面也带来了正确性、难度平衡、整体一致性这类新的负担。由于生成的内容与游戏规则的推进直接挂钩，错误的输出会直接转化为不公平或扫兴的体验。开发者们通过把 LLM 的输出强行纳入固定格式、并在中间插入验证机制，才勉强维持住了游戏可玩的状态。
先说明一点：这是尚未经过同行评审的 preprint(刚刚提交、尚未经过专家审阅的稿件)，也尚未进行以玩家为对象的验证。请在「这终究是对『制作者本人的回顾』进行系统性解读的研究」这一前提下阅读本文。
引言
本论文为 arXiv preprint 2603.27896，投稿于2026年3月29日，领域为 cs.SE(软件工程)。作者共6人：Keeryn Johnson、Muhammad Ahmed、Charlie Lang、Sahib Thethi、Wilson Zheng、Ronnie de Souza Santos，均来自卡尔加里大学。原稿是以 ACM 会议的格式撰写的，但并非被某个具体会议接收的 peer-reviewed(同行评审)论文，目前仍是 preprint(同行评审前)状态，这一点需要先说明清楚。
我今天选择这篇论文的理由如下。关于把 LLM 用于游戏的话题，展示「能做到什么」的演示可谓多如牛毛。但冷静回顾「实际嵌入游戏骨架之后，开发与游玩的手感会如何发生变质」的记录，却出乎意料地稀少。这篇论文并非提出什么华丽的新技术，而是仔细解读了真正做出两款游戏的学生们的内省，非常贴近制作者明天就会碰到的现实。因此我判断它有翻译介绍的价值。
背景
在游戏研究领域，游戏玩法(gameplay)、可玩性(playability)、玩家体验(player experience)这三个概念一直被视为关键。借用论文的整理：游戏玩法指「玩家及其他存在能够在虚拟世界中进行的一系列活动」；可玩性指「游戏中易用性(usability)的具体化——能够以多好的质量完成这些活动」；玩家体验则指「游玩过程中所产生的沉浸感、乐趣与反应」。
论文首先指出，传统软件是以「是否正确运作(functional correctness)」与「是否易用(usability)」来衡量的，但游戏以乐趣与娱乐性为主要目的，仅凭一般软件的尺度是不够的。近年来，LLM 便是在这样的背景下被引入进来。此前，LLM 已被用于内容自动生成(PCG，Procedural Content Generation，即用程序生成关卡、道具等内容)、对话系统，以及由人类与 AI 协作推进开发的「混合主导(mixed-initiative)」等场景，人们已经报告过它在变化性与个人化方面的优势，以及在不可预测性、一致性、评估难度方面的课题。
但作者们指出的空白在于以下这一点——「在开发过程中嵌入 LLM」这件事，与游戏玩法、可玩性、玩家体验这些已经确立的概念之间存在怎样的关系，此前几乎没有被正面审视过。应用案例的目录固然在不断增加，但「嵌入如何重新塑造结构」这一问题却近乎无人触及。本文的目的，正是要从制作者的第一手体验出发，填补这一空白。
研究方法
研究方法为「协作式自我民族志(collaborative autoethnography)」。这是一种质性方法，不是由外部的研究者进行观察，而是由当事人自己记录自己的实践并加以系统分析(自我民族志，即把自身经验作为资料写下来、并从中读取共通模式的写作方式)。在本研究中，学生开发者们记录下自己把 LLM 嵌入游戏的体验，再透过构成概念(construct)的视角来解读这些记录。
研究对象是两款游戏，分别产生于一门本科课程(3个月)与一个研究项目(6个月)，共有7名学生参与开发，其中5人是本论文的共同作者。嵌入 LLM 是必要条件，被用于对话生成、剧情分支、NPC(非玩家角色)行为以及 PCG。所使用的模型来自 Google Gemini 与 OpenAI。数据由5篇内省叙事(每篇约2页)、加上设计资料与代码构成。分析方法结合了主题阅读(通读 narrative、找出反复出现的主题)与内容分析。
第一款游戏 Wizdom Run 是用 Unity 制作的「一边学习一边游玩」的 RPG。玩家将自己的学习笔记以 PDF 形式导入后，LLM(OpenAI)会读取这些内容，并生成三个难度等级的多项选择题。题目会被整理成 JSON 这一固定格式，保存到 PostgreSQL(数据库)之中。在普通战斗中，答对会恢复施放法术所需的法力，答错则会限制行动。Boss 战则采用回合制卡牌系统，答对会转化为增益或能力。第二款游戏 Sena 是一款学习软件工程可持续性的游戏，由 LLM 负责对话中的补充说明、情境解读与反馈生成，并拥有会随决策而改变的状态模式。两者都是把 LLM 作为「结构部件(architectural component)」、而非「辅助工具」嵌入进去的。
顺带说明一下，这篇论文中并未出现数学公式或统计模型。它不是数值实验，而是以制作者的话语作为主要资料的质性研究。因此，以下我也将以概念与具体例子来介绍，而非依靠数字。
研究发现
对游戏玩法的影响。生成的内容不再是「有没有都无所谓的叙事装饰」，而成了与规则执行、进程推进直接挂钩的部件。某位参与者(P1)表示，出题「直接驱动着技能点恢复、Boss 战、关卡进程，是游戏玩法的核心」。与此同时，内容会随输入而每次改变。P1 写道：「代码本身基本没变，但每一场战役(campaign)却变成了完全不同的体验」；P2 写道：「问题和答案每次都会改变」。不过，这种变化并非无限的。P5 表示：「反复使用同一份资料时，出现的大体是同一类问题」，这说明生成的多样性会受到设计的制约。
对可玩性的影响。作为灵活性的代价，系统需要「封装(containment)」以防止自身崩坏。P1 表示：「通过把 LLM 的响应整理成预期的格式，使后端设计得以保持一致」；P4 也表示，通过明确返回值的格式，「才能在游戏的 C# 端生成对象」。难度的校准同样成了一处紧张点。P3 报告称：「原本为 medium 或 hard 难度生成的问题，有时候感觉起来却像 easy 的题目(原文：felt like the easy set)」，导致进程的平衡被打乱。正确性则直接关系到公平性。P2 回忆道：「明明出的是简单的计算题，却没有一个选项是正确的(原文：none of the answer options were correct)」；P5 则谈到错误输出时表示：「玩家并非在学习，而只是变成在揣测 AI 的思路，这损害了体验」。此外，P3 还指出「正确答案多次出现在同一个选项位置上」，并警告这可能会催生意料之外的攻略手段(漏洞)。
对玩家体验的影响。个人化确实有所增加。P2 表示：「玩家可以尝试的话题是无限的」；P4 则对对话功能评价道：「玩家可以补充语境后再重新提问」。但体验的质量，取决于变化性与可预测性之间的平衡。P5 表示：「一定程度的变化能拓宽变化的幅度，但为了让游戏保持公平且可玩，也需要一定程度的可预测性」。当语境设定不足时，系统「就会像一般公开的 LLM 那样作答，甚至根本不判断问题是否切题(原文：answer like any publicly available LLM)」——P4 的这句话，很好地体现了一致性与信任崩溃的瞬间。
需要再三提醒的是，以上这些全部都是开发者的内省，正确率或停留时间之类的数值指标并未出现在本论文中。因此，无法用数字来说明「究竟起到了多大效果」。作者们所展示的，并非效果的大小，而是效果出现的位置与形态。
应用场景
1. 如果你正在制作 Sokoban-like(如仓库番那样的推箱子解谜)或以解的唯一性为生命线的谜题，并打算用 LLM 自动生成关卡——那么应当把「正确性」与「可解性(solvability)」当作游戏玩法上至关重要的性质来对待。论文反复提到的可玩性关键，正是把 LLM 的输出强行纳入固定格式并加以验证的模式(schema)强制。基于同样的思路，务必在 LLM 的输出与玩家之间插入一个求解器(solver，即自动求解并验证的程序)，绝对不能把 P2 所说的「不存在正确答案的题目」推向世界。
2. 如果你在制作问答或冷知识类的超休闲游戏(hyper-casual，即可以轻松游玩的量产型手机游戏)——不要盲目采信 LLM 自己贴上的难度标签。在这篇论文中，就出现过「面向 hard 难度生成的题目却让人感觉是 easy」这种落差。难度最好不是依据生成时的标签、而是依据实际正确率等外部指标来校准。顺序应该是「生成→测量→重新贴标签」，而不是「生成→信任标签」。
3. 如果你在制作以叙事或对话为核心的游戏——请对 LLM 进行 grounding(通过检索或约束把它「束缚」在该作品世界之中)，以防止出现 P4 所报告的「偏离主题、像一般 LLM 那样作答」这种失败。此外，还应把输出固定为 JSON 等模式(schema)，使下游代码(例如 C# 中的对象生成)能够稳定地进行解析。这正是论文中所述、确实有效的做法本身。
4. 无论哪种类型的游戏都通用的一点——检查生成物的模式(例如正确答案总是出现在同一位置这类偏差)，并堵住漏洞。但也不要堵得太过。正如 P5 所说，为了公平性与可玩性，保留「一定程度的可预测性」才是健康的做法。变化性与可预测性，不应偏向任何一端，而应被视为需要有意识去权衡、取得平衡的对象。
局限性
先从作者自己承认的弱点说起。这是一项不追求统计学意义上的普遍化的质性研究，资料规模不大，是在两个本科课程情境下写成的5篇内省。由于是当事人讲述自身的内部视角与自我报告，解释上的偏差与对记忆的挑选性取用很难避免——作者们表示，他们通过多篇内省之间的相互印证(三角验证)、参考设计与代码资料、以及共同作者之间的相互审阅来加以缓解。而最大的保留在于，这终究是开发者的视角，而非玩家所做的独立验证。作者们也将用户研究列为未来的课题。
接下来是我 Fukai 阅读后注意到的几点。第一，本文所处理的两款都是学习/教育类游戏，是「正确性」尤其致命的一类作品。因此，我想谨慎对待把这一教训直接推广到那些以手感与惊喜、而非正确性为优先的纯娱乐解谜游戏上。第二，所使用的模型是 Gemini 与 OpenAI 在某一特定时间点的行为表现。由于模型会随更新而改变行为，把它当作「LLM 的普遍性质」来解读是有风险的。第三，被引用次数目前几乎为零(考虑到这是刚提交不久的 preprint，这也是理所当然的)，还不是经过广泛讨论的知识。而且再次强调，由于没有数值指标，本论文无法用数字来说明效果的大小。
Fukai 的解读
以下先声明这是我个人的解读。我想把这项研究，放在「把生成当作结构、而非装饰来对待」这一潮流之中来看待。用设计批评的词汇来说，把 LLM 放入游戏这项工作，与其说是「添加内容」，不如说更接近于重新划定作者亲手写下的确定性规则、与概率性生成的部分之间的边界线。这篇论文反复展示的是，趣味性的真面目，栖息在提示词设计、模式(schema)、验证这些看似朴素的「管道工程」之中。在华丽的生成表象背后，我认为制作者真正在设计的，正是「把多少交给机器、从哪里开始要靠自己的手来保证」这一边界本身。
结语
写给想看更广阔地图的读者：整体概貌可以参考 Gallotta 等人2024年的「Large language models and games: A survey and roadmap」(IEEE Transactions on Games)作为路线图。应用范围的拓展，则可以通过 Yang 等人2024年的「GPT for games: A scoping review」，以及 Sweetser 2024年的范围综述(scoping review)来把握。把本论文放在这幅地图之中、作为「实际做出两款游戏并加以回顾的第一手体验」记录来阅读，其定位便会更加清晰。接下来，如果作者们预告的玩家参与式验证问世，我会持续关注。生成式 AI 与游戏之间的关系，正在从展示演示的季节，转向设计朴素管道工程的季节。
参考文献
本文所参考的论文与相关资料：
・DOI: 10.48550/arXiv.2603.27896(arXiv 发布，同行评审前的 preprint)
・相关研究：Gallotta 等人「Large language models and games: A survey and roadmap」(IEEE Transactions on Games, 2024) / Yang 等人「GPT for games: A scoping review」(IEEE CoG, 2024)
Reactions (no login)
Anonymous • one of each per visitor per day