Looking for wisdom, for what is more maintainable when my programs become much larger that the simple small programs I am writing right now.
In my first program I ended up populating a gameobjects list using the FindGameObjectsByTag function quite a bit. As I started refactoring my game, to gain flexibility for additional game states, I found that sorting GameObjects by tag did not offer enough flexibility. So I started maintaining my game objects in their own dictionary.
It seems like, if I have a game where I am instancing and destroying a lot of game objects throughout the lifetime of my program, I will almost certainly want to always maintain my own index of objects, rather than rely on Unity’s object management expressions.
Am I not seeing something here? I feel a bit like I am reinventing the wheel, but the Unity API is less than a week old to me, so I do not know.
My general experience is that if you find yourself searching for game objects - via any of the Find* methods - you are doing something wrong.
Traversing Unity’s tree of game objects are potentially a performance killer, and is a suspect for many bugs.
However, depending on your game, it might be the only solution. If you describe what you are trying to achieve - or the problem you are trying to solve - we might be able to help you further.
Thanks. You answered my question. I am sorry if I was not clear.
When I started my program, I ~was~ traversing Unities tree of game objects. As I refined my code, to make it do more things, I found it much easier to maintain my own System.Collections.Generic.Dictionary object.
My concern was, when my program gets to 10k+ lines this might introduce problems (rather than the <1k I am at right now). For example, keeping my dictionary synchronized with Unities GameObject dictionary.
Bear with me here, my first game is trivially simple. It is TicTacToe. I am instancing the X’s and O’s onto the game board. When a victory condition occurs, I needed to be able to refer to three of them by index. Tag didn’t seem to be an appropriate place to store an index, neither did anything else in the game object datastructure. In my code I made a Dictionary of <int,GameObject> type in which to store the game pieces, so that I could easily find either the index, or the object on demand.
I should have been more clear: I think it’s also wrong to keep your own list/dictionary over the objects in your game, unless extremely necessary. And for TicTacToe it’s extremely unnecessary. In other cases, for example in relation to object pooling, it’s (almost) required.
For a game like TicTacToe I would probably have the game state stored in a 2D array and just update the board’s graphics when the 2D array changes. This way, you already have a natural list of the game’s state without needing to access the game objects in the scene.
Yikes. Ok, thanks for all the help. This was a forest, and I couldn’t find it with all these trees in the way.
Anyhow, what was messing me up was coroutines. Once I took the multi-tasking madness out, and made each of the game pieces a state machine in the update function, it all fell together, and I removed a bunch of lines of code to manage finding, and launching coroutines…
In other cases, for example in relation to object pooling, it’s (almost) required.