Announcement

Collapse
No announcement yet.

GameplayAbilities questions

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

    GameplayAbilities questions

    Howdy!

    I'm currently working on adding the GameplayAbilities system into my project and have a few questions about how the system works.

    1) In the GameplayEffect editor, how do you get Attributes from certain AttributeSets to show up in the modifier list? Right now all I see are AbilityComponent.Incoming/OutgoingDuration.

    2) Why are certain Attributes supposed to be done in the execution section (like health) vs the modifier section? Is this just for attributes that scale with level?

    3) How would I go about building an ExecutionCalculation class? I'm not sure I understand how they work.

    Thanks a lot. I'm really excited to get this set up for our game!

    Edit: May be worth noting I'm running in 4.7 preview.

    -Matt
    Last edited by mcucuzza; 02-02-2015, 04:35 PM.

    #2
    I'm going to start my answer with this big disclaimer: The abilities system is still under active development and isn't considered ready for widespread external use. It's possible that we will make big changes that break all of your data. The further we get with things the less likely this is but it is still a possibility at this point. When we think this feature is ready for more general use there will be an announcement. For now, use at your own risk.

    1) To appear in the attributes drop down in the modifier list an attribute needs to be a member of a class derived form UAttributeSet, have a UProperty, and be of type float.

    Code:
    class UMyAttributeSet : public UAttributeSet
    {
    	...
    
    	UProperty()
    	float MyAttribute;
    };
    2) Most things should modify attributes using modifiers. Executions are for custom code. Health is an example that could go either way depending on your game.

    At the most basic level you could simply have a health attribute that is increased or decreased when you take damage or are healed.

    For a slightly more complicated example, you might have three attributes: health, damage and healing. In this case players apply damage or healing to their target. Inside your attribute set you'd implement PostGameplayEffectExecute. If the modified attribute is damage or healing then you convert these to positive or negative health changes, apply the change to health, and zero the damage/healing attribute.

    Finally, we might want to make our example really complicated. Let's say I need to be able to do calculations on the damage at various stages and apply buffs/debuffs at each stage. For this scenario I'd use an execution instead of a modifier. For this you'd write a class that inherits from UGameplayEffectExecutionCalculation. Inside the Execute_Implementation function you'd put all of your logic to calculate the final damage numbers.

    Hopefully that's enough to get you started.

    Comment


      #3
      Is GameplayAbilities editor easiest to enable on 4.7 than 4.6.1?
      When I've try to edit an AbilityBlueprint after enable then, the editor always crashes by lack of a GameplayTag about GameplayCue.

      GameplayTagsManager line 313.
      VIDA - U4 Indie Goth Horror Game
      Project Thread

      Comment


        #4
        Thanks Fred, that explanation clears things up a bit about when to use modifiers vs executions.

        Going back through my code I realized that I had copied over a UCLASS parameter that was filtering all my attributes out of the editor (was looking at the unit test code).

        Also, thanks for the disclaimer. I'm aware that things may be changing, and I have two options:
        1) Deal with changes as they come through the pipeline, and possibly rebuild things.
        2) Implement basically the same system, but be forever behind in robustness and quality.

        I think for my specific case I'm better off with option 1 as it lets design start iterating now, freeing me up to work on other systems.

        I sincerely appreciate you taking your time to come in here and help out with a feature that is not ready for full consumption yet.

        -Matt

        Comment


          #5
          Creasso -

          I had the same issue you're having and was able to solve it by importing a csv file into a GameplayTags table with the GameplayCue tag and nothing else. My csv file looks like this:
          ,Tag,CategoryText
          0,GameplayCue,


          In your config file you need to point the GameplayTags system to the corresponding table:
          [GameplayTags]
          GameplayTagTableList='/Game/tagstable.tagstable'


          That should get you up and running with no crashes and allow you to trigger GameplayAbilities with no issues. The next one you'll hit will be the reason I switched to 4.7. GameplayEffects are not blueprintable in 4.6.

          Hope that helps.

          -Matt

          Comment


            #6
            Originally posted by mcucuzza View Post
            The next one you'll hit will be the reason I switched to 4.7. GameplayEffects are not blueprintable in 4.6.
            I'm guessing you meant the fact that UGameplayEffects are blueprints in more recent versions of the engine. This change was made to allow for inheritance to work as expected in gameplay effects. The initial solution using template classes wasn't robust enough. Even though UGameplayEffects are blueprints you should never use their event graphs. Gameplay effects don't get instanced and should be treated as just data.
            Last edited by FredK; 02-02-2015, 08:40 PM.

            Comment


              #7
              Thanks Matt!
              It's enough to at least make some mess.
              Now I'm like a child on a candy shop. lol

              Fred:
              I've read and do accept the terms/risks of mess with this pre-experimental feature.

              Thanks guys!
              VIDA - U4 Indie Goth Horror Game
              Project Thread

              Comment


                #8
                Originally posted by Fred K View Post
                I'm guessing you meant the fact that UGameplayEffects are blueprints in more recent versions of the engine. This change was made to allow for inheritance to work as expected in gameplay effects. The initial solution using template classes wasn't robust enough. Even though UGameplayEffects are blueprints you should never use their event graphs. Gameplay effects don't get instanced and should be treated as just data.

                Question. Why Effects are not instanced ?
                Does instancing, objects to execute their event graphs, have some serious performance implications ? I've been looking trough code of this module and I see you guys generally try to avoid instancing of objects.
                So I'm actually curious how big impact it can have on performance, with several thousands of instanced objects (bar in mind not all of them are executed at the same time).

                I've been coding something similar, and I just well instance objects, when needed, to save myself headaches, and make it easier to use in blueprints.
                https://github.com/iniside/ActionRPGGame - Action RPG Starter kit. Work in Progress. You can use it in whatever way you wish.

                Comment


                  #9
                  There are a few reasons why we don't want to instance gameplay effects. Gameplay effects in this system are intended to be data only. The only reason they are blueprints is for inheritance. The event graphs were never intended to be used and we have no plans to support event graphs running inside gameplay effects.

                  Instancing gameplay effects would have performance implications. One of the biggest considerations here is networking and replication. Replicating that many objects would be a bad idea.

                  If you need to use an event graph in this system you should do it at the ability level, not the effect level. Abilities can be instanced and support multiple options for how they are instanced.

                  Comment


                    #10
                    Just wanted to echo Fred's disclaimer and provide a little more info about executions. (Also potentially handy is the original thread about the system in the github sub-forum, but not much has changed re: status since my last post in there, everything is still WIP: https://forums.unrealengine.com/show...em-Explanation).

                    To add onto what Fred mentioned about the execution classes, we currently use those for things that are otherwise too complicated to encapsulate with a simple modifier, or that rely heavily on additional information. As an example, we implement all of Fortnite's damage calculation formula inside one execution class as a way to enforce that all sources of damage in our game use the exact same code path. The formula can be pretty complex though and cannot be represented with just a normal mod. We use a custom gameplay effect context so that when the execution goes off, it can additionally query stuff like the item acting as a damage source.

                    When you set up an execution class, you can optionally specify attributes from the source/caster or target that are potentially relevant to the calculation at hand and the execution will attempt to capture them for you so can query them from the execution parameters (see RelevantAttributesToCapture, we initialize them in our native execution constructor). In our damage formula, that manifests as capturing outgoing damage buffs from the source, etc. vs. incoming damage resistance from the target, etc., among others.
                    Lead Programmer (Gameplay), Fortnite, Epic Games
                    Twitter: @EpicIrascible

                    Comment


                      #11
                      Originally posted by Billy Bramer View Post
                      When you set up an execution class, you can optionally specify attributes from the source/caster or target that are potentially relevant to the calculation at hand and the execution will attempt to capture them for you so can query them from the execution parameters (see RelevantAttributesToCapture, we initialize them in our native execution constructor). In our damage formula, that manifests as capturing outgoing damage buffs from the source, etc. vs. incoming damage resistance from the target, etc., among others.
                      This is making a lot more sense now. Thanks for the more in-depth example, those are always very helpful for understanding the how/why of things.

                      -Matt

                      Comment


                        #12
                        I have some questions regarding target data and how to get that fed into the system.

                        1) First thing I found was GameplayAbilityTargetActor classes which spawn an actor to assist with targeting. When I initially tried to use this, I found that I was never getting target data, and upon digging saw that the predefined versions all seem to expect that a PlayerController is present for the selection process. I made a new version of the radius target actor which skips the check for a player controller and runs purely on the server. Is that the approach I should be using, or are these targeting classes really expecting a player to be assisting with the targeting at all times?

                        2) Suppose I know my target already (have AI running that handles target selection) - are there any built in mechanisms to get this data into the ability?

                        Thanks again,

                        -Matt
                        Last edited by mcucuzza; 02-04-2015, 05:29 PM.

                        Comment


                          #13
                          Originally posted by mcucuzza View Post
                          I have some questions regarding target data and how to get that fed into the system.

                          1) First thing I found was GameplayAbilityTargetActor classes which spawn an actor to assist with targeting. When I initially tried to use this, I found that I was never getting target data, and upon digging saw that the predefined versions all seem to expect that a PlayerController is present for the selection process. I made a new version of the radius target actor which skips the check for a player controller and runs purely on the server. Is that the approach I should be using, or are these targeting classes really expecting a player to be assisting with the targeting at all times?

                          2) Suppose I know my target already (have AI running that handles target selection) - are there any built in mechanisms to get this data into the ability?

                          Thanks again,

                          -Matt
                          Targeting is actually a part of the system I'm expecting will likely change again. Since re-integrating the system back to Fortnite, we've already changed how Fortnite does targeting through abilities (and doesn't use the targeting actors at all), so I'm expecting a hybrid result back in the main engine branch once we figure out a good mix. I'll see if I can fetch someone more familiar with the existing targeting to provide an answer as well.
                          Lead Programmer (Gameplay), Fortnite, Epic Games
                          Twitter: @EpicIrascible

                          Comment


                            #14
                            I know I'm essentially asking for voodoo, but is there any sort of ETA on a stable release, either in time or version number?

                            Comment


                              #15
                              Originally posted by DamirH View Post
                              I know I'm essentially asking for voodoo, but is there any sort of ETA on a stable release, either in time or version number?
                              Unfortunately not at the moment, though we're working to try to figure that out alongside the engine team (hoping to get an example made with it, if possible). We'll be sure to provide an update/announcement/etc. as soon as we figure these things out. I can tell you it definitely won't be stable/documented/etc. by 4.7, but that's all I know for now. In general, it's solidifying more and more (except for maybe targeting), but it's still very rough around the edges and not super user-friendly.
                              Lead Programmer (Gameplay), Fortnite, Epic Games
                              Twitter: @EpicIrascible

                              Comment

                              Working...
                              X