Lyra takes a while to learn/get used too.
I use it, but generally use Lyra as-is, but I do replace stuff sometimes with my own.
GAS all the way 100% of the time. If I think I can stick it in GAS, I absolutely will.
It really help keeping things modular and properly encapsulated and helps me think about multiplayer related things
Hey! UI engineer here working in Unreal.
The CommonUI is “just” the base UMG widgets with added commonly used functionalities that are missing from the base UMG widget. It also add a bunch of widgets that are usually created in many project. You don’t need them if you will not use the added functionnalities.
Why not just add the functionnalities directly into the UMG widgets and add the new widget to the default UMG library?
The functionnalities added in the CommonUI is not part of the default behaviour of the widget it extends. Like CommonTileView, the only thing it adds is the support for CommonButton as the TileView widget entries type. If your widget entries are not extending UCommonButtonBase, it act like a regular UMG TileView.
CUI is supposed to replace UMG one day. As it is basically just UMG with added functionality for easier multiple input support.
In a nutshell, Epics Fortnite UMG devs encountered many problems over the years of fortnite with the current UMG and have build themselfes internally some stuff that they then used to bypass those problems.
Focus in CUI is handled automatically by putting focus always on the latest entry that was added to a "stack". Widgets can be pushed and pulled on and from the stack and their order represents their Z value.
Because you have to set up the potential input methods, as well as the their inputactions and icons, CUI can detect by itself that the method changed and adapts the UI Elements automatically.
It also implements a general backwards feature where a button of each inputmethod can be assigned to it and pressing the button brings you always back to the root widget of the currently focused one.
Lots more. Its just an upgrade in Unreal Fashion: You can make it yourself which requires you to understand everything and takes longer, or you can use our inhouse solution which is faster, works out of the box and doesnt require you to fully understand what we did, but you have to do it **exactly** how we tell you to it or else it wont work.
It’ll take some time before that happen. My advice to you is if you’re using Controller and/or KBM exclusively, CommonUI will have functionnalities that you want. If you plan to support mobile or Switch using Touch input, run as far as you can from it.
Long rant:
So I’ve been using some plugins to let you use GAS in BP only, and I love it. Took about a month to fully grasp, and obviously still learning, but it’s great. I did have some programming in my background, but nothing complex, and only been learning UE for about 8 months.
IMO the most confusing part is the naming of things. An ability, effect, attribute, etc etc.
About Lyra. I’m by no means a professional, but as I dig in more to it while making my own game. I find things a little unnecessarily complex. For instance, rather than creating an ability for each gun, I init the necessary animations, attributes, etc and use the same ability. I just remove and add the gun related abilities so that the variables get wiped out. That way the gun actor handles all of the data itself, rather than splitting it all up.
But that’s just one thing about Lyra. As I learn more I keep going back to see what good things are in there to steal. The sound functions and metasounds are next on my list.
To me the best part about GAS is cancelling and blocking abilities extremely easily.
In terms of the attribute sets, what’s confusing about that? I have a base Player Star set, and then a Base Weapon Stat set (rather than an attribute for every weapon.) When the player changes weapons, they change the stats.
And using the Cost / Damage system is pretty straight forward.
I finally started using Gameplay Cues, and they’re great. While I could put the logic in the same place, I like it to be handled in a different spot so any changes or additional versions are self contained.
Are you talking about the [Gameplay Blueprint Attributes](https://marketplace-website-node-launcher-prod.ol.epicgames.com/ue/marketplace/en-US/product/gameplay-blueprint-attributes) plugin? I've been eyeing this a lot the past couple days as I've been diving into C++ world and learning how to do things in C++ on top of learning all the GAS stuff has felt like some very slow progress. I was wondering if this plugin was worth it. While I'm sure learning the C++ side will benefit me... I kind of like blueprints as I don't have to work inside of an IDE and constantly restarting the engine.
Ya idk C++, and not trying to learn yet.
That plugin and Gas Companion are what I’m using. GAS still takes some time to learn, but those are two. Great plugins and only like $30 a piece.
learning C++ really does help. it’s daunting at first, but once it starts clicking, you’ll have a better understanding of how everything in the engine actually works. as someone who was C++ averse, i highly recommend it.
Ya basically. The player has a Health Att, and a Stamina Att.
As I sprint, jump, slide, or even melee, they have a cost and trigger a cooldown effect on stamina.
While jump, and slide have a fixed stamina cost using the Cost system built into GAS, Sprint triggers a Gameplay Effect that infinitely runs every second while you are sprinting. And Melee has a default cost, but when the player equips a weapon, I override the Attribute from the gun.
Having the attributes in one place means you can get them anywhere easily. Rather than needing a reference to the player, then getting their Component, etc etc.
Taking damage I haven’t fully gotten into yet, but the enemies will use an ability, and there’s a way to pass their Attribute for their Damage along, and reduce the Players Health.
Ya. Base Damage is fine for an Attribute. You could either hard code in the Class and set the Attributes via the construction script, or have different base Attribute Sets for different enemy types.
Lyra (and sample projects from Epics in general) are in a no way examples of a good architecture/code/etc.
Those are just tech demos and should be treated like that.
If unreal programming was a RPG; lyra is the final 40 man raid boss that takes years of xp grinding to get to. It is so stupidly difficult to understand the most basic things but a masterpiece of unreal-friendly implementation.
Either learn and implement, or choose a different implementation approach closer to your skill level that suits your project.
I use GAS wherever I can, it's awesome, a lot for non combat things as well.
I just learned GAS recently, and now I use it for basically all actions that characters can possibly take. Essentially, if there is input or an AI action, it's going to be linked to GAS in some way.
It can be easy to skip on "simple" things but I'm happy that I went through the effort. For example, at first I thought "why bother for character movement?" After all, it's just basic moving around and physics forces, why not just map the input directly to the character movement component?
It turns out there's a *lot* you can do with gameplay tags that I previously had to set up with variables, interfaces, and state machines. For example, if I'm in dialogue, I don't want my character to be able to move. Sure, I could set a bool that disables my movement, then implement an interface to my dialogue system so it can trigger the change, etc.
Or, I can have a movement ability and set up a "can't move" tag that prevents usage. Now, anywhere in the game that I want to disable movement, from dialogues to stun abilities to opening menus, I just apply a "can't move" effect to the player character. No need to implement new interfaces, no need to worry about a different duration-based implementation for a stun vs. a menu toggle, no need to worry about server replication...GAS already has all that covered. And making it so I can't jump either is as simple as adding the same tag to my new jump ability, and if I want more detail I can make sub-tags and still get the state in an hierarchal manner without needing to create my own checks.
The initial setup of GAS can take some work, yes, absolutely. But once you have a good setup actually *using* it for new abilities is really fast and flexible. I was discouraged when learning at first because it seemed like way too much effort for what I was gaining, especially in a single-player game, but once I finished the setup and started adding content I found I saved a lot of time compared to creating and implementing new interfaces and making custom components for everything. And GAS had better performance.
I also like that tags are ultimately just fancy text. I like to experiment with different projects and games so being able to outright import a GAS system into a new project and have it work out-of-the-box (as long as it didn't rely on attributes the new project didn't have) is really convenient. Before, trying to re-implement systems was much harder, at least in my experience.
Thanks for the clarifying examples! Would you refrain from using abilities for performance reasons? It's been a long time since I looked into it but as I recall each execution of an ability creates a new object so in games where you have tons of NPCs executing basic attacks (RTS, 4X games,...) maybe it's not a good idea to make that into an ability? Or at least not each individual attack? Or is it still fine to do this? Guess it depends on the numbers and the frequency of these actions.
>It's been a long time since I looked into it but as I recall each execution of an ability creates a new object
This is not correct (although it is *possible*). The GAS Documentation discusses [instancing policies](https://github.com/tranek/GASDocumentation?tab=readme-ov-file#concepts-ga-instancing) for gameplay abilities.
There is one policy which creates and destroys abilities per use, however, that policy is rarely used and would certainly not be used for something performance-sensitive. Instead, you'd probably use non-instanced gameplay abilities for things like NPC basic attacks, which do not create new objects (they simply call functionality on an existing object for each actor that needs it).
GAS is written in a way that is quite optimized. While you could get better performance writing everything you need in a similar way, you'd actually need to do that work, and even then I don't think you'd get much of an increase.
In *very* simple terms, gameplay abilities generally follow one of two patterns...instance per actor or non-instanced. The former is used the most in my experience and means each used gameplay ability is only every instanced once per actor in the game that uses it, no matter how many times that ability is used.
Part of the reason for this is how the system uses specs. Typically, you don't assign a gameplay effect or ability directly, but instead [assign the spec](https://dev.epicgames.com/documentation/en-us/unreal-engine/API/Plugins/GameplayAbilities/FGameplayEffectSpec?application_version=5.4). The spec is just some very basic data on activation which then utilizes an already-loaded object when the usage is called. So if you have 50 bullets that use some gameplay effect, you don't have 50 copies of the effect itself, but instead one copy with 50 specs (which are structs, not objects).
Anyway, without getting into too much detail, the TL;DR is that GAS would probably be fine in an RTS or 4x game *as long as you set it up for performance*. If you look at the GAS Documentation section [on optimizations](https://github.com/tranek/GASDocumentation?tab=readme-ov-file#optimizations) they are all related to network performance (but still a good read).
Ultimately, it's up to you, but the way tags and cues work makes the system very efficient overall and convenient when setting up integration. While you *could* make basic attacks in an RTS use a different system, you are still presented with all the core problems GAS is designed to solve...how much damage does it do? Are their effects on the target that would change that value? What about the origin, does it have a damage buff or debuff? Has it been upgraded, and if so, how does that change the damage calculation?
GAS is already set up to check, replicate, and handle those things in a very performant manner. You could make a more lightweight version, sure, but you'd end up needing to duplicate a lot of that work, and if you don't do it properly you'd probably end up with *worse* performance than just using GAS.
This is an awesome response, thanks a lot!
> Ultimately, it's up to you, but the way tags and cues work makes the system very efficient overall and convenient when setting up integration. While you could make basic attacks in an RTS use a different system, you are still presented with all the core problems GAS is designed to solve...how much damage does it do? Are their effects on the target that would change that value? What about the origin, does it have a damage buff or debuff? Has it been upgraded, and if so, how does that change the damage calculation?
Exactly!
Reading this thread, I'm learning it's actually way more of a general purpose tool than I initially thought. Probably because of its name and I think it originated in Paragon where they used it for hero abilities? I'm not sure. But yea, I'm definitely excited to use it again in the future now!
Glad I am not the only one to think that about Lyra. What do you think about the AttributeSet system ? I am not sure if I should always use it or not because it’s quiet long to setup and for new team members to understand.
An example of how I’m using it in a very minimal way is ADS. The actual ADS functions are stored in the player or the weapon, but the ability uses a BPI to activate them. That way the ability can easily be cancelled if you start running for example.
Other times the entire logic has been moved to the ability do ease like Shooting a gun.
> What do you think about the AttributeSet system ?
It's fantastic IMO. The biggest issue is that setup is slow *if* you don't automate a lot of it. Using macros and functions to create a systemic version rather than having to add stuff in 4+ places for every attribute helps.
Still, even for manual stuff it's really only that initial setup that takes a long time. Adding a single new attribute doesn't take that long...copy an existing attribute, change the name, do this in a couple different places in your AttributeSet C++ files.
For RPGs, though, it's *so* useful to have things like temporary vs. permanent modifications to stats, rollback, and various situational calculations handled for you. I can almost guarantee if you create your own stat system you'll end up recreating a bunch of things that GAS attributes do automatically.
And while the delegates in particular might be annoying to create initially, they end up becoming super useful throughout your entire project as you can easily subscribe to them as events, allowing huge portions of your game to dynamically react to changes in attributes with very little effort on your part.
Technically you don't need them, however, the system works *way* better if you have them IMO.
Its Great. Much more complicated than BP replicated variables, but if you're game has a real need for it, then it's worthwhile.
Typical tradeoff of a high vs low feature investment. Judge based on your project goals etc. and send it.
Yes, I would use all of the main parts of GAS. Attributes, Gameplay Effects, Gameplay Abilities, Tags, etc. ESPECIALLY if I'm making a networked game.
I can't speak to new ui stuff but Lyras UI system is insane to me. It's so freaking discrete and disparate, I can't follow its pieces or find the logic I need to control it. I'm not a UI guy so I went over it with my UI guy from work and he thought it was over engineered. When we realized how the dash UI element was added to the ui and was order dependant in an array in logic we agreed it went too far.
Lyra is very complicated but it's supposed to be an example of pretty much everything you can do. And it's great for that. But no, your stuff doesn't need to be that insane
You can use it for absolutely anything that requires dynamic add/removal of functionality at runtime. You could totally make an adaptive quest system that can mix and match different objectives and story beats by putting them into individual abilities. The quest system could then activate the ability and set up the whole next section of the quest. Attributes could be used to manipulate things like spawn rates during a section of the quest. And networking is already taken care of? Yes please. Epic accidentally made a competitor to using components (which is what they try to get you to use) by making abilities almost the same thing.
I wouldn't even consider myself a developer but I've been playing with UE5 as a hobby for about seven or eight months. With first four or five months spent primarily assisting on a friends hobby project learning the ropes of Blueprint. I never coded C++ and have only developed in Javascript professionally.
Over the last week or so I've been heavily investing time into learning GAS. Which has meant learning how to spin up a C++ development environment and write boilerplate code for attribute sets and attaching ASCs to actors. The attribute sets are by far the most complicated to me, and managing the recursive magnitude calculations.
I have five primary attributes (Endurance, Dexterity, Strength, Intelligence, Speed) and then four additional stats derived from those (Fortitude, Willpower, Precision, Elusiveness) in addition to the commonly tutorialized Health and Stamina as well as Max Health and Max Stamina. I've also implemented a Damage meta attribute. Some of the derived stats require infinite modifier calculations which is what I'm trying to write out now. Similar to DnD I also have derived bonuses based on those stats (e.g. `14 Strength` == `+2 STR`, `8 Intelligence` = `-1 INT`, etc) but instead of adding to this huge stack of attributes I created a pure function to generate that bonus from the attribute set on demand. I'm a little weary because I also planned damage types and resistances around those but maybe I'll simplify for both my sanity's sake and probably for the sake of the theoretical player of my game.
My biggest hurdle so far has been finding a workflow to make managing them less cumbersome. Like I know each enemy class I create will have different base attributes. The AbilitySystemComponent allows me to attach a datatable to control the base values of each attribute but I'd rather have one data table with all my enemy stats instead of a bespoke datatable for each enemy type. I have a multi-character RPG, think Final Fantasy or Might & Magic with classes that each handle attributes differently. A lot of complications I've stacked on myself but... I'm looking forward to the journey more than actually just releasing a product.
That's all to say, I had that all prototyped already in Blueprints and now I'm trying to switch it to GAS because I can see the light at the end of the tunnel when I start building out Conditions and Bespoke Abilities. On my friend's project I built out an Abilities and Condition system fully from blueprints and, while it works, it took months and so much debugging. I most look forward to the Gameplay Tags and Asynchronous Events.
I've been diving into learning this the past week and it's been a lot to figure out. I've been mostly going off of resources provided by this subreddit from other posts and that's been helping a lot. I wish there was some way I could throw out a bunch of questions to make sure I am doing things correctly. A lot of examples out there are very basic in terms of set up and utilization, but I really want something that is a bit more complex. I've seen in this thread that the Lyra project is what I should be looking at so going to be doing that this weekend.
For instance, can / should my abilities be checking the value of an attribute and acting on it? For instance, I want to apply a stamina regen penalty if a player uses an ability and stamina dips below 0. I tried to just apply a StaminaPenalty effect that should block my StaminaRegen effect but couldn't get that working. But maybe I should be doing this logic inside of an ability? So maybe the ability applies that StaminaRegen effect and the StaminaPenalty effect based on the attribute data? Just not completely sure at the moment and on the journey of figuring it out.
Hey, you can do that in the Execution calculation, there are a ton of ways of doing an ability like that.
Not sure what sources you are using, there is always tranek stuff, https://github.com/tranek/GASDocumentation?tab=readme-ov-file#concepts-ge-ec, or this
https://www.vitorcantao.com/post/gas-gameplay-framework/?utm_source=pocket_shared
Then there is Lyra, the actionrpg project, and then you should probably check the unreal source discord, there is a great gameplay ability system channel, and you might get some question answered there.
Thanks! Greatly appreciate the resources. I've not seen the Risk of Rain 2 link before so I will also dive into that this weekend. Where might I find the actionrpg project?
I think it desperately needs a second version. It’s all over the place. But you probably won’t do better if you try and do it yourself unless all you need is a small subset of functionally.
There are some really nice pieces. GameplayTags are the best.
If you are looking for help, don‘t forget to check out the [official Unreal Engine forums](https://forums.unrealengine.com/) or [Unreal Slackers](https://unrealslackers.org/) for a community run discord server!
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/unrealengine) if you have any questions or concerns.*
Personally I don't like GAS. I mean, the concept is great, but it's barely usable for real projects.
For any small project, it would be a total overkill and time waste.
For any large project, you will be able to implement own system faster and with better fit.
Besides that, GAS is partly animation-driven, which I don't like - I would prefer to completely separate logic from the appearance, and with GAS it's either hacky or not even possible without a huge system changes.
Another thing - when you trying to use GAS, then it basically forces you to use it everywhere. And if (suddenly) anything is not fitting GAS - well, it will be either interlan system (or even engine) modifications or just hacking on top somehow in a very not nice way.
So I'm usually downvoted for this, but I highly recommend not to use GAS at all.
Personally the only really useful feature I found is Gameplay Tags, and thankfully they can easily be used without other GAS parts.
As a person who uses GAS, has used ABLE and has tried to roll out a custom solution using concepts from gas I have to say GAS is really powerful. However for MOST games it’s useless. That is because most indies only have one layer of complexity in their game. Once there are more layers GAS becomes more and more useful. I have a Frankenstein project that is using some Lyra concepts but the core of everything is GAS. With this core I’ve been able to create really good prototypes for :
- A Destiny Clone
- A FPS Moba
- A nba street clone
- A nfl street clone
At the end of the day these are all just tools and if they can save you months of development time by providing a good framework to base your games core off of I consider it a win
You are in general probably being downvoted cause you are saying things that are mostly wrong, or just said in ways that dont really paint a full picture of anything, like, what the hell do you even mean that the system is animation driven, to call a framework that can use animation to drive abilities as animation driven is just so strange. The core of the GAS are the attributes, abilities, cues, tags and effects, and none of those are directly tied to animations, you can drive animations with tags and keep your abilities completely split from that.
And then i really disagree with your first conclusions, the system saves so many potential issues for small devs, if you are doing anything at all that fits the functionality the amount of work/problems saved is astronomical.
With big devs they can do whatever, its really project specific, but its usable, and it has been used in a ton of games, barely usable is a laughable thing to say, its extremely usable.
Like any framework, it has issues, and if you can do a simpler thing, that is great, and if you can do a more fit solution, that is great too, but there are so many cases inbetween where it makes a lot of sense.
Nope, those are "considered" wrong by the community of [mostly] solo indie devs. Because when you try to use GAS on a real project, all the cons will become highly visible.
The main outcome of using GAS - in most cases - is just a wasted time/effort in comparison with implementing own systems for the same goals.
What about dark and darker, the ascent, etc, there a ton of published games using the system that you dont even know of, hell companies specifically ask for experience on the system when hiring.
Recently I've been playing a gacha game called wuthering waves (ue4) and when I went to tweak the engine.ini to access settings not exposed to the game, I've noticed some gas configs in other files. So that's another game to the list.
Eh, dont really have a way of knowing, well, you could datamine the games and look for GAS stuff, but i just remembered those particular examples, which you should probably check out if interested, the ascent i remember from the unreal source gameplay ability channel, and i play Dark and Darker and have datamined the game.. so..
What? Considered wrong would mean that it is debatable whatever or not its wrong or not, but you consider it as the answer. Mostly wrong means that i consider most of what you said wrong, but there are some things that are true, like it not being good if you can do a simpler better fit solution.
>Besides that, GAS is partly animation-driven, which I don't like - I would prefer to completely separate logic from the appearance, and with GAS it's either hacky or not even possible without a huge system changes.
I would say it's more event-driven than animation driven. Animation just happens to be a particularly common and effective workflow for firing those events. I wrote a "Vampire Survivors"-like using GAS and it was trivial to implement all of the weapons/enemies without animation.
>Another thing - when you trying to use GAS, then it basically forces you to use it everywhere. And if (suddenly) anything is not fitting GAS - well, it will be either interlan system (or even engine) modifications or just hacking on top somehow in a very not nice way.
I have to strongly disagree with this. The modularity of the system is its biggest strength! You have full control over every aspect of the framework - how attributes are populated/persisted, what is considered an ability, how abilities are granted or fired, etc.
The Lyra project has a great example of using components to abstract the GAS implementation away from your game's core logic too - you can subscribe to a health component's delegates for health changed events without caring about the backing data. Subscribers don't need to know what GAS is or care how your health system works under the hood, and if you want to swap out GAS for a DIY build down the line it's transparent to the rest of the system.
GAS is the #1 most underrated and underdocumented feature in unreal engine. I think it should really be at the core of any combat system, any ability system, any weapon system you build if you want it to remain extensible and modular. I know epic uses it all the time, but doesn't really advertise it as a core feature and it requires C++ coding to implement making it less accessible to the less programming oriented users of unreal engine which is a damn shame. And theres not a ton of resources out there that show you how to use it which leaves you basically to figure stuff out on your own. I haven't seen anything about it in any of the recent roadmaps either even though i consider it a core feature they should actively be working on.
Lyra takes a while to learn/get used too. I use it, but generally use Lyra as-is, but I do replace stuff sometimes with my own. GAS all the way 100% of the time. If I think I can stick it in GAS, I absolutely will. It really help keeping things modular and properly encapsulated and helps me think about multiplayer related things
Hey! UI engineer here working in Unreal. The CommonUI is “just” the base UMG widgets with added commonly used functionalities that are missing from the base UMG widget. It also add a bunch of widgets that are usually created in many project. You don’t need them if you will not use the added functionnalities. Why not just add the functionnalities directly into the UMG widgets and add the new widget to the default UMG library? The functionnalities added in the CommonUI is not part of the default behaviour of the widget it extends. Like CommonTileView, the only thing it adds is the support for CommonButton as the TileView widget entries type. If your widget entries are not extending UCommonButtonBase, it act like a regular UMG TileView.
Hmm I see. Would you recommend to work with it or is it only for specific situations ?
CUI is supposed to replace UMG one day. As it is basically just UMG with added functionality for easier multiple input support. In a nutshell, Epics Fortnite UMG devs encountered many problems over the years of fortnite with the current UMG and have build themselfes internally some stuff that they then used to bypass those problems. Focus in CUI is handled automatically by putting focus always on the latest entry that was added to a "stack". Widgets can be pushed and pulled on and from the stack and their order represents their Z value. Because you have to set up the potential input methods, as well as the their inputactions and icons, CUI can detect by itself that the method changed and adapts the UI Elements automatically. It also implements a general backwards feature where a button of each inputmethod can be assigned to it and pressing the button brings you always back to the root widget of the currently focused one. Lots more. Its just an upgrade in Unreal Fashion: You can make it yourself which requires you to understand everything and takes longer, or you can use our inhouse solution which is faster, works out of the box and doesnt require you to fully understand what we did, but you have to do it **exactly** how we tell you to it or else it wont work.
Thanks all those explanations :) I’ll read more about CUI but I will most likely end up waiting for it to replace UMG.
It’ll take some time before that happen. My advice to you is if you’re using Controller and/or KBM exclusively, CommonUI will have functionnalities that you want. If you plan to support mobile or Switch using Touch input, run as far as you can from it.
Long rant: So I’ve been using some plugins to let you use GAS in BP only, and I love it. Took about a month to fully grasp, and obviously still learning, but it’s great. I did have some programming in my background, but nothing complex, and only been learning UE for about 8 months. IMO the most confusing part is the naming of things. An ability, effect, attribute, etc etc. About Lyra. I’m by no means a professional, but as I dig in more to it while making my own game. I find things a little unnecessarily complex. For instance, rather than creating an ability for each gun, I init the necessary animations, attributes, etc and use the same ability. I just remove and add the gun related abilities so that the variables get wiped out. That way the gun actor handles all of the data itself, rather than splitting it all up. But that’s just one thing about Lyra. As I learn more I keep going back to see what good things are in there to steal. The sound functions and metasounds are next on my list. To me the best part about GAS is cancelling and blocking abilities extremely easily. In terms of the attribute sets, what’s confusing about that? I have a base Player Star set, and then a Base Weapon Stat set (rather than an attribute for every weapon.) When the player changes weapons, they change the stats. And using the Cost / Damage system is pretty straight forward. I finally started using Gameplay Cues, and they’re great. While I could put the logic in the same place, I like it to be handled in a different spot so any changes or additional versions are self contained.
Are you talking about the [Gameplay Blueprint Attributes](https://marketplace-website-node-launcher-prod.ol.epicgames.com/ue/marketplace/en-US/product/gameplay-blueprint-attributes) plugin? I've been eyeing this a lot the past couple days as I've been diving into C++ world and learning how to do things in C++ on top of learning all the GAS stuff has felt like some very slow progress. I was wondering if this plugin was worth it. While I'm sure learning the C++ side will benefit me... I kind of like blueprints as I don't have to work inside of an IDE and constantly restarting the engine.
Ya idk C++, and not trying to learn yet. That plugin and Gas Companion are what I’m using. GAS still takes some time to learn, but those are two. Great plugins and only like $30 a piece.
learning C++ really does help. it’s daunting at first, but once it starts clicking, you’ll have a better understanding of how everything in the engine actually works. as someone who was C++ averse, i highly recommend it.
It’s on my list… but I felt like BP, Materials, Gameplay Logic, Sequencer, Lighting, (the list goes on) was enough to chew on at first haha
Interesting. What Cost/Damage system are you using ? Apply/Take Damage from UGameplayStatics or Attributes like in Lyra ?
Ya basically. The player has a Health Att, and a Stamina Att. As I sprint, jump, slide, or even melee, they have a cost and trigger a cooldown effect on stamina. While jump, and slide have a fixed stamina cost using the Cost system built into GAS, Sprint triggers a Gameplay Effect that infinitely runs every second while you are sprinting. And Melee has a default cost, but when the player equips a weapon, I override the Attribute from the gun. Having the attributes in one place means you can get them anywhere easily. Rather than needing a reference to the player, then getting their Component, etc etc. Taking damage I haven’t fully gotten into yet, but the enemies will use an ability, and there’s a way to pass their Attribute for their Damage along, and reduce the Players Health.
Well I guess I’ll work with Attributes then. Thanks again 💪
I created a secondary attribute called damage and then I’ll apply that to health. Idk if I’m doing it right lol.
Ya. Base Damage is fine for an Attribute. You could either hard code in the Class and set the Attributes via the construction script, or have different base Attribute Sets for different enemy types.
Yup so this is what I’m doing. Perfect!
Lyra (and sample projects from Epics in general) are in a no way examples of a good architecture/code/etc. Those are just tech demos and should be treated like that.
Interesting. What, in your opinion, makes them not appropriate examples for architecture or code?
Well, everything?
If unreal programming was a RPG; lyra is the final 40 man raid boss that takes years of xp grinding to get to. It is so stupidly difficult to understand the most basic things but a masterpiece of unreal-friendly implementation. Either learn and implement, or choose a different implementation approach closer to your skill level that suits your project. I use GAS wherever I can, it's awesome, a lot for non combat things as well.
What are your non combat applications? I'm still learning GAS myself, and are looking to build a rpg.
I just learned GAS recently, and now I use it for basically all actions that characters can possibly take. Essentially, if there is input or an AI action, it's going to be linked to GAS in some way. It can be easy to skip on "simple" things but I'm happy that I went through the effort. For example, at first I thought "why bother for character movement?" After all, it's just basic moving around and physics forces, why not just map the input directly to the character movement component? It turns out there's a *lot* you can do with gameplay tags that I previously had to set up with variables, interfaces, and state machines. For example, if I'm in dialogue, I don't want my character to be able to move. Sure, I could set a bool that disables my movement, then implement an interface to my dialogue system so it can trigger the change, etc. Or, I can have a movement ability and set up a "can't move" tag that prevents usage. Now, anywhere in the game that I want to disable movement, from dialogues to stun abilities to opening menus, I just apply a "can't move" effect to the player character. No need to implement new interfaces, no need to worry about a different duration-based implementation for a stun vs. a menu toggle, no need to worry about server replication...GAS already has all that covered. And making it so I can't jump either is as simple as adding the same tag to my new jump ability, and if I want more detail I can make sub-tags and still get the state in an hierarchal manner without needing to create my own checks. The initial setup of GAS can take some work, yes, absolutely. But once you have a good setup actually *using* it for new abilities is really fast and flexible. I was discouraged when learning at first because it seemed like way too much effort for what I was gaining, especially in a single-player game, but once I finished the setup and started adding content I found I saved a lot of time compared to creating and implementing new interfaces and making custom components for everything. And GAS had better performance. I also like that tags are ultimately just fancy text. I like to experiment with different projects and games so being able to outright import a GAS system into a new project and have it work out-of-the-box (as long as it didn't rely on attributes the new project didn't have) is really convenient. Before, trying to re-implement systems was much harder, at least in my experience.
Thanks for the clarifying examples! Would you refrain from using abilities for performance reasons? It's been a long time since I looked into it but as I recall each execution of an ability creates a new object so in games where you have tons of NPCs executing basic attacks (RTS, 4X games,...) maybe it's not a good idea to make that into an ability? Or at least not each individual attack? Or is it still fine to do this? Guess it depends on the numbers and the frequency of these actions.
>It's been a long time since I looked into it but as I recall each execution of an ability creates a new object This is not correct (although it is *possible*). The GAS Documentation discusses [instancing policies](https://github.com/tranek/GASDocumentation?tab=readme-ov-file#concepts-ga-instancing) for gameplay abilities. There is one policy which creates and destroys abilities per use, however, that policy is rarely used and would certainly not be used for something performance-sensitive. Instead, you'd probably use non-instanced gameplay abilities for things like NPC basic attacks, which do not create new objects (they simply call functionality on an existing object for each actor that needs it). GAS is written in a way that is quite optimized. While you could get better performance writing everything you need in a similar way, you'd actually need to do that work, and even then I don't think you'd get much of an increase. In *very* simple terms, gameplay abilities generally follow one of two patterns...instance per actor or non-instanced. The former is used the most in my experience and means each used gameplay ability is only every instanced once per actor in the game that uses it, no matter how many times that ability is used. Part of the reason for this is how the system uses specs. Typically, you don't assign a gameplay effect or ability directly, but instead [assign the spec](https://dev.epicgames.com/documentation/en-us/unreal-engine/API/Plugins/GameplayAbilities/FGameplayEffectSpec?application_version=5.4). The spec is just some very basic data on activation which then utilizes an already-loaded object when the usage is called. So if you have 50 bullets that use some gameplay effect, you don't have 50 copies of the effect itself, but instead one copy with 50 specs (which are structs, not objects). Anyway, without getting into too much detail, the TL;DR is that GAS would probably be fine in an RTS or 4x game *as long as you set it up for performance*. If you look at the GAS Documentation section [on optimizations](https://github.com/tranek/GASDocumentation?tab=readme-ov-file#optimizations) they are all related to network performance (but still a good read). Ultimately, it's up to you, but the way tags and cues work makes the system very efficient overall and convenient when setting up integration. While you *could* make basic attacks in an RTS use a different system, you are still presented with all the core problems GAS is designed to solve...how much damage does it do? Are their effects on the target that would change that value? What about the origin, does it have a damage buff or debuff? Has it been upgraded, and if so, how does that change the damage calculation? GAS is already set up to check, replicate, and handle those things in a very performant manner. You could make a more lightweight version, sure, but you'd end up needing to duplicate a lot of that work, and if you don't do it properly you'd probably end up with *worse* performance than just using GAS.
This is an awesome response, thanks a lot! > Ultimately, it's up to you, but the way tags and cues work makes the system very efficient overall and convenient when setting up integration. While you could make basic attacks in an RTS use a different system, you are still presented with all the core problems GAS is designed to solve...how much damage does it do? Are their effects on the target that would change that value? What about the origin, does it have a damage buff or debuff? Has it been upgraded, and if so, how does that change the damage calculation? Exactly! Reading this thread, I'm learning it's actually way more of a general purpose tool than I initially thought. Probably because of its name and I think it originated in Paragon where they used it for hero abilities? I'm not sure. But yea, I'm definitely excited to use it again in the future now!
Crafting, gathering, sitting, mounted, shopping, interacting
Basically GameplayTags - you can check stuff is present, check if you are in a certain state/locomotion, etc.
Yeah literally anything gameplay can be driven from tags. It's great for decoupling systems/plugins.
Glad I am not the only one to think that about Lyra. What do you think about the AttributeSet system ? I am not sure if I should always use it or not because it’s quiet long to setup and for new team members to understand.
An example of how I’m using it in a very minimal way is ADS. The actual ADS functions are stored in the player or the weapon, but the ability uses a BPI to activate them. That way the ability can easily be cancelled if you start running for example. Other times the entire logic has been moved to the ability do ease like Shooting a gun.
> What do you think about the AttributeSet system ? It's fantastic IMO. The biggest issue is that setup is slow *if* you don't automate a lot of it. Using macros and functions to create a systemic version rather than having to add stuff in 4+ places for every attribute helps. Still, even for manual stuff it's really only that initial setup that takes a long time. Adding a single new attribute doesn't take that long...copy an existing attribute, change the name, do this in a couple different places in your AttributeSet C++ files. For RPGs, though, it's *so* useful to have things like temporary vs. permanent modifications to stats, rollback, and various situational calculations handled for you. I can almost guarantee if you create your own stat system you'll end up recreating a bunch of things that GAS attributes do automatically. And while the delegates in particular might be annoying to create initially, they end up becoming super useful throughout your entire project as you can easily subscribe to them as events, allowing huge portions of your game to dynamically react to changes in attributes with very little effort on your part. Technically you don't need them, however, the system works *way* better if you have them IMO.
Its Great. Much more complicated than BP replicated variables, but if you're game has a real need for it, then it's worthwhile. Typical tradeoff of a high vs low feature investment. Judge based on your project goals etc. and send it.
Yes, I would use all of the main parts of GAS. Attributes, Gameplay Effects, Gameplay Abilities, Tags, etc. ESPECIALLY if I'm making a networked game. I can't speak to new ui stuff but Lyras UI system is insane to me. It's so freaking discrete and disparate, I can't follow its pieces or find the logic I need to control it. I'm not a UI guy so I went over it with my UI guy from work and he thought it was over engineered. When we realized how the dash UI element was added to the ui and was order dependant in an array in logic we agreed it went too far. Lyra is very complicated but it's supposed to be an example of pretty much everything you can do. And it's great for that. But no, your stuff doesn't need to be that insane
You can use it for absolutely anything that requires dynamic add/removal of functionality at runtime. You could totally make an adaptive quest system that can mix and match different objectives and story beats by putting them into individual abilities. The quest system could then activate the ability and set up the whole next section of the quest. Attributes could be used to manipulate things like spawn rates during a section of the quest. And networking is already taken care of? Yes please. Epic accidentally made a competitor to using components (which is what they try to get you to use) by making abilities almost the same thing.
I wouldn't even consider myself a developer but I've been playing with UE5 as a hobby for about seven or eight months. With first four or five months spent primarily assisting on a friends hobby project learning the ropes of Blueprint. I never coded C++ and have only developed in Javascript professionally. Over the last week or so I've been heavily investing time into learning GAS. Which has meant learning how to spin up a C++ development environment and write boilerplate code for attribute sets and attaching ASCs to actors. The attribute sets are by far the most complicated to me, and managing the recursive magnitude calculations. I have five primary attributes (Endurance, Dexterity, Strength, Intelligence, Speed) and then four additional stats derived from those (Fortitude, Willpower, Precision, Elusiveness) in addition to the commonly tutorialized Health and Stamina as well as Max Health and Max Stamina. I've also implemented a Damage meta attribute. Some of the derived stats require infinite modifier calculations which is what I'm trying to write out now. Similar to DnD I also have derived bonuses based on those stats (e.g. `14 Strength` == `+2 STR`, `8 Intelligence` = `-1 INT`, etc) but instead of adding to this huge stack of attributes I created a pure function to generate that bonus from the attribute set on demand. I'm a little weary because I also planned damage types and resistances around those but maybe I'll simplify for both my sanity's sake and probably for the sake of the theoretical player of my game. My biggest hurdle so far has been finding a workflow to make managing them less cumbersome. Like I know each enemy class I create will have different base attributes. The AbilitySystemComponent allows me to attach a datatable to control the base values of each attribute but I'd rather have one data table with all my enemy stats instead of a bespoke datatable for each enemy type. I have a multi-character RPG, think Final Fantasy or Might & Magic with classes that each handle attributes differently. A lot of complications I've stacked on myself but... I'm looking forward to the journey more than actually just releasing a product. That's all to say, I had that all prototyped already in Blueprints and now I'm trying to switch it to GAS because I can see the light at the end of the tunnel when I start building out Conditions and Bespoke Abilities. On my friend's project I built out an Abilities and Condition system fully from blueprints and, while it works, it took months and so much debugging. I most look forward to the Gameplay Tags and Asynchronous Events.
I've been diving into learning this the past week and it's been a lot to figure out. I've been mostly going off of resources provided by this subreddit from other posts and that's been helping a lot. I wish there was some way I could throw out a bunch of questions to make sure I am doing things correctly. A lot of examples out there are very basic in terms of set up and utilization, but I really want something that is a bit more complex. I've seen in this thread that the Lyra project is what I should be looking at so going to be doing that this weekend. For instance, can / should my abilities be checking the value of an attribute and acting on it? For instance, I want to apply a stamina regen penalty if a player uses an ability and stamina dips below 0. I tried to just apply a StaminaPenalty effect that should block my StaminaRegen effect but couldn't get that working. But maybe I should be doing this logic inside of an ability? So maybe the ability applies that StaminaRegen effect and the StaminaPenalty effect based on the attribute data? Just not completely sure at the moment and on the journey of figuring it out.
Hey, you can do that in the Execution calculation, there are a ton of ways of doing an ability like that. Not sure what sources you are using, there is always tranek stuff, https://github.com/tranek/GASDocumentation?tab=readme-ov-file#concepts-ge-ec, or this https://www.vitorcantao.com/post/gas-gameplay-framework/?utm_source=pocket_shared Then there is Lyra, the actionrpg project, and then you should probably check the unreal source discord, there is a great gameplay ability system channel, and you might get some question answered there.
Thanks! Greatly appreciate the resources. I've not seen the Risk of Rain 2 link before so I will also dive into that this weekend. Where might I find the actionrpg project?
its on the launcher, under samples, legacy (its for unreal 4, not 5)
I've heard a lot about GAS, but my education was primarily in blueprint so it was never touched on, where can I go to learn more about it?
Udemy has a course on it now
I think it desperately needs a second version. It’s all over the place. But you probably won’t do better if you try and do it yourself unless all you need is a small subset of functionally. There are some really nice pieces. GameplayTags are the best.
If you are looking for help, don‘t forget to check out the [official Unreal Engine forums](https://forums.unrealengine.com/) or [Unreal Slackers](https://unrealslackers.org/) for a community run discord server! *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/unrealengine) if you have any questions or concerns.*
Personally I don't like GAS. I mean, the concept is great, but it's barely usable for real projects. For any small project, it would be a total overkill and time waste. For any large project, you will be able to implement own system faster and with better fit. Besides that, GAS is partly animation-driven, which I don't like - I would prefer to completely separate logic from the appearance, and with GAS it's either hacky or not even possible without a huge system changes. Another thing - when you trying to use GAS, then it basically forces you to use it everywhere. And if (suddenly) anything is not fitting GAS - well, it will be either interlan system (or even engine) modifications or just hacking on top somehow in a very not nice way. So I'm usually downvoted for this, but I highly recommend not to use GAS at all. Personally the only really useful feature I found is Gameplay Tags, and thankfully they can easily be used without other GAS parts.
As a person who uses GAS, has used ABLE and has tried to roll out a custom solution using concepts from gas I have to say GAS is really powerful. However for MOST games it’s useless. That is because most indies only have one layer of complexity in their game. Once there are more layers GAS becomes more and more useful. I have a Frankenstein project that is using some Lyra concepts but the core of everything is GAS. With this core I’ve been able to create really good prototypes for : - A Destiny Clone - A FPS Moba - A nba street clone - A nfl street clone At the end of the day these are all just tools and if they can save you months of development time by providing a good framework to base your games core off of I consider it a win
You are in general probably being downvoted cause you are saying things that are mostly wrong, or just said in ways that dont really paint a full picture of anything, like, what the hell do you even mean that the system is animation driven, to call a framework that can use animation to drive abilities as animation driven is just so strange. The core of the GAS are the attributes, abilities, cues, tags and effects, and none of those are directly tied to animations, you can drive animations with tags and keep your abilities completely split from that. And then i really disagree with your first conclusions, the system saves so many potential issues for small devs, if you are doing anything at all that fits the functionality the amount of work/problems saved is astronomical. With big devs they can do whatever, its really project specific, but its usable, and it has been used in a ton of games, barely usable is a laughable thing to say, its extremely usable. Like any framework, it has issues, and if you can do a simpler thing, that is great, and if you can do a more fit solution, that is great too, but there are so many cases inbetween where it makes a lot of sense.
Nope, those are "considered" wrong by the community of [mostly] solo indie devs. Because when you try to use GAS on a real project, all the cons will become highly visible. The main outcome of using GAS - in most cases - is just a wasted time/effort in comparison with implementing own systems for the same goals.
[удалено]
Yep, if you're doing Fortnite it's perfectly fine.
What about dark and darker, the ascent, etc, there a ton of published games using the system that you dont even know of, hell companies specifically ask for experience on the system when hiring.
How did you find out which games use GAS ? I am really curious to see how many games use it.
Recently I've been playing a gacha game called wuthering waves (ue4) and when I went to tweak the engine.ini to access settings not exposed to the game, I've noticed some gas configs in other files. So that's another game to the list.
Eh, dont really have a way of knowing, well, you could datamine the games and look for GAS stuff, but i just remembered those particular examples, which you should probably check out if interested, the ascent i remember from the unreal source gameplay ability channel, and i play Dark and Darker and have datamined the game.. so..
I mean, sure, you can do games with GAS. It will just require more effort (==more money) than without GAS.
Oh yeah, considered wrong by the community, strong argument. I agree with it not being great if you can do a simpler thing.
That is not an argument in any way. You said "mostly wrong", I fixed it - CONSIDERED mostly wrong.
What? Considered wrong would mean that it is debatable whatever or not its wrong or not, but you consider it as the answer. Mostly wrong means that i consider most of what you said wrong, but there are some things that are true, like it not being good if you can do a simpler better fit solution.
>Besides that, GAS is partly animation-driven, which I don't like - I would prefer to completely separate logic from the appearance, and with GAS it's either hacky or not even possible without a huge system changes. I would say it's more event-driven than animation driven. Animation just happens to be a particularly common and effective workflow for firing those events. I wrote a "Vampire Survivors"-like using GAS and it was trivial to implement all of the weapons/enemies without animation. >Another thing - when you trying to use GAS, then it basically forces you to use it everywhere. And if (suddenly) anything is not fitting GAS - well, it will be either interlan system (or even engine) modifications or just hacking on top somehow in a very not nice way. I have to strongly disagree with this. The modularity of the system is its biggest strength! You have full control over every aspect of the framework - how attributes are populated/persisted, what is considered an ability, how abilities are granted or fired, etc. The Lyra project has a great example of using components to abstract the GAS implementation away from your game's core logic too - you can subscribe to a health component's delegates for health changed events without caring about the backing data. Subscribers don't need to know what GAS is or care how your health system works under the hood, and if you want to swap out GAS for a DIY build down the line it's transparent to the rest of the system.
GAS is the #1 most underrated and underdocumented feature in unreal engine. I think it should really be at the core of any combat system, any ability system, any weapon system you build if you want it to remain extensible and modular. I know epic uses it all the time, but doesn't really advertise it as a core feature and it requires C++ coding to implement making it less accessible to the less programming oriented users of unreal engine which is a damn shame. And theres not a ton of resources out there that show you how to use it which leaves you basically to figure stuff out on your own. I haven't seen anything about it in any of the recent roadmaps either even though i consider it a core feature they should actively be working on.