PaperlayerView exact revision on arXiv

Source-linked AI summary

WorldCast: Distributed Multiplayer World Models

Ziyang Ye, Junchao Huang, Evelyn Zhang, Zhihao Xie, Ruicheng Zhang, Boyao Han, Litao Ban, Ziye Wang, Xinting Hu, Shaoshuai Shi, Zhuotao Tian, Li Jiang

arXiv:2610.12412v1cs.CV

TL;DR

Multiplayer world models need to keep independently controlled views consistent, while joint multi-view generation grows costly as players are added. WorldCast gives each player a local generator and state model, with clients sharing player and scene state. On Counter-Strike 2, the player field raises rendering rate by over an order of magnitude versus joint-generation methods, and shared scene state improves whole-round consistency.

  • Problem

    Multiplayer world models must maintain consistent player locations and shared-environment appearance across independently controlled views, while joint multi-view generation increases computation and communication as players are added.

    Source: §1 · p. 2

  • Method

    WorldCast gives each player a local video generator and state model, with clients exchanging player states and generated scene observations to guide rendering.

    Source: §1 · p. 2

  • Results

    The camera-aligned player field achieves a player rendering rate over ten times that of joint-generation and frame-concatenation baselines, while shared scene state improves whole-round consistency.

    Source: §1 · p. 2

  • Takeaways & Limitations

    WorldCast explores a networked-game world model in which each client generates a view on its own GPU and exchanges only shared world state.

    Source: §5 · p. 10

    The scene-state gain in PSNR, SSIM, and LPIPS holds after 30 s, but not in the first 30 s.

    Source: G LIMITATIONS AND SCOPE · p. 26

Abstract

from arXiv · show

Multiplayer world models must generate independently controlled views with consistent representations of both players and their shared environment. Most existing approaches coordinate multiple players through joint multi-view generation, whose cost grows with each additional player. We present WorldCast, a distributed multiplayer world model in which each player runs a local client comprising a video generator and a state model. Using recorded player positions and map geometry during training, the state model estimates the player's position from generated video and control inputs. Clients exchange player states and project them into camera-aligned player state fields that guide where and how other players are rendered. Shared scene state enables clients to reuse one another's generated observations to maintain consistent scene appearance across views. Experiments on Counter-Strike 2 demonstrate WorldCast's consistency, real-time performance, and distributed scalability. The camera-aligned player state field improves player rendering rates by over an order of magnitude over joint-generation methods, while shared scene state improves visual consistency over whole rounds. Each client runs in real time and exchanges only player and scene states, enabling scalable multiplayer generation without a centralized computational bottleneck. Image quality remains stable over hour-long rollouts.

1 INTRODUCTION

Multiplayer world models must keep independently generated views consistent without coupling their computation, but independent clients need shared player and scene information. WorldCast exchanges these states between local clients and evaluates the approach on Counter-Strike 2.

1 INTRODUCTION

  • Independent multiplayer views must keep visible player locations and previously observed environment content consistent across viewpoints and over time.Existing joint-generation methods increase computation and inter-device communication as players are added, while independent generators lack information about other players and views.Source: §1 · p. 2
  • WorldCast clients independently generate their views while exchanging player state and shared scene observations once per video block.A fixed-resolution player field and bounded number of retrieved scene frames let additional players be added without enlarging the generator’s input.Source: §1 · p. 2
  • Without a game engine supplying positions and geometry at inference, each client uses a state model trained on recorded positions and map geometry to estimate its position and scene depth from generated video and controls.Position estimates correct control-based extrapolation and update player state; depth supports visibility checks and scene-memory retrieval.Source: §1 · p. 2
  • The state model’s estimates and generated observations are published after each block, completing the loop between generation and state estimation.The shared world state comprises player positions and attributes, alongside a memory bank of generated observations.Source: §1 · p. 2
  • The camera-aligned player field achieves a player rendering rate over ten times that of joint-generation and frame-concatenation baselines, while scene state improves whole-round consistency.Each client generates video at over 16 FPS across deployments of 2 to 16 clients, and image quality remains stable over hour-long rollouts.Source: §1 · pp. 2–3

2 RELATED WORK

Prior multiplayer world models include joint generation, shared-screen approaches, and shared-state approaches, while controllable video generation supplies spatial conditioning techniques. WorldCast combines player-state conditioning with shared memory in independently generated views.

Multiplayer World Models

  • Joint-generation multiplayer methods denoise all views together, while shared-screen and shared-state methods coordinate agents through a shared frame or state; WorldCast instead exchanges estimated player state and generated-block memory.Joint views on different machines exchange attention features at every step (Appendix B); shared-state approaches may use central state, map-based per-player generators, or state encoded from recent frames (Cai et al., 2026; Po et al., 2026; Wu et al., 2026).Source: §2 · p. 3

Controllable Video Generation

  • Controllable video generation uses spatial guidance such as object-box tokens, image-aligned control maps, motion trajectories, and time-varying 3D states; WorldCast projects exchanged player states into the local camera and generator tokens.The state injector places spatial and gameplay attributes at the corresponding generator tokens.Source: §2 · p. 3

Autoregressive Video Diffusion

  • Autoregressive video diffusion generates incrementally, while memory-augmented models retrieve past frames and ShareVerse retrieves other agents’ frames within joint denoising; WorldCast shares generated content across independent clients.WorldCast combines four-step autoregressive generation with a shared memory bank, without jointly denoising the clients’ views.Source: §2 · p. 3

3 METHOD

WorldCast separates shared world state from local rendering: each player generates its own view, while clients share player and scene state to support consistency across views.

3.1 DISTRIBUTED GENERATION WITH SHARED WORLD STATE

  • A fixed-resolution player state field and at most one retrieved memory entry keep each generator’s attention sequence from growing with player count.Each player runs an independent client, and only shared world state—not activations, KV caches, or intermediate features—is exchanged.Source: §3.1 · pp. 3–4

3.2 SHARED PLAYER STATE

  • Player state records each player’s position and attributes; clients project visible players into their camera-aligned token grid to guide where and how they are rendered.The field encodes coverage, camera-relative depth, facing direction, and gameplay attributes such as team, identity, weapon, and controls.Source: §3.2 · pp. 4–5

3.3 SHARED SCENE STATE

  • Shared scene state stores generated latent-frame blocks with camera poses and coarse depth, then retrieves the entry covering the most scene content missing from recent context.Plücker-coordinate embeddings express relative camera geometry so the generator can use shared observations through its existing attention layers.Source: §3.3 · p. 5

3.4 THE STATE MODEL

  • The state model estimates position and depth from generated video and controls; a complementary filter combines motion and map-based estimates, while depth supports retrieval and visibility.Motion and place heads use recorded positions for supervision, and the depth head uses maps rendered from public 3D map assets; these targets are used only in training.Source: §3.4 · pp. 5–6

3.5 TRAINING AND INFERENCE

  • Four training stages adapt a pretrained video diffusion model to shared-state conditioning, block-causal generation, and a four-step generator for real-time inference.Stages 1–3 use weighted flow matching, with foreground weights emphasizing visible players and memory weights emphasizing target regions absent from recent context; inference publishes each completed block’s updated player state and memory entry.Source: §3.5 · pp. 6–7

4 EXPERIMENTS

Experiments on Counter-Strike 2 evaluate WorldCast on ten-second windows and whole rounds, covering player rendering, state estimation, scene consistency, deployment, and ablations. The results show strong rendering and consistency, while testing performance with predicted rather than ground-truth player states.

4 EXPERIMENTS

  • Evaluation uses four Counter-Strike 2 maps, 256 ten-second windows, and 32 whole rounds; methods receive GT player positions and map-geometry visibility unless marked predicted.Whole rounds use concurrent clients; the implementation uses four-latent-frame blocks and a 12-frame recent context.Source: §4 · p. 7

4.1 MAIN RESULTS

  • 0.817 rendered rate versus 0.056 for Solaris and 0.074 for frame concatenation, with 0.039 unmatched, under matched backbone, data, budget, and GT positions.WorldCast outperforms both baselines across all reported metrics.Source: §4.1 · p. 7, Table 1 · p. 8
  • With predicted states, render rate stays close to GT-position results, while unmatched rate rises from 0.031 to 0.093.Table 2 compares the same generator under GT and predicted player states.Source: §4.1 · p. 7, Table 2 · p. 8
  • After 30 s and over whole rounds, scene state improves PSNR, SSIM, and LPIPS against every design except GT-frame memory; without it, quality is on par before 30 s.Table 3 uses GT player positions to exclude imprecise rendering positions as a confound.Source: §4.1 · p. 7, Table 3 · p. 8
  • On rollout frames, the state model estimates positions more accurately than integrating controls and keeps error low over a minute.Figure 5 depicts predicted depth and predicted and GT trajectories and visibility over the map.Source: §4.1 · p. 7, Figure 5 · p. 8
  • In closed-loop deployment, scene state improves all four client-agreement measures, while VBench scores change little over one-hour rollouts.Table 4 reports agreement with scene state off versus on and VBench over one-hour rollouts.Source: §4.1 · p. 9, Table 4 · p. 9
  • With one GPU per player, each client exceeds 16 FPS for 2–16 players and receives only other players’ states and memory entries; the cited single-GPU baselines fall below 16 FPS from two players.The exchanged traffic is described as a few Mb/s.Source: §4.1 · p. 9, Figure 6 · p. 9

4.2 ABLATION STUDIES

  • Camera alignment matters most in the player state field: removing it drops rendering to joint-generation levels, while disabling visibility checks renders occluded players and raises unmatched rate.Retrieving any client’s best-covering memory entry gives the best scene-state results after 30 s.Source: Table 5 · p. 9, §4.2 · p. 10

5 CONCLUSION AND LIMITATIONS

WorldCast distributes multiplayer world modeling across clients that generate individual player views and exchange shared world state. It achieves higher player rendering rates than joint generation and improved whole-round consistency, with position error on generated video growing over time.

5 CONCLUSION AND LIMITATIONS

  • WorldCast distributes generation across clients, each producing one player’s view on its own GPU while exchanging shared world state.The shared state includes player information and scene memory.Source: §5 · p. 10
  • Player rendering rate is over an order of magnitude higher than joint generation, and scene state improves whole-round consistency.Source: §5 · p. 10
  • Position error from the state model on generated video grows with time.The conclusion identifies this as the main limitation.Source: §5 · p. 10

APPENDIX CONTENTS

The appendix distinguishes recorded GT player states from states predicted by the state model.

APPENDIX CONTENTS

  • GT states use recorded player positions and map-geometry visibility; predicted states replace both with state-model predictions.Source: APPENDIX CONTENTS · p. 13

A STATE MODEL IN DETAIL

The state model combines video- and control-based motion estimates with map-based position estimates, and predicts scene depth for visibility and memory retrieval. Its complementary filter combines position estimates, while rollout results show the limits of control extrapolation and growing error on generated video.

Components

  • The model processes 41 noise-free latent frames with control inputs; its motion head predicts three-dimensional displacement, while its place head predicts map position.The trunk and action encoder have 338M parameters; the motion and place heads have 11M.Source: A STATE MODEL IN DETAIL · p. 13

Address

  • The place head predicts a position as a map cell, a sub-cell, and an offset, representing it exactly within the tiled map.Cells are 256 × 256 × 64 u and divided into 4 × 4 × 1 sub-cells.Source: A STATE MODEL IN DETAIL · p. 13

Complementary filter

  • The parameter-free complementary filter weights integrated position and the place-head estimate equally at each latent frame, initializing from the player’s GT position.The place-head estimate enters as displacement from its first estimate, canceling constant bias.Source: A STATE MODEL IN DETAIL · p. 13

Within a block

  • Within each four-latent-frame block, clients extrapolate players from controls, then each client corrects and publishes its own position estimate for the next block.Movement keys are integrated at 64 Hz without collisions; camera and other-player positions are also extrapolated during the block.Source: A STATE MODEL IN DETAIL · pp. 13–14

Depth head

  • A separate depth head predicts depth from three latent frames; depth and camera poses support visibility gating and scene-memory retrieval, but map assets omit player occlusion.On held-out recorded frames, 85% of patches are within a factor of 1.25 of rendered map depth.Source: A STATE MODEL IN DETAIL · p. 14

Training

  • The trunk and action encoder train on 150k windows from 8,317 rounds, followed by place-head training; the depth head trains on 283k windows from 10,469 rounds.Per one-second block, the trunk with heads takes 17 ms and the depth head with read-out about 12 ms.Source: A STATE MODEL IN DETAIL · p. 14

Contribution of each component

  • On generated video, state-model error reaches 2.6 body widths at 50–60 s, a third of extrapolation; on recorded video, median error stays near 0.5 body widths over the minute.At 60 s, 87% of clients are within two body widths with the state model, versus 2% with extrapolation.Source: A STATE MODEL IN DETAIL · p. 14, Table 6 · p. 15

B DISTRIBUTED DEPLOYMENT IN DETAIL

WorldCast’s deployment assigns clients to separate GPUs and exchanges state through peer messages rather than a central merge. The appendix reports bounded long-stream costs and training-memory comparisons with joint-generation methods.

B DISTRIBUTED DEPLOYMENT IN DETAIL

  • Each client publishes and reads peer messages once per block without a central merge, and runs on its own GPU in the serving setup.Evaluations advance clients in lockstep; without lockstep, clients read the latest messages.Source: B DISTRIBUTED DEPLOYMENT IN DETAIL · p. 15, Table 7 · p. 16
  • Player-state messages take 3.7 kB and memory-entry messages 8.3 kB, while fetching an entry’s latents takes 387 kB.At 16 players, a client receives 3.5 Mb/s on average, including messages and retrieved latent data.Source: B DISTRIBUTED DEPLOYMENT IN DETAIL · p. 15, Table 7 · p. 16
  • Over a three-minute stream, block time is 633 ms in minute one and 654 and 650 ms in minutes two and three; memory footprint grows once by 0.9 GiB.The timing increase is mostly memory-bank writes after the client’s own memory-entry pool fills; footprint does not grow afterward.Source: B DISTRIBUTED DEPLOYMENT IN DETAIL · pp. 15–16
  • WorldCast’s training sample stays at 11.3 GiB beyond weights for any player count, while joint methods need 100.9 GiB at five players and do not fit one GPU at eight.WorldCast always trains on one player’s window; joint-generation samples contain 82P frames.Source: B DISTRIBUTED DEPLOYMENT IN DETAIL · p. 16

C TRAINING STAGES AND SCALING

This appendix describes WorldCast’s training stages and scaling experiments. Camera-aligned player-state injection outperforms token-fed alternatives in rendering players, while the appendix also reports distillation and cross-view depth agreement.

C TRAINING STAGES AND SCALING

  • From stage 2, the foreground weight emphasizes visible other players, assigning a center weight of 3 to a near player and at most 7 to a distant one.The map uses a unit-peak Gaussian on the 24 × 42 latent grid and is normalized by its batch mean.Source: C TRAINING STAGES AND SCALING · pp. 16–17
  • Stage 4 distills a four-step generator without memory frames in its windows, yet after 30 s it exceeds the same weights with scene state off by 1.23 dB PSNR.The reported interval is [0.91, 1.55] dB; the model generates ten blocks of four latent frames conditioned on its earlier outputs.Source: C TRAINING STAGES AND SCALING · p. 17
  • WorldCast training uses 2,637 GPU-hours, compared with 3,146 for frame concatenation and 3,110 for Solaris; each model sees 1.6M windows with player states.The training runs use different step counts and GPU configurations as detailed in the passage.Source: C TRAINING STAGES AND SCALING · p. 17
  • 0.763 of players are rendered by WorldCast at 384k windows, versus below 0.1 for models that receive player states as tokens.The authors attribute the gap to explicit camera-aligned placement rather than merely supplying states; token-fed attention must learn placement implicitly.Source: C TRAINING STAGES AND SCALING · p. 18
  • 0.84 of the other player is rendered by WorldCast, against 0.03 for frame concatenation and 0.02 for Solaris, over views with at least eight scored pairs.This comparison scores only the other player of the pair jointly generated by the baseline methods.Source: C TRAINING STAGES AND SCALING · p. 18
  • Over the last five seconds of ten-second windows, depth agreement is 0.207 for WorldCast, 0.170 for frame concatenation, and 0.179 for Solaris; recorded video reaches 0.309.Agreement is the share of pixels whose reprojected depths agree within the stated tolerance.Source: C TRAINING STAGES AND SCALING · p. 18, Table 10 · p. 18

D EVALUATION PROTOCOLS AND LONG HORIZONS IN DETAIL

The appendix details the held-out Counter-Strike 2 data, evaluation-set construction, scoring rules, and rollout protocols. It also reports corruption sensitivity for VBench and player rendering across crowding levels.

D EVALUATION PROTOCOLS AND LONG HORIZONS IN DETAIL

  • The held-out data comprise 40 matches and 1,373 rounds across Dust2, Mirage, Nuke, and Ancient; models use video at 384 × 672 and 16 fps.The training split contains 303 matches and 10,480 rounds.Source: D EVALUATION PROTOCOLS AND LONG… · p. 19
  • Ten-second evaluation windows use 64 rounds per map, while the whole-round set selects eight rounds per map using groups of three players with sufficiently long recordings.The selected players are teammates in all 32 rounds, and all methods and ablations use the same rounds and windows.Source: D EVALUATION PROTOCOLS AND LONG… · p. 19
  • Whole-round tests include GT-state rollouts with three client teammates and closed-loop deployment with all five team players as clients using predicted states.The GT-state setup gives clients recorded states; closed-loop clients estimate and publish their own positions after each block.Source: D EVALUATION PROTOCOLS AND LONG… · p. 19
  • The ten-second state-model comparison holds the generator fixed and changes GT versus predicted states; predicted-state clients initialize at GT position and then publish estimates in closed loop.Paired differences use bootstrap intervals, and alternative entity-criterion settings preserve their signs with intervals excluding zero.Source: D EVALUATION PROTOCOLS AND LONG… · p. 19, Table 11 · p. 20, Table 12 · p. 20
  • The 16 one-hour rollouts use one WorldCast client with scene state, recorded controls, and GT states for other players, across 66 to 102 consecutive held-out rounds.At each round start, the scene state is cleared and the position estimate restarts from the recorded spawn position.Source: D EVALUATION PROTOCOLS AND LONG… · p. 20
  • Under seven corruptions, imaging and aesthetic quality fall by up to 48% and 20%, while subject consistency, background consistency, and motion smoothness change by at most 3.5%.Those latter scores rise when frames are held; dynamic degree responds only to held frames.Source: D EVALUATION PROTOCOLS AND LONG… · p. 20, Table 13 · p. 20, Table 14 · p. 21
  • Rendered players are scored against the state supplied to the generator using visibility, box-size, detector, and distance criteria; position agreement separately checks whether two clients render a third player.The rendered rate is summarized by its median over qualifying views; Table 15 specifies the paired-view scoring scope.Source: D EVALUATION PROTOCOLS AND LONG… · p. 21, Table 15 · p. 21
  • WorldCast’s whole-round render rate stays between 0.79 and 0.82 with one to four other players in view.Crowding groups count visible players whose clipped box covers at least 242 pixels.Source: D EVALUATION PROTOCOLS AND LONG… · p. 21, Table 16 · p. 22

E SCENE STATE IN DETAIL

This appendix specifies how shared scene memory is stored, selected, and introduced during training. Its ablations and agreement measures report scene-state benefits after 30 seconds, with FVD remaining similar to inference-time scene-state removal.

E SCENE STATE IN DETAIL

  • After 30 s, WorldCast exceeds scene-state-off and no-scene-state ablations on PSNR, SSIM, and LPIPS; in the first 30 s, the trained-without-scene-state model is slightly ahead with intervals including zero.The ablations change one aspect at a time; Table 18 marks intervals that include zero.Source: E SCENE STATE IN DETAIL · p. 22, Table 18 · p. 22
  • In closed-loop deployment, scene state raises cross-client depth agreement after 30 s from 0.092 to 0.120, while leaving each client’s agreement with its own next latent frame unchanged.The unchanged within-client measure indicates the gain is not from a steadier depth estimate.Source: E SCENE STATE IN DETAIL · p. 23, Table 19 · p. 23
  • WorldCast and scene-state-off inference have similar FVD scores, 89.3 and 90.5; the no-scene-state-trained model scores 78.4.The passage attributes the latter difference to its weights or clean context, not to a specified single factor.Source: E SCENE STATE IN DETAIL · p. 23
  • Each client keeps at most 64 of its own memory entries, so the shared scene state holds at most 64 entries per client and 64P for P clients.Retrieval examines entries completed before a block, and its per-block cost grows at most linearly with player count.Source: E SCENE STATE IN DETAIL · p. 24
  • Retrieval selects at most one earlier memory entry covering the most missing pixels, keeping generator input to twenty latent frames regardless of client count.A memory entry is retrieved for 95% of scene-state-reading blocks in Table 3 rollouts and 96% in closed-loop deployment.Source: E SCENE STATE IN DETAIL · p. 24
  • With probability 0.8, training samples include teammate GT frames as memory; stage 3 places them before twelve recent and four target latent frames.Stage 2 instead uses 32 recent frames under bidirectional attention, and the loss weights combine αk and ck.Source: E SCENE STATE IN DETAIL · p. 24

F THE PLAYER STATE FIELD IN DETAIL

The player state field encodes other players on the generator’s token grid, combining projected player information for rendering. Ablations show that field design choices affect rendering and image-quality measures.

Channels

  • The field has 23 channels per latent-frame token grid, including coverage, log-compressed depth, relative yaw, team, headcount, controls, weapon, status, and identity information.The control channels encode the fraction of the latent frame during which each of nine keys is held.Source: F THE PLAYER STATE FIELD IN DETAIL · pp. 24–25

Splatting

  • Players are splatted onto the token grid with a Gaussian centered at projected body position; coarse fields yield a 0.708 render rate versus 0.763 for WorldCast.The kernel spread encodes sub-token position, while player size is represented in the depth channel.Source: F THE PLAYER STATE FIELD IN DETAIL · p. 25

Composition

  • At each token, the field selects the two players with the largest depth-discounted weights and combines their state channels; headcount sums peak weights and caps at four.A frame with no players to write has zero values in every channel.Source: F THE PLAYER STATE FIELD IN DETAIL · p. 25

Field ablations

  • Without camera alignment, per-player state tokens replace the field; inference-time ablations either discard the field stem output or mark every in-frustum living player visible.The visibility-off change uses the WorldCast weights and writes other living players at full confidence.Source: F THE PLAYER STATE FIELD IN DETAIL · p. 25
  • Every retrained field ablation lowers render rate by 0.03 to 0.55 in median paired per-view difference, with all 95% intervals below zero.Table 20 reports paired differences against WorldCast over views both rows score.Source: F THE PLAYER STATE FIELD IN DETAIL · p. 25, Table 20 · p. 26
  • Training without camera alignment or either inference-time change lowers PSNR and SSIM and raises LPIPS; visibility off at inference raises unmatched rate by 0.14 ([0.11, 0.17]).Removing visibility, foreground weight, or using a coarse field raises PSNR by 0.13 to 0.17 dB; late-injection PSNR and LPIPS intervals include zero.Source: F THE PLAYER STATE FIELD IN DETAIL · p. 26

G LIMITATIONS AND SCOPE

The appendix clarifies what the evaluations measure and what they leave untested, including limits in state accuracy, evaluation criteria, deployment conditions, and scope.

Player states

  • At 50–60 s, the state model’s median position error reaches 2.64 body widths against the recorded trajectory, and 39% of clients are within two body widths at 60 s.Closed-loop evaluations measure agreement on a shared world rather than whether the rollout follows the recording as errors accumulate.Source: G LIMITATIONS AND SCOPE · p. 26

The entity criterion

  • The entity criterion inherits detector errors and does not check team, identity, facing, weapon, or controls; players missed by the detector in recorded video are not scored for Rendered.Rendered counts a player as drawn when a detector finds a person within one body width of the supplied state position.Source: G LIMITATIONS AND SCOPE · p. 26

Scene state

  • Scene-state gains in PSNR, SSIM, and LPIPS hold after 30 s but not during the first 30 s; depth agreement is 0.206 for WorldCast versus 0.365 for recorded video.The depth measure compares two clients’ generated frames at the same instant after reprojection into one camera.Source: G LIMITATIONS AND SCOPE · p. 26

Number of players

  • Overlapping players are limited to two descriptions per field token and headcount saturates at four; denser crowds were not evaluated.No frame in the 32 rounds had more than four other players in view with a box of at least 242 pixels.Source: G LIMITATIONS AND SCOPE · p. 26

Clients and the network

  • Evaluations advance clients in lockstep and vary neither network delay, jitter, nor loss; stale-state effects are unmeasured, and faulty clients can alter others’ rendering.Clients use received player states and memory entries without cross-checking.Source: G LIMITATIONS AND SCOPE · p. 27

What comes from the recording

  • Rollouts use recorded first frames and positions, follow recorded controls, and restart position estimates at recorded spawn points each round; WorldCast does not determine hits, damage, or deaths.Only position and depth are estimated by the state model; other player-state attributes come from player inputs.Source: G LIMITATIONS AND SCOPE · p. 27

Maps and domain

  • All results use one game and its training maps; a new map requires recorded positions for training, and depth supervision uses public 3D map assets.Source: G LIMITATIONS AND SCOPE · p. 27

Baselines and runs

  • Each Table 8 model and retrained baseline was trained once, so tables report no variation across training runs; released Solaris and Gamma-World were timed with random weights but not scored.Bootstrap intervals resample windows or rounds.Source: G LIMITATIONS AND SCOPE · p. 27

H ADDITIONAL QUALITATIVE COMPARISONS

The appendix adds held-out round comparisons, whole-round scene-state examples, predicted-state windows, and closed-loop deployments with scene state on and off.

Held-out rounds

Whole rounds and windows

Closed-loop deployment

  • In Figure 18’s five-player closed-loop deployment, three views with scene state stay around the A-site ramp, agree on landmarks, and show teammates ahead.Source: Figure 18 · p. 31
  • In Figure 19, scene-state views show players pushing from mid to A site with teammates ahead, while scene-state-off views remain in a corner or face a wall.Source: Figure 19 · p. 31

Related papers

Loading 2610.12412v1…