GameFactory: Creating New Games with Generative Interactive Videos

Paper: arXiv:2501.08325 Code: KwaiVGI/GameFactory Code reference: main @ 0f2a38fe (2025-03-22)

1. Motivation (研究动机)

当前的 generative game engine 通常把游戏建模成“给定玩家动作，预测下一段视频”的 action-conditioned video generation 问题。这个方向很有吸引力：如果模型能像游戏引擎一样响应键盘、鼠标输入，就可能自动生成可交互内容，降低传统游戏开发中场景、美术、关卡和交互脚本的手工成本。但论文指出，已有方法大多被训练在特定游戏或小范围游戏数据上，例如 Atari、CS:GO、DOOM、Super Mario Bros.、Minecraft 或 AAA game clips；它们能学习“这个游戏里的动作-画面转移”，却很难把交互能力迁移到全新的开放场景。

Figure 1 解读：这张 teaser 展示了 GameFactory 想达到的效果：模型从小规模第一人称 Minecraft 数据中学到键盘与鼠标控制，然后把这种控制能力迁移到开放域生成场景中。黄色按键表示当前按下的键，箭头表示鼠标移动方向；重点不是复刻 Minecraft，而是在不同视觉风格下继续让动作影响画面。

论文认为真正困难的点有三个。第一，开放域视频虽然丰富，但通常没有逐帧 action annotation；如果直接为所有可能场景采集键鼠动作标注，成本不可接受。第二，已有 Minecraft 人类游玩数据存在强烈 human bias：玩家常按 W 向前走，极少长时间后退、原地跳或做反常键鼠组合，导致模型容易忽略低频动作。第三，直接用小规模 action-labeled Minecraft 数据 fine-tune 一个 open-domain video diffusion model，会把动作控制和 Minecraft 视觉风格一起写入模型，造成 style leakage：模型学会动作的同时也塌缩到 Minecraft 域，失去生成新场景的能力。

本文要解决的具体问题是：给定一个已经在大规模开放域视频上预训练的 text-to-video diffusion model，再给它少量带键盘/鼠标动作标注的 Minecraft 数据，能否得到一个既能响应动作、又能在 open-domain scenes 中生成“新游戏”的视频模型？这个问题值得研究，因为它把 generative video model 从“离线生成好看的视频”推进到“可被用户输入持续驱动的 world model / simulator”。如果可行，它不仅能服务游戏内容生成，也可能作为 data producer 或 simulator，为 autonomous driving、embodied AI 等缺少大规模 action-labeled 数据的领域提供可控、多样、近似真实复杂度的训练环境。

2. Idea (核心思想)

GameFactory 的核心洞察是：游戏视觉风格和动作控制规律必须用不同参数承载，否则小规模 Minecraft 数据会同时把“如何响应动作”和“Minecraft 长什么样”绑定起来。论文用 LoRA domain adapter 单独吸收 Minecraft style，用独立 action control module 学键盘/鼠标到视频动态的映射；推理时移除 LoRA，只保留 action control module，于是动作能力可以挂回 open-domain pretrained model 的生成先验上。

Figure 2 解读：蓝色上半部分表示预训练视频模型已经有开放域生成能力；绿色下半部分表示从少量 Minecraft action-labeled data 学到的 action control module。GameFactory 的关键不是重训一个新游戏模型，而是把 action control 当作可插拔能力注入已有生成模型，并避免 Minecraft 风格污染开放域先验。

关键创新可以概括为三点。第一，作者构建 GF-Minecraft：用 MineDojo 自动执行随机化动作序列，得到无明显人类行为偏置的 action-annotated game video dataset，并用 MiniCPM-V 生成文本描述。第二，作者把离散键盘动作与连续鼠标动作分开建模：键盘动作更像 categorical token，用 cross-attention；鼠标移动携带连续幅值，用 concat 保留大小信息。第三，作者提出 multi-phase training：先用 LoRA 学 Minecraft 风格，再冻结 backbone/LoRA 只训动作模块，最后推理时移除 LoRA 以获得 scene-generalizable action control。

与 GameNGen / Oasis 这类 game-specific world model 不同，GameFactory 的目标不是在单一游戏域内保持高保真 roll-out，而是验证“从一个小规模动作域中学到的控制信号能否泛化到开放视觉域”。与只依赖 text prompt 或 video-level instruction 的可控视频生成也不同，它的控制粒度是 frame-level keyboard + mouse input，更接近真实游戏交互。

方法	Game sources	Resolution	Control granularity	Action space	Scene generalizable
DIAMOND	Atari, CS:GO	$280\times 150$	Frame-level	18 keys	否
GameNGen	DOOM	$240$p	Frame-level	Key	否
GameGenX	AAA Games	$720$p	Video-level	Instruction	否
Oasis	Minecraft	$640\times 360$	Frame-level	Key + Mouse	否
Matrix	AAA Games	$720$p	Frame-level	4 keys	是
Genie 2	Unknown	$720$p	Frame-level	Key + Mouse	是
GameFactory	Minecraft	$640\times 360$	Frame-level	7 keys + Mouse	是

3. Method (方法)

3.1 Latent video diffusion 预备知识与 action-conditioned objective

论文采用 transformer-based latent video diffusion model 作为 backbone。给定视频序列 $\mathbf{X}$，encoder $E(\cdot )$ 先把视频在空间和时间上压缩为 latent representation $\mathbf{Z}=E(\mathbf{X})$。若 VAE temporal compression ratio 为 $r$，则一个 $(1+rn)$ 帧视频被压缩成 $(1+n)$ 个 latent frames： $\mathbf{X}=[{\mathbf{x}}^0,{\mathbf{x}}^1,\dots ,{\mathbf{x}}^{rn}],\mathbf{Z}=[{\mathbf{z}}^0,{\mathbf{z}}^1,\dots ,{\mathbf{z}}^n].$ 训练时，模型在 timestep $t$ 给 clean latent ${\mathbf{Z}}_0$ 加噪得到 ${\mathbf{Z}}_t$，并预测噪声 $\mathbf{ϵ}$。引入动作序列 $\mathbf{A}=[{\mathbf{a}}^1,{\mathbf{a}}^2,\dots ,{\mathbf{a}}^{rn}]$ 后，${\mathbf{a}}^i$ 表示从 ${\mathbf{x}}^{i-1}$ 转移到 ${\mathbf{x}}^i$ 时执行的动作，action-conditioned loss 写为： ${\mathcal{L}}_{\mathbf{a}}(\mathbf{\varphi })=\mathbb{E}\left[{\Vert {\mathbf{ϵ}}_{\mathbf{\varphi }}({\mathbf{Z}}_t,\mathbf{p},\mathbf{A},t)-\mathbf{ϵ}\Vert }_2^2\right],$ 其中 $\mathbf{p}$ 是 text prompt，$\mathbf{\varphi }$ 是带 action control 后的模型参数。推理时从 noisy latent ${\mathbf{Z}}_T$ 采样 ${\mathbf{Z}}_0$，再通过 decoder $D(\cdot )$ 还原视频 $\mathbf{X}=D({\mathbf{Z}}_0)$。这条公式本质上说明：动作不是后处理控制，而是进入 diffusion denoising network 的条件变量。

3.2 GF-Minecraft Dataset：无 human bias 的动作标注数据

作者认为训练数据必须同时满足三点：动作可自定义、动作分布没有人类偏置、场景多样且有文本描述。为此他们用 MineDojo 控制 Minecraft agent，随机组合 atomic keyboard/mouse actions，并执行到模拟环境中采集 observations。主文报告 GF-Minecraft 共包含约 $70$ 小时 gameplay video；附录进一步说明，作者预配置 $3$ 种 biomes（forest、plains、desert）、$3$ 种 weather（clear、rain、thunder）和 $6$ 种 time of day，生成 $2,000$ 个 action-annotated video clips，每个 clip 含 $2,000$ frames。

Figure 11 解读：这张图展示了 MiniCPM-V 的视频文本标注流程。GameFactory 不只保存动作序列，还为切片视频生成 scene/object 描述，使训练时模型能同时看到 text prompt、visual dynamics 和 action sequence。红色加粗词对应场景与物体描述，有助于把动作控制和文本条件结合起来。

数据预处理分两步。首先 slicing：从完整视频中随机采样连续 $k$ 帧形成训练 clip，实验中 $k=81$，略大于模型生成长度 $77$；持续采样直到总采样帧数达到原视频总帧数的 $n=3$ 倍。其次 text annotation：使用 MiniCPM-V 给切片视频生成文本。动作空间覆盖第一人称 Minecraft 中的核心玩家输入：W/S 前后、A/D 左右、Space 跳跃、Shift 潜行、Ctrl 冲刺，以及 mouse yaw/pitch movement。附录中还说明 mouse movement 以鼠标指针相对游戏区域中心的 offset 表示，并对每帧计算相对第一帧的 cumulative offset 作为模型输入。

Behavior	Control Signal	MineDojo Action Interface
forward / back	W / S key	Interface${}_1$
left / right	A / D key	Interface${}_2$
jump / sneak / sprint	Space / Shift / Ctrl key	Interface${}_3$
vertical perspective movement	mouse movement (yaw)	Interface${}_4$
horizontal perspective movement	mouse movement (pitch)	Interface${}_5$

3.3 Action Control Module：把连续鼠标和离散键盘分开融合

GameFactory 把 action control module 注入 video diffusion transformer blocks。设连续鼠标动作 $\mathbf{M}\in {\mathbb{R}}^{rn\times d_1}$，离散键盘动作 $\mathbf{K}\in {\mathbb{R}}^{rn\times d_2}$，Transformer 中间特征为 $\mathbf{F}\in {\mathbb{R}}^{(n+1)\times l\times c}$。这里 $d_1,d_2$ 是动作维度，$l$ 是 token sequence length，$c$ 是 channel 数。

Figure 3 解读：左侧展示 action control module 如何插入 transformer block；右侧展示两种 action fusion 机制。论文没有把所有控制信号简单拼进同一个 token，而是让 mouse 和 keyboard 走不同路径：mouse 作为连续幅值信号通过 concat 进入特征，keyboard 作为离散 token 通过 cross-attention 影响特征。

因为 VAE 的 temporal compression ratio 是 $r$，原视频有 $rn$ 个动作，但 latent 只有 $n+1$ 个 frame features，动作和 latent feature 存在粒度不匹配。作者用 sliding window size $w$ 做动作分组：对第 $i$ 个 latent feature ${\mathbf{f}}^i$，使用动作窗口 $[{\mathbf{a}}^{r\times (i-w+1)},\dots ,{\mathbf{a}}^{ri}]$；越界位置用边界动作 padding。这样一个 latent feature 可以看到多个相邻原始帧动作，能表达“跳跃命令会影响之后若干帧”这类延迟效应。

Figure 4 解读：图中强调的是 action-frame granularity mismatch。压缩后 latent feature 数量更少，如果只把某一帧动作对齐到某个 latent，模型会丢掉动作持续时间和滞后影响；sliding window grouping 让每个 latent feature 聚合 $rw$ 个动作，从而对短时连续控制更稳定。

对 mouse movement，作者先得到 ${\mathbf{M}}_{group}\in {\mathbb{R}}^{(n+1)\times rw\times d_1}$，再 reshape 为 ${\mathbb{R}}^{(n+1)\times 1\times rw{d}_1}$，沿 token length 复制得到 ${\mathbf{M}}_{repeat}\in {\mathbb{R}}^{(n+1)\times l\times rw{d}_1}$。然后与 $\mathbf{F}$ 在 channel 维拼接： ${\mathbf{F}}_{fused}\in {\mathbb{R}}^{(n+1)\times l\times (c+rw{d}_1)}.$ 融合后的特征再经过一层 MLP 和一层 temporal self-attention。这个设计的直觉是：鼠标移动的 magnitude 很重要，小幅转头和大幅甩头应造成不同视觉流；concat 能保留连续数值大小，而 cross-attention 的相似度归一化可能削弱幅值差异。

对 keyboard actions，作者先学习 action embedding 并加入 positional encoding，再 grouping 得到 ${\mathbf{K}}_{group}\in {\mathbb{R}}^{(n+1)\times rw\times c}$。融合时令 $\mathbf{F}$ 作为 query，${\mathbf{K}}_{group}$ 作为 key/value 做 cross-attention。这更适合离散类别控制，因为 W/A/S/D/Space/Shift/Ctrl 类似一组 categorical tokens，模型需要判断“当前 feature 应该 attend 到哪些按键语义”，而不是保留连续幅值。

这个模块为什么可能有效？它把“视频生成质量”仍交给预训练 diffusion backbone，把“动作如何扰动 latent dynamics”作为额外条件局部注入 transformer block。动作模块不需要从零学会世界外观，只需学会输入动作与 feature change 的关系；同时 mouse/keyboard 的分治避免了一种融合机制同时承担连续控制与离散控制两种不兼容的 inductive bias。

def group_actions(actions, latent_count, r=4, window=4, pad="boundary"):
    """Paper-level pseudocode: align frame-level actions to latent-frame features."""
    groups = []
    for i in range(latent_count):
        start = r * (i - window + 1)
        end = r * i
        idx = list(range(start, end + 1))
        idx = [min(max(j, 0), len(actions) - 1) for j in idx]
        groups.append(actions[idx])
    return torch.stack(groups, dim=0)
 
 
def action_control_block(F, mouse, keyboard, key_embed, mlp, temporal_attn, key_cross_attn, r=4, window=4):
    """Paper-level pseudocode for the action control module."""
    # F: [n+1, l, c]
    M_group = group_actions(mouse, latent_count=F.shape[0], r=r, window=window)
    K_group = group_actions(keyboard, latent_count=F.shape[0], r=r, window=window)
 
    # Continuous mouse: preserve magnitude by concatenation.
    M_flat = M_group.reshape(F.shape[0], 1, -1)
    M_repeat = M_flat.repeat(1, F.shape[1], 1)
    F_mouse = torch.cat([F, M_repeat], dim=-1)
    F_mouse = temporal_attn(mlp(F_mouse))
 
    # Discrete keyboard: use action embeddings as key/value in cross-attention.
    K_tokens = key_embed(K_group)  # [n+1, r*w, c]
    F_key = key_cross_attn(query=F_mouse, key=K_tokens, value=K_tokens)
    return F_key

3.4 Autoregressive long video generation：一次生成多帧，而非单帧 next-token

普通 diffusion video model 通常输出固定长度视频，不足以支持长时间游戏交互。GameFactory 借鉴 Diffusion Forcing，让不同帧处在不同 noise levels：越早的条件帧噪声越少，越晚的预测帧噪声越多，从而让模型在 diffusion 过程中先确定历史帧，再生成未来帧。

Figure 5 解读：训练阶段随机选择前 $k+1$ 个 latent frames 作为条件帧，不对它们加噪，也不计算它们的 noise prediction loss；只对剩余 $N-k$ 个待预测帧加噪并计算 loss。推理阶段先生成第一段 $N+1$ 帧 latent，之后每轮取历史中最新 $k+1$ 帧作为条件，一次生成新的 $N-k$ 帧，并把新帧并入 history，从而得到超过单次窗口长度的交互视频。

这种 autoregressive generation 和传统 next-frame prediction 的区别在于：它每一步生成的是多帧 chunk，而不是一帧，因此长视频推理效率更高；同时只在需要预测的帧上优化 loss，避免模型把容量浪费在已经作为条件给定的历史帧噪声上。

def train_autoregressive_diffusion(model, latents, actions, prompt, scheduler):
    """Paper-level pseudocode for GameFactory long-video training."""
    N = latents.shape[0] - 1
    k = torch.randint(low=0, high=N, size=()).item()
    cond_mask = torch.zeros(N + 1, dtype=torch.bool)
    cond_mask[: k + 1] = True
 
    noise = torch.randn_like(latents)
    timesteps = scheduler.sample_timesteps(latents.shape[0])
    noisy_latents = scheduler.add_noise(latents, noise, timesteps)
    noisy_latents[cond_mask] = latents[cond_mask]
 
    pred_noise = model(noisy_latents, prompt=prompt, actions=actions, timesteps=timesteps)
    target_mask = ~cond_mask
    loss = F.mse_loss(pred_noise[target_mask], noise[target_mask])
    return loss
 
 
def generate_long_game_video(model, first_latents, prompt, action_stream, chunk_size, context_size):
    """Paper-level pseudocode for multi-frame autoregressive inference."""
    history = model.sample_full_sequence(first_latents, prompt=prompt, actions=action_stream[:chunk_size])
    cursor = chunk_size
    while cursor < len(action_stream):
        cond = history[-context_size:]
        actions = action_stream[cursor - context_size : cursor + chunk_size]
        new_latents = model.sample_future(cond, prompt=prompt, actions=actions, future_frames=chunk_size)
        history = torch.cat([history, new_latents], dim=0)
        cursor += chunk_size
    return history

3.5 Style-Action Decoupling：LoRA 适配风格，Action Module 学控制

开放域泛化部分的核心问题是 style leakage：如果直接对预训练视频模型做 one-phase fine-tuning，Minecraft style 和 action response 会同时写入模型，导致开放域场景变差。GameFactory 用 domain adapter 承担 game style，用 action control module 承担 action controllability，并把二者分阶段训练。

Figure 6 解读：Phase #0 是开放域视频预训练；Phase #1 只用 LoRA 让模型适应 game video style；Phase #2 冻结 pretrained parameters 和 LoRA，只训练 action control module；Phase #3 推理时移除 LoRA，仅保留 action module。这样，Minecraft 外观由 LoRA 吸收，动作规律由 action module 吸收，最终可以把动作规律迁移回开放域生成先验。

训练流程可以理解为参数归因控制。Phase #1 先让 LoRA 解释“为什么视频长得像 Minecraft”；Phase #2 冻结 LoRA 后，diffusion loss 中剩余可学习的主要路径就是 action control module，因此模型被迫把“动作导致的视觉变化”写入动作模块，而不是继续改写视觉风格。Phase #3 移除 LoRA 后，如果动作模块确实学到 style-independent control，它应当仍能驱动 open-domain scenes。

def multiphase_gamefactory_training(backbone, lora, action_module, minecraft_loader):
    """Paper-level pseudocode for the three trainable phases after pretraining."""
    # Phase #1: fit Minecraft visual style with LoRA.
    freeze(backbone)
    freeze(action_module)
    unfreeze(lora)
    for batch in minecraft_loader:
        loss = diffusion_loss(backbone, batch.video, prompt=batch.text, adapters=[lora])
        loss.backward()
        lora.optimizer.step()
 
    # Phase #2: learn action controllability while style adapter is fixed.
    freeze(backbone)
    freeze(lora)
    unfreeze(action_module)
    for batch in minecraft_loader:
        loss = diffusion_loss(
            backbone,
            batch.video,
            prompt=batch.text,
            actions=batch.actions,
            adapters=[lora, action_module],
        )
        loss.backward()
        action_module.optimizer.step()
 
    # Phase #3: open-domain inference removes Minecraft style adapter.
    return lambda prompt, actions: backbone.sample(prompt=prompt, actions=actions, adapters=[action_module])

3.6 Released code 搜索结果、可复现锚点与 paper-code gap

代码搜索找到了公开仓库 KwaiVGI/GameFactory，并锚定到 main@0f2a38fe。但 released repo 只包含项目说明、数据集格式说明、detection.py 与 visualize.py 等 GF-Minecraft 数据工具；没有公开 video diffusion backbone、action control module、LoRA training loop、autoregressive generation 或实验 config。因此本文的模型结构、loss、训练超参只能从论文与 arXiv source 读取，不能从 released code 验证。

论文公式与 released code 实现差异：released code 缺少模型/训练实现，无法逐行核对 action control module、multi-phase training、long-video autoregressive loop，也没有 launch script / config 覆盖论文中的训练超参；本笔记中的训练配置数字来自论文 Experiments / Implementation Details，不是代码默认值。

def mark_collision_and_invalid_jump(metadata, threshold=0.01, height_threshold=0.01):
    """Pseudocode based on released detection.py."""
    actions = metadata["actions"]
    for frame_idx, action in actions.items():
        action["collision"] = 0
        action["jump_invalid"] = 0
        action["delta_pos"] = [0.0, 0.0, 0.0]
 
    for frame_idx in range(1, len(actions)):
        cur = actions[str(frame_idx)]
        prev = actions[str(frame_idx - 1)]
        delta = torch.tensor(cur["pos"]) - torch.tensor(prev["pos"])
        cur["delta_pos"] = delta.tolist()
 
        if cur.get("scs") == 1 and delta[1] <= height_threshold:
            cur["jump_invalid"] = 1
        if abs(delta[0]) <= threshold and abs(delta[2]) <= threshold:
            cur["collision"] = 1
 
    jump_sequence_started = False
    for frame_idx in range(1, len(actions)):
        cur = actions[str(frame_idx)]
        if cur.get("scs") == 1 and cur["jump_invalid"] == 0:
            if jump_sequence_started:
                cur["jump_invalid"] = 1
            else:
                jump_sequence_started = True
        else:
            jump_sequence_started = False
    return metadata

def parse_action_segments_for_overlay(config):
    """Pseudocode based on released visualize.py::parse_config."""
    key_data = {}
    mouse_data = {}
 
    # visualize.py stores pressed Space frames in the last config entry.
    space_frames = set()
    if config[-1]:
        space_frames = set(map(int, config[-1].split()))
 
    for i in range(len(config) - 1):
        end_frame, action = config[i]
        w, s, a, d, shift, ctrl, _, mouse_y, mouse_x = map(float, action.split())
        start_frame = 0 if i == 0 else config[i - 1][0] + 1
 
        for frame in range(start_frame, int(end_frame) + 1):
            key_data[frame] = {
                "W": bool(w), "A": bool(a), "S": bool(s), "D": bool(d),
                "Space": frame in space_frames,
                "Shift": bool(shift), "Ctrl": bool(ctrl),
            }
            if frame == 0:
                mouse_data[frame] = (320, 176)
            else:
                global_scale_factor = 0.4
                mouse_scale_x = 15 * global_scale_factor
                mouse_scale_y = 15 * 4 * global_scale_factor
                mouse_data[frame] = (
                    mouse_data[frame - 1][0] + mouse_x * mouse_scale_x,
                    mouse_data[frame - 1][1] + mouse_y * mouse_scale_y,
                )
    return key_data, mouse_data

Code reference: main @ 0f2a38fe (2025-03-22) — pseudocode and mapping based on this commit

Paper Concept	Source File	Key Class/Function
GF-Minecraft 数据下载、目录结构、JSON 字段、动作编码	README.md	dataset sections; ws/ad/scs/pitch/yaw/pitch_delta/yaw_delta/pos field description
Collision 与 invalid jump metadata 后处理	detection.py	process_videos_and_metadata, extract_data_from_json
Action visualization / 键鼠 overlay	visualize.py	parse_config, draw_keys_on_frame, process_video
Action control module / LoRA multi-phase / AR long-video generation	released repo 未包含	只能依据论文公式、figures 与 text；无 public source file 可映射

4. Experimental Setup (实验设置)

4.1 Datasets

• GF-Minecraft：MineDojo 平台自动采集，主文报告约 $70$ 小时 gameplay video；附录报告 $2,000$ 个 action-annotated clips，每个 clip $2,000$ frames，覆盖 $3$ 个 biomes、$3$ 种 weather、$6$ 个 time-of-day。训练前按 $k=81$ 连续帧切片，并采样到原始总帧数的 $n=3$ 倍；用 MiniCPM-V 做文本标注。
• Test split：作者保留 segmented dataset 的 $5\%$ 作为 test set，不参与训练；ablation 又分为 only-key、mouse-small、mouse-large 三个子集。
• VPT Find Cave subset：用于 human-bias dataset comparison。作者选择 VPT 的 Find Cave，因为它较接近 Minecraft navigation setting，且主要排除了 inventory management 和 block modification。

4.2 Baselines / Comparisons

实验没有建立统一跨论文 benchmark，因为不同工作使用的游戏来源、分辨率、动作空间和可测试模型都不一致。作者主要比较三类对象：一是 action control module 内部 ablation（keyboard/mouse 分别使用 cross-attention 或 concatenation）；二是 scene generalization 中的 multi-phase training vs one-phase fine-tuning；三是 GF-Minecraft vs VPT-trained model。相关工作表中还比较 DIAMOND、GameNGen、GameGenX、Oasis、Matrix、Genie 2 的 game sources、resolution、control granularity、action space 与 scene generalization。

4.3 Metrics

• Flow：计算 generated video 的 optical flow，并与 reference video 的 optical flow 做 mean square error，用于衡量动作跟随的动态一致性，越低越好。
• Cam：用 GLOMAP 从 generated/reference videos 中提取 camera poses，再计算 Euclidean distance，越低越好。
• CLIP：在 CLIP feature space 中计算生成视频和 text prompt 的语义相关性，越高越好。
• FID / FVD：衡量 generated videos 与 reference distribution 的质量和时序分布差异，越低越好。
• Dom：scene generalization 表中使用的 domain similarity 指标，衡量 fine-tuned model 和 original model 生成视频在 CLIP space 的相似度，越高表示越接近原 open-domain model。

4.4 Training / Inference Config

论文实验基于一个 internal $1$B-sized transformer-based text-to-video diffusion model，该模型由更大的 pretrained video diffusion model 蒸馏而来；game video resolution 为 $360\times 640$，VAE temporal compression rate $r=4$。每个 fine-tuning / training phase 约需 $2$–$4$ 天，在 $8$ 张 A100 GPUs 上训练，batch size 为 $64$。LoRA fine-tuning 的参考超参为 rank=128、learning rate 1e-4；action control module 的 learning rate 为 1e-5。推理时只对 text prompt conditional input 使用 classifier-free guidance，并采用 DDIM sampling with $50$ sampling steps。

这些 training-config numbers 来自论文实验设置；released GitHub repo 没有训练脚本或 config，因此无法从代码侧验证 batch size、LR、LoRA rank 或 sampling steps。

5. Experimental Results (实验结果)

5.1 Action controllability：keyboard 用 cross-attention，mouse 用 concat 最稳

Figure 7 解读：这张定性图比较 key input control。结论与表格一致：离散按键如果只 concat 到特征中，模型更容易忽略按键；cross-attention 能让 feature 主动 attend 到按键 token，因此按键响应更明显。图中黄色按钮表示 pressed keys。

Table 2 的 ablation 直接支持作者的融合设计。最优组合是 keyboard 用 Cross-Attn、mouse 用 Concat：在 only-key 上 Cam 从 Cross/Cross 的 $0.0527$ 降到 $0.0439$，Flow 从 $8.67$ 降到 $7.79$；在 mouse-small 上 Cam/Flow/FVD 分别为 $0.0685/18.64/1032.98$，都是三组中最好；在 mouse-large 上 Cam 和 Flow 也最好，分别为 $0.1021$ 和 $249.54$。CLIP/FID/FVD 的差异相对小，作者解释为 visual style 主要由 Phase #1 学到，各 action-fusion 方案在语义和生成质量上差别不如动作跟随明显。

Only-Key subset

Key module	Mouse module	Cam↓	Flow↓	CLIP↑	FID↓	FVD↓
Cross-Attn	Cross-Attn	0.0527	8.67	0.3313	107.13	814.05
Concat	Concat	0.0853	22.37	0.3277	103.89	786.50
Cross-Attn	Concat	0.0439	7.79	0.3292	105.28	795.03

Mouse-Small subset

Key module	Mouse module	Cam↓	Flow↓	CLIP↑	FID↓	FVD↓
Cross-Attn	Cross-Attn	0.0798	20.46	0.3137	125.67	1203.29
Concat	Concat	0.0756	19.18	0.3159	133.42	1151.71
Cross-Attn	Concat	0.0685	18.64	0.3184	127.84	1032.98

Mouse-Large subset

Key module	Mouse module	Cam↓	Flow↓	CLIP↑	FID↓	FVD↓
Cross-Attn	Cross-Attn	0.1362	325.18	0.3103	167.37	1383.92
Concat	Concat	0.1179	258.93	0.3123	145.74	1405.47
Cross-Attn	Concat	0.1021	249.54	0.3107	139.91	1420.89

5.2 Scene generalization：multi-phase 比 one-phase 更接近开放域

Figure 8 解读：这张图比较 multi-phase training 和 one-phase training 在开放域场景中的视觉效果。multi-phase 保留了 original pretrained model 的场景域，同时还能响应鼠标方向；one-phase 则更容易出现 Minecraft style leakage 或生成质量下降，说明“把 style 和 action 分开训练”是开放域泛化的关键。

Table 3 显示，Multi-Phase 在 open-domain 上的 action following、domain preservation 和生成质量都优于 One-Phase。Open-domain Multi-Phase 的 Cam/Flow 为 $0.0997/54.13$，比 One-Phase 的 $0.1134/76.02$ 更接近 in-domain baseline $0.0839/43.48$；Dom 为 $0.7565$，高于 One-Phase 的 $0.7345$；CLIP、FID、FVD 也分别为 $0.3181/121.18/1256.94$，优于 One-Phase 的 $0.3111/167.79/1323.58$。

Strategy	Domain	Cam↓	Flow↓	Dom↑	CLIP↑	FID↓	FVD↓
Multi-Phase	In-domain	0.0839	43.48	-	-	-	-
Multi-Phase	Open-domain	0.0997	54.13	0.7565	0.3181	121.18	1256.94
One-Phase	Open-domain	0.1134	76.02	0.7345	0.3111	167.79	1323.58

5.3 Dataset 设计：GF-Minecraft 减少 human bias，低频动作更可控

Figure 9 解读：这张图比较 GF-Minecraft 和 VPT 在低频动作上的表现。VPT 来自人类游玩，模型容易把“jump”与人类常见的 forward+jump 联在一起，也可能在 backward 指令下保持不动；GF-Minecraft 通过均匀采样原子动作和组合动作，使模型能更好响应原地跳、后退等人类很少执行但游戏控制中必须支持的动作。

Table 4 中，GF-Minecraft-trained model 在动作跟随和生成质量上明显优于 VPT-trained model：Cam 从 $0.1324$ 降到 $0.0839$，Flow 从 $107.67$ 降到 $43.48$，FID 从 $156.69$ 降到 $125.85$，FVD 从 $1233.15$ 降到 $1047.59$；只有 CLIP 是 VPT 略高（$0.3174$ vs $0.3135$）。Table 5 进一步说明原因：VPT 中 W 键比例为 $50.11\%$，S 只有 $0.32\%$，Shift 只有 $0.14\%$；GF-Minecraft 中 W/A/S/D 均为 $13.56\%$，Space/Shift/Ctrl 均为 $15.25\%$，更适合训练任意动作输入。

Dataset	Cam↓	Flow↓	CLIP↑	FID↓	FVD↓
VPT	0.1324	107.67	0.3174	156.69	1233.15
GF-Minecraft	0.0839	43.48	0.3135	125.85	1047.59

Dataset	W	A	S	D	Space	Shift	Ctrl
VPT	50.11%	4.03%	0.32%	3.45%	20.37%	0.14%	19.58%
GF-Minecraft	13.56%	13.56%	13.56%	13.56%	15.25%	15.25%	15.25%

5.4 Long video generation：只对预测帧算 loss 更好

Figure 10 解读：图中展示了超过 $300$ 帧的 generated long video key frames。它验证了 autoregressive chunk generation 可以把短窗口 video diffusion 扩展到更长交互序列；但图中仍是 key-frame demo，不等同于真实游戏引擎中的无误差长期状态模拟。

Table 6 对比 long-video training 的 loss scope。只在 predicted frames 上计算 loss 明显优于 all frames：Cam 从 $0.1547$ 降到 $0.0924$，Flow 从 $148.73$ 降到 $85.45$，CLIP 从 $0.2965$ 升到 $0.3190$，FID 从 $176.07$ 降到 $136.95$，FVD 从 $1592.43$ 降到 $1154.45$。这支持了 Figure 5 的训练逻辑：条件帧已经给定，优化它们的 noise prediction 不仅无助于未来生成，还会引入与预测目标无关的噪声干扰。

Loss Scope	Cam↓	Flow↓	CLIP↑	FID↓	FVD↓
All frames	0.1547	148.73	0.2965	176.07	1592.43
Only predicted frames	0.0924	85.45	0.3190	136.95	1154.45

5.5 物理交互与跨游戏类型泛化：有潜力，但仍是探索性证据

Figure 12 解读：这张图展示模型对 collision 的响应。Minecraft navigation 中，碰撞是重要物理交互：即使输入继续向前，agent 也应在撞到障碍时保持相对静止。作者观察到模型能从随机场景采集数据中学到类似 collision feedback，但这仍是定性展示，不是严格物理一致性 benchmark。

Figure 13 解读：作者把从第一人称 Minecraft 中学到的 yaw control 迁移到 racing game prompt，发现 yaw 可以自然对应 steering，而 backward/sideways 等与赛车控制不太相关的动作会减弱。这个例子说明 action space 可能具有跨游戏语义，但也暴露了限制：当前动作空间主要来自第一人称 navigation，能否形成覆盖更多游戏和真实世界任务的 universal action space 仍未解决。

5.6 Limitations 与结论

主要限制有四点。第一，核心模型和训练代码未开源；公开仓库只提供数据说明和工具脚本，因此 action control module、LoRA decoupling 和 autoregressive diffusion loop 不能从 released code 复现。第二，backbone 是 internal $1$B text-to-video diffusion model，且由更大模型蒸馏而来；论文没有给出完整模型权重，外部复现实验会受限。第三，open-domain scene generalization 主要依赖定性展示和相对指标，没有统一 benchmark 能与 Genie 2、Matrix 等闭源或不可测试系统公平比较。第四，动作空间仍以 Minecraft first-person navigation 为中心，racing 和 autonomous driving 等跨域应用目前更像潜力展示，而不是已验证的通用 world model。

总体上，GameFactory 的实验支持三个结论：GF-Minecraft 的均衡动作分布能改善低频动作跟随；keyboard cross-attention + mouse concatenation 是更合适的 action fusion；multi-phase LoRA/action decoupling 能在保留开放域场景能力的同时注入动作控制。论文最有价值的贡献不是单个生成视频效果，而是给出了一个可解释的路线：用小规模 action-labeled simulator data 学控制，用大规模 open-domain video prior 负责视觉世界，再通过参数解耦避免二者互相污染。