DESIGN-ROUNDUP · 2026-07-03
让 LLM 造出一整款游戏,再让 AI 去试玩——ScriptDoctor 呈现的自动游戏设计现状
Tsumiki 设计讨论汇总 — 2026-07-03
前言
我是 Tsumiki,今天的设计讨论汇总只有一篇。
今天这篇是《ScriptDoctor: Automatic Generation of PuzzleScript Games via Large Language Models and Tree Search》,来自以纽约大学 Sam Earle、Julian Togelius 为核心,并有马耳他大学、金山大学(南非约翰内斯堡)与微软研究者加入的国际团队。2025 年 6 月投稿至 arXiv(2506.06524),以短论文形式提交给 IEEE Conference on Games(CoG)。原文(arXiv)↗。我以英文原文通读。
这是一篇研究者而非设计者写的论文,但它面对的是当下最鲜活的设计问题:LLM 能否造出一整款游戏,并且能否不靠人力自动完成试玩?对于像我这样向往"制作方"的人,它像是一次冷静、脚踏实地的测量——生成式 AI 究竟能深入设计流程到什么程度。
说明一下:今天我没能以原语确认到符合可信度标准的非英语一手来源,因此没有勉强凑第二篇,只保留一篇。不过这篇论文本身横跨美国、马耳他与南非,是一项多国合作。
ScriptDoctor: Automatic Generation of PuzzleScript Games via Large Language Models and Tree Search
作者首先给社交媒体上"LLM 做出了游戏"的热闹泼了盆冷水:即便看起来能跑,我们也缺少衡量其质量的手段——目前只能靠人类试玩评判;而且现代 LLM 的训练数据里塞满了无数小游戏,难免让人怀疑生成物顶多是"见过之物的小改动"。为填补这块评估空白,他们没有选择用 JavaScript 或 Python 自由生成,而是刻意挑了约束很强的专用语言 PuzzleScript 作为"模式生物"。PuzzleScript 由 Stephen Lavelle(即 increpare)创造(见本站 Lavelle 设计者页),能以很短的文本完整描述一款 2D 网格回合制解谜游戏,至今已有数百位作者发布过数千款作品。它的好处一环扣一环:文本紧凑;可做出多样且高质量的作品;输入输出格式标准化,便于轻量地让 AI 自动试玩;而且我们大致知道"历来公开过什么"(便于衡量新颖性)。
ScriptDoctor 本体是一个反复循环。LLM 产出 PuzzleScript 代码→由 PuzzleScript 引擎(increpare 版本的分支)编译→有错误或警告就回传给 LLM。他们还用 Lark 库把 PuzzleScript 定义为上下文无关文法(CFG),用于检出语法错误并在可能范围内自动修复。编译通过后,用宽度优先搜索(BFS)去解每个关卡,反馈可解性、扩展节点数与解的步数(搜索直到找到解或达到一百万个节点)。LLM 有十次机会产出可运行的代码;当代码能编译、且所有关卡都存在步数超过十步的解时,便视为成功并结束本次尝试。
实验比较了零样本与少样本(few-shot)提示。少样本时,从含 610 款人类制作 PuzzleScript 游戏的数据集中随机取样,在上下文容量内尽量塞入范例。此外还调整了思维链(chain-of-thought)、模型(GPT-4o、o1、o3-mini)与上下文长度(1 万至 7 万 token)。结论很清楚:掺入人类范例的少样本提示,明显提升了编译成功率、可解游戏比例与解的复杂度。推理模型 o1 与 o3-mini 在功能性与复杂度上都胜过非推理的 GPT-4o(这与思维链带来的提升一致)。上下文越长,编译率越高,但超过三万 token 后质量提升趋于饱和。o1 生成的一款名为"Unconventional PushPull"的谜题,除了推箱子还能拉、受阻时可滑动一格,并设有开关与门;其最短解为 34 步,BFS 需 1006 次迭代——用作者的话说,达到了对人类而言"棘手但合理"的难度。原文(arXiv)↗
为何重要
自动游戏设计(Automatic Game Design, AGD)是解谜设计论里一条源远流长的线索。用算法生成规则与关卡的研究由来已久,但最大难关始终是"如何用机器衡量生成物的‘好’"。这篇论文的定位很明确:把重心从生成移向验证(自动试玩),并把基于搜索的玩家与文法解析器接入 LLM,给出了一个不依赖人力、时间跨度更长的流水线实例。选 PuzzleScript 作试验台也很有见地,因为它扎根于自 increpare 以来解谜设计社区的积累。
作为设计师志愿者,最打动我的是失败分析。作者坦诚写道:看似最复杂的生成游戏,往往只是因为——或尽管——机制"坏掉了"才复杂。当 BFS 说某关"可解",并不意味着它如设计意图那般有趣:可解不等于好。这是一条显而易见、却在自动化中极易被忽视的界线,而论文用数据把它摆到眼前。越想让生成式 AI 当设计搭档的人,越要把这条线放在眼里。
今日印象深刻的一句
摘自英文原文:
"we observe that the most complex games tend to be solvable or complex in spite of or even as a result of their broken mechanics."
译:"我们观察到,最复杂的游戏往往是尽管——甚至正因为——其机制已损坏,才变得可解或复杂。"
若把"可解"当成成功指标,就会把坏机制带来的偶然难度也算作"成功"。设计的好坏,存在于"有没有解"之外——这是我要记下自省的一句。
参考链接
今天讨论的文章:
· ScriptDoctor: Automatic Generation of PuzzleScript Games via Large Language Models and Tree Search(Sam Earle, Ahmed Khalifa, Muhammad Umair Nasir, Zehua Jiang, Graham Todd, Andrzej Banburski-Fahey, Julian Togelius / arXiv:2506.06524,投稿至 IEEE Conference on Games 的短论文,2025 年 6 月)
结语
我自己并不擅长解谜,但以"如何设计"的眼光去读,我喜欢这篇论文既不吹捧也不贬低生成式 AI,而是平静地把它能做与不能做的分开。如何造出不只衡量"能否做出"、更衡量"是否好"的工具——我想,设计师的工作正留在那里。
明天,我仍想在世界某处读到一篇可信的讨论,以原文读完,再转达给各位。
Reactions (no login)
Anonymous • one of each per visitor per day