A2Z GameSpec-Bench: How Faithfully Can Coding Agents Generate Games from Game Design Specifications?
Seonho Lee, Wonryeol Jeong, Alberto Cereser, Inha Kang, Hyeonjong Kim, Seungmin Kwak, Dongmin Park
cs.AI
2026-09-30
KRAFTON 发布 100 份长 GDD 游戏生成基准,源码、回放、playtest 三轴评估;最强 agent 忠实度 77 分,需求级反馈较自修订高 10.9%。
把完整应用交给 coding agent,瓶颈已经从「写不写得出来」移到「做出来的是不是设计师要的那个」。游戏是这个问题最硬的试金石:长篇 GDD(游戏设计文档)里大量规则互相咬合,游戏逻辑、渲染表现、玩家交互要同时成立,一条规则没实现,下游规则可能根本没机会触发。
现有游戏生成基准测不到这一层。论文对比的八个同类基准里,输入规格最长的 GameCraft-Bench 约 7,998 token,最短的 PlaytestArena 只有 84 token;A2Z GameSpec-Bench 的 GDD 平均 20,191 token。评估也大多单轴。论文自己的例子:Siege Deck 2D 里「满 30 张牌先移除一张再给奖励」,源码检查拿满分,实际游玩时奖励照发、移除被跳过。游戏设计文本还特别因果:三个游戏设计语料平均 38.4% 的句子被 CiRA 判为因果句,一般文档是 28%。需求依赖是常态,独立打勾式评估盖不住。
基准分三层。
关键设计是把「验什么」(冻结契约)和「怎么验」(Test Policy)拆开,判决和证据都挂回具体需求。这既保证跨 agent 可比,也让评估输出直接变成修订反馈。
九个模型各建全部 100 个游戏,每 GDD 三个 build、每个 build 独立判三次:
| 模型 | GDD Fidelity | Small | Big |
| Claude-Fable-5.1 | 77.0 | 82.8 | 71.1 |
| Claude-Opus-5 | 73.9 | 80.9 | 66.8 |
| GPT-6-Astra | 71.6 | 78.5 | 64.6 |
| GPT-5.5 | 63.2 | 73.1 | 53.4 |
| Kimi-K2.7 | 39.5 | 51.4 | 27.5 |
对把整个应用交给 agent 的团队,结论直接:编译通过是最弱的信号,近 94% 的可运行率与最多 40 分档的忠实度差距并存。单轴评估还会扭曲排序,去掉源码轴后同一 agent 的 build 间排序有 20.5% 翻转。冻结契约加 Test Policy 的结构可以直接搬进自己的流水线当 QA 与修订回路:需求级证据指哪改哪,比让 agent 自己重读文档多涨 7.3 分。这是基准加评估方法论的工作,不训模型。
主实验锁死在 2D 单人 Phaser 游戏,3D 扩展只有 GPT-6-Astra 的三个 Three.js 案例,没有规模化分数。GDD 是自家流水线合成的考题,不是真实工作室文档,校验再严,代表性仍取决于生成管线。裁判是 GPT-5.6-Luna,源码轴与参考判决的 Pearson 相关只有 0.72(回放轴 0.85),三轴分歧也说明源码轴本身有噪声:25.7% 源码零分的规则在 playtest 里被确认满足。正常游玩的判决覆盖率只有 40.5%,其余要靠对抗初始化「助攻」才验得到,助攻虽在 trace 里标注,计入方式值得复核。三轴等权是默认选择而非结论,前三名对权重不敏感,但 36 个模型对序关系里只有 30 个在全权重域上不变。