How should I manage levels in a strategy game for max performance?

Development World Creation
,
1

I am working on a strategy game which should switch between these scenarios:

  • A map for building a base like a city builder.

  • A grand strategy style world map to move troops around and manage diplomacy.

  • A RTS style fighting map to load when troops on the world map engage.

The first two need to be able to load and switch back and forth instantly.

I am relatively new to the level system in UE but I know about how variables and blueprints do not get passed when switching levels, which is a trouble for me since I would like to keep all the data I stored in some actor blueprints. I cannot do the hide map somewhere else, then teleport cameras method, since the RTS map has to be generated differently for every fight, also because in multiplayer each player should have their own base builder map.

In this case, how should I manage or structure my levels to achieve the functions and optimization for performance? Any idea will help. Thanks in advance!

2

the important reframe: your state should not live in level actor blueprints at all, because then every level switch destroys it no matter how you load. move it out first:

  • persistent data goes in GameInstance subsystems (or PlayerState for per-player stuff). they survive all level transitions, streaming or not, in multiplayer too. this removes your variables-dont-carry-over problem entirely.

then structure the maps like this:

  • one persistent level that is always loaded. it holds the managers, the game mode, streaming setup, nothing visual.
    • city builder map and grand strategy map as sublevels, streamed in and out with Load Stream Level (async). for instant back-and-forth, keep both resident if they are small enough and just toggle visibility with Should Be Loaded/Should Be Visible, that is effectively free switching.
      • the RTS fight map: do not make it a separate persistent map, because you need one generated per fight and per-player variants later. make it a streamed combat sublevel that you populate at engage time (spawn the armies, build the terrain dressing) and reset when the fight ends. generating content inside one reusable streamed level is far cheaper than managing many maps.
        • per-player bases in multiplayer: separate streamed levels per player scale badly. better to spawn each base as actors under an ownership folder in one shared streamed level, or if bases must be isolated, accept only a handful of players with levels.
      • if the world map gets big, World Partition with data layers is the upgrade path, but for a strategy game with distinct screens, plain level streaming plus a GameInstance subsystem is simpler and does exactly what you described.