I’ve come to a point in my current project where I have over 100 tags. Every time I want to add a tag or assign a tag to an object I now have to scroll a long way down to get beyond all the other 100+ tags. Seeing as how it’s already taking me 10 seconds or so to scroll to the bottom of my list of tags I predict that at some point in the future it’s going to be over a minute of scrolling just to assign a tag. How do you deal with this? Is there an editor script of some sort for better tag management that doesn’t involve holding the mouse down on a little arrow for long periods of time to get to the end of the tag list, and perhaps a way to group tags into categories?
There’s probably an alternative way of doing whatever you think you need tags for. For example, if you are using FindGameObjectsWithTag a lot you could instead store references to these objects when you instantiate them instead of finding the objects, and avoid the need for a tag. If you’re using tags to check for certain objects during a collision you could instead check if a certain component is attached. etc, etc
Normally I don’t use many tags, but I started using them to get around having to check against object names during procedural generation to cut down on overhead. I’m under the impression that using object.CompareTag has less overhead than using object.Name == (“Whatever”) because comparing using == has heap allocation while CompareTag does not, so I stopped doing name comparisons and started using tag comparisons. It might be a minimal amount of overhead that I’m reducing but I’m generating dozens of objects every few seconds each with their own unique sets of variables so I’m trying to cut down on overhead wherever possible to keep framerate spikes down.
For instance during instantiation I’m doing this for position, scale and rotation for each uniquely tagged / named object.
if (theObject.CompareTag ("Object123")) {
float newScale = Random.Range (5, 10); //Where 5 to 10 is unique to this prefab
theObject.transform.localScale = new Vector3 (newScale, newScale, newScale);
}
I could have a script on each prefab containing the unique spawning parameters for it but that would require using GetComponent which I’m under the impression has far more overhead than CompareTag.
But disregarding usage entirely, unity has the ability to have up to 10,000 tags in a project and I have to wonder if there’s any way to even manage that many tags and if not what the point of even having the max set that high is if they can’t even be accessed in a reasonable manner.
Edit:
So after reading the following article I’m kind of baffled. It has test results that show that CompareTag takes 3 times as long as GetComponent. I’ve had it drilled into me over the years that GetComponent is high overhead and should be used minimally or not at all whenever possible, and I’ve noticed in the profiler that the more I eliminate GetComponent calls the better the framerate gets. I have not noticed framerate dropping as I do more and more CompareTag calls. So I’m not sure which to trust, my own experiences and the countless people saying GetComponent is high overhead, or the results of this guys tests. I may attempt to run my own set of tests to compare.
The advice to avoid extra GetComponent calls is still valid. It’s faster to cache the result of GetComponent in Awake/Start if you can do that. Not doing something is faster than doing something fast.
Also note that GetComponent is a lot slower in the editor than in builds. The article you linked above calls out GetComponent being slow and allocating garbage when it doesn’t return anything. That’s only in the editor - what’s happening is that Unity’s generating a “you forgot to add a DummyObject” message object to help you debug. In builds, it just returns a null object.
Now for “how to deal with very many kinds of tags”. Don’t Don’t use tags.
I’m generally of the opinion that all string-based programming should be avoided. It makes it impossible for the compiler to help you not make mistakes.
If you have a GetComponent call, and then delete the class Foo, your compiler will now tell you “hey, that Foo in GetComponent isn’t around anymore, you need to solve that”. If you do CompareTag(“Foo”), and then delete the things with the Foo tag, you have to remember to check all your code for the tag Foo, or else there’s a bug around.
So in your case, I would do what you’re saying - give each prefab a script with spawning parameters. Not for speed concerns - the difference between checking a tag and getting the data from a component is negligible, unless you have very, very many of them. It’s just much cleaner to have the info about how the thing spawns visible in the editor, and to be able to change it without having to recompile the code.
Note - I’m not saying “immediately rewrite the entire game to not use tags”, that would be a horrible waste of time. What I’m saying is that for future reference, you might want to avoid using them.