[QUOTE=Elvince;99071]
Hi,
Thanks for the answer. I already read thread, but I still don’t understand the Use for those tags. Could you please share some examples where they are useful?
Thanks,
The gameplay tags are a that we implemented for Fortnite and as we saw that we were using them more and more, figured they’d be useful for other projects and moved them to the engine so that we could share. They’re still under iteration though as we play around with them, and, as you’ve found, we don’t have any sample content available using them yet. The basic gist behind them is that they’re a way to mark things up in data with tags defined in a dictionary file that can then be easily queried against for gameplay reasons. I’ll give you an example of a usage from Fortnite:
Fortnite has the concept of abilities as well as character buffs/debuffs that do all kinds of various things. So as an example, one of our classes might get a bonus that says “+15% Damage” or something like that. We use the tags in conjunction with that to allow our designers the ability to make specific requirements/variations/etc. on that entirely in data without ever needing a programmer to actually write additional code to support it. So pretend you have that “+15% Damage” buff, but you really want it to actually be “+15% Sword Damage” instead of just damage to everything. Here’s where the tags come in. All of our buffs have a gameplay tag container on them that specify tags they require to actually be active. So our designers can take the +15% dmg buff and then in the container, mark it so that it only actually works if the “Weapon.Melee.Sword” tag (a tag we added to our dictionary) is present on the buff recipient. Likewise, we put tags on our weapons, items, etc. so that they can easily specify what they are. When the player is holding a sword, he has all the tags that are also on the sword, so when the buff checks if it’s active, it can check and verify the player has a sword, all without there actually being any code explicitly written that knows what a sword is. It basically allows for tons of gameplay interactions to be created entirely through data.
Another example, also with buffs/debuffs. Our buffs additionally have another tag container on them that we use as “when buff is applied, remove any buff/debuff on the player that has tags that match these tags.” So say we put a debuff on you that is poison damage which ticks over time. What if the designer really wants to make an ability that cleanses poison? They don’t need any code written now. They just apply a buff that says I clear other buffs that have the poison tags on them. The really neat part is the tags are hierarchical, so you can choose the depth you want to interact with. Using the poison example again, let’s pretend you want your game to have multiple types of poison…one type slows the character when it applies, but another type does damage over time when it applies. They’re both still poison though. So you might set up part of your tag dictionary to look like:
Effect.Poison.Slowing
Effect.Poison.Deadly
and mark the debuffs accordingly in their tag containers. Now when other buffs/debuffs want to interact with poison, they can be broad or specific. The cleanse debuff might say, “I want to remove ALL poisons, I don’t care which type,” so it would use its tag container to just look for “Effect.Poison,” which would match either of our sample debuffs! However, we could also make a cleanse that can only remove the deadly poison, by making its container only explicitly look for “Effect.Poison.Deadly.”
We use tags all over the place in Fortnite like that. All of our items have tags, any time anyone takes any damage, that damage specifies tags, etc. That said, it’s still a work-in-progress. We started exposing more pieces of it to blueprints, but full BP/editor support might not be all the way there yet. There were some bugs blocking a couple features in it I was hoping to expose to blueprints in the future as well. We’ve been pretty happy with what they allow us to do so far and they have tons of applications to a wide variety of game types. I personally want to use them in a side project one day to make a trading card game (a lot of the mechanics of CCG/TCG games could use tags).
One last thing to mention, another cool thing about using the tags (aside from the hierarchical stuff) is that because they come from a dictionary file and have custom UI, etc. you can pick the tags from the widget and not worry about typos or spelling things wrong like you would if you had to type everything out if you were using purely strings or names.