Hey everyone,
I’m currently working on a game which will require a grid system with 10s of thousands of nodes or more. I need to be able to store references to game object in a scene, but I’m weary about doing this in a property on a monobehaviour. Does anyone have any experience on dealing with grids of this size with respect to serialization?
I don’t think I understand what you think might go wrong. Why would the fact that it’s stored in a property on a MonoBehaviour make any difference? (And as opposed to what?)
It’s not being stored in a property that I’m worried about, it’s the size of the map. From my initial planning these maps will be something like 500 x 500, so it would be storing a massive amount of references. I’m already seeing some editor slowdown when selecting the object at around 100 x 100, so I don’t think my current solution is tenable.
Simply having 250,000 GameObjects in your scene will likely cause major slowdown (especially if they have any attached components that update every frame). Unless you have very carefully ruled this out, I am 99.9% sure this is the source of your problems, and the references to them that you are storing have nothing to do with it.
Displaying 250,000 public variables in the Unity inspector might possibly cause a slowdown.
But storing 250,000 references in an array is very likely to cause any issues. That’s a couple megabytes, which is minor on modern systems.
Certain data structures might have slower reading/writing when you store that many things in them, though it depends on the nature of the data structure. But unless you are accessing this data structure a huge number of times per frame, it is unlikely that it’s slowing you down more than simply having that many GameObjects active in your scene.
To cut down on the number of objects, you probably want to do at least one of the following:
- Figure out a way of representing your game board that doesn’t require a separate object for every cell. Maybe you have a single object that displays the terrain for the entire map, and then you only have GameObjects for the cells that actually have something interesting in them (which, hopefully, will be a very small percentage).
- Dynamically create just the GameObjects that you need to display what’s currently on-camera, removing everything else and storing any necessary data in low-overhead custom data structures. (Use object pooling.)