we are currently tasked with an office-simulation / sports-manager-game, which consists of a lot of different screens (recruiting, training, matches, statistics, etc, and a lot of sub-screens…) which can be navigated by the player more or less at will.
Now, I wonder how you would organize this:
A) Every screen is one scene
B) All screens are prefabs within the same scene, which are constantly being shown or hidden
C) All screens are prefabs within the same scene, but they are being instantiated on demand and destroyed immediately afterwards
D) A hybrid solution, like using a scene for every group of screens, which then are shown and hidden within that scene
I guess “pooling” would be B) .
Any thoughts?
The goal - of course - would be efficiency and performance (it’s going to be a WebGL game).
Ah, and one more thing: Is it even necessary/beneficial to use different scenes instead of instantiating and deleting screen-prefabs from code?
Somehow, I have the notion of changing scenes being a clean “cut” in Unity, like removing everything (that is not static) and instantly running the garbage collector, thereby completely freeing memory. But thinking of it now, I realize this being nothing but assumption. Maybe changing scenes does nothing that deleting everything wouldn’t do?
Prefab implies the object is going to be used more than once.
Meaning, one more option exists:
E) All objects are within the same scene and are shown/hidden when needed. They’re not necessarily prefabs.
That’s what i’d end up using, most likely.
“B” is not really pooling, as pooling implies that the objects are instantiated when the pool is empty, and then are hidedden and stored in the pool, when they should’ve been destroyed. If the pool is not empty, objects from the pool are being used instead.
Is it even necessary/beneficial to use different scenes instead of instantiating and deleting screen-prefabs from code?
Your entire game can be implemented as a single scene. So no. It is not necessary. Also scenes can be loaded additively.
Regarding E) : We are a team, so using Prefabs would have the benefit of people being able to edit screens (=prefabs) individually instead of everyone working in the same scene, showing/hiding different screens, and causing giant merge conflicts in git. Also, I thought it was best practice to make everything a prefab? (see f.e. Game Platforms recent news | Game Developer )
Regarding B) & pooling: Yes, you are right. What I mean is, performance-wise pooling ends up being the same as showing/hiding gameobjects.
Determine your memory budget. If your screens will all use a lot of unique high res images, you might not want all of the images loaded into memory at the same time. Otherwise, if that’s not an issue, (B) sounds good to me.
Thank you! At this point in the development, I cannot really forecast how much memory is gonna be needed. But I think I found a solution by using the Command-pattern and having an AddScreenCommand and a RemoveScreenCommand. Inside them I’ve got an implementation for both, pooling screens as well as instantiation + deleting, so I can toggle between both approaches whenever I want. Later in the process, I will profile and check which got better performance.
At the same time, I’m happy to hear more opinions!
You can always make worse case estimate, and use that, ie what is the maximum overdesign screen you can stuff. Determine asset placeholder that have the same technical cost for zero artistic works, so you can set up a test scene. Design around that.
True. Given that it’s a sports management game, there’s the possibility of a lot of portraits of athletes, photos of play, etc. Those were what I had in mind.
Additive loading and nested prefabs have made this question much more fuzzy than it used to be. There isn’t much functional difference between a scene and a prefab anymore.
I would be choosing between option B and option C.
B (enable and disable) will take the least processing power on switching. But it will cost you more memory, and possibly processing power if you leave anything running in the background. This makes sense if you are going to be switching between screens a lot.
C (instantiate and destroy) will be slower to switch screens. It might not be enough to notice. But it will cost you less memory. This makes sense if you aren’t switching screens very often.
One common hybrid approach is to instantiate on the first visit, then disable/enable afterwards. This means you aren’t wasting resources on an area the player never visits. But once they do visit, you get fast switching. For bonus points you can always do the load during non critical times.
Of course, depending on your game type performance might not matter at all.
I’ve actually got a lot of use out of using prefabs of single items to prevent merge conflicts when working with a team. A prefab represents a nice small chunk you can work on without disrupting the rest of the scene. As such we ended up with a lot of single use prefabs. This is especially useful in UI.
