I think the information is good but please speak faster. I sat the speed to 1.5 :-)

State machines are great, but they don't reduce spaghetti code. In all your examples you could invert the ifs and return early to reduce nesting. Also keep in mind that virtual methods can add a performance overhead. Stick to KISS and composition over inheritance. Still a good tutorial for learning the concept.

It:s not a bad approach but it can devolve into an inheritance hell with 30 classes for something.

You generally don't want a seperate class with just 1 method to override because you can just use delegate. And rather than returning a new instance of the state, the states should return a state flag that the caller should use to look up what to do next. Enum with a dictionary to look up would work well.

Put it at x1.25 speed and still slow...

I believe the CharacterState would be better as an Interface,as there's no real reason for a base class implementation of handleInput.

Awesome video! I recently got into Unity due to an assignment in my University which will be graded and am really loving it so far. Even though I already knew most of the stuff in the video I have to say it was a pleasure to listen and watch and I think you definitely helped a lot of people who are just getting started with programming languages and coding in general :)

Well, idk. I think using oop for this problem is a bit of an overkill. You just could have handled all the conditions inside the attack() function, using boolean operators and the return keyword to avoid nesting. The user presses the attack button, then the function is triggered and it checks the conditions for doing the attack. In this way you have all the conditions in one place for that specific context, making the update function much cleaner. I think also that the code will be easily understandable for other people, and for you too when you'll read it after a while

I still don't consider my self a game dev until i could make at least one game and not just little project that i do to learn different stuff.

Men Please I want a bunch of Tutorials on State machine pattern programming, You're now officially my fav UKpostsr. keep doing this stuff a lot I love it! :)

IDK, I think this boils down to whether you want your code to "look pretty", or you want a more performant/optimized game.

Imo you could also save the headache by implementing functions and guard clauses. So for instance that nested nightmare would look more like this:

State machines rule, however I would suggest you look into a more efficient solution that has less boilerplate code. If you have to create a brand new class for every state it gets incredibly tedious as your game grows. Consider making a StateMachine class that inherits from monobehavior that has a dictionary of <string, Action> which represents state then simply run the method for each state. it also makes declaring each state very simple and concise

Much like others have said, using enums and a dictionary with delegate functions is a much better solution to this. Or simply having functions that take care of each behaviour.

This was extremely understandable and helpful. State management seems to be one of the trickier initial hurdles in Unity, so I think your subject matter was on target as well.

I would recommend keeping your state as an enum instead of different classes then have a switch that shoots off to their own methods. Doing so will leave access to common data accessed by multiple states. This will also allow access for multiple states at once by using a flag enum if it's necessary (but i would recommend avoiding it)

12:28

I've seen Table Flip Games's tutorial and the great Unity finite state machine tutorial.

Spent the past week having a headache and a half trying to fully implement a state machine. And damn you just alleviated my headache.

I'm about 20% done with my game mechanics, and have around 20 classes already... It seems like the more I unwind my code, the more complex it gets, but the more complex it is, the easier it is to work with.