Hi, in your guys’s experience, in a game comprised of different, totally unrelated, not physically connected worlds, which are in turn made up of multiple smaller levels, obviously related and connected to each other, what is the best way to organize your levels so that it allows for loading screens between these worlds, in such a way that your worlds can actually load while the loading screen is running (on a different thread). Is it through open level or level streaming. Loading screen would be animated.
Thanks.
Hey @AllGamesSuck!
So what you would want to do is use “Open level” for the worlds themselves, and then level streaming for the smaller connected pieces.
I think this thread said it pretty well, so I’ll link you to their description! 
1 Like
Thanks. Do you know if there would be any issues with level streaming, on cooking and such?
I read some people had lighting spill from one level to another on cooking.
That’s very much a “Your mileage may vary, cross that bridge when you come to it” situation. I hate to be “that person” but… planning is a very good thing to do, but once you’ve planned it is better to do something and figure out your issues than spend forever planning!
I know. The thing is, some of the code will be different too, depending which way I choose. So, I wouldn’t want to go back and change it. Like, level transitions, saving/loading, or who knows what else along the way.
I mean regardless of which way you choose, there are going to be hurdles. Check and test often, MAKE BACKUPS OF YOUR PROJECT REGULARLY, every day you work on it at minimum (I cannot stress this one enough and too many people don’t do this). As far as the lighting spilling from one level to another on cooking, that could have been an edge case, I haven’t ever run into that.
But with a million+ moving parts you’re going to have weird things happen. If someone had an issue with cooking lights, for instance, the issue isn’t level streaming- it is likely the static meshes or the lights themselves- placement too far into the static mesh so it doesn’t block the light, making the light part of the persistent level, etc. You do the big stuff then figure out the small problems. But the way you are describing how you would do level transitions means you should definitely go the way of load the larger worlds with “LoadLevel” and then use level streaming as you go for performance reasons.
1 Like
You mean ‘open level’ on the large worlds?
The ‘larger’ worlds could also be partitioned for performance, right?
I learned that with level streaming there’s no need for save functionality for anything that resides in the Persistent level (except saving to disk), and you can actually get proper loading screens, not possible with open level unless you C++ your game instance to use a different thread for the loading screen. So it seems it’s the better option by far, unless there’s some serious downside to having all your game in one persistent level?
Yes, sorry, I meant “Open Level”.
You would use Open Level to load the primary piece (the Persistent Level) of your “not physically connected world” and then load in pieces as necessary with level streaming. Think of it like this:
You OpenLevel to go to “Paris”.
The streets and buildings are part of the persistent level.
You go to walk into a house. Before touching the door, the inside of the house does not exist. You touch the door handle, then stream in the “house 1” level, populating the inside of the house. You look around, then upon leaving, when the door shuts behind you, “house 1” is then unloaded to free up memory, so you can go into every house and have them detailed without having to load the entire city of Paris before arriving.
As far as larger worlds being partitioned for performance, you’re most likely going to just have to be creative with occlusion/frustum/distance culling and not overload the system with rendering absolutely everything. Hills and buildings in open world games are functioning as performance boosters!
1 Like
Makes sense. The thing is, if you only go one way, you don’t have to adapt the code for both open level and level streaming.
I’m gonna try level streaming first and adapt later if I need to.
Thanks for the advice.
Yeah, so using level streaming for now. I’ll tick this as the solution. Will try to use one Persistent level for the whole game, it’s a lot more flexible than open level.
^This^ is the most boring advice ever, and yet its absolutely the right advice.
Anytime you assume things in tech its dangerous, especially so in game dev.
Crucial to your very survival. Advanced Projects often fail just for this reason.
^This^ contains some dangerous assumptions already (from your other thread). Ask anyone whose ever experienced hangs in async level-streaming. 
So you need to prototype and stress test all of your assumptions now by building test-levels asap. Then afterwards, when you have the core setup working, be careful about upgrading or downgrading the engine once again, just to meet some promised new feature or claimed stability. As always upgrading the engine is risky (Russian Roulette suckers game). Unless you have a team of talented C++ coders about, that can fix whatever regression bugs have crept into the engine that release.
Overall, complexity is your enemy here. So if you can get away with anti-complexity or just 1 persistent level, great. If not, if you can get away with just using basic level-streaming, then great as well. But once you start bolting on heavy landscape use or world-partition or manual streaming or a mixture of things, stuff tends to break. So test your assumptions early on in PIE / Standalone / Packaged / Multiplayer now, and again continuously as advised. You can actually have everything from two worlds loaded at the same time (remember to boost paging-file size). Set half as hidden / unticked / no collision. Then customize the lighting setup as needed. However, like everything else in game dev, there’s usually an art to it and gotchas to figure out.
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.