Oh I can show you.
Let’s take a look at Skele-Tom, the game I linked in my previous post.
The root node is a Player which inherits from a custom Character3D Scene, which in turn inherits from CharacterBody3D. From that scene it inherits a CollisionShape3D and AnimationTree.
You’ll note the Cameras node, and the Camera3D nodes and CameraMount3D nodes. Both the Cameras and CameraMount3D nodes are from my Camera3D Plugin. Which you can look at and even use as it is open source under the MIT license.
Then we have the Player Action State Machine and Player Movement State Machine nodes, which are just renamed StateMachine nodes (node code changes). The StateMachine and State nodes are from my State Machine Plugin.
After this we have the Skeleton Rogue Skin, which in turn contains the Rig and AnimationPlayer. Below that, the CanvasLayer which contains all the Control nodes for the player’s HUD.
The Player Action and Player Movement state machines are both always running. This was done to solve some animation problems I was having at the time. (This game was created in a week as part of a game jam.) Ordinarily, the kinds of things I’d put in an Action State Machine would be things like attacks that can happen while the player is moving. Allowing things like running and shooting, or jump attacks.
IdleCharacterState
Since writing this code, I’ve come to decide to reorder state names in subsequent projects. So CharacterStateIdle is now IdleCharacterState. The intention is this state can be shared by Player, Enemy, and NPC characters. For a while, this was true, but as the AI for my Enemies has gotten more complex, that has proven to be less possible. At any rate, here’s the code:
class_name CharacterStateIdle extends CharacterState
func _activate_state() -> void:
super()
set_process(true)
# Only process physics if we are the active state.
func _enter_state() -> void:
super()
set_physics_process(true)
character.set_move_state(GameConstants.MoveState.IDLE)
# Only process physics if we are the active state.
func _exit_state() -> void:
super()
set_physics_process(false)
## If the player stops moving, move to the Idle state.
func _process(_delta: float) -> void:
if character.direction == Vector3.ZERO:
switch_state()
## Handles slowing movement and idle animation
func _physics_process(delta: float) -> void:
character.velocity.x = move_toward(character.velocity.x, 0, character.speed * delta)
character.velocity.z = move_toward(character.velocity.z, 0, character.speed * delta)
The _activate_state() function is run when the StateMachine initializes. This happens AFTER the Player’s ready Signal fires. This is because child nodes are constructed and _ready() is run on them before their parents are finished. Since out State onodes need to know things about both the StateMachine and Player, we put everything we would normally put in the _ready() function into _activate_state() instead.
The _activate_state() function first calls the default State version, which handles console logging, as well as turning off process, physics_process, input, and unhandled_input. As you will see, we only want some of those functioning when a State is active. However, for Idle we want process functioning, so that it can monitor the conditions for when this state should be entered.
Next, we have _enter_state() which is run when this State is entered. It turns physics_process on for the State, and sets the character node (which represents our Player node) to the Idle animation.
After that is the _exit_state(). All it does is turn our physics_process off. It does not clear the animation - we leave that to whatever State has just taken over - and this State neither knows, nor cares which one that is.
Then, we have the _process() function. All this function does is monitor the direction variable of the character (Player). If it is zero, we switch to this State. (Note that if we are already in this State, the StateMachine knows that and won’t switch again.)
Finally, we have _physics_process(). Here we have isolated the physics code for slowing down the character from where it would be in the default CharacterBody3D code. This ensures that when we enter the Idle State, if the Player still has velocity (i.e. Skele-Tom is still moving), then he will slow down gradually over a few frames to prevent a sudden jerky stop.
MovePlayerState
So now we come to the movement state.
class_name PlayerStateMove extends PlayerState
func _activate_state() -> void:
super()
set_process(true)
set_physics_process(true)
func _enter_state() -> void:
super()
character.set_move_state(GameConstants.MoveState.RUN)
## If the player has directional input, move to the Move state.
func _process(_delta: float) -> void:
if character.direction:
switch_state()
## Handles movement and animation
func _physics_process(_delta: float) -> void:
character.direction = _get_input_direction()
character.velocity.x = character.direction.x * character.speed
character.velocity.z = character.direction.z * character.speed
func _get_input_direction() -> Vector3:
var input_dir := Input.get_vector(GameConstants.INPUT_MOVE_LEFT, GameConstants.INPUT_MOVE_RIGHT,
GameConstants.INPUT_MOVE_FORWARD, GameConstants.INPUT_MOVE_BACKWARD)
var input_vector := Vector3(input_dir.x, 0, input_dir.y) #.normalized()
return character.cameras.get_facing(input_vector, character.transform.basis)
_activate_state() and _enter_state() are self-explanatory. Note that _process() serves the same function, but in this case monitors direction for movement.
_physics_process() in the Move State is always running, and every frame is checking for player input. It then applies it. It calls _get_input_direction() to do that. Note the last line in that function:
return character.cameras.get_facing(input_vector, character.transform.basis)
This is actually where we handle different views, Lets look at that function’s code:
## Returns the direction for a [CharacterBody3D] based on the passed input vector
## and the [member Characterbody.transform.basis]. If the active camera is 1st
## person, 3rd person free look or 3rd person follow, the player will point in
## the direction of the camera. If the camera is a 3rd person fixed, ISO or birds
## eye view camera, it will just reflect the actual direction the input is moving
## the player.
func get_facing(input_vector: Vector3, character_transform_basis: Basis) -> Vector3:
if active_camera is CameraMount3D:
return active_camera.horizontal_pivot.global_transform.basis * input_vector
elif active_camera.rotation.y != 0.0:
return input_vector.rotated(Vector3.UP, active_camera.rotation.y).normalized()
else: #If this is a fixed camera, we don't change the player facing based on it.
return character_transform_basis * input_vector
And that’s it!
By letting the Cameras node interpolate the movement, the Player does not actually need to know what movement in the world based on the camera position means. It just moves. The Cameras make sure that the Player moves in the correct direction.
