Neither an entirely open world nor totally linear corridors but inter-connected like soulsborne or castlevania games.
Low-poly models all around, targeting lower-end PCs
Landscape may be used sparingly but mostly it will be static meshes.
If it was year 2030 I will certainly go nuts with world partition but right now it’s still lacking some crucial features and quite unstable, thus I retract back to the old level system with world composition, which seems stable enough yet unfinished and there aren’t many released games using that?(not sure if early Fortnite uses WC). The thing is, I’d really like to utlize the convenience of distance-based streaming but it comes with its limitations compared to manual setup in regular old-fashioned level streaming.
So is it worth going for WP or WC in a case like this? Any suggestions are appreciated.
WP / WC for a 1.5km2 world??? Sounds a bit over-engineered actually. Although not exactly sure what the final actual performance goal is obviously. Usually as a developer, you shoot too high and then have to dial things back a little. Anyway, maybe talking about UE’s mesh capabilities would help here. HINT: UE is a workhorse, just as long as you stay well clear of UE’s Landscape / Terrain system.
So you can have levels with 10,000’s of actors over 100’s to 1000’s of Km without killing performance. Nod to LODS / HLODS / ISM / HISM and lighter collision of course. Typically WP / WC / Level-Streaming are all a nightmare, with just so many gotchas involved. So if you don’t need to make your life extra hard then don’t. Levels with 50k actors spread over 1000km2 are possible without any of the above.
I admit it’s a bit overthinking and premature optimization since I haven’t built larger worlds in unreal before. But it’s always better to think ahead and make workflows than redo everything later down the line. Glad to know 1.5km^2 isn’t “large enough” for distance-based streaming, and that’s a big relief!
Just digged out an old video about Fortnite. They talked about level streaming briefly and initially there aren’t any streaming for their 2.5km^2 battle royale map but the game still runs well, which says a lot.
Nothing beats a live example from Epic themselves!
Streaming was still on. Just not on the landscape.
They still had all the impostors and HLODs they needed.
Up to 4km square can do fine even when using landscape and even on a 1080 powered potato.
Provided you follow best practice ofc.
Using meshes only and a good replacement system you can easily do without any streaming up to 20km^2 the problem becomes the instance counts. You start needing a beefier non-potato CPU to get things to run and replace nicely.
The good thing is I could get rid of LODs completely as I’m making a 2.5D game in which the view distance is always set.
So the key factor is more about memory management on whether or how to unload stuff off-screen as the environment type could be varied.
In ue5 you can make your own Data Layer based system for that.
Personally, i would still do it manually.
And also, there is nothing wrong with deleting and creating actors from within another (manager) actor.
If or rather when the load gets to be too much, then you break into C++ and make yourself an Async system class to replace the actor class of the manager with (theres examples on how too by now).
Yeah I plans to go for manual management by utlizing level streaming volumes and in the end I may need to only create 10 to 20 sublevels for a game of this scale, which is totally (humanly) managable.
If it was out of control eventually I would roll out my own distance-based actor streaming system, but I feel the streaming processs could be way more complex than just spawning and destroying actors.
You could incorporate LOD management into it for instance.
Runtime mesh merge things directly into a single mesh so as to have a batch of drawcalls instead of separate ones which lead to better performance.
But you don’t really need to do any of that for low poly environs unless you really clutters things up with 1b instances…
What costs a lot, like always, is random one off things with on tick functions that get duplicated or instanced by someone who doesn’t know any better or forgot to check if they had tick stuff happening.
If you don’t do that sort of one off stuff, you dont even need to worry about the eventuality
