Difference between using Tags and GetComponent

Question

I was implementing a basic "check if the player enter the trigger" behaviour and I get myself wondering about this question:

What the difference between this:

And this:

I guess it is a performance issue for using GetComponent every time? If not, I dont really see the point of using tags in this kind of checks.

Answer 1

There's only a few differences between the two:

• You can have more than one component (even a single type of component) per object but only one tag per object (unless you do special parsing or get an addon for it).
• If you have special functionality for a player, you might already have a need to add a Player component to it. Adding the tag might get redundant and and hard to manage.
• Tags provide the useful GameObject.FindGameObjectsWithTag and GameObject.FindWithTag which seem to be performant enough (as of 2006, lol)
• While there are performance differences, they are very negligible in terms of a game. A generic functional call versus a string comparison won't make much of a difference unless you're hitting it many times a frame.

I've personally never had a need for tags but everyone codes their games different. I can see uses for it but I usually build my own lists of certain objects which tend to better describe the group they belong to and I have better encapsulation over that group too.

Answer 2

I reccon the main difference is that with the latter, you restrict your trigger logic to your player implementation, so it's more of a design issue.

Consider that, one day, you wake up to a realization that your current player codebase can't handle some new issue and a refactor is in place. And then you see, well damn, all my triggers depend on this specific class to exist in this specific gameobject! Tread carefully, lest you break something.

Now, if you used tags, you could rename, remove, refactor to your heart's content, and things will (quite likely) just work.

My personal approach is to remove the object inspection logic away from triggers and whatnot. Triggers simply ask "Do you recognize this object that ran into me just now?", to which a third party inspects the object and says either "Yes" or "No". Depending on the answer, the trigger either ignores the event or proceeds to do whatever the trigger does.

(The third party in my case are ScriptableObject assets that I pass to the objects in the editor. An asset to identify the player, an asset to identify pickable objects, etc. This makes it easy to mish and mash functionality inside the editor, like turning a pick-up into a damaging entity, with no extra code involved)