Announcement

Collapse
No announcement yet.

Engine Source SkillSystem Explanation

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Engine Source SkillSystem Explanation

    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

    #2
    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.

    Comment


      #3
      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.
      https://github.com/iniside/ActionRPGGame - Action RPG Starter kit. Work in Progress. You can use it in whatever way you wish.

      Comment


        #4
        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.

        Comment


          #5
          Originally posted by Dave Ratti View Post
          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.
          https://github.com/iniside/ActionRPGGame - Action RPG Starter kit. Work in Progress. You can use it in whatever way you wish.

          Comment


            #6
            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.

            Comment


              #7
              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.

              Comment


                #8
                Originally posted by Dave Ratti View Post
                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.
                https://github.com/iniside/ActionRPGGame - Action RPG Starter kit. Work in Progress. You can use it in whatever way you wish.

                Comment


                  #9
                  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:

                  Code:
                  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:

                  Code:
                  [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.

                  Comment


                    #10
                    Actually, it looks like GameplayTags and GameplayTagsEditor are already built by Engine/UnrealED. So the above steps are probably only necessary for the SkillSystem.

                    Comment


                      #11
                      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 Dave mentioned, the skill stuff is very much WIP.
                      Lead Programmer (Gameplay), Fortnite, Epic Games
                      Twitter: @EpicIrascible

                      Comment


                        #12
                        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?

                        Comment


                          #13
                          Originally posted by Billy Bramer View Post
                          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 Dave mentioned, the skill stuff is very much WIP.
                          Can you share some information about the timeline for this?

                          Comment


                            #14
                            Originally posted by Billy Bramer View Post
                            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 Dave mentioned, the skill stuff is very much WIP.
                            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 ?
                            https://github.com/iniside/ActionRPGGame - Action RPG Starter kit. Work in Progress. You can use it in whatever way you wish.

                            Comment


                              #15
                              Originally posted by Elvince View Post
                              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?
                              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 Dave 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.

                              Originally posted by order66 View Post
                              Can you share some information about the timeline for this?
                              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.

                              Originally posted by iniside View Post
                              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 ?
                              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 Dave 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.
                              Lead Programmer (Gameplay), Fortnite, Epic Games
                              Twitter: @EpicIrascible

                              Comment

                              Working...
                              X