What do you use most? FSM/HFSM/BehaviourTree/ScriptableObjects and which one for Character Controller

Unity Engine
, ,
1

1.Question
Which of the following options do you use “most” and why?
FSM/HFSM/BehaviourTree/ScriptableObjectStateMachine/AnimatorStateMachine

2.Question
Do you agree with what I have written below or is there any misinformation?
-Using fsm is the easiest and fastest solution. However, as the state increases, it becomes impossible to control.

-Since we can reuse the same states in hfsm, management becomes easier, but inheritance creates extra complexity.

-ScriptableObjects is nice for easily swapping states but creating scriptableobjects for every state and managing those scriptable objects becomes mass

-Behaviour tree in other hand has no downsides compared to hfsm etc right?

3.Question
For example, what state management system would you use for a somewhat complex character controller that has features such as swimming, climbing, and flying? (Like in Gta5 lets say)

2

The complexity should just match your requirements. Simple character controller? A simple FSM, or even no FSM should be fine. More nuance? Maybe a hierarchical FSM. Super detailed, AAA character controller? Probably need a behavioral tree. I know this was the approach in the Dead Space games to control every last detail of Isaac Clarke.

If you’re not sure what one to use, look at games that are doing something similar to your current idea, and see if you can find out how they were made.

3 Likes
3

Actually, this is one of the points I don’t understand.
Yes, if the problem is simple, solving it with if/else or enum will be much faster and more readable.

However, I don’t see much difference in usage or implementation between behavior tree or fsm. If you use fsm instead of behavior tree, your code doesn’t become more readable or easy.

Of course, if there are 3, 4 states in total, maybe statemachine can be faster, but as far as I can see, there is not much difference in difficulty between using behavior tree and managing a statemachine with more than 3, 4 states.

If what I said is true and the difficulties are similar, why would I use a statemachine?

After all, everything you can do with a statemachine can also be done with a behavior tree.

4

I mean write an FSM from scratch, and a behaviour tree system from scratch, and tell me which one takes you longer.

1 Like
5

Oh yes, of course, if we write from scratch, fsm.

I wrote assuming that i already have generic statemachine/behaviourtree that i can use. Since commonly they are used in that way. Because you usually use the system you have previously written or downloaded instead of writing from scratch every time.

By the way, I do not defend the accuracy of the messages I wrote, I just reached these conclusions as a result of my research and I want to confirm whether they are true.

1 Like
6

Why are you asking questions like it’s a school exam? Do you have an exam? What actual problem are you looking at.

Like, you’re asking about character controllers, character controllers should never have any of these involved. The animation for the character controller might want to have a state machine, though most games at the scales made in Unity would probably do better with just some light scripting on top of a list of animations. I have no idea what a BT is doing anywhere in the vicinity of a character controller.

What you do want in a character controller with states that have no overlap (like GTA swimming, walking, driving), is to have those types of movement seperated out, instead of trying to bunch them together. So a movement script, a swimming script, and a driving script. And I mean that turns it into a FSM if you squint, but if there’s a class in there called MovementStateMachine and then a bunch of things inheriting MovementStateMachineNodes then you need to think less about OO and write more code.

3 Likes
7

I mean, no? A FSM you can write in a few minutes. A behaviour tree, definitely not.

Consider the technical debt that might build from either.

And potentially look outside the perspective of a coder, and think about what designers might have to care about. Because you better believe it’s a lot different than what a solo programmer cares about.

1 Like
8

“I mean, no? A FSM you can write in a few minutes. A behaviour tree, definitely not.”

You’re right, sorry, I meant to say that behaviour tree takes longer, I wrote it wrong.

“Why are you asking questions like it’s a school exam? Do you have an exam? What actual problem are you looking at.”

it’s a good question, actually, my goal was to write a character controller, and while I was thinking about how to do it, I saw that state management was a must, so I wanted to know which way would be more correct.

“character controllers should never have any of these involved. The animation for the character controller might want to have a state machine”

Yes, it actually makes sense to create separate components for movement/swim etc. and enable/disable them. However, as you said, a state control is needed.

Most of the time it is enough to enable and disable some components and change some variables with triggering correct animations.

For example
Enable/disable Ik
Change Speed
Change CanJump boolean
Change allowing horizantal movement

When I think about it, hfsm is the most suitable for this because, for example, the main 6 7 components will change according to the state and these 6 7 components will have separate states within themselves.

For example,
GroundMovementState(or component) can have
Idle/Crouching/Crawling/Walking/Running/ states

AirMovementState(or component) can have
falling/walking(moving)/running(fast moving)/paragliding/flying states

So thats why i opened this topic. Why not use behaviour tree to control these instead of statemachine
(By the way, I haven’t used the behaviour tree in a real project other than playing around with it for learning purposes, so please correct me if I missed anything.)

“Unity would probably do better with just some light scripting on top of a list of animations”
Sorry, I didn’t quite understand what you meant here. Are you talking about assigning a script to an animation and changing the necessary parameters when it becomes active?

If so, yes, that could be a good way to go also.

9

Honestly, like I said, you should build to the requirements of your project. Because I guarantee a lot of your preconceptions will go out the door when you start to apply things in real practice.

And if you’re designing a system that’s meant to be reusable across projects, throw it into a real project as soon as it’s even remotely working. Because the longer you work on it in isolation, the higher the chance of it not being useful at all in practice it has.

1 Like
10

For most indie unity games im sure just the standard animation controller will be enough. We use that in combination with IK for our character.

Also the FPS controller and the character controller are completely separated. You can run the game without the character controller but off course without the feedback loop like footsteps etc since these are driven by the animation.

We do the same for our AI the difference is actually only where the input comes from AI or player.

1 Like
11

Thank you very much everyone, i will go with animation controller