How should I structure my game: world partition or streaming levels?

Development Programming & Scripting Blueprint
,
1

Hi, my game would consist of multiple “worlds”, if you will, that are thematically different from each other.
Each of these “worlds” consist of one or more small enclosed AREAS for the player to explore. Anything outside those areas will be just background. I’m not making an open world.
These areas may be close or far from one another. They may be visible, or not, to each other. But the player will never walk from one to another, rather be quickly transported between them by various means.

What’s the best way to approach this?
Is it Persistent levels using world partition, or just one persistent level with level streaming, or is there any other way?
I was thinking to avoid using multiple persistent levels because that blocks the game when loading them, hence no async loading screens.
Thoughts?

2

To figure this out, the best thing you can do is try both methods and see which one works for your game.

1 Like
3

Hello there @AllGamesSuck!

If you are making separated instances, then the best approach would be streaming levels, as world partition is designed for big, open worlds with seamless connections. You could use a single, persistent level, as a matter of home base or hub world, which then connects to the other enclosed areas.

This same topic was encountered in the following thread, and reached similar conclusions, and a few interesting tidbits:

In case you need a refresher, or end up testing world partition as an alternative as well, here are some resources from the UE community on all subjects:

1 Like
4

Thanks. After doing a bit of thinking, I realised that for my specific use case, I cannot go with world partition for multiple reasons:

  • Couldn’t use streaming volumes if I needed to, because my levels occupy the same 3d space most of the time. They’re just loaded separately. And World Partition relies on your game world being one continuous landmass.
  • It would be significantly harder to adapt my saving system to accommodate the use of data layers.
  • Loading/unloading chunks of the map wouldn’t bring much benefit because my maps are usually small. And I want the background geometry to be visible most of the time.
  • I would have to load/unload persistent levels and that locks me out of having async loading screens, and I want to avoid c++ as much as possible.

I’ll tick this as a solution because I think it answers the question a bit better for people in my situation.