Simple State Machines (GDScript)

This is a READ-ONLY snapshot of the Godot Community Forums when TwistedTwigleg was the owner, which is hosted for archival reasons only. The current Godot Community Forums can be found here.

Some links may point to external websites, including the current Godot Community Forums. These websites are not associated with TwistedTwigleg.

KanataEXE

Does anyone know any simple state machine that I can use?

fire7side

Maybe you should just look at the animation tree node first:

BumfuzzledGames

If you want a really simple state machine, you can just do this.

signal state_changed(state)
enum State { IDLE, WALK, FALL }
var _state = State.IDLE

func _set_state(state):
	_state = state
	emit_signal("state_changed", _state)

func _process(delta):
	# All state changes go here
	match _state:
		State.IDLE:
			if not is_on_floor():
				_set_state(State.FALL)
			elif _input.x != 0:
				_set_state(State.WALK)
		State.FALL:
			if is_on_floor():
				_set_state(State.WALK)
		# etc

	# Update depending on state goes here
	match _state:
		State.WALK:
			position.x += _speed * _input.x * delta
		# etc

The advantage of this is that it is absolutely dead simple and you can just do this any time you need a simple state machine. It takes just a few lines of code to set up. Libraries are often overengineered or overcomplicated and bugs in the library can be a show-stopper, and even the AnimationTree node has complexities that may not be appropriate for your project.

This does tend to get a bit unwieldy for large classes, though.

Calinou

See the State chapter of the Game Programming Patterns book.

Pyral

The object oriented way is pretty nice and typically how I do quick and fast state management for stuff in-game. It's great since you can easily just make new state scripts and break up a loooot of logic. Just need to reference player manually since its nodes and resources aren't local to the script.

http://hastebin.com/nabinexeke.php - pseudocode I just wrote up based on something I've worked with before. Won't work copypasta'd in on its own but gives an idea of what I do. change_state, you'd feed in the state instance's reference that you want to change to, and the logic of state transition could be handled by individual states (such as if the jump button is pressed, we call player.change_state(player.state_jump)). Some modifications would be needed to allow it to transition states by outside calls, but good OOP usually tries to make it so outside objects don't need to know how inside objects manage their own states.

Enums work but only for very small things since, as Bumfuzzled says, it gets very unwieldy.

sent44

The most simple state machine is just integer variable.

var state = 0
func run_state():
	if state == 0:
		print("This is first state!")
		state = 2
	elif state == 1:
		print("2nd state")
		state = 0
	elif state == 2:
		print("Last state :(")
		state = 1

Calinou

@sent44 Using enums is preferable to integers as enums result in more readable code.

sent44

@Calinou In my example, I didn't even think of the name of each states and I also want to show how much simple it is. If I want to make my example readable, I might as well use const variable over enum. Since Godot enum is just dictionary in disguise. (Yes, I use both)

fire7side

I haven't actually needed a state machine in Godot yet, but I think I like having each state be a function and calling it from process. Just call the next state from the function. That gives the most opportunity to fine tune it without getting too complicated. If it got really complicated, maybe use a class like in the example doc on states. Who wants all the elif's in process with code. Just use a match with enums and call the function each cycle.

sent44

The post author asked simple, I answered simple. Not complex but easy to read/manage system. Don't like else-if(elif)? Sure, go for switch-case(match). If is simple and switch has good readability but logic wise both are the same.

fire7side

@sent44 said: The post author asked simple, I answered simple. Not complex but easy to read/manage system. Don't like else-if(elif)? Sure, go for switch-case(match). If is simple and switch has good readability but logic wise both are the same.

Oh, yeah. I wasn't criticizing your example. I would just change the state in the state function, which your example just sort of assumed, but was mainly focused on the switch part of it.

if state == 0:
	idle()
elif state ==1:
	walk()

func idle():
	play animation
        velocity = 0
	move(velocity)
	if input == "move_left":
              state = 1
              direction = "left"

It's not actual code, but I would do all movement and input related in each state function even though the code might be redundant because you might want to use a different move statement or whatever. I've seen different ways of doing it and was just thinking how I would do it if I need to. Some people group inputs and just have one move statement which works fine also for most things. Indenting got messed up, I must have been inconsistent. I might change my mind when actually working on it, especially on the inputs. Right now I'm doing something so simple I don't need it, just basically walking around in first person and the interaction is separated already.

cybereality

I know @Calinou already posted the definitive link, but I'll quote the most relevant code for this discussion. The full tutorial gets into more advanced OOP state machines, which are great, but may be too much if you are just learning or want something quick to play around with.

enum State
{
  STATE_STANDING,
  STATE_JUMPING,
  STATE_DUCKING,
  STATE_DIVING
};

void Heroine::handleInput(Input input)
{
  switch (state_)
  {
    case STATE_STANDING:
      if (input == PRESS_B)
      {
        state_ = STATE_JUMPING;
        yVelocity_ = JUMP_VELOCITY;
        setGraphics(IMAGE_JUMP);
      }
      else if (input == PRESS_DOWN)
      {
        state_ = STATE_DUCKING;
        setGraphics(IMAGE_DUCK);
      }
      break;

    case STATE_JUMPING:
      if (input == PRESS_DOWN)
      {
        state_ = STATE_DIVING;
        setGraphics(IMAGE_DIVE);
      }
      break;

    case STATE_DUCKING:
      if (input == RELEASE_DOWN)
      {
        state_ = STATE_STANDING;
        setGraphics(IMAGE_STAND);
      }
      break;
  }
}

Note, that is C++ code, but could be converted to GDScript easily. The key is that you have a defined set of states as an enum, and then your update code simply uses a case/match statement to process a particular state each frame (and that you can only be in any one state at any given time).

When starting out you (without state machines) typically have a bunch of boolean variables like "is_jumping", "is_ducking", "is_attacking", but it gets very confusing if you want to jump and attack at the same time. Or maybe you are ducking and then you attack, and then press jump during the attack animation. It quickly gets unmanageable. FSMs solve this very nicely. You know for sure which state you are in, and you can easily code it so that if you press attack while ducking, you transition to the attack state (where you are standing). And if you are attacking, you don't respond to the jump button being pressed. It is way cleaner.

fire7side

I don't care for having that much code in a switch statement, and it's probably going to get more complicated. Suppose you want to test for collisions or something? That's what I basically was talking about for just calling functions only in the switch. I'm sure that would be fine for a simple case, though. There must be a simple state machine posted somewhere in GD script.

cybereality

Yeah, that is just an example so you can understand the idea. And it's not really a lot of code, the code has to live somewhere, whether you put it in a function to be cleaner doesn't change the logic. But I understand your point.

DaveTheCoder

The code looks longer than it really is, because it doesn't use K&R-style brace placement. (I know that it's copied directly from the book that Calinou linked.) In GDScript, it would be even shorter, since there wouldn't be braces or break statements.

cybereality

Also, if you want to see a lot of code, look at the player controller for Celeste. https://github.com/NoelFB/Celeste/blob/master/Source/Player/Player.cs

fire7side

@cybereality said: Also, if you want to see a lot of code, look at the player controller for Celeste. https://github.com/NoelFB/Celeste/blob/master/Source/Player/Player.cs

Actually, the switch case in there was very brief. It was weird seeing all that code on one page, though. That's kind of a Godot thing also with only one script per node. That's not so bad if you break it up into functions that separate it enough to be readable and give them names that tell what they do.

cybereality

Well, that is not the best code example in terms of structure. The developer could have used more classes and broke that large file into many different files (and Unity allows multiple scripts on a single node). But then again, the game was great and sold very well so who am I to judge.

Also, most games are not open-source and, of the stuff I've seen, production code can be very messy. Like you start with a good design and somewhere you start adding hacks, and you have to release a demo, or a milestone for a client/publisher/etc. and then it all goes downhill. But it's good to see what real code looks like.