Implementing player movement in a Finite State Machine

[Eroica]

Hello everyone,

first of all, I'm really grateful for having found LÖVE and this forum. Game development has always been my favorite hobby, and with LÖVE it feels like the game I'm day-dreaming about (like everyone else here probably ) could be really achieved with enough effort and time.

Right now, I'm trying to prototype a basic platformer---walking, jumping, and some combat later. I've attached a .love file that represents the current state. If you open it, you'll be able to control the player using A/D (left/right) and W (a single jump). (Big thanks to kikito for his bump.lua (and other libraries) that I'm using here. Most of the movement methods are from his bump.lua example game.)

(I've stripped away some unnecessary stuff like the component system so that only the important parts about player movement remain. These are mainly located in the player.lua file and in the love.update(dt) function.)

So far I'm quite satisfied with the current mechanics--for instance, the player has to release W if he (she, in this case) wants to jump again. (In the beginning it was the case that while holding W, the player would immediately start another jump after she touched the ground again.)

However, I'm a little bit concerned about how the game logic processes the player movement. If you look at the .lua files, player movement is split into two parts: love.update(dt) checks whether a specific key is pressed, but love.keypressed(key) is also processing the W key---giving the player a little bit of a "jump" velocity.

I was under the impression that it's best to keep player movement uniform in a single update() function. Especially since my next goal would be to process player movement using a finite state machine---something that I've read about here: http://gameprogrammingpatterns.com/state.html

This is where I'm currently finding myself at a loss. My first idea would be to use love.keypressed() to change the player stage, e.g. like this:

Code: Select all

function love.keypressed(key)
    if key == "a" then
        player.state = "WALKING_LEFT"
    elseif key == "a" then
        player.state = "WALKING_RIGHT"
    elseif key == "w" then
        player.state = "JUMPING"
    else
        player.state = "STANDING"
    end
end

And using love.keyreleased() in a similar manner, for instance to set the player state to "FALLING" (meaning that the player cannot jump during this time until he touches the ground again):

Code: Select all

function love.keyreleased(key)
    if key == "w" and player.isJumpingOrFlying then
        player.state = "FALLING"
    end
end

The player:update(dt) function could then look something like (this time in pseudo-code):

Code: Select all

if player.state == "STANDING" then
    goto STANDING
end

if player.state == "WALKING_LEFT" then
    goto WALKING_LEFT
end

if player.state == "WALKING_RIGHT" then
    goto WALKING_RIGHT
end

if player.state == "JUMPING" then
    goto JUMPING
end

::STANDING::
    applyFriction()
    goto END_MOVEMENT

::WALKING_LEFT::
    player.vx = player.vx - player.movementSpeed
    goto END_MOVEMENT

::WALKING_RIGHT::
    player.vx = player.vx + player.movementSpeed
    goto END_MOVEMENT

::JUMPING::
    player.vy = player.vy + player.jumpVelocity
    goto END_MOVEMENT

::END_MOVEMENT::
    if checkIfNoCollisions() then
        player.left = player.vx
        player.top = player.vy
    end

I'm using goto and labels here because of another pattern that I've found in "Programming in Lua" (something about State Machines being easy to implement using goto).

However, I find it terribly hard to reconcile this state machine with all the booleans the game has to check if it wants to allow the player to jump, or allowing movement while jumping (e.g. jumping to the right in an arc-like shape).

That's why I wanted to ask here first if you think that there's a better approach to this. If I shouldn't use a FSM---do you think it's alright to have movement logic both in love.update() and love.keypressed()?

[ArchAngel075]

Iremember implementing player states like "Walking" etc in the past using the vector of player movement.

Take positive X linear velocity as right, and Positive Y as upwards

If you check X > 0 then "MovementRight"
If you check X < 0 then "MovementLeft"
If you check Y > 0 then "MovementUp"
If you check Y > 0 then "MovementDown"

This also lets you use a physics system, either self made or using Love.physics (what i used)

Also if using Love Physics, for contact checking on ground, use the contact object from the world callbacks and get its normal, if the normal is above 0 then it ontop of platform, if its negative its below (or reversed, i cant test now atm)

The method worked amazingly well for a small platformer setup i made awhile back(when i was fiddling with multi-player)


Ive never used a state engine in the past i believe, so im not sure i ca assist regarding question about using finite states...

[s-ol]

Iremember implementing player states like "Walking" etc in the past using the vector of player movement.

Take positive X linear velocity as right, and Positive Y as upwards

If you check X > 0 then "MovementRight"
If you check X < 0 then "MovementLeft"
If you check Y > 0 then "MovementUp"
If you check Y > 0 then "MovementDown"

This also lets you use a physics system, either self made or using Love.physics (what i used)

Also if using Love Physics, for contact checking on ground, use the contact object from the world callbacks and get its normal, if the normal is above 0 then it ontop of platform, if its negative its below (or reversed, i cant test now atm)

The method worked amazingly well for a small platformer setup i made awhile back(when i was fiddling with multi-player)


Ive never used a state engine in the past i believe, so im not sure i ca assist regarding question about using finite states...

From the code he posted, OP is not going to use a physics engine; his states are more like "input states" and he wants a FSM, not how to figure out which way you are moving.

@OP: First of all, I would never use gotos because they tear your code apart and basically make a mess. What I have used in the past was a setup like this:

Code: Select all

function player:update(dt)
  if self.state == "jumping" then
    self:updateJump(dt)
  elseif self.state == "falling" then
    self:updateFalling(dt)
   else
     self:updateRunning(dt)
   end
   self.x, self.y = self.x + self.vx*dt, self.y + self.vy*dt
end

player:updateRunning(dt)
  local xaccel = 0
  if love.keyboard.isDown("a") then
    xaccel = xaccel - PLYR_ACCEL
  end -- intentionally no elseif here so they cancel each other out
  if love.keyboard.isDown("d") then
    xaccel = xaccel + PLYR_ACCEL
  end
  self.xvel = self.xvel + xaccel*dt
end
-- etc.

[Sosolol261]

I looked through your code and I think, this could possibly help you.

Code: Select all

-- in love.keypressed()

    if key == 'f1' then
        if DEBUG then
            DEBUG = false
        else
            DEBUG = true
        end
    end

[Jasoco]

This will help even more compactly

Code: Select all

if key == "f1" then
    DEBUG = not DEBUG
end

[Sosolol261]

Code: Select all

if key == "f1" then
    DEBUG = not DEBUG
end

wow.. unbelievable how I NEVER thought of that...

[nfey]

Regarding this little snippet and others like it:

Code: Select all

if key == "a" then
        player.state = "WALKING_LEFT"

The idea of using a FSM is to have all the conditional logic encapsulated inside the machine and invisible to the outside modules. The FSM will know how the different states work and what the transitions between them are. In order for this to work, you need to let the machine hold it's state and decide when to change it. Your input to the FSM should not be

Code: Select all

machine.state = NEW_STATE

but rather

Code: Select all

machine.execute(ACTION)

and then let the machine decide, based on it's current state and action entered, if a transition is possible and how to go about with executing it.

Just nitpicking on your original code, but I think it's an important detail to keep in mind if you want to obtain well organized code.

[s-ol]

Regarding this little snippet and others like it:

Code: Select all

if key == "a" then
        player.state = "WALKING_LEFT"

The idea of using a FSM is to have all the conditional logic encapsulated inside the machine and invisible to the outside modules. The FSM will know how the different states work and what the tranzitions between them are. In order for this to work, you need to let the machine hold it's state and decide when to change it. Your input to the FSM should not be

Code: Select all

machine.state = NEW_STATE

but rather

Code: Select all

machine.execute(ACTION)

and then let the machine decide, based on it's current state and action entered, if a tranzition is possible and how to go about with executing it.

Just nitpicking on your original code, but I think it's an important detail to keep in mind if you want to obtain well organized code.

That's basically like my example (except I didn't encapsulate it away in another "machine" object, the player object is the FSM).

Also your states are way too specific, they are what you would draw in theory for a FSM, but in programming we have much more optuons, and a vanilla FSM is just wasting stuff here (WALK_LEFT and WALK_RIGHT can very easibly be one state).

[nfey]

That's basically like my example (except I didn't encapsulate it away in another "machine" object, the player object is the FSM).

Yes, it is, I just wanted to explain why it should look like that.
Also, I know you put the FSM logic inside the player class just for convenience, for this example, but it might be a good idea to stress that the FSM should be a separate class. Mostly because the player will probably also need to fire weapons, interact with the environment, manage an inventory, etc. - it's best to have specialised classes to take care of these actions or the player class will become a mess.

[Eroica]

Hi, thanks for all your replies so far. I guess my original post was a little bit cluttered because it basically asked two things separately---how best to implement a finite state machine, and how best to split up movement logic in love.update(dt) and love.keypressed(key).

Regarding the FSM:

Regarding this little snippet and others like it:

Code: Select all

if key == "a" then
        player.state = "WALKING_LEFT"

The idea of using a FSM is to have all the conditional logic encapsulated inside the machine and invisible to the outside modules. The FSM will know how the different states work and what the transitions between them are. In order for this to work, you need to let the machine hold it's state and decide when to change it. Your input to the FSM should not be

Code: Select all

machine.state = NEW_STATE

but rather

Code: Select all

machine.execute(ACTION)

and then let the machine decide, based on it's current state and action entered, if a transition is possible and how to go about with executing it.

Just nitpicking on your original code, but I think it's an important detail to keep in mind if you want to obtain well organized code.

This seems clear to me, I'll try to implement movement this way and let you guys know. By the way, you were right that player movement is currently in player = {} out of convienience---in the original code I'm already using an entity component system in which a "playerUpdateSystem" (in a manner of speaking) updates the player's position, a "playerDrawSystem" draws the sprite, etc.

If I understand you correctly, a system like those should fire an "ACTION" based on which key was pressed, and update the player's state in its methods. Which brings me to my other point: Is there any inconvenience in having "key-press logic" both in love.update() and love.keypressed()?

I hope I don't sound too confusing with this, perhaps I'm still lacking the "a-ha!" moment before I see all of this clearly. Nevertheless, I'm already happy that you had the patience to look over my code and improve it (thanks for the DEBUG hint too, by the way!). If there is anything else that you think might help me, feel free to correct me.