Search Unity

Alternative to linking too many gameobjects to code in inspector

Discussion in 'Getting Started' started by TheCrake, May 15, 2019.

  1. TheCrake

    TheCrake

    Joined:
    Oct 24, 2018
    Posts:
    15
    I'm linking a objects to my code by setting them as "public gameobject" or something like that and then dragging them into the script tag in the inspector to connect them.

    If I want to create any object in my scene or control if from my code, I need to connect it there. If I have a main script running everything, does it really need every object connected to the script? Is there an alternative to linking hundreds of items in one giant panel in the inspector? It seems a bad way to do things, especially since problems in the code when closing and opening unity can sometimes cause that list to be empty and need to have things relinked.

    I know you can use GameObject.Find, But I was under the impression that's a computationally expensive (slow) way of doing things, and that it shouldn't be used much if at all.

    Thanks for your time
     
  2. Depends on what do you want to do with those game objects.
    You can Instantiate game objects from code and get back the reference to this GO (game object).
    Like GameObject go = Instantiate<GameObject>([blabla - parameters as per manual]);
    Then you can store it in a variable like above or if you have a bunch of them you can store the references in List<GameObject> or in GameObject[] (array).
    When you create GO from code, it does not exist in design time so you cannot hook it up in the inspector anyway. Unless you create them in editor script.

    If you give a bit more information, what do you want to achieve, we can help you more with advice.
     
  3. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    21,182
    Have them all link themselves for you. Essentially you'd have a singleton manager object that has a way to add and remove entries from its list of objects and the object that wants to be on the list asks to be added and removed when it's destroyed.

    https://unity3d.com/learn/tutorials/projects/2d-roguelike-tutorial/writing-game-manager - Singleton tutorial

    Code (csharp):
    1. private void Start()
    2. {
    3.     Manager.instance.Add(gameObject);
    4. }
    5.  
    6. private void OnDestroy()
    7. {
    8.     Manager.instance.Remove(gameObject);
    9. }
     
    JoeStrout likes this.
  4. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    Also, there's nothing wrong with using GameObject.Find (and related methods) once on startup. If it causes a 1/30-second hesitation on loading the scene, nobody's going to notice (and unless your scene is very large, it's almost certainly going to be less than that).
     
    Kiwasi and Ryiah like this.
  5. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    11,847
    Often with that many GameObjects you're getting them by instantiating prefabs instead of making them a part of the scene itself. When you instantiate the object it returns a reference to the object, and you can just take that reference and save it.

    If you're dealing with a lot of similar GameObjects that are all part of the scene itself, then you might instead consider giving them all the same tag. Then when the scene first loads you just call FindGameObjectsWithTag to return all of them in one shot.

    https://docs.unity3d.com/ScriptReference/GameObject.FindGameObjectsWithTag.html

    Finding by tag is a bit better performing than just using Find. Finding all the objects with the same tag is a lot better performing than individually finding 100+ objects by name.

    As already mentioned though, the performance issue with the various Find calls isn't really an issue when you've loaded a new scene. Players are used to waiting a bit for level loads, and a tiny fraction of a second more is a non-issue. Even the occasional Find call during game play is unlikely to be a concern unless your game is trying to eek every bit of performance possible.

    What you don't want to do is what a lot of novices do by calling Find inside Update, every single Update. There is always a better alternative than that.
     
    Ryiah likes this.
  6. TheCrake

    TheCrake

    Joined:
    Oct 24, 2018
    Posts:
    15
    Thanks everyone, that's all really helpful and I'm going to look into things like using "find" once in setup to link something in the script or use a gamemanager. And finding everything with the same tag is going to be useful for some of the item management I'm figuring out how to do.

    Basically, I'm just getting started learning unity and I'm building a game where the user will be able to build things like in a sims/tycoon style game, and I want to be able to load various items or prefabs based on code rather than build pre-existing levels with those items in them. I also want to be able to use code to load various items for the given small scene, AKA, various different enemies or background decorations for the scene, loaded or destroyed one at a time using the script.

    Since I want to have a decent number of 3d models for example, It feels like linking every possible 3d model into one script might not be how it should be done, so I want to ask before I spend a long time doing something the wrong way.

    I've got a rough idea how to code what I'm trying to build, but obviously since this is a "learning experience" project it's a lot of research and I'm probably doing lots of things the wrong way.
     
  7. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    That there might be part of your problem. Normally massive god classes are a bad idea. Have a look. You can probably break this class up into a set of smaller classes which each need less references.
     
  8. TheCrake

    TheCrake

    Joined:
    Oct 24, 2018
    Posts:
    15
    Thanks, this sounds like a good idea, but I'm not sure the best way to have the scripts talk to each other. Is there a best way to do this? Either link the scripts and their variables with find and have them check each other's variables? Or have them send messages to each other?