Hi,
By navigating into the U4 sources, I found “SkillSystem” module.
I start reading it as it seems to manage property like Damage, Health with attribute, dot system, etc…
Is it used somewhere so I can see how it has been implemented?
Because, it’s bit complicated to read it without any documentation on it 
Thanks
I’ve only spent a few minutes looking at it, but here is what I’ve discovered.
It looks like it is example code for how to use the GameplayTags system that is located in the Runtime/GamePlayTags folder. GameplayTags data seems to be generated from an Excel spreadsheet import. The SkillSystem uses values from the tables in the GameplayTags to determine health, damage, etc. Its basically a really good way for designers to alter gameplay values in a data driven way, instead of hard coding these kinds of values.
Both the SkillSystem and the GameplayTags are plugins, I think, and so they will need to be enabled in the editor to use them.
Also I recall hearing something about the GameplayTags not being complete yet.
Maybe these two things should be moved into the Experimental section.
I had more of an impression that GameplayTags were created to support skill system, rather than other way around.
It seems to more, of like a generic system for RPG games, though without seeing how it actually process data I how easy it is to use actually.
I honestly found using pure data from spreadsheet to not be so friendly as some people claim.
The SkillSystem module is a work in progress. We are using it internally, so while its not done, we think its past the experimental stage. Once it is a bit more fleshed out, expect to see documentation/examples (this could be months away). If you want a peak at using it, you may check out GameplayEffectTests.cpp.
You guys are on the right track for what it can do. The goal is a data driven system that scales with a large amount of gameplay content. For simple games it would certainly be overkill. For games that have hundreds of abilities/spells/equipment/talents/etc that all have to interact with each other and be balanced - this is what you’d want to use.
I’m honestly still not sure about last part. This might be because of lack of any real usage examples, but I honestly can’t see how this system can be used to quickly and easily create myriad of lets stick the it, Effects. I understand what are effects suppose to do. This part was actually pretty easy to get (aside that I made my own Effects system).
My point is that, this system seems to rely heavily on C++, to create any sort of derived effect, From simple life steal, as it is in example, to much more complex effects that are not in examples (effect that let’s say modify health only if certain attributes are between X and Y, while character is running).
And data tables are only used to provided raw numbers.
While we are on it, I’m curious why you guys didn’t leveraged blueprints, to let designers create effects entirely withing blueprints, and use C++ only to manage those blueprints ?
I’m actually doing very similar thing, though I took blueprint route (exposing as much as functionality to blueprint, and C++ handling on management side of things, not the actual game mechanics). It lacks centralized point of data store (like csv files), but it gives much more freedom to people who like doing stuff in blueprint. I would love to merge two worlds actually. As it would be perfect solution (;.
That being said I can understand why choose C++, route, because I myself have hit some serious usability walls with blueprints, but If those could be removed It would be even better.
Currently I’m not able to achieve enough abstraction to really separate RPGSystem from game because of some blueprint limitations, but it is getting here.
In anycase I found some interesting ideas in it, that I could use myself and learned few things while analyzing it.
The spreadsheet stuff isn’t meant to create new functionality. Its meant for game balancing by tweaking values such as health amounts, damage amounts, etc. Using spreadsheets lets designers very quickly alter these values without having to compile new builds of the game or compile blueprints. The other thing spreadsheets allow designers to do is create formulas within the spreadsheet program (say Excel) to better grok how the game balancing is working out. They can also pseudo ‘play the game’ by setting up formulas that would, for example, simulate a player with certain stats dealing damage to another player with another set of stats.
Hardcoding that data, or even having that data in Blueprints just isn’t going to give you the quick turn around time that designers need.
You may be reading a bit too much into the unit tests, which are purposefully setup to not rely on blueprints/data assets to be run. The intended use is much closer to what you suggest: C++ to manage the pipeline with data defined in blueprints, data assets, and spread sheets. GameplayEffectExtensions could be made blueprintable if a project wanted.
Ahh thanks for explanation.
Could you tell how to include this modeule for compilation to be able to use it ?
It seems that I’m really repeating job when not needed, and I would rather help with existing stuff then.
Warning - this is pretty rough! The setup has not been polished at all for public consumption. Here is a basic outline:
To use the modules now, you will need to edit your MyProject.Build.cs in your MyProject/Source/MyProject directory. Add SkillSystem and GameplayTags to your PublicDependencyModuleNames. E.g., something like this:
PublicDependencyModuleNames.AddRange(
new string] {
"Core",
"CoreUObject",
"Engine",
"InputCore",
"SkillSystem",
"GameplayTags"
}
);
The module should now compile when you build your project. You should be able to include headers from the SkillSystem such as AttributeComponent.h GameplayEffect.h etc. You should be able to create new GameplayEffects in the editor (New Asset → Misc → Data Asset → GameplayEffect).
You will also want to include the editor portion of these modules too (these are pretty bare bones but the GameplayTagsEditor is required for adding tags)! That is, the GameplayTagsEditor and SkillSystemEditor modules. Unfortunately I’m not quite sure the path of least resistance is here. I believe the templates already create a MyProject3Editor.Target.cs file but do not create EditorModules alongside the GameModules that they create. Setting up an editor module isn’t hard if you have an example to copy, but I don’t think any examples shipped doing this. It may be easier to just add these modules (GameplayTagsEditor, SkillSystemEditor) to your local UnrealEd.Build.cs file. (You would want to add them to PrivateIncludePathModuleNames and DynamicallyLoadedModuleNames - follow BehaviorTreeEditor as an example).
Finally for the SkillSystemEditor, you need to enable that module in your DefaultEngine.ini file:
[SkillSystemEd]
SKillSystemEditorEnabled=true
In the editor, Window -> Developer Tools -> Modules should confirm GameplayTagsEditor and SkillSystemEditor are loaded.
So, again, sorry that is not a very friendly setup. As these systems mature we will have templates/examples/tutorials for setting up and using them. Feel free to noodle with them now but heed the disclaimer that these are heavily under development.
Actually, it looks like GameplayTags and GameplayTagsEditor are already built by Engine/UnrealED. So the above steps are probably only necessary for the SkillSystem.
There’s also a decently sized refactor to GameplayTags coming down the pipe as well, so if it were me personally, I’d probably hold off a little bit on relying on these systems extensively just yet. As mentioned, the skill stuff is very much WIP.
Thanks for the answers & clarifications.
I will follow this as it might be an interesting module to put in place later on in my game.
I will wait for it to be more “polished” 
I don’t have time today to play with “beta” module.
Is it something that you planned to use in Fortnite?
Can you share some information about the timeline for this?
I hope that refactor include in editor tool for adding and editing tags.
Keeping your tags, in Excel might be nice, but I personally don’t like leaving UE4 Editor if I don’t have to.
Anyway, thanks for info guys. I successfully compiled and played around with it. I can’t say much about expect for the fact that heavy reliance on data tables and almost no blueprint support put me off a bit.
Though I can understand that, because blueprints on their own are not really friendly when it come about big stores of varied data (like Effects, that can have different values depending which ability apply them), maybe that is area that need some work ?
Yep. The Gameplay tag stuff originated in Fortnite and is something we pushed up to the engine figuring that it would be useful to others outside of our project. It’s still in flux though, so while I wouldn’t call it “experimental,” because we know we’re developing it, it’s still not ready for prime-time and might undergo changes that are a pain to reconcile across releases. Re: the skill/effect stuff, Fortnite’s work was kind of the basis for that as well, except Fortnite’s current version is simpler and not as feature-rich as the WIP stuff will be. As said, the engine skill stuff is WIP and potentially months away, but Fortnite will be a consumer of the system as it becomes more fleshed out.
Probably in the main branch sometime later this week or into next. Some of the changes off the top of my head are a new struct representing a tag (not just using an FName), forcing tag usage to route through the dictionary (so no rogue tags entered out of nowhere), changes to how tags are stored (right now if you tag something with say, “effect.poison.crippling”, you actually get “effect,” “effect.poison,” and “effect.poison.crippling” in your container, which leads to logical bugs in certain scenarios; post-refactor only the “leaf-most” tags get stored), option to check for tag matches via explicit matching or by including parent tags, etc.
All very in flux still though. Bound to be some issues post-refactor and will likely see more changes here or there in the future.
We already have a custom widget that edits tags containers. It shows the contents of the spreadsheet dictionary in a tree view in the editor and lets you mark a container up. As mentioned, this is still very WIP/early in development. This is the beginning of the framework that will eventually include blueprint support in some capacity, we’re just not there yet. All three of these systems are treading an interesting line of not being experimental but also under heavy iteration.
Is there any approximate time frame, when you guys plan to, refactor GameplayTags ?
Once I got that thing to work, I actually started used it pretty extensively in every place that need some identification.
The most important question, will this refactor break compatibility with FGameplayTagContainer, or is it going to be more, about inner working, not really exposed to game in most cases ?
I wanted to check and see if you guys feel Gameplay Abilites have reached a somewhat usuable point in 4.3? I noticed a lot of commits happened around gameplay abilities in master.
The Gameplay Abilities system is still at a WIP stage. It is still pretty unfriendly and there’s a reasonable chance that we’ll make changes to the system that aren’t backwards compatible. I wouldn’t start using it in your projects unless you’re willing to redo some or all of the work you’re using it for. If you are okay with this and want to try it out I think 's instructions earlier in the thread should still work for using the module in your project.
I’d keep an eye on the release notes going forward for a good idea of when the system is changing less drastically/frequently. I’m sure it’ll be mentioned once we’re past the WIP stage.
OMG… Why I just find these things after try get solutions from scratch… 
Well, since you are working on a “standard” skill system to UE4, I would like to know if what I did is “usable” or would be better implement trough your skill system.
One feature that I simply loved on Unreal4 was the DataAssets, I’m making heavy usage from it on my game since they looks like a great way to add content to it.
All DataAssets I’ve created to hold Gameplay aspects has an array of structs whose inner fields holds the Appearance/Localizable/Balanceable info and I’m planning in use the array Index as Execute/Online Description Command and SaveGame (with an additional parameter to tell SkillLevel/Intensity).
As example, the DataAsset contains all info
SkillDataAsset
{
TArray<SkillLocalInfo>
{
SkillLocalInfo[0]
{
Name = "Fireball";
IconLoc = {1,4}; // On the icon Atlas
Effect Description = "Burn your foes arses";
Type = Enum::SkillType_Spell;
Whatever...
}
}
}
The code above is just illustrative, the array filling is done on editor.
To support this, I have another struct that just holds SkillID (the index) and a float to tell the Intensity/Level to be used on Savegames as parameter to Multiplayer and communicate from UMG to the Controller “cast” the skill.
struct SkillRef
{
int32 CodeID;
float Intensity;
}
This can give you a good idea about what I did, will this perform much worse than what you’re doing? Any advice will be great.
Thank you.
I forgot I received a request to provide an update on this, sorry!
We are still actively working on this system, but it remains a work-in-progress. We have continued to make pretty large architectural changes to how pieces of it work, so I would personally still hold off on relying on it heavily just yet. Our game teams have been messing around with it, finding out what works for us and what doesn’t, and we’ve been constantly iterating on it. We’re trying to craft it in a way that remains performant with lots of abilities, gameplay effects, etc. while remaining generic/re-usable enough to be used by different types of games, all while we learn a lot from our systems designers about how they expect a system like this to operate.
I think we’re getting closer to where the architectural parts will start to settle down and we won’t have so many changes that would break content or ruin APIs in the next month or two. Everything involved still needs a lot of usability/polish to make it friendlier to use for people who aren’t systems designers involved in its construction though :p. Once we get closer to that, we’re hoping to make some documentation/tutorials or possibly a stream on what it can do, how to use it, etc. We initially created the system for our game teams, but we’re really excited to eventually get it out there for everyone and see all the crazy RPG/action/etc. stuff people make with it!