Matrix-Game 4.0: Plan Scene Downloads Before Running

Choose a scene before downloading the release

To plan a Matrix-Game 4.0 download, select one scene, include its shared dependencies and preserve the manifest’s source-to-local path mappings. Our offline audit of the pinned October 16, 2026 manifests finds about 24.26–24.36 GB of declared payloads per scene, versus 44.43 GB for all three. Those figures are file-size sums, not memory requirements or measured transfer sizes.[3][4]

Skywork announced Matrix-Game 4.0 on X on October 15, 2026. The release pairs conventional game-state control with neural rendering. For a creator evaluating it, the first practical question is which files belong to the chosen scene. This guide answers that with a reproducible resource audit rather than repeating launch performance claims.[1][9]

Start with the supplied scene, not an arbitrary asset

The published resources separate Castle, Ancient Egypt and Racing, with scene-specialized model files. A scene selection is therefore more than a scenery preference. The model card describes an inference release, not a drop-in Diffusers pipeline or a complete training pipeline for converting your own game into a supported scene.[9]

Choose one supplied scene as the first evaluation target. Write down the source commit, scene name and intended runtime mode before gathering files. Keep a separate acceptance checklist for visual stability and gameplay correctness: a completed download cannot establish either.

Count shared resources once

We ran an original Python standard-library audit against models.json and game-assets.json at source commit 56c61df7a3b1e63bed2340ebf7417ab1e1bdf67b. It follows the downloader’s shared-plus-scene selection and sums declared integer sizes. It neither retrieves model payloads nor runs the game. The companion includes 17 passing tests using small synthetic metadata.[3][4][6]

The shared-only row is an analysis aid, not an upstream CLI scene option. Adding the three scene rows would count shared resources three times. For these inputs, the all-scenes total equals the sum of those rows minus twice the shared row. The upstream selection also includes shared shooter assets in a Racing selection; the audit preserves that behavior instead of guessing which files can be removed.[6]

The full game-asset manifest accounts for 192,443,138 bytes. The remaining 44,235,963,680 bytes belong to the model manifest, which also contains configurations, images and notices. “Model files” in the CSV therefore does not mean that every entry is a checkpoint.[3][4]

Leave additional disk space for your environment, caches, temporary files and possible cache/install copies. The audit does not estimate those costs, network duration, reuse of existing files, RAM or VRAM. A 24 GB payload total is not a claim that a 24 GB GPU is required or sufficient.

Keep three different identifiers straight

Do not flatten remote filenames into one folder. The manifest maps source paths such as fps-egypt into the local models/ancient-egypt layout. Our renamed-paths.csv records 19 explicit remaps with effective repository coordinates. It intentionally omits unchanged entries and payload hashes, so it is an inspection aid rather than a substitute download manifest.[3]

For the actual download, follow the pinned release instructions from the Matrix-Game-4 directory and select the same scene for both manifests. After downloading, use matrix-game verify with --manifest releases/models.json --scene ancient-egypt --resources resources, then repeat with releases/game-assets.json. Replace the scene consistently if you choose Castle or Racing. These are documented commands, not commands we executed against installed payloads.[5]

Reproduce the audit before spending bandwidth

Open the companion README, save the two raw pinned manifests and keep their original bytes. Download manifest_plan.py and test_manifest_plan.py together. Run python3 -m unittest -v test_manifest_plan, then run the planner with --models, --assets and --out paths as shown in the README. The outputs are byte-budget.csv, renamed-paths.csv and input-sha256.json.

Compare the two input hashes with the README to reproduce this exact snapshot. The script records whatever supplied inputs it reads; it does not authenticate their source or force a match to our hashes. Reformatting JSON changes its byte hash even if the parsed values stay the same.

The planner rejects malformed sizes, unsafe relative paths, duplicate local destinations and cross-manifest collisions. It checks every bundle before producing outputs. Hash-format checks validate metadata syntax only: they do not prove that a remote file exists, that its bytes match, or that a downloaded release will run. Keep the upstream payload verification step.

Resource completeness is only the first gate

The source documents a native game path without neural rendering and a separate model environment. Use the native path to establish controls and game behavior before debugging the renderer. Check the current documented operating-system, compiler, Python, CUDA and driver prerequisites for the path you intend to run; this audit installs none of them.[2]

Decoder choice is another reason not to treat similarly named files as interchangeable. TAEHV’s author identifies taew2_2 as the Wan2.2 5B variant and describes the tiny decoder as trading some reconstruction quality for reduced work and memory. That explains a component choice; it does not independently establish Matrix-Game’s frame rate on your hardware.[8]

Review component notices before redistribution. The release lists separate third-party components, and its racing audio includes credits and asset-specific terms. Keep those notices with the relevant files rather than assuming the project-level license settles every included asset’s obligations.[7]

Use the result to make a smaller first experiment

A sensible first milestone is one pinned scene, both manifests verified, native gameplay working and a short renderer evaluation on your actual machine. Record failures and visual drift as well as successful frames. Only then expand to another scene or investigate a custom-scene workflow.

For an independent visual prototype, Goblin3D Image to 3D can turn an image reference into a model. Start with a reference you have rights to use and inspect the result in your own scene. A generated prop is not automatically compatible with Matrix-Game’s scene-specialized renderer; keep asset prototyping and renderer support as separate checks.[10]