If game object disabled, performance?

Unity Engine
1

For avoid scene loading, changing, I adopt following strategy from someone’s advice.
Is this effective?

My game has several 3d stages, each stage consist of small field objects and terrain which is low poly, low drawcall models.

From start, put out all stage’s mother gameobject (it has all its chilren gameobjects consist of that scene) to starting scene.

And deactive(disable) whole stage gameobjects except current playing one.

After user finishes playing one stage, turn it off.

So only turn on stage that user play now.

So there is no stage gameobject killing, no instantiating, no scene changing, no destroying.

Is this effective way to make scenes, stages, game?
If not, what is more good?

Thanks.

2

The problem with this method is:

  • Your starting scene will take longer to load. Because it is loading a lot of unused objects, it takes extra time.
  • Your scene will use extra memory. The unused objects take up memory even when not active.

A better way is to only load scenes when you need them, and destroy scenes you are not using. This will keep your game “lean and mean”.

3

Then how about instantiating stage mother object and play it, and destroying it after?
This will not take memory, and also can avoid scene changing?

4

What you describe looks like “pooling”. It’s a legit way to optimize your game but keep in mind it needs to be a compromise between performances and development cost.

There is nothing wrong with a bit of loading time between levels as long as it’s reasonable. Object pooling is mostly useful to avoid garbage collection spikes during gameplay and you can have your pool as a “don’t destroy on load” gameobject.

5

Instantiating prefabs and additively loading scenes is practically the same thing. Instantiate is less flexible though, as you can’t Instantiate prefabs asynchronously. Yes it will do what you want, but why are you so averse to scenes?

6

If, for example, you’re making a The Legend of Zelda clone, and each scene (additive-loaded) is each area the player enters in a level by walking through a corridor in the previous scene, then sure, it’s fine to pool them in the way you’re describing, because these would be very small scenes containing few GameObjects.

If you’re making a typical game though where your scenes are large levels containing tons of GameObjects, then you’d be putting some very heavy strain on system memory by pooling them like this.
Scene loading in this context is one of the few cases where it’s okay for the user to wait while the game instantiates a huge amount of objects at once. It would be better to take advantage of that instead.

Maybe scene loading takes a really long time for your game and you don’t want players to be waiting for that long. If it makes sense for your game, you could try doing what God of War (PS4) did, where they put the user in a small mini-scene to interact with while the game unloads the previous scene & loads the next main scene.

Bottom line though:
Don’t pre-optimize. Try going with typical scene loading first, and if you find that it becomes an issue (loading is too long/too frequent), then try a different approach instead.

1 Like
7

My game is similar with Monster Hunter World, or Most mobile RPG game. Start from lobby scene (Just 2d back images, few 3d models), and then should go to 3d Stages consisted of few low poly back models and hexagonal lands, which is not a big quantity. Then go back to lobby UI scene. These can be played in just one scene I hope.

Why I hate scene changing is…

  1. At first it will cause many bugs and generate many decision points of what should be permanent objects between scene. (though mostly game logic scripts contained objects will be that)

  2. I have many scripts consisted gameobject and those has many public variables that references to scene’s UI objects, gameobjects.
    If scene changing, all these reference will be decouples maybe?
    Then I should change variables structure to not referencing via drag&drop to inspector, but to scripting way like “GameObject.Find(”…“)”
    These are painful works…