Two Paths to Generated Worlds: Playable Video Models and Executable Three.js Environments

Executive summary

There are two emerging paths toward generated interactive worlds: pixel-generative world models and executable code-generated worlds. Both require structured game data, but they need different training signals, asset systems, and evaluation infrastructure. That is GaussMathematics’s working distinction, not a claim that the field has voted for a single standard.

Route A predicts future visual observations from current frames, user actions, and optional state. Route B asks a coding agent to emit a runnable environment — in the browser-native case, often a Three.js page with assets and a runtime schema. Public benchmarks indicate both are still hard. We should not assume that every buyer is responding to the same paper, or that Three.js is the universal substrate for world models.

This note compares the two routes using WorldCoder-Bench, AlayaWorld, GameCraft-Bench, GameDevBench, and OpenGame as references, then maps the data layers a production program actually has to deliver. It is original analysis. It is not a reprint of any of those papers.

Why two routes, not one stack

A playable video model can look like a game and still have no source, no GLB, and no reset that a QA harness can call. An executable Three.js world can pass a physics probe and still look unlike the customer’s title. The research direction helps explain procurement collisions: teams order “interactive world data” and receive the wrong oracle.

Related deep dives: WorldCoder-Bench and training-ready Three.js worlds, AlayaWorld and playable video-world data, and playable datasets for coding agents.

Route A: Pixel-generative playable world models

The model consumes current observation, prior frames, user actions, and optional world state, and emits future pixels (often in latent chunks). AlayaWorld’s July 2026 paper describes this as synthesizing future observations conditioned on state and interaction, with camera navigation and chunk-level prompt events, trained on gameplay recordings and real video (arXiv:2607.06291).

Typical data needs:

• gameplay video;
• action labels on the same clock;
• timestamps and episode boundaries;
• camera trajectories;
• events (including sparse “open-ended” prompts);
• temporal coherence / revisit tests;
• failure and recovery;
• state alignment where it exists.

Evaluation is usually visual quality, trajectory following, memory/revisit, and sometimes human preference. Hidden engine state is easy to skip and expensive to fake later.

Route B: Code-generated executable worlds

A coding agent consumes a natural-language specification, requirements, assets, and runtime interfaces, and emits a program that must run. WorldCoder-Bench instantiates the browser-native Three.js case: optional .glb files, hidden behavioral contracts, StateProbe in a sandboxed browser, and a typical window.__3D_STATE__ interface (arXiv:2606.01869). The paper reports 2,026 canonical tasks; the public snapshot we checked lists 2,004 unique tasks — keep those numbers distinct.

Neighboring benches show the same route in other runtimes. GameCraft-Bench asks agents to build complete Godot games judged through replayed interaction (arXiv:2606.17861; 140 tasks, 15 families; strongest reported agent 41.46%). GameDevBench studies multimodal edits in a real engine from tutorials (arXiv:2602.11103; 333 tasks). OpenGame targets end-to-end web game creation with build/visual/intent scoring (arXiv:2604.18394). None of these papers, on the pages we read, claim that Three.js is the only executable path.

Typical data needs:

• specification;
• source;
• GLB or engine assets;
• state schema;
• behavioral contracts;
• interaction traces;
• build evidence;
• runtime validation;
• playability QA.

Head-to-head

This table is ours. Cell values are route properties, not scores copied from any leaderboard.

What the referenced papers actually show

Keep facts on their own pages:

• WorldCoder-Bench: best reported V-Cov 27.8% on Core, 19.9% on Robust; failures in state-schema drift and broken chains; paper CC BY 4.0; repo snapshot is not a CC BY asset dump.
• AlayaWorld (2607.06291): playable long-horizon video framework; arXiv non-exclusive license; do not copy figures.
• GameCraft-Bench: engine-grounded complete games; interaction-based judging; Godot, not Three.js.
• GameDevBench: tutorial-derived engine tasks; visual feedback helps agents; localized development, not full world models.
• OpenGame: web games from design specs; build health vs playability.

Public benchmarks indicate executable playability is unsolved at high coverage. They do not show that WorldCoder-Bench caused Three.js purchasing, or that all world-model companies now need Three.js.

Shared data, different payloads

How to choose without pretending one paper decided

Ask which output the model must emit tomorrow. If it must emit pixels under a closed loop, you are on route A and you need synchronized video-action-state data. If it must emit a page or a project a third party can run, you are on route B and you need specs, assets, and a failing test.

Coupled programs exist: capture video from an executable world whose state you already log. That is often more honest than hoping a video model invents a customer’s props, or hoping a coding agent invents a cinematic title from unlabeled footage.

Coupled capture without contaminating eval

If you already have a customer-authorized Three.js or engine loop, Route A footage can be a render of Route B, not a separate scrape. Log __3D_STATE__ or engine ticks while you dump video. Then you can train a pixel model on the video and still grade an agent on the state. The contamination rule is unchanged: the traces used as Route A training must not be the only Route B contracts, and loop-closure eval scenes must not be the only long video.

QA differs by route:

• Route A: action-to-frame sync, dropped-frame gaps, prompt-event sparsity, revisit holdouts.
• Route B: boot, WebGL context, schema presence, probe deltas, reset, sampled human play.

A program that runs only one of those checklists and claims both routes is mislabeled.

A practical split:

program:
  route: A | B | coupled
  env: customer-authorized
  assets: licensed
  eval: holdout_contracts_or_holdout_traces

Production implications

From a production-data perspective, GaussMathematics’s work sits on the shared rows: customer-authorized game environments, licensed virtual assets, synchronized traces, benchmark tasks, runtime-state schemas, replayable traces, evaluation sets, and versioned delivery. Playable Three.js environments are one executable shape. Playable video is one generative shape. Neither is “the” world-model standard.

We do not claim a public data scale, a named customer, or that any of the cited authors reviewed this page.

What this page is not selling

A targeted dataset might be Route A traces, Route B tasks, or a coupled recorder. Naming the route in the intake is cheaper than discovering the mismatch after capture. GaussMathematics can help specify that split. We do not claim a warehouse of unlabeled Three.js pages or a public gameplay lake of a given size.

Limitations of this comparison

• Five papers, five oracles; we did not re-run any bench.
• Web Three.js ≠ Godot ≠ Unreal.
• “Playable” is defined differently in video papers and coding benches.
• License regimes differ (CC BY paper vs arXiv non-exclusive vs engine terms).
• Market demand is not identified with citation counts.

References

• Lu et al., *WorldCoder-Bench*, arXiv:2606.01869. https://arxiv.org/abs/2606.01869
• AlayaWorld Team et al., *AlayaWorld: Long-Horizon and Playable Video World Generation*, arXiv:2607.06291. https://arxiv.org/abs/2607.06291
• Luo et al., *GameCraft-Bench*, arXiv:2606.17861. https://arxiv.org/abs/2606.17861
• Chi et al., *GameDevBench*, arXiv:2602.11103. https://arxiv.org/abs/2602.11103
• Jiang et al., *OpenGame*, arXiv:2604.18394. https://arxiv.org/abs/2604.18394