Long Nguyen Huu

Combat Platformer in Godot 4: June 2024 progress

2024-06-18T00:00:00+00:00

Summary

Fireball Rain

The big addition is the Fireball Rain, which is a more classic bullet hell platformer move, inspired by Marisa’s Energy Bombardment in Touhou Luna Nights. Except instead of spawn a pillar of light, each fireball spawns a fire AOE that stays on the ground/wall it hit for a while.

The move is more regular that the previous homing fireballs, so it encourages the player to learn the pattern and safe spots to get there quickly rather than adapting to each shot very fast. That said, I find it a bit too regular now, maybe I’ll add some randomized offset to force the player to adjust their position a little.

New moves and animations

Player character can now Air dodge, and existing moves all got a dedicated animation. The boss is also animated when casting a spell and getting hurt.

Here is a video to recap new animations, all while trying to dodge the new Fireball Rain.

Your browser does not support the video tag.

And the player character death animation:

Simpler level

I removed all the platforms and re-added two so the player character can still jump high enough to reach the boss who is shooting Fireball Rain from very high above.

First BGM

I was tired of testing in a silent room so I added the first BGM, some free asset Last Boss 01 (ラストボス01), by MaouDamashii under CC BY 4.0.

Changelog

Gameplay

Player character: shorter ground Slide, add Air Slide
Player character: Melee attack: allow changing direction when chaining attacks
Boss: skill: replaced single fireball shot with new Fireball rain (projectile accelerates)
Projectile: Fireball damages player character but moves through it
Projectile: Fireball generates fire AOE for a short time after hitting ground or wall

Level

Simplify level with only 2 platforms

Visual

Player character: Slide, Hurt, Death, Jump, Fall, Crouch, DashAttack, AirSlide + transitions
Boss: new Idle, Hurt, SpellForward, SpellUpward animations and transitions between them (using AnimationTree)
Projectile: Fireball warm up FX, Fireball Rain round fireball sprite, Fireball explosion on hit

Audio

BGM: Boss theme phase 1 extracted from free BGM “Last Boss ラストボス01” by MaouDamashii

Godot threads opened

Issues

Proposals

Animation SpriteFrames: add keyboard shortcut to rename animation (default F2)

Combat Platformer in Godot 4: April 2024 progress

2024-04-12T00:00:00+00:00

Summary

Visual revamp

Big revamp! I finally switched the whole game to full custom graphics. I first worked with a resolution similar to the proto character asset (see previous post 3 months ago), then tried smaller sizes to draw faster. Below, some character scale research:

From left to right:

Tiny: fast to draw, but hard to show details like scars, sword erosion or body limb animations. Instead, it relies a lot on translations and FX.
Chibi: I don’t like how this one turned out, it was supposed to look like Momodora I-III but got ugly and now it reminds me of the horned idol statue in Indiana Jones and the Fate of Atlantis.
Small: It’s a nice compromise, I’d go with this one if I had more time.
Normal: The original sprite I’ve drawn, would take more time to animate, but I’d go with this one if I hired a pixel artist.
Tall: A funny experiment with the “thin body - long legs” pixel art style found in indie games like Superbrothers: Sword & Sworcery EP.

In the end I went for the Tiny art style, using references such as Time for Lunch (PICO-8 game) and Necrosphere.

Then I converted the other elements (boss, projectiles and FX) and added new elements (background, HUD) to fit in this style. The ice spike FX is very big so it was quite easy to convert (although the warm up animation needed some tuning), while I had to redo the fireball animation from scratch (and also recolored them).

Rebuilt boss level

I also rebuilt the whole level to something symmetrical with a few platforms. Kudos to the Lospec Pixel School which helped me tune the color palette! Using Aseprite, it’s quite fast with the Indexed Color Mode + Edit Color button.

First SFX

Finally, I added fireball spawn SFX. Instead of the usual sfxr (via jsfxr), I tried to use audio synthesizer Vital. I had already tested its free little brother Helm but was limited by the lack of wave modulation and wanted more features… Well, I got them, there are too many for me to understand now, so I just used a little bit of Vital’s features.

The biggest issue was Reaper + Vital plugin crashing on Linux which forced me to manually record the SFX from Vital standalone. I may eventually switch back to jsfxr or Helm because of this.

Since I was busy working on new graphics and plugging the HUD behavior, there is no new gameplay features in this update. I will work on improved boss patterns and main character moves next time.

Your browser does not support the video tag.

Changelog

Level

Rebuilt full level as a small, one-screen room with 5 platforms

UI

HUD: plug main character & boss life gauges to their remaining HP

Visual

Main character sprites: Idle (1 frame), Run cycle (4 frames), Attack (7 frames)
Boss sprites (Tiny art style): Idle (1 frame)
Fireball sprites (Tiny art style): Move (4 frames)
Ice spikes (Tiny art style): Warm up (13 frames), Appear (6 frames), Active (4 frames), Disappear (3 frames)
HUD: Main character life gauge (discrete cells), Boss life gauge (continuous gauge)

Audio

SFX: Fireball spawn

Godot threads opened

For the first time, I’ll also post the list of Godot issues and proposals I opened since the last devlog. It’s pretty long because they span over 3 months, hopefully next list will be shorter.

I realised I spent a considerable amount of time debugging, isolating MWE (Minimum Working Examples) and posting them on GitHub, so tracking issues I have opened is a good way to motivate me: I’ve not been doing nothing that day!

For now it’s my main way to contribute to Godot, but I hope I’ll be able to send pull requests to contribute to engine code in the near future.

Issues

Discussions

Proposals

Combat Platformer in Godot 4: January 2024 progress

2024-01-06T00:00:00+00:00

I decided to switch from a combat platformer where you fight many minions to a single boss fight where platforming is essentially to dodge boss attacks and find a right angle to counter-attack. I started drawing the first original sprites for the boss, so I could get exactly the character and projectile animations I needed.

Gameplay

Level: added 1 boss: the sorcerer
Enemy AI: the sorcerer continuously shoots fireballs in the same direction

Visual

Character sprite: Sorcerer 2-frame Idle, 2-frame Hurt, 2-frame Die, 4-frame SpellForward (not used yet)
Projectile sprite: Fireball 4-frame Move

Your browser does not support the video tag.

Assets used:

Snake remake in Godot 4: October 2023 progress

2023-10-11T00:00:00+00:00

In July 2023, I started working on a “Snake with a twist” in parallel to my other games. It’s a smaller project that I intend to finish within 100 hours of work, using only geometrical graphics and simple arcade mechanics to avoid artistic and technical difficulties (game design will probably be the most difficult part).

My latest addition is moving enemies. They currently move at half the speed of the player snake, but they still make the game significantly harder: new enemies regularly spawn and keep coming at you, and touching them causes instant game over. You can trick them by repeatedly warping to the other side of the arena, but I may eventually fix this by making enemies aware of edge warping to find the real shortest distance to player snake.

Your browser does not support the video tag.

One problem is inherent to snake: you cannot control the tail, so it is very vulnerable, even more as your snake gets longer. I may mitigate this by reducing penalty when a body part other than the head hits an enemy.

Dev status

Total work time: 27h

Gameplay

Player character: move like a classic snake (hold diagonal for laddering)
Pick-up: eat to extend snake length by 1 and increase Score

Visual

Dark background
All sprites are colored squares

HUD

Display score in top-left corner

Known issues

Pick-up and enemies can spawn anywhere, including near and inside the player snake without warning!

Combat Platformer in Godot 4: June 2023 progress

2023-06-08T00:00:00+00:00

I have added a few features to my prototype of combat platformer made in Godot since February, as well as less visible QoL/debug improvements:

Gameplay

Actions: Slide, airborne Attack
Flow: better action constraints (cannot move while attacking on ground, but can move when attacking airborne, with locked direction)
Enemy AI: Behaviour Trees with Yet Another Behavior Tree

Visual

Feedback: red hurt color, blue invincible color during Slide
More robust animation system with base (continuous) animations like Run + override (one-time) animations like Attack

Your browser does not support the video tag.

Debug

Restart all entities immediately when pressing R
Debug overlay: FPS, current frame, currently pressed input

Your browser does not support the video tag.

Assets used:

Combat Platformer in Godot 4: Feb 2023 progress

2023-02-12T00:00:00+00:00

I started working on a side-scrolling combat platformer prototype in Godot 4. I’m regularly downloading new snapshots of Godot 4 beta which sometimes introduces breaking API changes, but I hope it will be worth it when it finally gets released.

I managed to port most of my code for character control/animation from an older project. But it was top-view, so I still had to work more to get running and jumping to work.

The biggest issue I had with physics was a regression on move_and_slide (see this issue). Otherwise, I’d say Godot’s built-in classes made it pretty simple. I don’t have any custom raycasts in my code so far.

So far I implemented the following features for the player character:

move and jump
melee attack: can chain up to two slashes
health system: get hurt and die

I’d like to make this open source, but as it contains some copyrighted third-party assets (although free). I may extract the scripts into some public submodule (as with my Unity projects) though, so stay tuned!

Assets used:

C++ 2D Game Engine – Postmortem

2019-05-24T00:00:00+00:00

4 years ago, I started working on a custom 2D game engine in C++. At the beginning, I needed a simple game to experiment AI techniques with, but I ended up working on a small engine (I still wanted to train AI to I moved that project to Unity).

The main features I am aiming at are:

Entity-component system
Fixed update and input/render update loops
Game window with OpenGL with GLEW + GLFW
Keyboard/mouse input
Primitive 2D shapes rendering
Basic shaders
2D physics (Box2D)
Scene-Entity system
Scene editor and basic scene serialization
AI helpers
Unit tests (Catch2)
Sample game

At first I used SDL2 for window management and rendering, before switching to OpenGL with GLFW for more flexibility (e.g. zooming in and out with the camera). Now, I know that SDL2 supports OpenGL rendering too, so looking back at it, SDL2 wasn’t a bad choice at all (plus I’m still only rendering simple shapes like squares right now).

That said, I like GLFW’s window API better and I need some OpenGL training anyway, so why not start with simple shapes. Next time, I’ll also have a look at SFML, but for now I want to focus on the engine systems (modules).

Progress

I have implemented the game application window, basic keyboard input and basic rendering systems, as well as a simple entity-component system with a base Actor class for game objects, a base Component class for components and their respective factories. Input and rendering is done via Components, but the developer can also add custom behavior by subclassing the Actor class for all game, as in Unreal Engine (and Godot with Nodes).

Advantage: you can implement behavior specific to one entity directly inside the Actor subclass, without using components

Disadvantage: all game objects don’t have the same exact type and have different sizes, so you cannot put them in an array/vector of GameObjects (Unity-style) combined with handles for maximum cache efficiency (see Data Locality). If you still want data contiguity, you’ll need a custom container that supports variable object size.

For now, I have something like this:

Primitive rendering with Stealth Engine

Demonstration of Box2D collision in Stealth Engine (player controls right square)

The last thing I have done is refactoring the engine structure with a lot of interfaces to allow unit testing.

You can check the code on my GitHub repos:

Engine
Sample “game” (it uses the engine as submodule)

Next step

I’m not working on this project right now, but I’ll have to go back to it at some point, especially if I want to make an engine in a different language (e.g. Rust). This would be an opportunity to learn from my past mistakes and clean things up before I step onto a cleaner architecture.

Blueprint-defined behavior with dynamic multicast delegates in Unreal Engine

2017-02-14T00:00:00+00:00

Note: this post has been moved from my old website. It is about UE4 and has not been tested for UE5, however UE5 documentation shows that delegate macro names have not changed. Content has been adjusted to fix dead links and update links to their redirection, such as UE4 doc -> UE5 doc.

Quite often, gameplay programmers need to hand over the task of creating scripted events to level designers. In Unreal, a common workflow is to define shared features in C++ and level-specific behaviors with Blueprints.

While it is possible to implement C++ Actor methods via Blueprints using either BlueprintImplementableEvent or BlueprintNativeEvent, in this post, I’ll talk about dynamic multicast delegates.

Concept

Delegates allow you to handle functions as objects, pass them around and execute them later with the appropriate context. There are various ways to implement them in C++ (see this discussion on stack overflow and this proposition of Generic C++ delegates), and Unreal provides its own implementation (see Delegates in UE documentation). I won’t try to explain how they work in UE (getting myself lost among all the macros in the source code) but I’ll show you how to use them in a very specific case.

Imagine we have several Actors that share the same behaviors via Actor Components. Both Actors and Actor Components are initially defined in C++, but only Actors are extended via Blueprints (to reduce the number of Blueprints). Behaviors are defined as C++ methods in the Actor Components’ classes, but since those are not derived into Blueprints, we cannot use BlueprintImplementableEvent nor BlueprintNativeEvent UFUNCTIONs to move the implementation to a Blueprint event graph.

Instead, we declare a dynamic multicast delegate member in the Actor Component (called SwitchableComponent) and bind a function (actually a Blueprint graph) to that delegate in the Actor’s Blueprint.

Code

Actor Component

Below is an example on how to do that with a switch and a delegate for functions that takes 1 boolean parameter (true to switch on).

// SwitchableComponent.h

#pragma once

#include "Item/InteractableComponent.h"
#include "SwitchableComponent.generated.h"

// This macro will generate a declaration for a delegate that supports functions receiving
// one boolean parameter. Check the documentation for parameter variants.
DECLARE_DYNAMIC_MULTICAST_DELEGATE_OneParam(FSwitchableComponentSwitchSignature, bool, bOn);

// In my game, UInteractableComponent allows interaction from the player character,
// but you can derive directly from UActorComponent instead
UCLASS(BlueprintType, ClassGroup = (Interaction), meta = (BlueprintSpawnableComponent))
class MYGAME_API USwitchableComponent : public UInteractableComponent
{
    GENERATED_BODY()

public:

    USwitchableComponent();

    UPROPERTY(Transient, Category = "State")
    bool bIsOn;

    /** Toggle switch */
    void Switch();

protected:

    // Here is the delegate we'll bind the behavior to in the Actor Blueprint
    /** Callback on switch on / off (passed boolean argument is true if switching on) */
    UPROPERTY(BlueprintAssignable, Category = "Interaction")
    FSwitchableComponentSwitchSignature OnSwitch;

};

// SwitchableComponent.cpp

#include "StairlessTower.h"
#include "SwitchableComponent.h"

USwitchableComponent::USwitchableComponent() : UInteractableComponent()
{
    bIsOn = false;
}

void USwitchableComponent::Switch()
{
    // Toggle
    bIsOn = !bIsOn;

    // The IsBound() check is optional for multi-cast delegates, but let you know if
    // at least one function is bound to the delegate
    if (OnSwitch.IsBound())
    {
        OnSwitch.Broadcast(bIsOn);
    }
}

Note that we need a dynamic delegate because dynamic delegates are serializable, which allows them to be saved in the Blueprints. I’m not sure why multicasts delegates are required, maybe it’s because they support multiple function bindings or because they don’t have return values. Anyway, if you try to use DECLARE_DYNAMIC_DELEGATE_OneParam you’ll get the following error: ‘BlueprintAssignable’ is only allowed on multicast delegate properties.

Actor

Now, we create a WallSwitch Actor that uses SwitchableComponent:

// WallSwitch.h

#pragma once

#include "GameFramework/Actor.h"
#include "WallSwitch.generated.h"

// We'll need to derive a Blueprint from this Actor, so we make it Blueprintable
UCLASS(Blueprintable)
class MYGAME_API AWallSwitch : public AActor
{
    GENERATED_BODY()

    // Make the switchable component accessible in the Blueprint editor for later
    /** Switchable component */
    UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category = "Interaction", meta = (AllowPrivateAccess = "true"))
    class USwitchableComponent* SwitchableComponent;

public:
    // Sets default values for this component's properties
    AWallSwitch();

    // Called when the game starts
    virtual void BeginPlay() override;

    // Called every frame
    // virtual void Tick( float DeltaSeconds ) override;

};


// WallSwitch.cpp

#include "StairlessTower.h"
#include "WallSwitch.h"

#include "Item/SwitchableComponent.h"

// Sets default values for this component's properties
AWallSwitch::AWallSwitch()
{
    PrimaryActorTick.bCanEverTick = false;

    // Create and attach a SwitchableComponent
    SwitchableComponent = CreateDefaultSubobject<USwitchableComponent>(TEXT("SwitchableComponent"));
}

Blueprint

Actor Blueprint

We create an Actor Blueprint BP_WallSwitch derived from WallSwitch. The Components panel shows:

When we select the Switchable Component, the Details panel shows:

Binding

At first, the buttons in the Events section should all show a “+”. We click on the button next to On Switch to create the event node below (from then on, the button will show “View” as on the screenshot above):

Alternatively, you may right-click in the Event Graph area and type “Add On Switch” in the search field (ensuring SwitchableComponent is still selected and Context Sensitive is checked).

From here, we can bind a Blueprint graph to the OnSwitch delegate (represented by an event node) defined earlier in C++. In this example, we play a Sequence from a Sequence Actor reference we added directly as a Variable in the Actor Blueprint.

Result

When the player character tries to interact with the Wall Switch, the level sequence plays:

The red/green box you see is a Box Trace with visual debug that the Player Character uses to detect interactables. It’s quite easy to do with Blueprints but may be tricky in C++, I’ll explain how this works in another post.

Notes

The OnSwitch event node that appeared seems to be a convenience node provided by the Event Graph when handling a delegate on an Actor Component (BlueprintImplementableEvents also show such nodes). But in general, you can bind events to delegates by creating a Custom Event with its own subgraph and assigning it to the Event input pin of the Bind Event to … node (type “Assign” in the Blueprint search box and you’ll find an action that generates both the Custom Event and the Bind Event node for the delegate you want, provided it is accessible from the current Blueprint or you have selected it in the World Viewport).

For instance, I selected a Wall Switch instance in the Viewport, then in the Level Blueprint editor I right-clicked > Assign to OnSwitch. This allowed me to add an extra logging event when the Wall Switch was pressed (the multi-cast delegates will trigger all bounds functions/events on Broadcast).

For examples on how to bind functions from raw C++, check out Rama’s article on Delegates.

Screen Debug Message macros for Unreal Engine

2017-01-23T00:00:00+00:00

Note: this post has been moved from my old website. It is about UE4 and has not been tested for UE5, however UE5 documentation shows that AddOnScreenDebugMessage’s signature has not changed. Content has been adjusted to fix dead links and update links to their redirection, such as UE4 doc -> UE5 doc.

For all my Unreal projects, I insert a small header containing debugging utility, especially for printing on screen.

Code

First, I defined a bunch of macros to print debug messages on screen. The code is based on Logs, Printing Messages To Yourself During Runtime and uses AddOnScreenDebugMessage

#pragma once

#include "EngineGlobals.h"
#include "Engine/Engine.h"

#define print(text)                         if (GEngine) GEngine->AddOnScreenDebugMessage(-1, 1.5f, FColor::White, TEXT(text), false)
#define printc(channel, text)               if (GEngine) GEngine->AddOnScreenDebugMessage(channel, 1.5f, FColor::White, TEXT(text))
#define printf(format, ...)                 if (GEngine) GEngine->AddOnScreenDebugMessage(-1, 1.5f, FColor::White, FString::Printf(TEXT(format), ##__VA_ARGS__), false)
#define printcf(channel, format, ...)       if (GEngine) GEngine->AddOnScreenDebugMessage(channel, 1.5f, FColor::White, FString::Printf(TEXT(format), ##__VA_ARGS__))

#define printwarn(text)                     if (GEngine) GEngine->AddOnScreenDebugMessage(-1, 1.5f, FColor::Yellow, TEXT(text), false)
#define printcwarn(channel, text)           if (GEngine) GEngine->AddOnScreenDebugMessage(channel, 1.5f, FColor::Yellow, TEXT(text))
#define printfwarn(format, ...)             if (GEngine) GEngine->AddOnScreenDebugMessage(-1, 1.5f, FColor::Yellow, FString::Printf(TEXT(format), ##__VA_ARGS__), false)
#define printcfwarn(channel, format, ...)   if (GEngine) GEngine->AddOnScreenDebugMessage(channel, 1.5f, FColor::Yellow, FString::Printf(TEXT(format), ##__VA_ARGS__))

#define printerr(text)                      if (GEngine) GEngine->AddOnScreenDebugMessage(-1, 1.5f, FColor::Red, TEXT(text), false)
#define printcerr(channel, text)            if (GEngine) GEngine->AddOnScreenDebugMessage(channel, 1.5f, FColor::Red, TEXT(text))
#define printferr(format, ...)              if (GEngine) GEngine->AddOnScreenDebugMessage(-1, 1.5f, FColor::Red, FString::Printf(TEXT(format), ##__VA_ARGS__), false)
#define printcferr(channel, format, ...)    if (GEngine) GEngine->AddOnScreenDebugMessage(channel, 1.5f, FColor::Red, FString::Printf(TEXT(format), ##__VA_ARGS__))

#define printfloat(variable)                if (GEngine) GEngine->AddOnScreenDebugMessage(-1, 1.5f, FColor::Cyan, FString::Printf(TEXT(#variable ": %f"), variable), false)
#define printcfloat(channel, variable)      if (GEngine) GEngine->AddOnScreenDebugMessage(channel, 1.5f, FColor::Cyan, FString::Printf(TEXT(#variable ": %f"), variable))

#define printvector(variable)               if (GEngine) GEngine->AddOnScreenDebugMessage(-1, 1.5f, FColor::Green, FString::Printf(TEXT(#variable ": %s"), *variable.ToCompactString()), false)
#define printcvector(channel, variable)     if (GEngine) GEngine->AddOnScreenDebugMessage(channel, 1.5f, FColor::Green, FString::Printf(TEXT(#variable ": %s"), *variable.ToCompactString()))

There are multiple versions for each define because I wanted to support channels and string formats.

A message printed on a channel will override any previous message on the same channel, whereas a message not printed on a channel (-1) will always be printed as a new message.

String formats are very convenient for debugging, just remember to pass *TCHAR arguments to Printf by calling the operator* on the FString you want to display (variadic arguments, a float or a vector converted to a string). Note that I use FVector::ToCompactString() instead of ToString() to display 2 decimals instead of 3, but your mileage may vary.

#variable allows me to print the name of the variable or expression in front of its value. The fallback is that you shouldn’t type expressions that are too long.

In the other defines, the ## before __VA_ARGS__ will make sure the last comma will be stripped out of Printf arguments if no argument is passed along a format, although it is not required when using variadic macros in C++ (see Variadic Macros). Since the format version of each method (printf, printcf, printfwarn, etc.) supports 0 extra arguments, you may get rid of the non-format versions (print, printc, printwarn, etc.) and rely entirely on the format versions.

I also pass false as the 5th parameter of AddOnScreenDebugMessage, bNewerOnTop, so that new messages are printed toward the bottom of the screen. Again, you may prefer the opposite option (in this case, don’t pass a 5th argument at all, since the default is true).

Demo

Actor location debug message is continuously updated

Debug messages after switching view to first person

Debug messages after switching view to third person

Going further

I am still prototyping my new game, but when I enter production I will probably want to strip out the debugging calls of my non-dev builds. I will probably add conditional macros such as

#if UE_BUILD_DEBUG
    // defines here
    // ...
#else
    // empty defines here
    #define print(text)
    // ...
#endif

Also check out Rama’s post to prepend the function name and line to the message.

Crawling side-view character in Unity

2016-12-18T00:00:00+00:00

Note: this post has been moved from my old website. It was written for Unity 5 but Animation Controller has not changed much since.

I implemented crawling for my human character controller in a cooperative platformer made with Unity, Mars 21.

Astronaut crawling

Structure

The controller works with two MonoBehaviour scripts, AstronautPlayerControl.cs and AstronautMotor.cs, and an Animator component. The Animator Controller has 2 layers:

Motion layer for logic

The Motion Layer represents the character’s finite-state machine (FSM). A StateBehaviour containing the actual motion logic is added to each state, and all the transitions are immediate (transition time = 0). Below, you can see graph of the sub-state machine “Grounded”, with the grounded sub-states: Idle, Walk (hidden on the right), Turn 180 (for animated 180° turns), Crouched, Crawl and Idle-Crouch transition states.

Motion Layer

The Crouched and Crawl state logic is pretty simple. Both StateBehaviours contain the following:

override public void OnStateUpdate(Animator animator, AnimatorStateInfo stateInfo, int layerIndex) {
    if (!motor.isGrounded) {
        motor.Fall();  // enter Fall state (apply gravity + fall animation)
        return;
    }
    if (!control.continueCrouchIntention) {  // is the player still holding D-pad / stick down?
        motor.StopCrouching();
        return;
    }
    motor.MoveCrawling(control.moveIntentionVector.x);
}

where control is an AstronautPlayerControl and motor is an AstronautMotor. MoveCrawling() moves the character by setting his velocity as it would with a normal walking 2D character, with 3 main differences:

the character preserves his current direction when moving backward (he does not turn)
the motion velocity is lower, and even lower when moving backward
the character starts crawling after any motion in the Crouched state (à la Metal Gear Solid), although this difference is merely visual

On the video, the character switches between Idle, IdleToCrouched, Crouched, Crawl and CrouchedToIdle. The transitions between IdleToCrouched and CrouchedToIdle allow the character to quickly interrupt crouching to stand up again smoothly and vice-versa.

Animation Layer for aesthetics

The Animation Layer animates the character model. An animation is attached to each state, and the transitions have short durations (0.1s).

Animation Layer

Animations have been downloaded from mixamo after uploading the character model of the Astronaut.

Limitations

This approach has an important drawback: you have to duplicate the structure of the FSM between the two layers. Unity has a feature called Animation layer syncing which allows you to reuse an existing structure on multiple layers, but unfortunately it doesn’t support using different transition times on different layers (0 for the Motion layer and 0.1s for the Animation layer). For my next project, I will probably switch to an FSM completely in code (with my own StateMachine class), only using the Animator for actual animations.