OpenGame:面向游戏开发的开放式智能体编程框架 OpenGame: Open Agentic Coding for Games
首个端到端网页游戏生成智能体框架，含Game Skill与GameCoder-27B。
前置知识
智能体编程 (Agentic Coding)
指由LLM驱动的智能体在多文件、多工具、长时程任务中自主完成软件工程任务的范式。智能体通过工具调用迭代地规划、子任务分解与自我修正，需维护todo、状态与跨文件一致性，与一次性代码补全有本质区别。
OpenGame正是典型的智能体编程系统，它在六阶段流水线中使用run_shell_command、read_file、write_file等工具完成scaffolding→design→assets→code→verify的循环迭代；理解智能体编程的迭代与状态管理是阅读方法部分的前提。
Phaser 3 游戏引擎
Phaser是基于JavaScript/TypeScript的开源2D网页游戏框架，提供scene生命周期、physics、asset loader、input、camera等高层API。整个游戏可用纯文本代码表达且不依赖二进制资源序列化，被认为是LLM友好型引擎。
理解Phaser的多文件结构（scene class、preload/create/update生命周期、物理body与collider的耦合、asset key的全局注册）是看懂OpenGame为何必须解决"跨文件不一致"问题的基础；这也是论文为何把目标锁死在Phaser而非Unity/Unreal的原因。
三阶段训练管线 CPT + SFT + RL
CPT在领域语料上做继续预训练注入知识；SFT在合成的高质量指令-回答对上微调对齐指令；RL在可执行环境中以奖励信号驱动策略优化。OpenGame把三者按顺序叠加到Qwen-3.5-27B上得到GameCoder-27B。
GameCoder-27B的核心贡献正是这条三阶段管线，每个阶段都被独立消融验证（Table 2）。不熟悉这套范式就难以理解论文为何把CPT/SFT/RL按顺序串行叠加，以及为何RL阶段刻意限定在单文件模块而非完整游戏。
执行可验证奖励 (Execution-Grounded RL)
用代码在沙箱中是否真的运行成功、单元测试通过率等可执行信号作为RL奖励信号的方法。与RLHF不同，这种奖励是确定性的、可自动计算的、且不易被看似合理但无法运行的输出hack。
这是GameCoder-27B能从"会写代码"变成"会写能跑的代码"的关键设计，也是论文消融中RL阶段为Visual Usability和Intent Alignment同时带来增益的来源；理解执行奖励的稀疏性才能体会为何作者限制在component-level而非whole-game级别做RL。
模板方法模式 (Template Method Pattern)
面向对象设计模式中的一种：父类定义算法骨架（lifecycle hooks），把可变步骤延迟到子类覆写的hook方法中执行。子类责任只是"在指定扩展点注入游戏特定逻辑"，而不是重写整个算法。
这是OpenGame消融实验中drop最大的一个组件（去掉Hook-Driven实现后Build Health从72.4降至62.3，Intent Alignment从65.1降至53.5），理解这个模式才能体会"约束搜索空间"在长时程代码生成中的决定性作用。
研究动机
尽管LLM驱动的代码智能体在SWE-Bench类单点bug修复、孤立算法题上已接近人类水平，但当任务升级为"从一行自然语言需求产出一个完整可玩的多文件游戏"时，前沿模型普遍遭遇一道"复杂性墙"。论文观察到的失败集中在三类：(1) 逻辑不一致(Logical Incoherence)——智能体在跨scene、跨update tick的全局状态上跟丢主线，导致游戏循环冻结、状态机无法终止、关键机制未实现；(2) 引擎知识缺失(Engine-Specific Knowledge Gaps)——通用模型倾向重写已有抽象，例如抛弃Phaser原生physics而自己手写碰撞，或不正确的使用scene事件系统；(3) 跨文件不一致(Cross-File Inconsistencies)——单个文件读起来合理，但asset key在preload与create scene间不匹配、tilemap JSON与场景配置错位、初始化顺序倒置导致运行时崩盘。配套的评测也是瓶颈：传统软件基准靠静态单元测试pass/fail，对游戏这种"代码能跑≠游戏好玩"的交互系统几乎无效。SWE-Bench等benchmark以单元测试为唯一信号，无法捕捉"画面正常但玩法崩坏"这类静默失败。
本文的目标是本文目标有三：(1) 首次开源一个面向端到端网页游戏生成的智能体框架OpenGame，从自然语言设计说明直接产出可构建、可执行、可玩的多文件Phaser 3项目；(2) 提出Game Skill这一可演化能力——由可生长的Template Skill模板库L与可累积的Debug Skill调试协议P组成，分别解决"项目骨架从哪里来"和"集成错误怎么系统修复"两个根本问题；(3) 训练专门的代码基座模型GameCoder-27B（基于Qwen-3.5-27B）并发布OpenGame-Bench评测体系（150个跨5种游戏品类的提示，三维指标：Build Health、Visual Usability、Intent Alignment），让社区能复现、可比较地推进"LLM做游戏"这一方向。
与已有工作不同的是，切入角度的核心是"把生成从单点补全升级为带结构化先验与可累积经验的工程化流水线"。已有工作或在通用代码模型上做零样本生成（失败模式已知）、或如GameDevBench只把游戏作为评测载体而不提供生成框架。OpenGame的差异化在于把"模板即抽象、调试即经验"做成可被算法迭代的two-skill模块：模板库从M0(单一游戏无关元模板)随任务完成度自动长出5个稳定家族（gravity-based side view, top-down continuous motion, discrete grid logic, path-and-wave dynamics, UI-driven gameplay），调试协议从静态清单升级为可读写的living protocol P，每条entry包含signature/root cause/verified fix三段。这种"经验可沉淀"的agent evolution路径，与SWE-Agent、qwen-code、Cursor等通用框架强调的"通用工具链+强模型"路线形成鲜明对比。
核心方法
OpenGame的设计哲学是"领域专用模型+可演化技能+结构化智能体"三者耦合。基座是Qwen-3.5-27B（$27\text{B}$参数）经过CPT（Phaser/JS代码库+文档+社区教程，约数十万到百万级规模语料）、SFT（GPT-5.1合成设计指令 + MiniMax-2.5产出参考实现）、RL（单文件模块在执行沙箱中按测试通过率给奖励）三阶段训练得到的GameCoder-27B。智能体在六阶段流水线中运行：①初始化与Physics-First分类（按物理约束而非模糊genre选模板家族）→②scaffolding（从模板库 $\mathcal{L}$ 复制shared core + 模块子目录 + docs）→③生成Game Design Document(GDD)→④多模态asset合成（背景/角色/音频/tilemap）→⑤context-aware代码实现（Three-Layer Reading Strategy + Template Method覆写hook）→⑥build/test/render headless验证与bounded iterative自修正（最大迭代次数 $T$）。两条Game Skill在多轮任务中持续进化：Template Skill维护可生长的模板库 $\mathcal{L}$，Debug Skill维护可累积的living debugging protocol $\mathcal{P}$，二者通过经验回收闭环把"高发集成错误"逐步抽象为可复用规则。
核心创新是把"跨文件一致性问题"显式拆成两个可被算法迭代的能力：Template Skill以"家族化模板"压缩生成空间（让智能体只需在hook里注入游戏特定逻辑，而不是每次重写游戏循环），Debug Skill以"living protocol"形式让调试经验以 $(\sigma, r, f)$ 三元组（其中 $\sigma$ = error signature, $r$ = root cause, $f$ = verified fix）形式累积并被后续任务直接调用。这与已有工作的本质区别在于：(a)对比SWE-Agent/qwen-code/Cursor等通用框架——它们给模型完整工具链自由，但不对结构化项目骨架做任何假设，于是每次都要重新发现Phaser该有的scene wiring；OpenGame通过模板把"必须正确的部分"先行固定下来，让模型精力集中在"可以变化的部分"。(b)对比零样本LLM生成——后者在多文件项目里几乎注定因asset key/scene wiring/config字段错位而崩，OpenGame的Debug Skill把这种错误变成"高发模式"并以pre-execution check的形式前置拦截。(c)GameCoder-27B与现有代码LLM的区别是它专门在Phaser多文件项目上做过component-level RL，使生成的单个文件在单元测试层面就有更高的执行可靠性。
方法步骤详情
完整方法由"模型训练+智能体workflow+技能演化"三部分组成，运行时按六阶段流水线执行。(1) 基座训练：CPT阶段在GitHub上的Phaser/JS/TS开源项目+官方文档+社区教程语料上做继续预训练，建立game loop、physics、asset、state management的先验；SFT阶段用GPT-5.1合成多步设计指令(例如"实现带二段跳与sprite动画的2D平台跳跃角色控制器")，再由MiniMax-2.5生成高质量参考实现蒸馏成指令-代码对；RL阶段限定在单文件模块(碰撞检测、状态机转换等)，在执行沙箱中按单元测试通过率给出可验证奖励，避免奖励稀疏。(2) Physics-First Classification：智能体第一步调用classify-game-type，按"物理约束+空间机制"分类(例如"无地面支撑的falling"映射到platformer，"snapping to a grid"映射到grid_logic)，避开genre标签的歧义。(3) Scaffolding：通过run_shell_command把模板库L中选中的T(含shared core + modules/{archetype} + docs)复制到工作区，得到稳定结构baseline。(4) Design Generation：调用generate-gdd，动态加载archetype-specific API约束后产出GDD，并把它分解为todo_write的细粒度文件级动作。(5) Asset Synthesis：读asset_protocol.md后调用generate-game-assets(多模态生成背景/角色动画/静态道具/音频)，tilemap游戏额外调用generate-tilemap把ASCII布局转JSON；最后读asset-pack.json锁定texture/asset key以防下游hallucination。(6) Code Implementation：先把GDD参数merge进gameConfig.json；用Three-Layer Reading Strategy分三层读文件——(i)template system的API summary、(ii)待修改的目标源文件(例如_Template.ts)、(iii)implementation guide最后读以最大化即时显著性；按Template Method覆写hook(如setupCustomCollisions)，保留父类deterministic lifecycle。(7) Verification & Self-Correction：读debug_protocol.md做静态自检→run_shell_command执行npm run build与npm run test(headless browser评测)→若失败，parse编译器输出定位错误脚本→bounded iterative repair(论文消融T=3增益最大，T=5开始饱和)。(8) 技能演化闭环：每次任务后从y中提取"稳定+有用+安全"的fragment merge入L；每次失败把(签名,根因,修复)加入P；P还包含pre-execution validations主动拦截高发错误类(资产key mismatch、config字段缺失、非法scene transition)。算法1给出Game Skill整体执行：select T→scaffold→generate→repeat{verify, repair, append}→optional extract→return。
技术新颖性
技术新颖性体现在四点。第一，把"结构化先验"从prompt级prompt trick提升为可被算法迭代的template library：L不是静态提示词而是会随任务完成度自动abstract出5个稳定家族(gravity-based side view, top-down continuous motion, discrete grid logic, path-and-wave, UI-driven)的活体资产，这种emergent family机制在SWE-agent类工作中不存在。第二，把"调试"从临时上下文做成可写可读的living protocol P：每条entry三元组(signature, cause, fix)结构化、可搜索、可复用，且P包含pre-execution validation把高发问题拦截在编译前，这是对"debug as code"思想在多文件游戏场景的具象化。第三，Three-Layer Reading Strategy是工程上对lost-in-the-middle问题的具体解法：在超长context里把"最该被记住的implementation guide"放到最末位置读取，与RAG/中段检索等已有方案相比，约束更轻、不需额外检索器。第四，RL阶段刻意限定在component-level而非whole-game：奖励信号是单文件测试通过率而非端到端可玩性，既绕过了"游戏是否好玩"这种近乎不可定义的奖励稀疏难题，又确保组合的积木本身可靠；Table 2证明这一受限RL仍能为Intent Alignment和Visual Usability同时带来增益，验证了"自下而上RL+自上而下模板"的协同效应。
实验结果
在OpenGame-Bench(150条跨platformer/top-down shooter/arcade/strategy/puzzle五个品类的提示)上系统评测，全部报告valid runs上的均值，每条任务跑3个不同随机种子。主结果(Table 1)：OpenGame w/ Claude Sonnet 4.6后端取得BH=72.4, VU=67.2, IA=65.1的新SOTA，比最强基线Cursor(w/ Claude 4.6)的66.8/61.4/58.9分别高5.6/5.8/6.2个点，最大相对增益出现在Intent Alignment(+6.2)，说明结构化规划+模板脚手架+迭代验证能更好保留用户指定机制而非hallucinate引擎行为。GameCoder-27B独立成绩为63.9/57.0/54.1，在Build Health和Intent Alignment上超过全部direct LLM(开闭源)基线，并能在BH和VU上反超qwen-code (w/ Claude 4.6)的63.2/54.3，仅在IA上落后3.7。三指标trade-off：视觉强模型(Gemini 3.1 Pro)VU领先60.2但IA仅42.1；代码专用模型(DeepSeek V3.2)BH=57.0但VU/IA偏弱——说明静态pass/fail会掩盖质性差异。消融Table 2(训练管线)：Qwen-3.5-27B基线62.8/53.8/49.8，+CPT 63.2/54.7/50.6(BH提升主因)，+SFT 63.5/55.7/52.5(IA +1.9最大)，+RL到full 63.9/57.0/54.1(VU/IA进一步提升)。消融Table 3(workflow机制，固定Claude 4.6)：去掉Hook-Driven实现后BH由72.4→62.3(-10.1)、IA由65.1→53.5(-11.6)跌幅最大；去掉Three-Layer Reading后IA由65.1→56.5(-8.6)印证lost-in-the-middle问题；去掉Physics-First Classification后IA由65.1→61.6(-3.5)相对最小但仍非平凡。消融Table 4(Game Skill成熟度)：从Static Skeleton+Static Checklist 60.5/54.8/51.2→Full Library(5 Families)+Full Living Protocol 72.4/67.2/65.1，模板从M0到L的演化贡献+11.9 BH、+12.4 VU、+13.9 IA；Full Living Protocol相比Post-Execution Fixes Only在BH上+2.9、IA上+3.7，说明pre-execution validation贡献真实存在。Figure 3(调试迭代次数T)：T=0时BH=58.4(零生成已脆弱)，T=1→3区间BH从约65升到约70，IA从约50升到约60，T=3到T=5增益开始饱和——bounded iterative repair是关键但有上限。Figure 4(按genre拆IA)：OpenGame在physics-centric品类最强——Platformer 76.8、Top-Down Shooter 71.4、Arcade 66.5，在Strategy 58.2和Puzzle/UI 52.6上退化明显，原因是状态机/规则类游戏错误不触发编译告警与运行时崩溃，VLM/judge难以捕捉。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| OpenGame-Bench 端到端网页游戏生成 (150 prompts) | Build Health (BH, 越高越好) | 72.4 (OpenGame w/ Claude Sonnet 4.6) | Cursor w/ Claude 4.6 = 66.8; qwen-code w/ Claude 4.6 = 63.2; Claude Sonnet 4.6 直出 = 58.5; GPT-5.1 = 57.4; DeepSeek V3.2 = 57.0 | 比最强agentic基线Cursor +5.6 BH, 比最强direct LLM Claude 4.6 +13.9 BH, 创新SOTA |
| OpenGame-Bench 端到端网页游戏生成 (150 prompts) | Visual Usability (VU, 越高越好) | 67.2 (OpenGame w/ Claude Sonnet 4.6) | Cursor w/ Claude 4.6 = 61.4; Gemini 3.1 Pro 直出 = 60.2; qwen-code w/ Claude 4.6 = 54.3; Claude 4.6 = 50.8 | 比最强agentic基线Cursor +5.8 VU, 比最强direct LLM Gemini 3.1 Pro +7.0 VU |
| OpenGame-Bench 端到端网页游戏生成 (150 prompts) | Intent Alignment (IA, 越高越好) | 65.1 (OpenGame w/ Claude Sonnet 4.6) | Cursor w/ Claude 4.6 = 58.9; qwen-code w/ Claude 4.6 = 57.8; Claude 4.6 = 50.3; GPT-5.1 = 49.4 | 比最强agentic基线Cursor +6.2 IA, 比最强direct LLM Claude 4.6 +14.8 IA, 三指标中相对增益最大 |
| GameCoder-27B 独立配置 (vs 开源direct LLM) | BH / VU / IA | 63.9 / 57.0 / 54.1 | DeepSeek V3.2 57.0/38.9/33.5; Kimi K2.5 45.6/46.8/44.6; Qwen-3.5-Max 51.8/35.5/38.9; GLM-4.5 46.5/45.0/31.2; MiniMax m2.5 39.7/39.3/31.8 | 在BH/IA上反超所有direct LLM(闭源+开源)，VH/IA超过Claude 4.6/GPT-5.1直接输出，验证了专用训练+框架的组合价值 |
| 训练管线消融 (Qwen-3.5-27B→GameCoder-27B) | BH / VU / IA (固定OpenGame框架) | +CPT+SFT+RL = 63.9 / 57.0 / 54.1 | Base 62.8/53.8/49.8; +CPT 63.2/54.7/50.6; +CPT+SFT 63.5/55.7/52.5 | 三阶段累加带来 +1.1 BH, +3.2 VU, +4.3 IA, SFT对IA贡献最大(+1.9), RL对VU/IA贡献最大(+1.3/+1.6) |
| Agent workflow消融 (固定Claude 4.6) | BH / VU / IA | Full = 72.4 / 67.2 / 65.1 | w/o Hook-Driven 62.3/57.6/53.5; w/o Three-Layer Reading 67.8/61.9/56.5; w/o Physics-First Classification 70.2/64.6/61.6 | Hook-Driven是workflow最大约束来源(去后BH -10.1, IA -11.6); Three-Layer Reading防止lost-in-the-middle(IA -8.6); Physics-First Classification对IA -3.5 |
| Agent Evolution (Game Skills) 消融 | BH / VU / IA | Full Library (5 Families) + Full Living Protocol = 72.4 / 67.2 / 65.1 | Static Skeleton (M0) + Static Checklist 60.5/54.8/51.2; M0 + Full Living Protocol 65.4/59.2/56.3; Full Library + Static Checklist 66.3/60.7/57.9; Full Library + Post-Execution Only 69.5/63.8/61.4 | 模板演化+完整调试协议相比静态基线带来 +11.9 BH, +12.4 VU, +13.9 IA, Full Living Protocol相比Post-Execution Only额外 +2.9 BH, +3.4 VU, +3.7 IA |
| 调试迭代次数T对性能的影响 | BH / VU / IA vs T | T=5时 BH≈75, VU≈70, IA≈67 (估读论文图) | T=0 (零样本) BH=58.4, VU≈48, IA≈45 (估读) | T从0→3带来最大增益, T>3开始饱和, 证明bounded iterative repair的有效性与边际成本 |
| 按游戏品类拆解IA | Intent Alignment (5 genres) | Platformer 76.8; Top-Down Shooter 71.4; Arcade 66.5; Strategy 58.2; Puzzle/UI 52.6 | Cursor (Claude 4.6) 同五品类大致 64.5/70.1/58.2/47.8/约45区间 (估读图4) | physics-centric品类领先最大(Platformer +12.3 IA), 抽象逻辑类(Strategy/Puzzle)领先收窄, 暴露silent state bug检测的评测瓶颈 |
局限与改进
作者明确承认的局限：(1) 即使是full OpenGame配置，weighted mechanical requirements仍约有34.9%被部分或完全未满足，说明自然语言→自洽可玩多文件系统的鸿沟远未填平；(2) 评测pipeline本身要求至少一次非空截图才计为valid run，因此彻底死掉的项目不进入均值，可能掩盖极端失败模式；(3) 评估锁定在Phaser 3 2D web游戏，泛化到3D/Unity/Unreal等binary-rich引擎的能力未被验证；(4) 调试迭代T>3后增益饱和但仍消耗token预算，存在效率上限。作者未深入讨论但从数据可见的局限：(a) VU与IA只在physics-centric品类同向增长，在Strategy/Puzzle这类"无显式几何"的品类上，模板家族的覆盖明显不足(只有5个family，UI-driven和discrete grid可能并不足以表达棋类/匹配类游戏的复杂规则)；(b) OpenGame-Bench依赖VLM judge评VU和IA，VLM本身对"游戏是否好玩"的判断可靠性未被量化，存在judge bias风险；(c) GameCoder-27B在闭源模型加持下增益仍来自框架(72.4 vs 65.1差7.3)，而专用模型自身(63.9)与最强direct开源(DeepSeek V3.2 57.0)差6.9——说明模型规模与RL成本投入的边际产出需要更多ablation数据来回答；(d) Debugging protocol P的append机制没有去重与冲突解决策略，长期演化可能积累冗余甚至矛盾规则。
独立分析的弱点
弱点1：模板家族覆盖与品类不匹配。从Figure 4看OpenGame在Strategy(58.2)和Puzzle/UI(52.6)上的IA远低于Platformer(76.8)，原因是当前L只覆盖5个由物理机制聚类出的家族(gravity-based side view, top-down continuous motion, discrete grid logic, path-and-wave, UI-driven)，对"棋类规则演化""库存/合成逻辑""多回合状态机"等抽象品类缺乏对应的稳定骨架。改进方向：把模板抽象从"物理机制聚类"扩展到"状态机复杂度聚类"，例如把回合制/资源管理抽象为独立家族；并把L的演化做成可被外部监督的版本管理(M0→L_v1→L_v2)便于诊断退化。弱点2：Living protocol P的工程健壮性。P以(error signature, root cause, verified fix)三元组累积，但论文没有给出冲突解决(同一错误的不同fix)、过期清理(框架升级后旧fix失效)、优先级排序(高频vs低频)的算法，长期运行易积累矛盾与冗余。改进方向：借鉴知识库版本的best practice——给每条entry加confidence score与last-validated timestamp，做周期性pruning与冲突合并测试；甚至把P的维护本身作为一个RL子任务(评判"fix是否被再次需要")。弱点3：评测指标的judge依赖与天花板。VU和IA完全依赖VLM judge，judge对"游戏是否好玩""机制是否完整"的标准本身存在主观性，且对silent logic bug(图4中Strategy/Puzzle退化)几乎无能为力。改进方向：补充基于符号执行的mechanism probe——对每个requirement自动合成input trace并验证代码中是否真存在对应分支；以及基于可玩性日志的客观信号(平均session时长、玩家输入分布熵)作为IA的补充维度。弱点4：训练数据的合成循环风险。SFT数据由GPT-5.1合成prompt + MiniMax-2.5生成solution蒸馏而来，存在模型间bias传递；RL也只对单文件模块做，未必能泛化到多文件耦合错误的修复。改进方向：引入human-in-the-loop review对synthetic SFT数据做质量抽样；并把RL扩展到whole-game级别(以T次迭代后是否通过build/test作reward)虽然稀疏但可能带来质的飞跃。
未来方向
作者提出的方向：(1) 把OpenGame框架扩展到更复杂的游戏品类(3D、回合制策略、开放世界)，需要新模板家族与新asset pipeline；(2) 提升对silent logic bug的检测能力，把P从纯文本协议升级为可执行的pre-flight checker集合，并引入基于符号执行或property-based testing的mechanism verification。基于成果可延伸的方向：(a) 可解释的Debug Skill——当前P是黑盒文本，未来可以把每条entry挂上"在什么模板家族、什么archetype、什么asset key下触发"的元数据，使debug决策可追溯可审计；(b) 跨引擎迁移——把模板库L从Phaser扩到PixiJS/Kaboom/PlayCanvas时，研究哪些family是引擎无关的(物理优先分类)、哪些是引擎绑定的(scene wiring)，这本身就是有趣的元学习问题；(c) 多智能体协作——当前是单智能体六阶段流水线，可以拆为designer/asset/developer/QA四个角色用OpenGame-style协议通信，模拟真实游戏工作室的分工；(d) 与人类设计师的协同创作——把GDD从一次性产出变成迭代可编辑对象，让人类设计师在scaffolding后注入创意，模型负责完成实现与回归测试；(e) OpenGame-Bench v2——把judge替换为多模型ensemble与人类spot-check混合，并加入对抗性prompt(故意模糊/矛盾的requirement)以测鲁棒性；(f) 可玩性驱动的RL——把人类真实玩家会话数据作为reward源，做preference-based RL，把"游戏是否好玩"从VLM judge的近似提升为更可靠的信号。
复现评估
开源情况：论文明确承诺OpenGame将"fully open-sourced"，包括框架代码、GameCoder-27B模型权重、OpenGame-Bench评测pipeline与150个prompt。数据规模：CPT使用GitHub上开源Phaser/JS/TS项目+官方文档+社区教程，论文未给精确token数但描述为"large-scale"；SFT合成数据由GPT-5.1(curate prompt) + MiniMax-2.5(produce solution)生成；RL训练语料为单文件模块级，量级未披露。算力要求：GameCoder-27B基于Qwen-3.5-27B，CPT+SFT+RL三阶段总训练成本论文未给具体GPU小时数，但27B级模型在8×H100/A100上做CPT+SFT+RL通常需要数周；推理侧OpenGame w/ Claude 4.6是闭源API调用(成本可接受)，GameCoder-27B w/ OpenGame可在单台8卡A100/H100上自托管。复现难度：中等偏上。算法层面Game Skill(Template Library + Living Protocol)、六阶段workflow、Three-Layer Reading Strategy描述清晰，OpenGame-Bench的headless browser+VLM judge管线也可重建；但(1)GPT-5.1+MiniMax-2.5的合成数据受限于闭源模型的snapshot与seed，复现时合成的SFT数据可能与原版存在分布差异；(2)L和P的演化是随任务累积的，论文未公开"完整L_v_final"和"完整P_v_final"的具体内容(只给五个family名)，复现者需自行跑任务回收；(3)VLMEvaluator(用于VU和IA)未明确指出是哪个VLM(疑似GPT-5.1或类似强VLM)，评测稳定性受此影响。建议复现路径：先复现Table 1中"OpenGame (Claude 4.6)"配置(只需API+框架代码)，再尝试用GameCoder-27B替换后端，最后挑战训练自有GameCoder变体。论文给的ablation设计良好(Qwen-3.5-27B基线 + CPT/SFT/RL逐步叠加)便于研究者定位自己的改进点。
论文图表
展示三个真实用户场景的端到端游戏生成：教师想要"学生通过游戏与课程互动"(生成K.O.F.: Celestial Show教育类游戏)、玩家想要"基于漫威宇宙的boss战游戏，每个英雄有独特技能"(生成Marvel Avengers: Film Lover 2026动作类)、YouTuber想要"用最热meme做游戏吸引流量"(生成Hajime Defense: The Tuna Crisis塔防类)。图右列出生成的三个项目名：Marvel Avengers, Film Lover 2026, Infinity Strike, K.O.F., Hajime Defense, The Tuna Crisis等。
让读者直观感受"自然语言→多文件可玩游戏"这条端到端流水线的输出质量与多样性，确立论文要解决的具体问题域(教育/动作/塔防等多品类)。