Custom GameObject Tags

Made replacement for native tags with asset-based approach:
https://github.com/neon-age/Tags



It fixes very-much all the problems I've encountered with default tags, and is also easier for collaboration, as anyone can add tag they need, without changing TagManager asset.
I think it could come in handy for this project

 

Wow that's cool,i believe it's open source for anyone to use it? (as you shared the repository link)

 

Interesting! This might be helpful down the road if we end up using lots of tags.

 

Hey, that's neat!

A couple of questions: What about adding/removing tags from the gameobjects at runtime? -- Is this possible? What's the performance cost? -- Also, what's the performance cost of looking up multiple tags at once for multiple gameobjects?

 

Welcome @awesomedata! I've been reading your drama on Visual Scripting 8th drop today, and now you're there

Adding/removing tag is just a list operation, you only need Tag asset reference.

There's one-time TryGetComponent call on each unique HasTag(), then it's just dictionary lookup.
And FindWithTag() lookup is filled with game objects on Awake, so barely no cost!
Tho' it still can be optimized further

 

Personally, I avoid using tags, because layers needed for physics optimization anyway, and they were more than enough in the last couple of years.

 

Regarding the bit about "drama" -- Fair enough! -- And to also be fair, I don't normally get involved in anything "drama"-related though. I do, however, pick my battles. Even if they're battles I cannot win, if it is a battle I've picked myself, I will fight until there is a resolution (whether or not that resolution happens to be the one I want) because I don't tend to argue something unless I've got an important point that I am deeply convinced needs to be addressed. Since people don't tend to hold themselves accountable without someone being there to say "Wait. Aren't you forgetting something?" -- For better or worse, I just happen to volunteer sometimes to be that someone.

I love Unity. But no matter how much I enjoy the capabilities Unity (the editor) provides me, Unity (as an organization) is still not immune to forgetting very important stuff that drives me nuts. Stuff that will make their features harmonious with game development, rather than working against it (i.e. as anyone around since drop 6 knows, Vertical Scripting is better, for example). Therefore, before I complain later, I am obligated to speak up now (or just get a crappy version of visual scripting made by the tool developers for the tool developers -- instead of for the audience it claims to be made for -- which was essentially what happened with Mecanim and other stuff in the past -- but "after-the-fact" is never the time to complain about something you really care about -- so yeah, "drama" lol).
In my defense, Unity has a long history of overlooking some very important aspects of game development in its editor, and since Visual Scripting is fated to become ingrained in that same editor, it is important to speak up now (before it is riddled with really big workflow problems, or even just before it becomes yet another missed opportunity for a better approach), which just ensures the future of the software is far closer to where it needs to be (since these things aren't being allowed to be overlooked) -- even if Unity still misses the mark in the end. Undoing a system like Mecanim is hard enough -- but overlooking some fundamental issues in Visual Scripting (and then undoing them later) is going to be infinitely worse. Unity is currently being rebuilt because fundamental things were overlooked, and it clearly sucks for everyone, lol -- Why would anyone want to perpetuate that? -- In this particular case, "Tags" are clearly among just some of the more obscure (yet still extremely important -- but deceptively simple, easy to overlook) powerful things game developers still fundamentally need that keep getting overlooked or sidelined, for example.
So it's not "drama" -- I'm simply not standing idle and letting important things continue to be overlooked.

That said...

-- I was actually just writing my own Tag system when I found this thread! -- Great minds think alike I suppose!

That's what I was thinking it probably was -- I just haven't had a moment to look through your code. The fact that you'd made something similar to something I've just recently been preaching about happened to catch my eye first, and I just wanted to ask a couple of questions before I set aside the time to dig in.

Back when I started with Unity, and I learned how slow Tags were, I almost wrote this exact system! -- However, I've been more busy since then writing tools to complement my art pipeline, and less busy writing actual games! Sadly, I never got to this.
That being said -- I'm glad someone did!
Thanks for taking the time to make this for people who really need it! -- A system like this is critical for a concise workflow.

Looking at your code, the only thing I can see that might make a more optimized system (when fetching multiple tags at once) is doing it based somewhat on how the "Layer Mask" system is done. In other words -- Use binary flags to represent each "Tag" index and then directly compare the resulting numerical values (all at once!) via a binary "mask" to one (or more) "expected" numerical values. These can be stored in an asset and populated on the gameobject in a very similar way as you have right now.

The only "cost" is finding what bytes a particular set of tags exist in, which can use a Dictionary-like setup similar to what you have now to "build" that list on Awake. The advantage is that you can look up multiple bytes simultaneously (without having to do individual comparisons on the CPU). This would enable the Tags to be used in heavy behavior-based logic/state comparisons.

Here's an example of what I mean: