Moving Platforms - Horizontal and Vertical ⋆ Nikles dabbling in Game Dev (2024)

I’ve seen a lot of bad implementations of moving platforms in GameMaker Studio, especially the vertical moving platforms. Some rely on the fact that, due to gravity, the player will naturally follow a downward moving platform (which is odd, and wrong), whilst others don’t even try to explain the vertical moving platforms at all. Like they don’t exist.

I’m not sure what’s going on here. Maybe my code is super naive and I’m not doing it right either, but moving platforms don’t have to be difficult. They’re objects that live in the begin_step event; they do their collision checks, they can push or carry other objects (or squish them or whatever you decide) and… and that’s it, really.

The player will naturally collide with these platforms but only in the step event, when the platforms have already completed their movements so there won’t be any odd behavior. To entities, moving platforms are… not really moving at all. I’d say that entities are, to moving platforms, also not moving at all. Remember that they live in two separate events.

///@func platformer_init()xvel= 0yvel= 0xvel_int= 0 // Integer x speedyvel_int= 0 // Integer y speedxvel_fract = 0yvel_fract = 0

Also open the oPlayer object and slightly alter the movement lines in the step event to accommodate these changes.

// Use the xvel_int hereif !move_x(xvel_int, true){ xvel = 0 xvel_fract = 0}// Use the yvel_int hereif !move_y(yvel_int){ yvel = 0 yvel_fract = 0}

There’s one last piece of code I need to alter: round_vel()

///@func round_vel()///@desc Round the xvel/yvel while keeping track of fractionsxvel_fract += xvel;xvel_int = floor(xvel_fract); // use xvel_int herexvel_fract -= xvel_int; // and hereyvel_fract += yvel;yvel_int = floor(yvel_fract); // Use yvel_int hereyvel_fract -= yvel_int; // and here

Other than using the new variables, I decided to go with flooring, instead of rounding. It should work either way but I prefer to know we always round down the velocities.

I’ve introduced a couple of new scripts to avoid having to write collision checks over and over. Let’s see how they work. Passing a direction, will automatically select the correct side to check. Also the obj parameter is optional.

///@func coll_x(xdir, [obj])var xdir = argument[0]var obj = argument_count == 2 ? argument[1] : oWallvar side_to_check = xdir ? bbox_right + 1 : bbox_left - 1return collision_rectangle(side_to_check, bbox_top, side_to_check, bbox_bottom, obj, false, true)

///@func coll_y(ydir, [obj])var ydir = argument[0]var obj = argument_count == 2 ? argument[1] : oWallvar side_to_check = ydir ? bbox_bottom + 1 : bbox_top - 1return collision_rectangle(bbox_left, side_to_check, bbox_right, side_to_check, obj, false, true)

Now let’s see what happens when we begin to move the moving platforms. Spoiler alert: they do not collide with the player.

Open the create event of the oMoving platforms and initialize the platformer by calling platformer_init(). Then open the begin step event and place the movement code inside it.

/// @desc moveround_vel()// Let the instance decide what to do when it can't moveif !move_x(xvel_int, false){ xvel = -xvel // Reverse the speed in case of collision xvel_fract = 0}if !move_y(yvel_int){ yvel = -yvel // Reverse the speed in case of collision yvel_fract = 0}

This is the very same code we have inside the oPlayer object slightly altered to let the moving platforms invert their speed when colliding with walls. Now, for the moving platforms to actually move we need to define an initial speed. We can do so in the room editor with the creation code.

If you run the game now, you end up with this. Disappointed? That’s exactly the result we expected though.

This is what might get some people confused. It’s true that the player cannot go inside the platforms but the platforms can go inside the player. While the player’s collisions are already set correctly (since the moving platforms are children of oWall), the oMoving platforms need some more work.

We can’t use the same movement and collision code that we use in the oPlayer object. Indeed those scripts don’t take into account collisions with the oPlayer itself (of course) so to the moving platforms, there is no collision at all. We need to define movement and collision detection specific for the moving platforms.

/// @desc moveround_vel()if !move_platform_x(xvel_int){ xvel = -xvel xvel_fract = 0}if !move_platform_y(yvel_int){ yvel = -yvel yvel_fract = 0}

The collision from the sides may return false in case the player cannot move at all (e.g. squashed between a moving platform and a solid). Here is where you decide what to do in your game (I just return false and let the platform reverse its speed but you might as well kill the player). It’s also where the MacOS crashes, btw.

The collision with the player standing on the platform, on the other hand, does not return anything. This is because the platform doesn’t care about the player being unable to move. It will simply slide off its feet and continue its movement.

///@func move_platform_x(xvel_int)///@arg xvelvar _xvel = argument[0]var _xdir = sign(_xvel)// Movement/Collision Xrepeat(abs(_xvel)){ // Colliding with solid if coll_x(_xdir) return false // Pushing the player var player_on_sides = coll_x(_xdir, oPlayer) if player_on_sides && false == move_x(_xdir, true, player_on_sides) return false // Squashed between solids // Carrying the player // Notice how we don't care if the player // can't move in this case. The underlying platform will // simply slide off its feet (hence we don't return false) var player_on_top = coll_y(-1, oPlayer) if player_on_top move_x(_xdir, false, player_on_top) // Finally move x += _xdir}return true

The following script is for vertical movement instead. If the platform is going upward, in case of player collision, we simply try to push it upward as well. No big deal. As usual we return false if the player is stuck (or you might kill it). Note: this is where the macOS crashes.

Here comes what might confuse someone. If we’re going downward, we move the player downward as well via its own move_y script. But if we’re carrying it on top of the platform, we need deactivate the platform during player’s collision checking.

If we don’t do this, the player would collide with the very platform that is trying to move it, before being able to move downward. This collision will leave the player behind in mid-air, making it bounce on the platform on its way down. That’s why we deactivate and reactivate the moving platform really quickly, just to remove the instance from the possible collisions.

It’s like saying “Not considering this very platform, try moving the player down 1px”.

///@func move_platform_y(yvel_int)///@arg yvelvar _yvel = argument[0]var _ydir = sign(_yvel)repeat(abs(_yvel)){ // Colliding with solid if coll_y(_ydir) return false // Going upward if !_ydir { // Carry the player upward (lift it) var player_above = coll_y(_ydir, oPlayer) if player_above && false == move_y(_ydir, player_above) return false } // Going downward if _ydir { // Push the player downward if it's colliding from below var player_below = coll_y(_ydir, oPlayer) if player_below && false == move_y(_ydir, player_below) return false // Carry the player downward with the platform if it's standing on top of the platform var player_above = coll_y(-1, oPlayer) instance_deactivate_object(self) // Dirty trick begins if player_above move_y(_ydir, player_above) instance_activate_object(self) // Dirty trick ends } // If everything went good, move y += _ydir}return true

And just like that, believe it or not, the moving platforms are done. There’s nothing else to do to have horizontal and vertical moving platforms capable of carrying and pushing the player around without odd, jerky movements.

If you are curious about more advanced platforms, able to carry more than one item, simply stay tuned for the next iteration about advanced moving platforms.