I prefer states/enums over gameplay tags to be honest. I think they are even easier to organize than gameplay tags. I see some people trying to push gameplay tags and I think it’s just overcomplicating
Thanks for the vid :). I've been trying to figure out how to set up a class based state machine with blueprints but I'll settle for enums and switches for now!
I've been mulling over the best option for class based state machines in Unreal too, and from what I can see it would either be using the new StateTree system, or a solution in C++. I'll probably do a video on StateTree soon since it seems like there's not much out there on it, and it's something that I think could help my own workflow.
@@acdev7027 I ended up making a kind-of 'class based' state machine with just blueprints and its going well so I thought I'd share in case anyone finds it helpful. Though it's not truly class based and still uses switch statements and an enum for the current state, it emulates the structure more and gets the job done. My blueprints work is much more organised as a result (I'm working on a character controller). I create an event graph for each state, each graph has an enter and exit state custom event. I 'construct' each state on BeginPlay by binding event dispatchers to the custom events. Could skip this and call the custom events directly, but I thought it might be handy to be able to listen to state changes from outside the blueprint. The change state function is basically the same as yours. I'm using timelines as update methods that can be started/stopped when you go into different states, for things that need that functionality. So that the default event tick doesn't get clogged up. I ended up handling inputs in its own event graph, instead of within the individual states. Using switch statements to decide what should happen for different inputs. For functions, macros and variables I'm just being very organised about folder structure, organising each one by state. It can get very big, since all the 'classes' are just different event graphs within the same blueprint but as long as I'm organised it's manageable. So kinda same-same but different to what's in the tut, I just prefer having the code separated more from each other in their different event graphs!
I prefer states/enums over gameplay tags to be honest.
I think they are even easier to organize than gameplay tags. I see some people trying to push gameplay tags and I think it’s just overcomplicating
Thanks for the vid :). I've been trying to figure out how to set up a class based state machine with blueprints but I'll settle for enums and switches for now!
I've been mulling over the best option for class based state machines in Unreal too, and from what I can see it would either be using the new StateTree system, or a solution in C++. I'll probably do a video on StateTree soon since it seems like there's not much out there on it, and it's something that I think could help my own workflow.
@@acdev7027 I ended up making a kind-of 'class based' state machine with just blueprints and its going well so I thought I'd share in case anyone finds it helpful.
Though it's not truly class based and still uses switch statements and an enum for the current state, it emulates the structure more and gets the job done. My blueprints work is much more organised as a result (I'm working on a character controller).
I create an event graph for each state, each graph has an enter and exit state custom event. I 'construct' each state on BeginPlay by binding event dispatchers to the custom events. Could skip this and call the custom events directly, but I thought it might be handy to be able to listen to state changes from outside the blueprint. The change state function is basically the same as yours.
I'm using timelines as update methods that can be started/stopped when you go into different states, for things that need that functionality. So that the default event tick doesn't get clogged up.
I ended up handling inputs in its own event graph, instead of within the individual states. Using switch statements to decide what should happen for different inputs.
For functions, macros and variables I'm just being very organised about folder structure, organising each one by state. It can get very big, since all the 'classes' are just different event graphs within the same blueprint but as long as I'm organised it's manageable.
So kinda same-same but different to what's in the tut, I just prefer having the code separated more from each other in their different event graphs!