Modularity. Splitting the player into its “moves” and move them out as separate scenes

[jeffreywalther]

Hi!

My game is growing and growing. I’m reaching a point where I’d like more modularity.

Question:
Does it make sense to split the Player into its “moves” and move them out as separate scenes?

The main player script would then simply determine the status and trigger the corresponding component (i.e., the sub-scene).

Example:
PLAYER (main node and script with state machine)
|— Walking (with motion calculation + own animation sprite)
|— Running (with motion calculation + own animation sprite)
|— Jumping (with motion calculation + own animation sprite)
|— Shooting (with motion calculation + own animation sprite)
|— Swimming (with motion calculation + own animation sprite)

Does anyone have any thoughts on this approach?

Jeff

[wchc]

Hi @jeffreywalther,

You just invented the idea of a State Machine (SM), or Finite State Machine (FSM). It’s a well known and popular concept.

See here an example of a State Machine designed by @dragonforge-dev:

GitHub - dragonforge-dev/dragonforge-state-machine: A base state machine class to be used in games.

[jeffreywalther]

Thank you very much. I do use the state machine in a way. I was just wondering if it’s common practice to move the “states” into their own nodes—along with the logic and the animations/sprites.

In most tutorials, all of that is packed into the player script, and I personally find that it gets out of hand pretty quickly when you’re developing over several months. With modular animations and logic, I can more easily add new moves without the player script exploding.

[OleNic]

Do what suits you best, while being aware of possible pitfalls.
The idea is whatever helps finishing the game is good, the rest is useless

[wchc]

There are multiple ways how you can approach designing your State Machine, there is no “one solution fits all”. Just to name a few most popular ones:

1. You can have states as enums within the same script.
2. You can have states as Resources with the state logic delegated to each Resource script separately.
3. You can have states as Nodes and rip the additional benefits of being able to see them easily in the scene tree.

Here’s an interesting discussion about Resource vs Node based State Machines.

Resource based state machine example

Godot Version v4.5.1.stable.mono.official [state machine example] Introduction Hello! In my current project, I reached the point where I needed to make the state machine. I began doing some researches on how to make one and all the tutorials were awful but in the end I kind of understood how it works. I thought of re-designing the usual way that it’s made in most projects (i think it’s called “node based state machine”) which i thought was very bad the way they did it, or rather t…

Here’s another discussion about a completely different approach that does not use states at all, although this idea is less refined than a traditional State Machine yet.

Modular Character Controller (v4.4-4.6)

Hi everyone, I’d like to share with you my Modular Character Controller. It’s a project I have been working on and is a set of scripts for making characters in your Godot games do the things they should. This applies to player characters, any NPCs, and even vehicles. I just released a major update for it that includes ways for much better control over the actions a character can make. Its available in a few places and can be used as a plugin or a project if you want to see the demo characters. …

I’ll let you draw your own conclusions.

EDIT:
I forgot, there are also State Charts, worth considering:

GitHub - derkork/godot-statecharts: A state charts extension for Godot 4

[jeffreywalther]

Thanks for the info. I’ve had a tough week phasing out my old code bit by bit so I can be more flexible.