Ultimate State machine character controller architecture

I’m getting stuck and it is so difficult for me to create a character with a lot of states (advanced state machine).

I want these states for example Idle Walk Run Crouch Jump Fall Swim Fly (with glider) Drive

Attack (3 different states) Reload Interact

As I can see I have here two machines that communicate between them; one for movement, and one for interaction (attack and more) Examples for things that make it difficult:
*Player can attack in each state except fly and drive… and while attacking player cannot run…
*When a player jumps he can move on the jumping…
*In the swimming state player cannot crouch.

I want of course to make the code reusable as much as possible!

So guys what do you think? How would you solve it?

Why!!! You haven’t even got it working yet!!!

This is my position on finite state machines (FSMs):

https://discussions.unity.com/t/834040/6

I’m kind of more of a “get it working first” guy.

Your mileage may vary.

So what do you say? Do I need to script it in a messy way and then refactor it?

It’s really bizarre to me how often online discourse these days is people jamming words into your mouth.

Can you please show me, either in the post above or in the link contained within that post, where I said that you should “script it in a messy way?”

I don’t think I’ve ever said that in my life.

In the link above I suggested that you hard-wire the first version and tweak the behavior to get it exactly how you want. That’s not “script it in a messy way.” That means “solve the ACTUAL problem first.”

But hey, if you can solve it AND write totally reusable code, hey, more power to you! I’ve never seen that done yet. Usually what happens when this is tried is that people report “I’m getting stuck.”

1 Like

@electr1on
FSM works ok for well defined and simple process (consisting of a few states and few transitions). However it scales badly when you want to add more states or want to modify the existing ones; fsm is resistant to changes.

For implementing complex logics, Behaviour Tree (BT) is more appropriate. It is also a nice tool for fast prototyping: you can design, modify or try out different behaviours until you settle down with a satisfying one, without too much of technical hassle. However, BT has a slower learning curve compared to FSM. But once you’ve learned the fundamentals, the benefit is considerable in terms of programming effort and maintenance.

Can you explain more on how will it behave with BT?

@electr1on
It seems you character behaves differently given in the situation (On ground, In air, in water, in vehicule) : Behaviour Trees are inherently hierarchical. This come as handy for organizing your behaviors when they become more and more complex. It would be difficult or lengthy to both explain BT and help you implementing your character here.

If you want to know more about Behaviour Tree, here is a 5 minutes introduction:

There are several Behaviour Tree packages on the Asset Store. I am the author of Panda BT, if you have questions about implementing your character using Panda BT or general questions about Behaviour Tree, you are welcome to ask them on this thread .

Aiming for code reusability right from the start requires knowing what situations require the code, and this knowing only comes from experience. Even then it isn’t specific code that can be reused, but instead libraries accessible only via its API, which are essentially plugins and tools. This is one reason to “start messy” as you describe, to accrue said experience.