2D open world - one single scene vs multiple scenes, performance concerns

[kzkkzm]

I’m working on a 2D open world game. The game begins with some ‘minor’ introductive scenes, and then the open world part begins.
And well, that’s when I hit my doubt: should the open world be implemented as one enourmous scene containing all of the GameObjects of the open world part… or multiple minor scenes, with the issue of introducing a loading time / transition which would (could?) impact player’s experience negatively?

Obviously, my preference goes towards one big scene, for a number of reasons. But: I lack enough experience in Unity 2D to properly evaluate the impact of this design choice on the long run, especially from the performances PoV. So, those are my two main concerns (apart from other standard ones, such as memory usage):

• Unity culling implementations. This is an open point for me: how much is it effective? Does Unity effectively cut-out the cost of rendering GameObjects currently not seen by the player (out of camera view)?
• Update() and FixedUpdate() routines. Most of those on the GameObjects I’m implementing do actually nothing as long as the player is not ‘infighting’ them or is close enough to the GameObject to trigger some ‘activate’ routine. But still: those cycles are running. What’s the actual impact of having a ton of GameObjects running thought their Update and FixedUpdate routines, even if most of those do nothing?

As a strategy to mitigate the performance hit in this scenario, I was thinking about a scanner routine on the player. This should every X seconds and evaluate the presence of such GameObjects around the position of the player, activating them only if distance < a certain threshold. That could mitigate performances issues by playing around the ‘active’ state of GameObjects but… would that have an impact? Is this a shot in the dark?

So, in conclusion: do you have any suggestion between one scene / multiple scenes? What’s the best scenario to accomodate Unity’s engine? Am I ignoring other concerns or possible solutions / workarounds which I did not specify in this thread?

[Kurt-Dekker]

Every performance parameter is dependent on the hardware you’re running it on. How it runs on a $5000 ultra crazy gaming rig is going to be different than a $50 cheapo Android device.

Everything else will be somewhere in between.

Predicting the performance of unwritten software on unspecified hardware is a complete waste of everybody’s time.

Organizing the project as one scene vs many scenes is a matter of preference, workflow, possibly performance and many other concerns.

Additional reading:

---

DO NOT OPTIMIZE “JUST BECAUSE…” If you don’t have a problem, DO NOT OPTIMIZE!

If you DO have a problem, there is only ONE way to find out. Always start by using the profiler:

Window → Analysis → Profiler

Failure to use the profiler first means you’re just guessing, making a mess of your code for no good reason.

Not only that but performance on platform A will likely be completely different than platform B. Test on the platform(s) that you care about, and test to the extent that it is worth your effort, and no more.

Is it still worth optimizing square roots in 2021+?

It depends on the target architecture and runtime library of course, as all computer code runs on the actual CPU where your game is running, not some “theoretical magical global CPU of today” construct. But in 2021 a floating point unit (FPU) is pretty standard on most targets. All that said, don’t do needless work, especially on mobile, as that just burns down battery life. If you suspect you have a performance bottleneck, DO NOT START MAKING OPTIMIZATION CHANGES!! Instead, start with the …

Remember that optimized code is ALWAYS harder to work with and more brittle, making subsequent feature development difficult or impossible, or incurring massive technical debt on future development.

Notes on optimizing UnityEngine.UI setups:

How to efficiently copy transform data into an array

Just so you know, the entire UnityEngine.UI system is available in source control from the package manager (and from github) and you can look at it and probably see there isn’t going to be a lot of fat. If there are some particular specific widgets you use in there that are too slow because of the use-generalization assumptions made, you might be able to get some benefit by tweaking them, but since so much of mobile performance bumps against pixel fill bounds, it’s unlikely to get you much ben…

At a minimum you want to clearly understand what performance issues you are having:

• running too slowly?
• loading too slowly?
• using too much runtime memory?
• final bundle too large?
• too much network traffic?
• something else?

If you are unable to engage the profiler, then your next solution is gross guessing changes, such as “reimport all textures as 32x32 tiny textures” or “replace some complex 3D objects with cubes/capsules” to try and figure out what is bogging you down.

Each experiment you do may give you intel about what is causing the performance issue that you identified. More importantly let you eliminate candidates for optimization. For instance if you swap out your biggest textures with 32x32 stamps and you STILL have a problem, you may be able to eliminate textures as an issue and move onto something else.

This sort of speculative optimization assumes you’re properly using source control so it takes one click to revert to the way your project was before if there is no improvement, while carefully making notes about what you have tried and more importantly what results it has had.

---

Additive scene loading is one possible solution:

Right way for performance, divide scene?

I always favor breaking the scenes up and loading additively. reduces overall memory consumption lets multiple team members trample on each other less often ensures clean “reset” of all objects in a fresh loaded scene I’m working on a game now where we each have our own “content” level, the level we’re working on. the content scene has all the lighting baked in. Just press play and that level has one script that additively loads: music scene (just an audiosource on autoplay) the …

Right way for performance, divide scene?

Glad you asked… going this route definitely requires slightly-higher awareness of what scene is what. In no particular order, responding to you questions, When the game or level is over, I try to go to a fresh “end level” scene (not additively!) and clear everything else out (except overall ongoing game manager obviously, as a singleton) when the game gets paused I stop time and bring up a pause scene that sorts above all else, then unload it and restart the time. OR if you quit, I just …

Problem with canvas & UI prefabs

There are underlying reasons this happened and you can track it down by examining everything about each scene’s canvas setup and scaling that are different from the other. But keep in mind it might not be super-easily to address it in the general case, especially if you start partitioning your UI into chunks. An alternate workflow is to put chunks of your UI into separate scenes and then load those scenes additively. For instance you might have the following scenes, all loaded additively: c…

A multi-scene loader thingy:

Unity additive scene loading example - Pastebin.com

My typical Scene Loader:

https://gist.github.com/kurtdekker/862da3bc22ee13aff61a7606ece6fdd3

Other notes on additive scene loading:

Removing Duplicates on Load Scene

Why not remove the player from ALL your scenes, put him in his own separate scene, then load scenes additively? That way you don’t even need a Player prefab at all, just have a Player scene and load him additively. I tend to break up all my games into partial scenes, all additively loaded by the game manager: UI player enemy manager other stuff? and then finally I load the content scene. The first batch of screens all have scripts that do nothing until the content scene appears and they kn…

Timing of scene loading:

Function called from preloader script doesn't change parent of gameobject (in the second scene)

If line 8 relies on something being present from the scene load in line 7 (in GameController), it won’t be: scenes are loaded at the end of frame and would never be available until the next frame, at the very earliest. You can trivially make void Start() into a coroutine by declaring it to return an IEnumerator, then put a while loop (with a yield return null; in it!!!) to wait until the scene loads and you find the “Trains” object, then proceed. Obviously you would need to interlock other thi…

Also, if something exists only in one scene, DO NOT MAKE A PREFAB out of it. It’s a waste of time and needlessly splits your work between two files, the prefab and the scene, leading to many possible errors and edge cases.

Two similar examples of checking if everything is ready to go:

Daily Events and content changes

I think multiple scenes are definitely worth chasing. You need to make everything in your game tolerant of perhaps not having stuff ready at the same time, and you have to track things that you need only ONE of: Camera (Main) Audio Listener EventSystem I like to put all of those in the BASE scene if possible, then load other scenes like UI and pause and the level itself, etc. You have to sort of figure out which works for you. You can actually make Start() be a coroutine too, such as lookin…

Unit scripts calling Start function before other scripts

Indeed. I like to use a lot of additively-loaded scenes, so I tend to code my individual item controllers (including the player controller) so that they are happy to wait around if other stuff isn’t ready yet. You can make Start() into a coroutine, which is a super-easy way to get this kind of lazy-sloppy startup that is extremely tolerant of late loading and uneven loading. // typical base framework for all entities bool ready; IEnumerator Start () { // don't proceed unt…

[DragonCoder]

@kzkkzm

• Unity culling implementations. This is an open point for me: how much is it effective? Does Unity effectively cut-out the cost of rendering GameObjects currently not seen by the player (out of camera view)?

Unity does do culling based on the “bounds” of whatever is being rendered. You can experience this with the isVisible property of any renderer: https://docs.unity3d.com/ScriptReference/Renderer-isVisible.html
However this check does happen constantly in the background so it does add some workload.

@kzkkzm

• Update() and FixedUpdate() routines. Most of those on the GameObjects I’m implementing do actually nothing as long as the player is not ‘infighting’ them or is close enough to the GameObject to trigger some ‘activate’ routine. But still: those cycles are running. What’s the actual impact of having a ton of GameObjects running thought their Update and FixedUpdate routines, even if most of those do nothing?

Are the Update and FixedUpdate() truly needed? Can’t the player itself launch some Coroutine on the objects when nearby instead?
So called “busy waiting” is indeed a possible performance killer if you have >10000 objects on medium desktops (on mobiles way lower).
Disabling the objects fully does help, albeit it leaves a memory footprint.

For the actual impact, it depends a lot what your target hardware is. Gaming desktops or low end smartphones?
Note that objects in the scene also have a memory load. And so do textures (and meshes). Especially if your open world is so large that it has different “biomes” of some sort, doing everything in one scene directly would mean that all textures are constantly in memory even if the player would need to wander ten minutes to reach a location where a particular texture is used.

Besides splitting into completely separate scenes there are many techniques one can use. Additive loading/unloading of scenes is one option. A common technique is to store data needed to instantiate all (or most) objects in some grid datastructure. Then you dynamically load/unload cells of that grid and instantiate using an object pool (in that case you would have to additionally manage the texture memory).

[quote=“kzkkzm, post:1, topic: 913968, username:kzkkzm”]
As a strategy to mitigate the performance hit in this scenario, I was thinking about a scanner routine on the player. This should every X seconds and evaluate the presence of such GameObjects around the position of the player, activating them only if distance < a certain threshold. That could mitigate performances issues by playing around the ‘active’ state of GameObjects but… would that have an impact? Is this a shot in the dark?
[/quote] This technique can work as well, however try not to keep a huge list of Transforms and then access position all the time because 1. that causes a call crossing the boundries over to Unity’s c++ side and 2. means a huge number of distance checks. A custom “spatial data structure” tends to be far better to determine what’s nearby (you find a lot of info on those online).

Best if you do experiment yourself to see where the limits are and to familiarize with the profiling tools Build for example some scripts that replicate a quick sample structure across a huge landscape and randomly swaps textures as well.
Also note that an actually built game may be a fair bit faster than in the editor.

[steven1022]

I made an open world 3d game for mobile using this asset. I was loading in and out scenes based on proximity. The world was built in sectors and this method made managing memory realistic. This would be the additive technique others are mentioning above. Profiling was key to know how many objects and how busy a single sector group could be given groups of sectors were always loaded in at the same time. For example, if I knew I had a busy town, I kept the next busy town at minimum 3 sectors away.

Scene Streamer | Utilities Tools | Unity Asset Store

[karderos]

@kzkkzm

I’m working on a 2D open world game. The game begins with some ‘minor’ introductive scenes, and then the open world part begins.
And well, that’s when I hit my doubt: should the open world be implemented as one enourmous scene containing all of the GameObjects of the open world part… or multiple minor scenes, with the issue of introducing a loading time / transition which would (could?) impact player’s experience negatively?

Obviously, my preference goes towards one big scene, for a number of reasons. But: I lack enough experience in Unity 2D to properly evaluate the impact of this design choice on the long run, especially from the performances PoV. So, those are my two main concerns (apart from other standard ones, such as memory usage):

• Unity culling implementations. This is an open point for me: how much is it effective? Does Unity effectively cut-out the cost of rendering GameObjects currently not seen by the player (out of camera view)?
• Update() and FixedUpdate() routines. Most of those on the GameObjects I’m implementing do actually nothing as long as the player is not ‘infighting’ them or is close enough to the GameObject to trigger some ‘activate’ routine. But still: those cycles are running. What’s the actual impact of having a ton of GameObjects running thought their Update and FixedUpdate routines, even if most of those do nothing?

As a strategy to mitigate the performance hit in this scenario, I was thinking about a scanner routine on the player. This should every X seconds and evaluate the presence of such GameObjects around the position of the player, activating them only if distance < a certain threshold. That could mitigate performances issues by playing around the ‘active’ state of GameObjects but… would that have an impact? Is this a shot in the dark?

So, in conclusion: do you have any suggestion between one scene / multiple scenes? What’s the best scenario to accomodate Unity’s engine? Am I ignoring other concerns or possible solutions / workarounds which I did not specify in this thread?

you should do one large scene, but you are not supposed to have all the game objects in the scene. You are supposed to do it like minecraft, where you load objects and terrain from disk, based on proximity from the player. You would do this in chunks, whenever a player approaches a chunk that chunk is loaded and all the terrain and objects in that area are loaded into the game from disk. On the same token, when leaving an area that area is unloaded and saved to disk, this will make sure that you always have only the needed amount of objects and terrain that are needed and ensures good performance.