Script Only assignments

Unity Engine
1

Here is a question for those that have worked on larger projects using Unity / C#.

To what extent do you assign dependencies to objects using RequireComponent within script? Am I wrong in thinking that it’s safer to build up a project’s entire dependencies within script, rather than rely on drag and drop within the editor?

Any advice in experience in script only based builds welcome.

Is there anything that cannot be done in script that must be done in the editor?

2

To answer your last question first, no: as far as I’m aware, there is nothing you can do in the editor that can’t be done from script.

As to which is better, well, that’s a more complex question. It depends on who’s on your team, what the division of responsibilities are, and what their skill sets are. I’ve worked on projects where the level designers don’t want to muck with the code, but are very happy using the Unity editor and hooking things up as needed. I’ve worked on others where everyone on the team is a coder and is much more comfortable doing setup work in code than in the editor.

Version control is another factor. Yes, you can (and should) set your project to always use the text format, which makes things a little better. But you can still run into conflicts on the scene file which are hard to resolve. So, if a lot of people are going to be editing a scene at once, it might be better to push as much setup work as possible into the code. On the other hand, if it’s just one or two scene editors, it doesn’t much matter.

Personally, on my own projects I tend to use a combination. Simple stuff is hooked up in the editor via public properties, or via containment/naming conventions (but in either case, I verify in Awake or Start that everything required has been found). For more complex setup, I use code. This is especially true if there are going to be a lot of objects that need to be spawned in specific locations, for example — far easier to get that right in code than with manually editing each one.

3

(I’ve been acting mostly as a tools developer and development support programmer for the past couple years, so my opinions below are tinted by that. My primary goal has been to enable other developers to get their games implemented quickly and as robustly as possible.)

More code means more bugs.

If you’re working with anyone else, especially artists and level designers, they and you will both appreciate being able to do as much as possible within the editor. You don’t want artists mucking around in your scripts. :slight_smile: The editor also gives you lots of validation that you’d have to implement manually in a code-only solution. Take this script for example:

public class MyClass : MonoBehaviour {

    [Serializable]
    public class MyNestedData {
        public string myString;
    }

    public MyNestedData data;

    void Start() {
        Debug.Log(data.myString);
    }
}

If you add it using the editor, the inspector will serialize it and initialize data.

If you add this using GameObject.AddComponent(), data will be null. When Start() runs, you’ll get a NullReferenceException.

Now of course you could add an initializer to the variable declaration:

public MyNestedData data = new MyNestedData();

but as the programmer you have to remember to do this. And this is just one example of many little things that the editor does for you.

Attributes like [RequireComponent] are also semantic definitions. Placed at the top of a class definition, [RequireComponent] makes it clear that the class requires a certain component:

[RequireComponent( typeof(Animator) )]
public class Character : MonoBehaviour {
    ...

This makes it pretty clear that Character requires Animator.

You could bury a check inside Awake(), but it’s harder to notice:

void Awake() { // <-- starts somewhere fairly deep down in the script file
    var animator = GetComponent<Animator>();
    if (animator == null) {
        // Need to add code to handle the case where there's no Animator on the GameObject.
        Debug.LogError("This component requires an Animator!");
    }
}
1 Like