How many Game objects are too many? (optimizing a game so it doesn't freeze)

I’m making a game where you can design a highly customizable castle.
Because internal walls, floors, windows, etc. are constantly shifting and stretching as player tweaks the parameters, I have an elaborate hierarchy of game objects, the leaf level often containing a single quad or triangle. A segment of castle (ie a tower or short stretch of wall) would contain about a thousand GameObjects.

So far the game works great!
The only problem is that instantiating all of those game objects takes time.
Generating a single tower takes about 3 seconds during which the screen freezes.
But I want the player to be able to place segments just like: “click, click, click”.

How should I optimize my game?
Some ideas I had were:

  • Generating the castle by adding vertices and faces to a single mesh and then update the mesh by holding references the vertices which can be translated. (This would be fine for allot of stuff… but my existing system rotates chunks of wall into position around a central pivot point provided by the gameobject hierarchy. Trying to place verts without the parenting or rotation systems provided by GameObjects would require an insane amount of geometric calculations on each individual vert making the code incomprehensible.)
  • Instantly placing some crude approximation of a segment of castle when the player clicks, while secretly instantiating a hierarchy of game objects behind the scenes ready to replace the temporary gameobject as soon as possible. (I have no idea how to multi-thread or whether the Unity API would even allow you to instantiate game objects on a separate thread.)
  • The “aproximation” mentioned in point 2 could be accomplished by merging the entire segment into one mesh so that it could be saved. This singular mesh can then be instantiated as one gameobject when ever it needs to be duplicated quickly.
  • I could use a combination of these ideas if I keep the Gameobject hierarchy approach but generat Quads in code rather than instantiating prefabs of quads.

My arising questions are:

  • Is creating a mesh in code faster or slower than instantiating the same geometry from a prefab?
  • Can you Multithread Unity and instantiate Gameobjects secretly without creating an unresponsive state for the player?
  • Is there an easy way to merge all the meshes of a game objects children into one mesh while retaining their relative positioning?
  • Are there any statistics on how long(processing) a GameObject takes to instantiate?
  • Do you know of a better way to do this?

You could use coroutines ; instead of instantiating a thousand gameObjects in a single frame, you could split the work. It will not freeze the computer (but it might be longer to load, but who cares ?). It’s like Minecraft ; the game does create all chunks at once, it creates X chunks / frame. That why you see the world creation even when you’re walking.

Also, the creation of a gameObject depends on the user’s computer. So it’s up to you to have a limit per frame.

1 Like
  1. Creating one mesh is probably going to be much more efficient than having a crap load of them. It also depends on if you have colliders on the objects or not.
  2. Unity by itself isn’t exactly threadsafe. However, there are things you can do in separate threads. However, parallel processing is very difficult and requires some advanced techniques. How far along the path of the progammer are you? I would not advise an amateur to try threading. That stuff is incredibly easy to break. That being said, one thing you can do is create appropriate data on one frame in a separate and then load it on the next.
  3. I have no idea. That would have to do with modifying the individual meshes and their coordinates which may or may not be efficient. That can lead to modifying a lot of numbers.
  4. If there isn’t you can test it yourself. Instantiate large numbers of game objects, time how long the frame takes, and then divide that by the number of game objects. Try it multiple times and you can get a good idea of how long that takes on your computer.
  5. This is probably a case where you want to have as few game objects as is possible and have the meshes be altered rather than creating and destroying game objects. Read about how voxel engines work. You can separate the data of just what is there from the game objects themselves and generate a mesh rather than a crap load of game objects. Then when the player interacts with the mesh you can intuit from the mesh what part of the thing the player is interacting with.

How experienced of a programmer are you? This is some heavy duty territory.

4 Likes