Using GAS only for Tags and Abilities?

So I’m trying to implement GAS to my very first project, and while tags and abilities are rly easy to understand for a beginner, I’m having hard times with attributes and GameplayEffects.

Since I already had a dmg system before GAS, is that stupid to ignore that GAS’s side?

I mean I’ll have a fair amount of stats in my game (health, stamina, armor & some more) and a fair amount of effects (not too far from ignite, poison and armor shred at best) that I can replace with some variables and functions.

Since it should be a rogue-like, the plan is to have tons of abilities given by items, which I should be able to manage with tags and simple abilities right?

I know this will not be perfect but still, can this be a viable approach?

2 Likes

Hi,

If your game is a roguelike even though is a single player game, a framework like GAS would help you on the way a lot even though I understand it can be hard to digest all the kicks and knacks of the framework in depth at the first glance.

However if you designed the progression, attributes, damage systems already and you know give or take what you are doing, it is ok to create your own systems / frameworks further.

The “tons of abilities given by items,” is a strong indication that either you utilize GAS or systems design in the first place very good to serve you long term. However GAS out of the box can do a lot and with respect to core fundamentals of the system it is quite mallable/bendable to your needs with some touches. I personally love GAS as a framework.

To give you some very high level utilizing it and introducing you about the abilities and effects and cues;

In an imaginary game;

  • You are a magician, have health, magic armor, mana and some other stats defined
    • You have a shoot ability that makes a magic projectile at that moment, spawns a projectile
    • Ability makes shooting, animation, trace, sound maybe even calls inventory or attributes to be shot or decrease stats like mana
    • Projectile flies, has GAS information maybe tags.. impacts to a target
    • OnImpact some GAS GameplayEffects tried applied to target with the information inside projectile coming from ability.
    • Depending on the target status (armor, health, buffs etc) and depending on the projectile something will happen. Maybe this one was a simple fireball that needs to decrease health attribute, and apply a DOT effect additionally on the target. So its 2 effects will be tried.
      • Effect 1 OnFireBall-> GE_TradeHealthAttribute (give or take) →
      • Effect 2 OnFireBall-> GE_TradeHealthAttributeOverTime (give or take)->
        • Then they maybe apply some Gameplay Cues for the player feedback like burning etc.

So when you look at this scenerio this 2 effects will be applied and they will have to talk with the attributes right?

What we want is not to directly call attributes but instead have our custom damage calculation class to check wheter target.

  • Armor : Does armor effects fire incoming damage. Does it decreases it directly a percent or first goes damages armor till it is zero then health attribute?
  • Buffs: Does target has some buff like, fire shield temporary at that moment? If so maybe it will be neglected as zero.
  • Skiils: Does target has a skil that removes these effects like “cleanse” .. if so maybe on some tick this will be applied by target and the remaining effects maybe will be removed or damage will be zero … if clense its removed if buble shield better damage will be zero etc by design.

So during a gameplay moment many things can happen and GAS has nothing to do with directly decreasing the health actually. GAS is a framework for considering all these complexity of the gameplay in an efficient / clean way and quite the right way. Even there can be scenarios like these 2 effects we described above maybe not applied at all since maybe the target will have an armor equipped that already gives a gameplay effect to player as “FireResist_GE” with some tags. When these tags exist effect will be neglected/not applied etc.

In short it can get complex, it can get more sophisticated with progression.

If your game has deep systems use GAS its out of the box designed for these and as a plus;

  • Network Ready
  • Standartized
  • Designer Friendly
  • Modular , reusable and even extendable (sometimes you need things that is not defined in framework)

If not: you have limited pool of items, defined progressions, no network need you don’t have to, you can create your own systems.
Try to focus on items first and their results like

  • Fire Rate Changers
  • Impact Changers
  • Attribute Changers
  • Shooting (Deployment) changers etc.
  • Is there an item that prevents player from dying? Cheat Death? Or Raise back From death one more time fully or limited time? These kind of skill/item scenarios can be a decision point fo use gas or not.

What I see in teams, If team doesn’t really know what they are really really doing and lots of creative ideas flying, design is not conceretely defined by a knowledable designer who can go in to deep thinking mode about systems or your game is tend to go complex use GAS

If team knows what the game will be give or take, the vision is defined, no network need, can define the system around it and your system will be flexible enough for future design needs you can go with your own systems too.

I would suggest you lastly to not to fear into exploring new things , maybe there are some things over there that will help you do the game, even if you think your project is not sophisticated, learn GAS too and best way to learn is to do things with it. You can mix your existing systems with GAS framework and make something even hybrid (I use GAS framework exactly like that). Using GAS only for tags and abilities? don’t see a downside to it.

Let me know if it helps to take a decision around it.

you got me at “If team doesn’t really know what they are really really doing and lots of creative ideas flying”, so I’ll try to learn everything I can from GAS even if this is goin to be a pain.

Really ty for your exhaustive response.

1 Like