什么更好：链接到游戏对象或 Unity 中的类？

Question

Example: GameObject A has a script attached to it called MakeItRain. Inside that script is a public void Drizzle();

GameObject B also has a script and wants to tell MakeItRain to do Drizzle();

Inside the script of GameObject B, I can do this:

public GameObject makeitrain;

and then I have to use GetComponent to reach Drizzle(); in my code. In the inspector, I drop GameObject A into the slot of makeitrain and I'm done.

However, I could also do this in the script of GameObject B:

public MakeItRain makeitrain;

and then just call makeitrain.Drizzle(); in my code of GameObject B's script, without GetComponent.

In both cases, in the Inspector, I have to drag and drop GameObject A into the slot of GameObject B.

Is there a difference or reason why I should definitely not do the last option? I understand that the first method gives me more flexibility because I could call other components of GameObject A as well and not just the script's stuff. Just wondering if there is any other rationale for not doing the second method.

Answer 1

The answer depends if you need to call any function or use variable from the MakeItRain script.

If you don't need to to call any function in the MakeItRain script or access any variables from it then it is better to use GameObject as the reference. Also, if what you need to do is activate, de-active, rotate the GameObject then use the GameObject as reference.

On the other hand, if you need to be able to call a function such as Drizzle or access a variable from the MakeItRain script from multiple places , then you need to use the MakeItRain reference. At this time, it doesn't make sense to use the GameObject reference since by using it, it's required to use GetComponent every-time you need to call a function or access a variable from the MakeItRain script attached to it.

Finally, when using the MakeItRain script to reference your object, you can directly and easily access the GameObject it is attached to without using the makeitrain.gameObject . This doesn't require the use of the GetComponent function.

Just wondering if there is any other rationale for not doing the second method.

Performance issue due to the required use of the GetComponent function is the reason. Using it once in the Start or Awake function and initializing your MakeItRain variable is better.

For example, this is better:

public MakeItRain makeitrain;

void Start()
{
    makeitrain = GetComponent<MakeItRain>();
}

void Update()
{
    makeitrain.Drizzle();
}

than this:

public GameObject makeitrain;

void Update()
{
    makeitrain.GetComponent<MakeItRain>().Drizzle();
}

And should be used to avoid having to search for the component on the native side every frame .

Answer 2

Using MakeItRain and explicitly defining the type is better than using GameObject .

As @hacksalot commented, using MakeItRain offers strong typing . One of the benefits of this is related to your comment:

In both cases, in the Inspector, I have to drag and drop GameObject A into the slot of GameObject B.

If you explicitly set the public variable type to MakeItRain rather than GameObject , it is not possible to drag and drop a GameObject A into the slot of GameObject B unless GameObject A is has a script of the correct type. This gives you a compile-time/editor-time check that you are linking to the correct GameObject in the Unity Editor inspector .

Also, while not necessarily so, using GameObject references often encourages messier code , whether because of unnecessary chaining of methods together (eg GetComponent ) just because the type wasn't specified, or because it adds a bit of friction to writing & using helper methods. Consider even in a simple example which one reads better:

makeitrain.Drizzle()

makeitrain.GetComponent<MakeItRain>().Drizzle()

---

I understand that the first method gives me more flexibility because I could call other components of GameObject A as well and not just the script's stuff.

Note that you still have the flexibility to access GameObject , it's just a bit more verbose (which is one downside of this approach):

public MakeItRain makeitrain;

void Start()
{
    makeitrain.gameObject.SetActive(false)
}

However, you'll likely be using helper methods anyway (for anything more than basic calls), or even wrapper methods (which are inconvenient to write but sometimes helpful for readability).

In most cases, the benefits of linking to the class rather than the GameObject outweigh the downsides.

Answer 3

If u don't want to use GetComponent() , you can simply use SendMeassage() , like this

public Gameobject makeItRain;
void Start(){
    makeitrain.SendMeassage("Drizzle");
}

Another way to link a script is that use FindObjectOfType() , which do not need to drag and drop GameObject into the slot, here is the sample

void Start(){
    MakeItRain makeitrain = FindObjectOfType("MakeItRain");
}

Also you can use Gameobject.Find() to link a GameObject instead of dragging into slot, but I don't recommand this way, it cost a lot performance since you need to find every single GameObject in scene.