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
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.
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;
}
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: