Let's Build the RPG! - 26 - Creating a Blueprint-Only Gameplay Ability System in Unreal Engine 5
ฝัง
- เผยแพร่เมื่อ 8 ก.ค. 2024
- In this episode we begin the creation of a brand new Blueprint-only Gameplay Ability System (often abbreviated GAS) from the ground up. I considered using Unreal Engine 5's out-of-the-box Gameplay Ability System framework, which appears to be an excellent framework, but I realized if I used it I would have to learn C++. And one goal of this series is to keep gamemaking accessible to non-programmers for as long as possible, and hopefully, all the way.
And so, this episode goes through the frame work of what I'm envisioning for a Gameplay Ability System. Although this is not a 'fun' episode, it's foundational to every gameplay ability we will develop over the course of this series. We also transition the gameplay ability we created in Episode 23, the TorchLight effect, into the new framework as a starting point.
00:00 Intro
00:16 Today's Goals and Conceptualizing a Gameplay Ability System
05:00 Quick Overview of Inheritance and why it's important for our Gameplay Ability System
08:17 Key Concepts
08:34 Creating and Setting up Gameplay Ability Actors
16:51 Creating references back to ThirdPersonCharacter and Animation Blueprint
20:50 Triggering Gameplay Ability from ThirdPersonCharacter
28:30 Setting up activation of first Gameplay Ability (Torchlight Effect)
34:59 CORRECTION: Correcting the ThirdPersonCharacter reference
36:06 Conclusion and Preview of Next Episode
New episode released every Saturday morning!
Direct References
Unreal Engine's standard Gameplay Ability System documentation:
docs.unrealengine.com/4.27/en...
Blueprint inheritance overview:
couchlearn.com/parent-and-chi...
Example of Blueprint Inheritance:
docs.unrealengine.com/4.27/en... - เกม
![[페이스캠4K] 베이비몬스터 치키타 'FOREVER' (BABYMONSTER CHIQUITA FaceCam) @SBS Inkigayo 240707](http://i.ytimg.com/vi/x9VRNTV4VDI/mqdefault.jpg)
![[LIVE] : ONE ลุมพินี 69 | คู่เอก "กุหลาบดำ vs นาบิล"](http://i.ytimg.com/vi/PNM6U8e_HMo/mqdefault.jpg)
17:30 - doing it this way significantly impacts performance because of all the hard references. I would look into soft references and blueprint interfaces. As a rule of thumb, you should only ever hard reference something that will always exist on your character at all times. Otherwise, use a soft reference.
Bro you don’t know how long i have been looking for something like that, thank you
I’m not sure if you’ve changed this down the line, but the first thing you did was introduce a circular dependency between the player and ability class. If anyone is following along, it might be better to use interfaces or components (the ability and the player would both have a dependency on the component, and could pass the data between without introducing the circular dependency)
Your a legend. Thank you for being so clear in explaining everything.
You and Gorka Games are keeping indie devs and people learning how to make games, alive. Thank you.
Tis a beginning
dont forget ryan laley uisco astrum sensei virtus hub and unf games other great devs that help the community if you dont already follow them too
@@magegames6202 just unreal sensei.
Really great tutoiral, thanks for taking the time. Lots of great explanations too.
You seem confident in your knowledge and it's encouraging. I started learning the basics following some other tutorials, felt tired of it and stepped away... coming back I'm excited to find your series and it's like the next step (in the sense you're the best teacher I've come across so far). Thanks a lot!
Confident enough that the same pattern has repeated enough times for me: I come to an impasse, not sure how to go about a solution, but there is a solution, and it just requires some time to pass along with fresh eyes. Welcome and glad to have you!
been very excited to get into this video! Finally there!
Hello i found you while i was searching and make my day it was awesome thank you i dropped a like and subscribed. Thank you
Subbing immediately. First time watching and im very impressed how informative you are. Im building a wizard game and have been focusing on level design and character rigging because i knew i wasnt ready for any coding or scripting for the spellcasting systems just yet. This is definitely giving me the confidence to start working on my spells soon. Which is perfect timing because i finally reached a point where im ready to start the next steps in development.
im kind of in the same boat im making a zelda type game but with magic ive played with spells a little but i bet this is a better method than i had set up hope your game progress is going well
This is one of the best tutorial series i ve ever seen, if youtube recommended this sooner my job would be so much easier
I was trying to use GAS for a hack and slash I'm working on but I couldn't get it up and running due to my nonexistent C++ knowledge which led to me having to restart due to errors I got in VS when trying to set it up. This actually is helping me set it up and piece together why it works. I saw that you even address problems in future videos from the comments and that there is the GAS companion. Even though I'll pick up the companion, I'll stick around to see how far I can get and understand it. Thanks a lot for this!
Gas companion has its limits, your still required to use C++ for some of the stuff you would probably want to implement into a hack and slack game.
glad i found this channel..
Thank you very much
I like how thorough you are in structuring the video, and not cut out any errors/ refactors, and even including chapters to properly keep the viewer paced. Alot of other videos I watched keep on referencing their older videos, and end up being incompatible with the tutorial asking for the said video. Thanks and keep up the great work!
29:49 - You should use anim notifies to get this timer. If it ever changes or is different for different characters, you're screwed.
Hello! I'm having an issue where whenever i press the 2 key, the fire spawns in my guy's hand which is what I want, but it also spawns again in my guy's chest, is there any way I can fix this? thanks!
The 4 elements have a basis in physical reality as well. It's solid, liquid, gas, and energy or plasma or whatever.
Great
You probably know by now. As you have set the variables and defined your functions in the parent class, you can simply right click on the begin play and activate events and click "Add Call to Parent Function"... this will basically inherit the functionality of its parent for that event into a single node. In addition, you can add more functionality to the child class e.g. Fire, either before or after the call to parent. However, if you want to change the functionality of the parent, you can override the function itself to write new code in that child exclusively. You should also set the parent class as an Abstract class under Class Settings so that class itself cant be spawned into the world.
Also, you only need an Actor if you intend to add it to the world, if you know it will never been placed in the world, use an Object instead as this is much more efficient.
I did not know about that option for 'Abstract class' under Class Settings! I will check that out. Are there specific performance advantages to doing that? Appreciate the guidance!
@@NumenBrothers Its under the Class Options, Advanced, Generate Abstract Class, it has 2 benefits (probably more), stops the parent class ever being spawned by accident, also if you set a variable in any other class to the type parent abstract class, whenever any values are set, the abstract class itself will not appear in the list, just its children. I think, like you said in the video, its like declaring it as an archetype only, a concept with some functionality.
Loving this series, hope you keep up with it because a lot of people seem to abandon their RPG series and you seem to teach us some cool stuff i haven't seen much about on youtube, it's mainly melee and shooting. One thing i was thinking though, is that on event begin play on our child blueprint we can just use the call to parent action. Wondering if there was a specific reason you didn't do that?
the specific reason was... inexperience :) We fix it in a few episodes
@@NumenBrothers Ah i see, fair enough xD Great job, keep it up, am working my way through the ability system right now and really enjoying it!
im not quite here yet in my game but will be coming back when im ready to implement gas into my project
Is there a way to assign these abilities to a specific level to which they can only be activated in that particular level?
For example, say you have a main menu that says select your ability and in this case, the player could choose between Earth, Fire, Water, and Air as their assigned ability.
And let’s say that you select the fire ability and you only want the fire ability to be activated with a specific key, without activating the other abilities.
How could that be achieved?
There are many ways to do what you describe. Most likely the easiest way is to have some sort of variable or tag on each gameplay ability that is 'enabled' depending on the level.
@@NumenBrothersOk. Do you know of any blueprint nodes I could use that could help me get started on that?
gas does replication for you and does it well.
Great explanations. I've learned something I didn't find anywhere else. Much appreciated for your effort making the tutorial. Might be better reducing many direct references and casting by using Interfaces.? Also, on the child blueprints can just overwrite the parent functions instead of doing a switch on enum and then cast? Another thing regarding using the enumerator is , can we just use the gameplay tags? Maybe I'm wrong since I'm still learning. However, you explanations of making a functional system is the best and for beginners,that's important and helpful. Thank you again. Please make more tutorials
Yes- your instincts are accurate and you're asking the right questions. I made this tutorial when I was much less experienced than I am now.
@@NumenBrothers Many thanks for the confirmation. If I was a complete beginner, I'd prefer the approach used in the video though since it's much more intuitive. When the beginners have gained more experience, they sure will learn the new ways. So please don't let my comments distract you, keep things simple and functional. That's more important :-). thanks again for sharing your knowledge with the world
only one part has stumped me 20 mins in, i have an issue i dont know how to solve, so before this video i have setup my first person charecter with independent left or right attacks using enums to tell me which spell is in either the left or right hand and all that works fine, but for your system how could i define which hand
So instead of '1' or '2' on the keyboard, it would be your left and right hand, tied to whichever button you like.
Do you know if this can be applied to 2d to a similar degree?
Absolutely
Would this work for something like VR?
is this gonna help me enable game play ability without having to use visual studio which deosnt build and gives native errors which i dont wanna edit the source code to fix?
I have not had to use visual studio for anything I've yet worked on. However, I would say 'Yes' to this question only if you are planning a single player experience. I cannot speak to multiplayer.
@@NumenBrothers never mind got it to work, apartenlty just building gives issue, probably because of configuration set up failed, but in extensions, unrealVS, Start build, that worked real well, i can continue 😅
Personally, I think there's a level of abstraction that is crucially missing here. 26:54 how this is setup is not scalable let alone easy to append. Why not instead use Interfaces? Have ActivateAbility and DeactivateAbility be Interfaces that the child classes can implement to execute how they are executed? Casting the ability type from the parent class is nooooot a good way of going about it. The parent should never have to know about the child class of itself like that. Having a massive list of ability types in an enum can get messy. I understand it's a mock up of GAS without GAS per say, but deeeffinitely emphasize better abstraction with the parent GameplayAbility actor.
You are most likely correct. Appreciate the feedback!
This is the stuff I come for!
you are awesome!!! where have you been for the past two years ??!!!!
preparing
@@NumenBrothers LOL
Great now I am starting to get gas!
hopefully it continues to grow inside you with time
Part of me is concerned about performance issues, since you seem to be spawning a new actor everytime you want to call an ability. Why do that instead of having multiple functions in the one character blueprint?
yes you're right about this- we switch this up in the gameplay ability pickup episodes. Only spawned when they are picked up. Having separate actors for each ability solves a few problems- one is that, there's no point in loading in functions for a character for abilities the character doesn't have.
Watching this, at the very beginning I’m not sure if you’re going to have your action bar / spellbook full of actors, but if you are I might rework the base class to pull in a data asset so we can just hold an ability book full of data and spawn an actor from the data asset on successful cast. I know it’s probably not that big of a deal performance wise but holding a transform for each icon in a UI book just feels pointless 😂
Um, @20:40 why don't you call parent begin play??
What if I do "Ref to Creator" instead by making: "Get Instigator"-"Cast to character"-"Set Creator" for unification of the ability, that can be later used by enemy npc also?
Yes- use 'Get Owner' instead. We actually fix this later on in the series.
@@NumenBrothers Thanks, bro. Awsome tutorials and great work!
I don't know where to start. Any thoughts on remaking it so that beginners can easily copy it?
If you start this series from the beginning with UE 5.0, 5.1, or 5.2, by the time you get to this episode you'll have the requisite knowledge to understand what we're doing. If you already have decent blueprint knowledge, start at episode 23.
@@NumenBrothers Thank you for your answer.
Hey, thanks for another great episode. There are plugins you can use to avoid having to use the c++ setup and still use GAS. The ohne is gas campanion, the other is free and more a light weight Version of Gas campanion, but still very good. Sorry, i have just forgotten the Name of it. best regards, Michael
Appreciate it. I think, even with an ideal plugin, I still want to do it from the ground up. We actually talked about this on the Discord yesterday. The main reason is about understanding. And it's a personal challenge for me- I have a difficult time understanding something by simply looking at it or viewing it. In order to understand something typically I need to struggle with it, I need to play with it, and so as I'm building a GAS, I'm going to make tons of rookie mistakes, I'm sure, but I'm also sure I will learn a lot along the way, and I'm also hopeful that this channel (And the Discord community) will point out my flaws so I can benefit from the wisdom of the community. I very much appreciate the comments and suggestions.
Using this method, are you able to use gameplay tags ?
I don't use them but there's no reason why you could not.
@@NumenBrothers Thank you for the prompt reply. Out of curiosity, What’s really the difference between this method and the c++ Lyra method one?
It's really the difference between using a pre-packaged ability framework, vs. building one from scratch. If you have relatively conventional abilities, use Lyra@@ray3dx661
@@NumenBrothers oh I see.. Thanks for the info. I was debating in my head weather or not to use the C++ method. I might do what you're doing here. Really appreciate the quick replies.
Nice work but it can use some very much needed cleaning up. Wouldn't the other elements benefit from being channeled or instant or summons as well? That fire type should probably just be an ability casting type and put into the parent class of fire, the gameplay ability you made. Also, you can call the parent function of an event by right clicking on the event and select call to parent function. That will use the functions on the parent, so you do not need to replicate the same functionality on the children that you did on the parent.
Also it's generally a not so good idea to hard reference different class types, as it just doubles your memory load. You will want to use Interfaces for getting your third person character and such when it is a different class.
I can tell by your comment you're much more experienced at this than me. I appreciate the feedback. This piece: "You can call the parent function of an event by right clicking on the event and select call to parent function. That will use the functions on the parent, so you do not need to replicate the same functionality on the children that you did on the parent." I know what you're referring to, and should have done it that way, you're right. I'm anticipating having to have 'fix/cleanup' episodes specifically for this kind of stuff in the future. And the last comment regarding interfaces- I actually didn't know that about casting- I appreciate it. Same with that- most likely will need to correct it in the future.
@@NumenBrothers No, not more experienced, just spouting some knowledge I've gleaned from browsing around the various tutorials out there. You are doing great with this series but I needed to say something to prevent you from doing something that could become difficult to fix later. On that note, there's another thing I feel I must mention at this time.
Please try to make sure you make sure your abilities may be usable by both AI and players (if that's part of your focus). I don't know the end game for all of this yet, as it hasn't happened yet, but with what you have built up so far, it looks like you are heading in that direction. Your tutorials have helped me immensely in not only learning a different way to do things, but the reason WHY you do them is SOOO important to hear.
Also you helped me track down and fix an issue I have had for a very long time with the Engine. The "DerivedDataCache" folder location, due to all of those Bridge assets being so big, I finally had that folder moved to a much more efficient location.
I think I'm understanding what you're suggesting. And please, let me know if this is right. My ThirdPersonCharacter blueprint would call a blueprint interface function like 'ActivateAbility', and the blueprint interface function would simply check what blueprints can activate the right interface (based on the switch on the Enum that is passed into the blueprint interface function), and then that way, the initial 'GameplayAbility' blueprint switchboard I set up is completely unnecessary. Is that accurate? Please feel free to email me directly if that would be easier way to convey. Very much want to get this right. Just based on thinking about this over the past hour, I'm leaning toward making a follow-up episode in a few episodes where we fix precisely this, and if I can give you credit, let me know if that would alright :)
@@NumenBrothers I don't need any credit for anything, but thank you for considering the option to do so.
I believe the switchboard enum you have will work well, it is something that you probably want to keep. As for interfaces, they call out a message to anything you send it to. The receiver just needs to have it listen for the message being sent. If it implements the interface, it will do whatever code you have for it. If it doesn't listen for the message, nothing happens. These guys explain it much better than I can put into words here. I've retyped this thing 5 times... ===> th-cam.com/video/96vJiKrAa9k/w-d-xo.html th-cam.com/video/qLpjGxyfZLg/w-d-xo.html
5th element is sky as per hindu mythology
27:20 - You're kind of missing the point of inheritance. Currently, if you had 1000 abilities, you'd have a switch board in your base class with that many options. You shouldn't have a single switch in your base class. Adding a new ability means you have to add a new switch pin. You should just be overloading the inherited parent functions or using a blueprint interface. When you create a new ability, you should never have to adjust the base class again. That's why it's the base class. You're effectively just making unique blueprints with almost none of the benefits of inheritance except variables.
I see that you do not follow Unreal Engine´s way of using GAS. That is, starting with a new user class derived from UGameplayAbility, not from AActor as you do, then using tasks derived from UAbilityTask, in C++, and most importantly the mandatory component in your GAS character, the Ability System Component, attributes, effects, etc. Your approach is interesting. Thanks for sharing
does this all replicate?
nope- making a single player game
This makes me wonder if the unreal GAS system is kind of unnecessary? It seems to package up all the same types of data with the same intent but adding just another 'blackbox' of custom unreal terminology and the usual unreal baggage.
I suspect UE's GAS system is more performant than what I'm doing with blueprints. So that's one factor. The second is when working with a large team- you want a system that is clear for all team members to be able to follow. In that case, I would recommend their GAS, simply because they have a proven preexisting framework.
The GAS system is very comprehensive, flexible and powerful system to cover all your needs. However, the biggest turn off for most people is that you need a bit of C++ to get is setup in your project. If you wanted to learn how to use it the ActionRPG has it included along with the C++ files you can pull apart to get it set up. I'm surprised Epic haven't made a full blueprint version of it yet. However, for most it is has a steeper learning curve and doing something in blueprint can cover most use cases. In my own system I took some ideas from the Epic one and implemented them into my own. GameplayTags are heavily included in that system, very powerful and mostly under appreciated.
@@stevenprice378 GameplayTags are a very efficient way to manipulate the data needed.
In my opinion there are 2 mistakes here in the architecture of this system. First one is a big circular dependency where you cast your ThirdPersonCharacter in the GA Actor but actually you spawn the GA Actor in the Character class, I must say this is a no-go unfortunately. Also you can cast a base class to get abstract functions and variables but shouldn't cast children, otherwise you'll reference everything along the way. Best to use interfaces and delegates for example! It's an okay tutorial for beginners exploring UE but you shouldn't use it in your game imho.
it's a good criticism. We get closer to what you're describing later on in the series.
9:58 I'm sure you get to this, but I'm wondering why you're not using ActorComponents as your GamePlayAbilityBPs rather than actors with child classes. I'll edit or remove this comment if necessary as the video goes on.
Hey Kavan, this is a good summary: www.reddit.com/r/unrealengine/comments/3ir4el/c_when_to_use_actor_when_to_use_component/
I like where you wanna go with this, but you should really go back and review some of the basics. Your naming conventions and structure is very poor and people shouldn't be learning it this way. It is not scalable.
You are somewhat correct.