What are the benefits, risks, advantages, and disadvantages of using a non-MonoBehavior script for simple objects?
In this case, I have a “master” script that is MonoBehavior derived, that kind of acts as a central repository for game state, etc.
I’d like to add a “scoring” script that breaks this section out. My intuition is that this would be better served as a straight C# base class, but I’d like to hear thoughts on the whys and wherefores before I jump in with both feet.
I assume that it would be fairly easy to just create a new Scoring class from the master script, then my other objects could basically interface through that to query or update scoring related things.
Or am I looking at this in a completely wrong way?
A MonoBehavior class is attached to and directly interacts with GameObjects. It has methods and varibles that allow it to perform these tasks better (SendMessage, this.transform, drag-and-drop vars, etc.). You cannot create a MonoBehavior using the keyword new
A non-monobehavior class is a floating piece of data that defines an abstract object. This object generally cannot directly interface with GameObjects. They are basicly a blank slate that allows you to define a custom OBJECT (not a GameObject!) that you can use inside of scripts. You cannot use SendMessage and other such functions on a non-monobehavior, but you can use one to call SendMessage on another object, if you can get a reference to that object.