一句话定位
GameFactory：用一个预训练开放域视频扩散模型的生成先验加上仅 70 小时的 Minecraft 动作标注数据训练一个可插拔的动作控制模块，通过”风格学习”与”动作控制学习”解耦的多阶段训练，把在 Minecraft 上学到的键鼠控制能力迁移到训练时从未见过的开放域场景，从而”创造新游戏”；同时提出自回归机制支持无限长可控视频生成，并开源 GF-Minecraft 数据集。
背景与定位
现有游戏视频生成 / 神经游戏引擎工作大多是”游戏特定”的：Genie（genie-generative-interactive-environments）、DIAMOND、GameNGen、Oasis 只能在其训练所用的单一游戏（Atari、CS:GO、DOOM、Minecraft）上生成内容；GameGen-X 引入了更丰富的 OGameData，但依然局限于开放世界游戏本身的风格。同期的 The Matrix 与 Genie 2 已经讨论”控制泛化”问题，但仍依赖收集大量高成本动作标注数据来学习场景知识。
GameFactory 的立场是：与其烧钱标注覆盖所有可能场景的动作数据（不可行、也无法真正做到开放域覆盖），不如利用互联网上大量无动作标注但已蕴含丰富生成先验的开放域视频，只用一个小规模、动作标注干净的数据集去训练一个可插拔的动作控制模块。作者选择 Minecraft 作为动作数据来源，理由是其动作空间可自定义、支持逐帧标注、且可用程序化方式采集不带人类行为偏置的数据——论文明确点名批评了基于人类真实操作采集的 VPT 数据集存在动作分布偏置（模型学不到”倒走""原地跳”等罕见但合法的动作）。论文进一步把这一思路概括为一种 Generalizable World Model（可泛化世界模型），并呼应自动驾驶（同一团队的 WorldSimBench）与具身智能领域同样面临的”动作标注数据稀缺”问题。工作发表于 ICCV 2025（Highlight）。
模型架构
- Backbone：一个内部（未开源）的约 1B 参数基于 Transformer 的文本到视频潜空间扩散模型，由更大的预训练视频扩散模型蒸馏得到，具备较强的开放域生成先验；论文未公开该基础模型的具体来源 / 架构细节。VAE 时间压缩比 r=4（1+rn 帧视频压缩为 1+n 个潜帧）。训练 / 生成分辨率 360×640。
- 动作条件建模：连续的鼠标动作 M（yaw/pitch 累积偏移量，相对首帧的绝对偏移作为输入）与离散的键盘动作 K（WASD/space/shift/ctrl）分别处理。
- 因时间压缩，“动作数（rn）“与”潜帧数（n+1）“粒度不匹配，用滑动窗口（窗口大小 w=3）把动作分组对齐到每个潜帧，以捕捉延迟动作效应（如跳跃键会影响后续多帧）。
- 鼠标（连续量）→ 拼接（concat）：分组后的鼠标动作 repeat 到 token 长度，与 Transformer 中间特征沿通道维拼接，再过一层 MLP + 一层时间自注意力。
- 键盘（离散量）→ 交叉注意力（cross-attention）：分组后的键盘 embedding 作为 key/value，视频特征作为 query，类比文本 prompt 的 cross-attention。
- 消融实验（见”评测”Table 1）证实”连续量拼接 + 离散量交叉注意力”的组合最优：拼接保留数值幅度信息，交叉注意力的相似度归一化会削弱这一点；交叉注意力更适合类别型信号。动作控制模块整合进 Transformer block 内部，而非作为外部条件。
- 自回归生成：借鉴 Diffusion Forcing 思路，允许同一批潜帧带不同噪声水平——前 k+1 帧作为无噪声”条件帧”，后 N−k 帧加噪并作为预测目标，一次可生成多帧（而非严格 next-frame 逐帧预测），显著提升长视频生成效率。
数据
- GF-Minecraft 数据集：通过 MineDojo 接口执行预先设计的动作序列（而非人类真实操作）来采集，消除人类行为偏置——把键鼠输入拆解为原子动作并保证均衡分布（含”倒走""原地跳""静止转视角”等人类玩家很少做的动作组合），并随机化每个原子动作的持续帧数以避免时序偏置。
- 规模：共采集 70 小时游戏视频，生成 2,000+ 个带动作标注的视频片段，每段 2,000 帧。
- 场景多样性：预设 3 种生态群系（森林 / 平原 / 沙漠）× 3 种天气（晴 / 雨 / 雷暴）× 6 种时间段（一天开始 / 正午 / 日落 / 夜晚开始 / 午夜 / 日出开始），用多模态 LLM MiniCPM-V 为切分后的视频片段生成文本描述。
- 切片预处理：从完整视频中随机采样连续 k=81 帧的片段（比模型原生生成长度 77 帧略长），采样直到片段总帧数达到原视频总帧数的 n=3 倍。
- 数据集组织（HF 上实际发布）：
data_2003/（含鼠标 + 键盘动作）与data_269/（仅键盘动作），每条含annotation.csv+ 逐帧 JSON（ws/ad/scs/pitch/yaw/pitch_delta/yaw_delta/pos）+ mp4；并提供detection.py（标记无效跳跃帧 / 碰撞帧）与visualize.py（动作可视化）两个处理脚本。 - 测试集：保留采集数据的 5% 作为 held-out 测试集，并按控制类型划出三个子集：only-key（仅键盘）、mouse-small（小幅鼠标位移）、mouse-large（大幅鼠标位移）。
- 训练数据全部来自仿真（sim）环境，未涉及真实世界视频数据；开放域生成能力完全来自预训练视频扩散模型自带的先验，而非额外的开放域动作数据。
训练方法
四阶段流水线（Phase #0 为给定条件，其余三阶段是本文的核心贡献）：
- Phase #0（给定，不训练）：开放域文本到视频扩散模型的预训练（内部已有的 ~1B 模型）。
- Phase #1：LoRA 拟合游戏视频——用 LoRA（rank=128，学习率 1e-4）微调预训练模型以适配 Minecraft 视频风格，其余参数冻结，产出一个专精 Minecraft 风格的模型。
- Phase #2：训练动作控制模块——冻结预训练参数与 LoRA 权重，只训练动作控制模块（学习率 1e-5）。因为风格学习已在 Phase #1 完成，扩散 loss 里能继续下降的部分主要来自动作控制学习，从而让控制模块学到与风格无关的动作控制能力。
- Phase #3：开放域推理——推理时移除 Phase #1 的 LoRA 权重，只保留动作控制模块参数，实现动作控制能力在开放域场景下的泛化。
- 解耦必要性的消融（见”评测”Table 3）：直接在原始参数上训练动作控制（one-phase training）会导致开放域场景下动作跟随能力下降、生成画面出现失真，量化指标全面劣于多阶段训练。
- 训练目标：标准扩散噪声预测 loss（对无动作条件与有动作条件分别为 Eq.2/Eq.3 的 MSE），仅对文本 prompt 使用 classifier-free guidance；推理用 DDIM 采样、50 步。
- 自回归训练细节：与全序列生成保持相同配置（含动作控制），仅噪声水平随帧位置不同；额外对条件帧施加约等于扩散第 15/1000 步噪声水平的小扰动，以缓解长时生成的误差累积。
Infra（训练 / 推理工程）
- 每个训练阶段（LoRA 微调或动作模块训练）耗时约 2–4 天，使用 8 张 A100 GPU，batch size 64。
- 并行策略、精度（fp16/bf16/fp32）、总 GPU-hours 均未披露。
- 推理速度、FPS、延迟等未披露——论文只描述离线的固定长度片段扩散生成（+ 自回归拼接），未声称支持实时交互；基础 1B 模型本身也未开源，第三方无法独立测速。
评测 benchmark
评测指标：Flow-MSE（生成视频光流与参考视频光流的均方误差，衡量动作跟随程度，越低越好）、CLIP-Sim（与文本 prompt 的语义一致性，越高越好）、FID（生成质量，越低越好）。
动作控制机制消融（论文 Table 1，三个测试子集）：
| 键盘控制 | 鼠标控制 | Only-Key Flow-MSE↓ | Mouse-Small Flow-MSE↓ | Mouse-Large Flow-MSE↓ |
|---|---|---|---|---|
| Cross Attention | Cross Attention | 8.67 | 20.46 | 325.18 |
| Concat | Concat | 22.37 | 19.18 | 258.93 |
| Cross Attention | Concat | 7.79 | 18.64 | 249.54 |
（CLIP-Sim / FID 三种组合间差异很小——因为多阶段训练已把风格学习解耦到 Phase #1，各组合共享同一套风格。）“键盘 cross-attention + 鼠标 concat” 组合在三个子集上 Flow-MSE 全部最优，成为最终方案。
多阶段训练 vs 单阶段训练的场景泛化对比（论文 Table 3）：
| 方法 | 域 | Flow-MSE↓ | Domain-Sim↑ | CLIP-Sim↑ | FID↓ |
|---|---|---|---|---|---|
| Multi-Phase | Minecraft | 43.48 | – | – | – |
| Multi-Phase | Open-Domain | 54.13 | 0.7565 | 0.3181 | 121.18 |
| One-Phase | Open-Domain | 76.02 | 0.7345 | 0.3111 | 167.79 |
Domain-Sim 定义为生成视频与原始预训练模型（同 prompt）输出之间的 CLIP 特征相似度，反映开放域先验的保留程度。多阶段训练在开放域场景下 Flow-MSE 更低（动作跟随更准）、Domain-Sim 更高（先验保留更好）、FID 更低（生成质量更好）；定性结果显示单阶段训练在开放域场景出现动作控制能力退化和画面失真。
论文没有与其它开源游戏世界模型（Oasis、GameNGen 等）做同基准的直接量化对比——这些方法本身不支持开放域场景生成，缺乏可比较的统一评测协议。赛车游戏场景迁移（Fig.9）只有定性展示（鼠标 yaw 控制自然迁移为转向控制，非相关按键的响应自动减弱），未给出量化指标。
创新点与影响
- 首个明确聚焦”场景泛化”的可控游戏视频生成框架：把问题从”在某个游戏里生成更好的视频”转向”用小规模游戏数据 + 大规模开放域先验，创造训练时从未见过的新游戏场景”。
- 风格-控制解耦的多阶段训练策略：用 LoRA 承担风格学习、独立模块承担动作控制学习，再在推理时”卸下”风格 LoRA，是一个简单但被消融验证有效的工程技巧；后续 Matrix-Game 明确沿用了本文的动作控制模块设计（cross-attention 处理离散键盘 + concat 处理连续鼠标 + group operation 对齐时间压缩比）。
- 提出”连续量拼接、离散量交叉注意力”的动作控制设计准则，并给出消融证据支撑。
- GF-Minecraft 数据集：程序化采集、消除人类操作偏置的动作标注数据集，公开 70 小时 / 2,000+ 片段，为后续同类研究提供了可复用的数据与预处理工具（碰撞 / 无效跳跃检测、动作可视化脚本）。
- 自回归长视频生成机制：基于 Diffusion Forcing 思路支持”一步生成多帧”，比逐帧自回归更高效。
作者自述局限（Conclusion）：生成式游戏引擎仍面临多项未解决挑战——多样关卡与玩法设计、玩家反馈系统、游戏内物体操纵、长上下文记忆、以及实时游戏生成；GameFactory 明确定位为该方向的”第一步”尝试。此外，论文所用的基础视频扩散模型是内部研究模型，未公开权重 / 架构细节，第三方难以独立复现完整流水线（只能复用开源的 GF-Minecraft 数据 + 动作控制模块设计，本身没有公开可下载的 GameFactory 模型权重）；学到的动作空间以第一人称视角为主，向赛车等第三人称 / 载具视角的迁移只有初步定性展示，未有系统评测。
原始链接
- arXiv abs：https://arxiv.org/abs/2501.08325
- arXiv PDF：https://arxiv.org/pdf/2501.08325
- 项目主页（现行）：https://yujiwen.github.io/gamefactory/ （arXiv 论文与早期 GitHub README 中的
vvictoryuki.github.io/gamefactory已 404，作者迁移至此域名） - GitHub：https://github.com/KwaiVGI/GameFactory
- HuggingFace 数据集：https://huggingface.co/datasets/KwaiVGI/GameFactory-Dataset
一手源存档（sources/）
- gamefactory—github-readme — GitHub README 快照（fetched 2026-07-16）
- gamefactory—hf-dataset-card — HuggingFace 数据集卡快照（fetched 2026-07-16）
- gamefactory—project-page — 项目主页文本快照（fetched 2026-07-16）
- arXiv 2501.08325 全文（arXiv 原文 HTML，不入 git，见上方链接）