Skip to content

Step 07: Multiple Maps & Streaming

Jump to bottom
BavGames edited this page Jul 11, 2026 · 4 revisions

One slot holds your whole game - every map, separately.

Multiple maps, one slot

Save data is chunked per map inside the slot file. Saving in map B does not touch map A's data. Loading reads only the chunks of the maps currently loaded. You never need to put the map name into the slot name.

Map identity is the map's package path (PIE prefixes are stripped), so editor saves load in packaged builds and vice versa.

Level streaming & sub-levels

Streamed sub-levels are supported out of the box - your streaming setup does not change:

  1. Put Saveable Components on actors in sub-levels exactly like anywhere else.
  2. Stream levels the normal Unreal way (Load Stream Level, World Partition, level volumes).
  3. Save with any mode - each sub-level's actors land in that sub-level's own chunk.
  4. Load with Load From Slot Streaming (on the Save Subsystem). Levels that are currently visible restore immediately, and the slot stays MOUNTED: a sub-level shown LATER automatically reads and applies only its own chunk the moment it appears. The rest of the file is never touched.

Hidden levels are never forced to load - data waits in the file until the level is shown. You can also mount a slot without loading anything now (Mount Slot For Level Streaming) and stop the lazy restore with Unmount Level Streaming.

Sync vs Async vs Streaming

Mode When to use
Save/Load Game Small scenes, loading screens. Blocks one frame.
Save/Load Game (Async) Default choice. File work on a background thread; result via events.
Save To Slot Streaming / Load From Slot Streaming Very large worlds (tens of thousands to millions of records). On the Save Subsystem. Work is time-sliced with a per-frame budget - the game keeps running with no hitch.

Streaming behavior is tuned with three Project Settings: Capture Budget Ms Per Frame, Streaming Memory Ceiling MB and Max Records Per Chunk (see Step 5).

Very large worlds (millions of records)

The recipe for survival-scale games:

  1. Use the streaming nodes - Save To Slot Streaming / Load From Slot Streaming. They never hold the whole save in memory: one sub-chunk is resident at a time, work is sliced by the frame budget, and the game keeps running while the save streams.
  2. Split the world into streamed levels or World Partition cells. Chunks are keyed per level, so a load only ever pays for what is currently visible.
  3. Tune the three Performance settings to your target hardware:
    • Capture Budget Ms Per Frame: 2 ms is safe at 60 FPS; raise it on loading screens.
    • Max Records Per Chunk: higher = better compression, lower = smaller memory spikes.
    • Streaming Memory Ceiling MB: hard cap for resident chunk data during restore.
  4. Only mark what matters. A Saveable Component on pure decoration wastes file size and restore time. Use the component's Save Policy to limit which components are captured.
  5. Let the fast path work for you: actors still at their saved state cost almost nothing to restore. In a huge world where 1% changed, restore work scales with that 1%.

Every load logs its timing - this line is your benchmark while tuning:

LogUSS: Restore: 300 in place, 0 respawned, 0 tombstoned, 0 skipped, 0 removed (2.9 ms)

Multiplayer at scale: gameplay-relevant actors (structures, creatures) should be normal Replicated actors - Unreal's own relevancy streams them to clients. The plugin's load sync handles the non-replicated remainder in paced batches.

Player experience during async/streaming loads

The player's saved position and camera are applied on the very first frame of the load, so they never watch themselves snap into place while the world streams in behind them.

Next: Step 8: Autosave & Checkpoints

Clone this wiki locally