State Machine with Gameplay Tags - C++ and Blueprints - Unreal Engine Workshop
ฝัง
- เผยแพร่เมื่อ 15 ก.ค. 2024
- Here are the project files if you are interested in just getting the final product:
github.com/Monster25/TagState...
0:00 Introduction
0:40 Enumerators vs Gameplay Tags
4:48 State Machine Implementation
27:35 Testing and Showcase - เกม
very helpful to see some unreal tutorials showing traditional programming techniques/patterns. Thank you.
Thanks! It was increasingly frustrating for me not finding stuff like this. I always ended up finding tutorials for animations and stuff that I didn't really need.
I've been using my own "pattern" for implementing state machines for a while now with the intention of transitioning to an Actor Component but my biggest hurdle has been getting away from enums to represent state. This is brilliant, thank you so much for sharing.
Its really interesting to see a StateMachine design style I use quite frequently, used in Unreal and how different it is.
dipped my toes into C++ for the first time with this. got it running and packaged with UE5.2, everything working fine so far. thanks a lot :)
this is great u should upload more of these tutorials ^^
Thank you 🙏
New to C++ for Unreal (and in general), this was incredibly easy to follow.
Random question: is the color formatting you use in Rider a custom scheme or from a certain plugin/setting? Your settings made it visually much easier to differentiate between variables, functions etc.
Glad you enjoyed it! I can't use Rider right now since I'm having some issues with my installation of it and I can't check but from what I remember its a setting you can choose in it. From what I understand, since 30th of June, there is no more Rider for Unreal Engine, all the functionality has been merged to the main IDE so I'm sure you can find it there.
So it seems like this version of implementation means you end up with a lot of 'Event fires -> switch onGameplayTag' in the StateMachine component blueprint space, whereas the uObject version in your other video is a lot neater in that respect because instead each event would have an 'if [event fires]' code in individual state scripts instead? In other words, the uObject version is a bit neater in terms of encapsulation?
Correct but its all relative, you should use whatever solution is best for your case. The solution I usually end up using is doing a very lite version of GAS where I implement an ability system with gameplay tags and use the gameplay tags to keep the state while doing everything else in the abilities (UObjects). If you're working on a small game, gameplay tag switches are perfectly fine, if you're working on something larger, UObjects might be the better approach.
Hey! great video! what would you recommend using if I want a state machine for my movement abilities, like walking, sliding, wall running, jumping... and I want to write those abilities in C++
So for a movement state machine completely in c++, do you recomend this system or the system using the Uobjects?
Thanks a lot for this vedio,
can u tell me is it possible to use DataTable in cpp?
(as gameplay tags)
I've seen both of your state machine tutorials (1 is using UObject and this one using GameplayTag). Just wondering to your experience, which one you feel better ??? I think the GameplayTag one is more flexible, am I right ???
GameplayTag one is definitely a lot more flexible however it will require a lot less encapsulation when using it, meaning you ll likely use a lot of switches and branches inside an object. The Uobject one will offer more encapsulation since each state will have its own separate UObject so it will be cleaner but you will have more uobjects and it will be a bit harder to work in blueprints since you ll have a lot more windows opened.
@@AltrayDigital Thanks for your quick reply :v Love your videos man. Keep up the good work
@@AltrayDigital great stuff, thanks for confirming that this approach would require a bit of switching and branching, was wondering if I was missing some super elegant aspect but I guess that's just part of the state machine game then :D
Very useful, thank you for the video. One question: how do you switch on GameplayTag in C++? Or how do you check states, etc.?
You can use FGameplayTag and FGameplayTagContainer's functions in C++ however you want, it is however a lot easier and safer to use them from blueprints. In order to access the state tags in C++ of an actor you'll have to add the State Machine Component to the actor in C++.
Thanks. I have already implemented it in C++ , I was just looking for the best/most efficient way to check against a gameplay tag in C++.
@@LucianoIurino Hey! Would you mind sharing a little hint on how you would use that in C++? For example the Switch on gameplay tag equivalent, or whatever direction you ended up using?
@@WackyWhiskerDev Hey hey! I ended up using a totally different solution, but IIRC, there was a way to do everything you need with tags!
Sorry, very noob here. But how did you opened the IDE with all this content from the Project already?
If I just open Visual Studio, its not linked with any of my Unreal project, so... is that a way to do it from unreal to have access to all this content already?
Wow, it is so powerful compared to traditional enum, I use enum mostly and get complicated very quickly.
Would it be a good idea to be able to add multiple sets of "state tag" variables to handle different things within the same component? For example: I could have a state tag set for movement gaits, 1 for rotation modes, 1 for base poses, etc. Would I essentially copy that code a bunch of times and change the names of the variables and functions to add additional ones? Thanks.
Well, hopefully I didn't misunderstand you, but the sole purpose of the State Machine Component right now is to hold a state, handle the changing of that state and keeping track of previous states. There is nothing stopping you from adding more than 1 state machine to your actors, 1 for your movement, 1 for your rotations, 1 for poses etc. Instead of copy and pasting all the functionality multiple times in order to keep everything in one single component, you can re-use it multiple times and keep things nice and clean. So in the future if you have another actor that needs to hold entirely different states, you can always re-use the base state machine component instead of using a big state machine component that handles lots of different things and is tailored towards a very specific actor you had in mind.
You can even create children of the component if you neeed to do highly specialized things such as a state component just for handling animations, provided you have some custom code that will always run when handling animations with a state machine etc. but as a rule of thumb, keep things separate and clean, better to split things into multiple components than to have large bloated ones that will be hard to keep track of.
@@AltrayDigital I was thinking of a locomotion component with multiple state machines so that I can add the whole lot at once. I'm thinking that I should use state machines with limited states so that things are in smaller chunks and compartmentalized. I'm used to building locomotion systems with enums, this should help a lot to streamline things
@@AltrayDigital I think making a single state machines at a time solution may be amazing for additional movement modes like you suggested with climbing, and still use a larger one for the main parts of my locomotion.
@@furrybproductions Sure if you think that is a better solution for your case then go ahead. But you can always just create a more specialized state machine component for your situation by inheriting from the base one. Just keep encapsulation in mind and split functionality up between multiple components if you have to.
I cant compile for UE5. I prefer not to build by hand. Is there a compiled UE5 plugin please?
Just follow the video, it takes an hour max.