koobas.hobune.stream
Empty game objects - too much?
Is it bad to have a lot of empty game objects for your game? I am working on a side-scroller and utilize empty game objects alot - primarily for moving enemies and platforms between two points (e.g., 5 enemies would mean 10 empty game objects). I plan to build this game for iPhone and Android devices so i'm trying to improve performance in anyway possible.
There shouldn't be performance impact with empty game objects cause they are only pivot points in space (X,Y,Z), unless you have like million of those :).
But for moving object between 2 points I would use programming, or Tween class.
The only performance impact I can think of that empty game objects would presumably slow down Find commands to some extent, but you shouldn't be doing those a lot anyway.
Sorry to bump this but I am doing a racing game that has huge courses. I'm going to have hundreds of waypoints which are just empty game objects. This shouldn't affect performance?
EDIT: $$anonymous$$ake that thousands.
@POLYGA$$anonymous$$e Your scenario isn't inherently a problem, but it's reaching a point where certain operations may be expensive enough to cause a performance hiccup. Be careful to avoid unnecessary lookups, especially anything that might require an O(n) operation against GameObjects in the scene.
@rjdfhorn2006 Among other reasons not to create too many game Objects, there is a limit in the number of game objects you can create in one scene. Some reported a crash after creating 16K or so, some say the limit was 5000. (Refer https://answers.unity.com/questions/365552/why-would-you-use-a-scriptable-object-versus-an-em.html?_ga=2.88130203.1241098326.1611400501-548920451.1586375942) In any case, it is not desirable to create too many game objects even if they are empty, as others mentioned, since it will undermine the performance overall.
I can safely point out that there's no actual limit to the amount of game object you can add to a scene for as long as their relevant memory allocation doesn't exceed the devices memory.
To put it bluntly, an empty game object comes with a tiny overhead of a few bits (for its object ID which is used as reference by the Engine) and a total of 9x 16+2 bits float value. In other words, each empty object is approx. 162 bits + its overhead and that's in a built game.
Remember that, in the case of the Editor, there's a bigger overhead since each game object may also generate a UI icon in the Hierarchy window. The one way of reducing this overhead is to set a proper parenting system with grids within grids. $$anonymous$$ost of the people's crash comes from this single point where they generate 5000+ game object in a way that makes them appear right into the editor's Hierarchy and, that in particular, is heavy.
I'm currently working on a game that generate, at this moment, a grid with 1,000,000 empty game objects with a parenting system of 100 per "layer". • 100 squares per Block (10x10 squares) • 100 Blocks per Zone (10x10 blocks) • $$anonymous$$ap has 100 Zones. (10x10 zones)
In reference and size, 1 zone is 1km x 1km while 1 game's unit = 1m relatively speaking. All is managed by a script, but instead of calling it through the Awake() method, I'm passing the creation through a Coroutine as it allows me to pass the instantiation through more than 1 single overpacked frame.
