Skip to content

Step 07: Multiple Maps & Streaming

Jump to bottom
BavGames edited this page Jul 23, 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.

The FIRST time you load the slot in a map it has never been saved in, there is simply no world data for it yet - the load still succeeds: players and registered objects restore, the world part is skipped, and the map's chunk appears with its first save. Your Begin Play -> Load Game works unchanged on brand-new maps.

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

Changing maps (Open Level)

The simple pattern just works - each map takes care of its own data:

  • GameMode End Play -> Save Game (Async)
  • GameMode Begin Play -> Load Game (Async)

Behind the scenes: when a map change (or quit) starts, the system snapshots the whole world before any actor shuts down. A save fired from End Play writes that snapshot - real state, not a half-torn-down world. Loading one frame early is equally fine: the system defers the load until the world has begun play. The log confirms it:

LogUSS: World teardown: snapshotted 213 actor record(s) for saves fired during shutdown.
LogUSS: Save 'World1': fired during world teardown - writing the state snapshotted at teardown start (213 record(s)).
image

The snapshot costs one capture per map change (Capture World On Teardown setting, on by default). For huge worlds where that capture is too heavy, turn it off and save during gameplay instead (autosave, or a save right before Open Level).

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.

image

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.
image

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

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%.

With Verbose Logging on, 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

Apply the player's saved position from the pawn's Begin Play (Restore Player Pawn, or a manual teleport via Get Saved Player Transform - see Step 06). Done there, the player is placed on their first frame and never watches themselves snap into position while the world streams in behind them.

Next: Step 08: Autosave & Checkpoints

Clone this wiki locally