I'm considering using a state machine for a character controller but, I don't know why I would use it yet. The reason why I'm asking this now, is because this is the type of thing I need to consider early in the first stages of development. I can't just put in a finite state machine at the last minute. Any advice?

You do need one, if your game is even remotely complex. I mean, you could code Flappy Bird with if statements, but anything with real animation and running, jumping, crouching, etc. needs a state machine or your life will be a nightmare.

This is because there are lots of combinations of things and transitions from states. Even with just a few states, it gets complex. Like if you can walk, run, jump, and crouch. You should be able to jump while you are walking or running, but jumping from a crouch doesn't make sense. Jumping while you are already jumping doesn't make sense either, if it's a realistic game. Or how about opening a door. Opening a door makes sense when walking, running doesn't make sense (you would need to stop or kick it), and opening a door while jumping doesn't work. Opening a door while crouching does make sense in a stealth game, but you would need to detect this, to play a different animation. If you don't use state machines, you end up with horrible code like this:

if ((button_pressed == OPEN and (current_speed.length < 4.0 and velocity.y == 0.0 and current_animation != CROUCHING) or (button_pressed == KICK and (current_speed.length >= 4.0 and current_animation == RUN))) {
    // open the door
}

This is madness, it will break, you will have no idea why and every time you add a new animation or change the speed of something you will have to go and update every single if statement. Basically a nightmare.

    It's a workflow situation, I myself haven't yet really needed a state machine to do stuff but I can understand the use case for it certainly.

    cybereality but jumping from a crouch doesn't make sense.

    Well, it could for something like getting a little extra boost for jumping straight up to grab a ledge or something. But that's really niche I guess. Plus if you have a more platformery game and it's a wall ledge maybe wall run might make more sense, right?

      Sure, but the point is that every time you add a "state" without a state machine the complexity is exponential. Since every if statement needs to be updated and will likely break in ways you don't expect.

      I disagree on jumping from a crouch, you ever tried it? There's also crouch jumping in games which I just like generally as an action, feels nice and smooth for when you're hopping on boxes or across ledges lol 😃 I've just been playing Half Life 1 for reference while I work on my own shooter.

        I second this question. In my projects I haven't yet run into situation, where state machine felt a good choice for character controller. Every game has different needs, so one needs to evaluate things per case.
        For example, I'm currently making a platformer, and the character can run, jump, wall slide/jump and dash. It would sound like there's a clear cut between states, but I don't find that's the case. For example, character runs off a cliff - trigger falling animation. However, for better gameplay, character can still jump for a fraction of a second (coyote time) - so which state is it, run or fall? Or should there be an intermediate state? I couldn't find satisfying boundaries between different states, and animation and gameplay needs don't always go hand in hand, so I felt it was better to organize my code in a different way.
        But if your character states do have defined boundaries, maybe transitions, and differences in how they're handled, state machine is a very good tool. For first prototype I wouldn't jump straight into using it. I would write the character controller, see how it works, and then evaluate the complexity of the code and the need for refactor. If there are such long if clauses as cybereality provided example of, there's probably good value in state machines.

          Yeah, there are definitely some edge cases you have to account for. For some stuff you would just define a new state like you have RUN, JUMP, FALL, then you can add RUN_JUMP, RUN_FALL, etc. But this can get unwieldy fast depending on how complex the movement is. The other option is to stay in the previous state for longer than normal. Like in the coyote run scenario, you can simply stay in the RUN state, and change the requirements to when you switch to JUMP or FALL. States are discrete, but also not static. So lets say your character walks first and then after a certain amount of time starts running. You can still have some transition (either before or after the cut off point) where the player starts walking faster (changing animation, etc.) and then goes to the run full sprint. It doesn't have to be at the exact same point in time. The animation state similarly does not have to be exactly the same as the state machine (though it typically is). The state machine is mostly used for the gameplay programming, the controls and movement (or AI for enemy characters). It's really the same for any game, at least any game with characters. I imagine there are some physics based games, or puzzle, etc. that wouldn't use a FSM. But for FPS or third person games, it should work across the board.

          aXu_AP However, for better gameplay, character can still jump for a fraction of a second (coyote time) - so which state is it, run or fall? Or should there be an intermediate state?

          State transitions don't have to be instant. a transition could have a timer counting down. Or you could have a interim state between the two for the coyote time.