How to section off the code of a First-Person controller, in order to apply a state machine on it?

Tudor

Hello! I want to build a state machine for my First-Person game. But, I heard that before applying the state machine, I have to section off my code into small chunks.

In the following tutorial, the author is applying a state machine on a Platformer game:

He organizes his code in the following chunks: - apply_gravity - apply_movement - apply_jumping + handle_jump_input - handle_move_input

What would these chunks be, in the case of a First-Person controller?

TwistedTwigleg

I would say it depends, I do not think there is a right or wrong way to make code chunks. Ultimately, constructs like state machines are designed to make the code flow easier, so whatever you feel would accomplish this task is what I would ultimately suggest.

That said, if I was going to break a FPS controller down into a state machine, I would use something like the following:

hande_movement_input (keyboard and potentially gamepad)
handle_mouse_input (mouse and potentially gamepad)
handle_jump_input (I generally place this with my movement stuff instead of a separate state)
apply_gravity
apply jumping
apply_movement
apply_other (interactions, flashlight, etc)

Tudor

Interesting approach :)

I don't really understand, why to separate the functionalities from input and from gravity?

TwistedTwigleg

@Tudor said: Interesting approach :)

I don't really understand, why to separate the functionalities from input and from gravity?

Personally, I generally put gravity, jumping, and movement handling all into one state when I am programming, but the chunks in the Video were different so I figured I would follow a similar style. That said, if I use a state machine, I generally design it as I go rather than plan ahead.

I actually would not recommend placing input and gravity into the same function, because gravity should (for the most part) be standalone from whatever the player can do (unless the player can control gravity :tongue: ). On a whole, I would recommend placing similar things in the same state and leave different things into different states.

If I was structuring the state machine based on what I generally end up with, which is not necessary the design I would recommend, then it would look something more like this:

handle_movement_input
- Walking, jumping, etc. I may alter velocity here, but I do not call anything like move_and_slide or apply RigidBody forces.
handle_mouse_input
- If there is time, otherwise its part of handle_movement_input. Especially for game jams, I just do whatever is easiest.
- Generally I separate this out because I use _input for mouse movement and _physics_process for keyboard/gamepad input.
apply_movement
- Apply gravity here, generally stronger gravity the longer the player is in the air for a more weighty feel.
- Move the player using something like move_and_slide or RigidBody forces
Other stuff here
- Handling collision events (info passed from apply_movement), conditions for checking health, etc.

Though keep in mind, as I mentioned, I generally actually do not really go into a project with a design in mind. Most of the time I just program stuff like this as I go and have to make revisions and adjustments as the project develops :lol:

From a development cost perspective, keeping things simple and broken down into smaller, focused tasks is easier to debug and maintain, which is a big plus for breaking things down into states to begin with. The amount of stuff in each state is something I would say varies depending on the complexity of the project, the experience of the programmer(s) writing the state, and what direction is predicted to be necessary for adding future functionality.

Tudor

Thank you for your great and detailed explanation! :)

I decided to put my 3d project on freeze and to develop some 2d games.

This project begins to be too complicated for me. That's why, I want to gain experience with advanced concepts, like state machines, in simpler contexts, like 2d games.

From now, I will post in 2D section =)