To State or not to State (FSM related question)

General
, , ,
1

Hey all! I am starting work on a movement shooter, and I have begun trying to implement a Finite State Machine (FSM) for the Player CharacterBody3D Class. It is my first time making an FSM, and I have a few concerns that I am afraid I will run into in the future.

1.) If my player is switching weapons, jumping, and running all at the same time (or they attempt to do all three at the same time), does this mean I will have to have a lot of duplicate code within each state? For example, do the running, jumping, and walking states all need a isSwitchingWeapons flag and weapon switching logic?
2.) I feel like for programming it is easier for me visually to have all the code in one place (I am working in C#). Is it straightforward to transition code into a FSM paradigm later on?

A part of me wants to use FSMs for the NPC’s only, and not utilize it for the player since they will have much more advance/complex movement. Is this a good/fair idea?

2

Hi, I am also working in C#, there is a great person Firebelley who wrote a finite state machine for Godot C#, here is the link on Github. I’ve used it quite a bit and know how it works, although there’s nothing particularly complex there. I suggest you use it, if you have any questions, ask.

1 Like
3

Interesting question, as I went through exactly the same thing when I started my first game. For my first godot game I’ve ended up using FSMs for the NPCs, and imperative code for my Player class, and it’s worked well for me.

My rationale for the NPCs was as follows. I initially started using imperative code, but when I got to my 1st boss, their behaviour was more complicated, and it became easier to rationalize things by using an FSM. When I then realised some of my other enemies needed similar code to the boss, I switched them out to use FSMs, and now they all use them.

For my player, I also started with imperative code, and once all the NPCs were using FSMs, I had a little play with moving it to an FSM. However, in my case the key benefit I could see to retrospectively using an FSM for the player, was to make it consistent with the NPCs.

While my NPCs needed FSMs-or something equivalent-to drive their behaviour, as the player’s behaviour is driven by controller inputs, my feeling was the FSM would be more complex, and would likely need a hierarchical FSM to capture all its nuances. Although i could see that might help me think about and debug the player behaviour, the FSM code I was using wasn’t hierarchical, so it wouldn’t give me the consistency I’d been after.

1 Like