koobas.hobune.stream
are there drawbacks to exposing variables/game objects through the editor?
I want to know what are (if any) the drawbacks to making a variable of type GameObject public in a script?
Background Information:
I have a map with a bunch of nodes it. I have the nodes organized so that from east to west we have our starter nodes, each starter node has multiple children that runs north to south until a certain point. I am loading all the nodes into a multidimensional array, however I have recently found out that Unitys "Findxxx" does not follow the hierarchy. Since I now have to manually pick each starter node and their children in sequential order, I am worried about having loops within loops...within yet more loops. My idea to cut back on the nested loops is to public expose an array for the starter nodes, and load them sequentially by hand in the editor (total of 56 starter nodes). Generally as a rule of thumb, I try to avoid making anything public (I blame my old professors for this) so before I do this I just want to find out if there are some reason(s) to avoid exposing variables/game objects through the editor?
While I disagree with the accepted answer, I think if you're having to hook up an array of 56 nodes in the inspector, then there's going to be as better way to do it.
Hard to say exactly what without having more details, but it'll probably be based on looking at the immediate children of each node recursively (using transform.transforms rather than Find), so that the algorithm is tracking a path through the hierarchy.
1: Any scene-based reference variables (non-prefabs) should be serialized and controlled via a manager which can be referenced via a singleton (Manager.instance.serializedVar).
2: Anything you want to make a prefab, you cannot serialize anything other than other prefabs or internal references (components attached to children).
3: Contrary to MezFo's advice, avoid filling reference variables inside a script. This is hard-coding conditions which can (and usually will) change over the development of the project. Serialized reference variables will never break as long as the referenced object still exists. Even components on the same object as the script are better off serialized.
4: Never, EVER, use GameObject.Find or any other "Find" methods in Unity. It's horribly inefficient and there is no reason a coding structure should ever do this.
Unity is built around components and serialization, use the engine the way the developers intended and you will avoid a lot of headaches.
Okay, I think this has given me some new insight and I will be looking into serialization. Thank you for the heads up and pointing me down a different path. The originally accepted answer I think has been removed so i am marking yours as correct. Thanks!
Please also remember that you do not need to make fields public to expose them in the editor. You can decorate any private field with the SerializeField attribute and it can be edited in the Inspector without exposing it to your API surface.
Exposing a GameObject in the inspector is certainly not a bad thing in general. Follow the same rule as you should with any kind of behaviour member variable: only expose it if you actually intend to set it via the inspector.
But in your case since you wrote that you do it just because
I would say implement your own find method that traverses the hierarchy the way you expected it? Mostly because assigning too much stuff manually can become tedious as your project grows and makes your inspectors more complex than they need to be. And, as other users noted, exposing stuff in inspector does not mean it has to be public and having assigned the references ahead-of-runtime will give you better performance (which is probably not an issue if you do it only at startup)"Findxxx" does not follow the hierarchy
