• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

GML SOLVED: Organizing player states, avoid skipping a frame

Bentley

Member
I've been trying to organize player states and this is what I have. It's all in the Step Event in this order:

1. Run state scripts
2. Move and collide
3. Check for state changes.

So it would look something like this:

Step Event
Code:
// States
switch (state)
{
   case PSTATE.IDLE: script_execute(player_state_idle); break;
}

// Move and collide
repeat ( abs(vspd) )
{
   if (!place_meeting(x, y + sign(vspd), obj_solid) y += sign(vspd);
}

// State changes (that I want after movement and collision)
if (state == PSTATE.FALL)
{
   if ( place_meeting(x, y + 1, obj_ground) ) state = PSTATE.IDLE;
}
It does seem weird to check for state changes outside their respective state scripts. But I did it that way to avoid skipping a frame. Let's say I checked for the transition from falling to idle inside the fall state script, this is what would happen (I think):

I'd be in the fall state, the collision code would put me on the ground, and instead of setting the player to the idle state in that frame, he'd enter the next frame still in the fall state, and then, in the fall state, he'd change to idle. So it seems like a frame would be wasted in the fall state, when he should be idle.

Is it true that I'd be skipping a frame? Am I overthinking this? Are there much better ways to organize a player state machine?

Thanks for reading. Any advice is welcomed.
 
Last edited:

TheouAegis

Member
So only pstate.FALL will check for collisions below before changing to idle? No jump attack state or anything like that which could also require a landing code?

There is only one time when your landing code needs to run - when you have been in the fall state for at least one whole step. Your idle state will never need to transition to falling AND need to check for landing in the same step.

It's a valid concern, but superficial in most cases. It is mostly an issue with sprite changes and other pronounced visual changes.
 
Last edited:

Bentley

Member
So only pstate.FALL will check for collisions below before changing to idle? No jump attack state or anything like that which could also require a landing code?

There is only one time when your landing code needs to run - when you have been in the fall state for at least one whole step. Your idle state will never need to transition to falling AND need to check for landing in the same step.

It's a valid concern, but superficial in most cases. It is mostly an issue with sprite changes and other pronounced visual changes.
Thanks for the reply.
So only pstate.FALL will check for collisions below before changing to idle?
Yeah, I should have clarified. I was just using the above as an example (and not a very good one). You're absolutely right, normally I'd have multiple states that would be checking for the ground (like jump attacks).

Thanks again, SOLVED.
 
Top