Using MonoBehavior or not for PathFinder

Unity Courses Talk
, ,
#1

After I saw this video, I began to think about reducing the number of MonoBehaviors on a game object. Is it bad practise by not extending MonoBehavior?

You can still use the FindObjectsOfType from Object

var wayPoints = Object.FindObjectsOfType<WayPoint>();

Or referencing the GameObject to get components in children

private GameObject _gameObject;

public PathFinder(GameObject gameObject)
{
     _gameObject = gameObject;
}

public void LoadWaypoints()
{
     var waypoints = _gameObject.GetComponentsInChildren<WayPoint>();
     ....
}
#2

I see what you mean but it’s worth nothing that simply inheriting a class from MonoBehaviour is very cheap, almost zero loading cost and literally zero run time cost during the game.

The runtime cost from MonoBehaviour only comes from using the special Unity Engine functions like Start() or Update() or FixedUpdate() etc. If your class inherits from MonoBehaviour but doesn’t use any of these special Unity functions, i.e. it only uses your own custom-defined functions, then it’s free. Using MonoBehviour means you can easily attach scripts to gameObjects, and rely on all code running off gameObjects in a scene, which is how most game developers will work (especially in their first few years of coding).

You’re right that some of the C# code functionality can be detached from scenes and MonoBehaviours entirely, but I would argue that there’s almost no benefit for this at this stage.

If you’re really worried about having too many gameObjects doing nothing, you could have just one empty gameObject called “OtherFunctionality” or “RawObject” or something like that, and attach all your bare-bones MonoBehaviours there.

Privacy & Terms