Instance_activate_object(self) // Dirty trick endsĪnd just like that, believe it or not, the moving platforms are done. Instance_deactivate_object(self) // Dirty trick begins Carry the player downward with the platform if it's standing on top of the platform If player_below & false = move_y(_ydir, player_below) Var player_below = coll_y(_ydir, oPlayer) Push the player downward if it's colliding from below If player_above & false = move_y(_ydir, player_above) Var player_above = coll_y(_ydir, oPlayer) It’s like saying “ Not considering this very platform, try moving the player down 1px”. That’s why we deactivate and reactivate the moving platform really quickly, just to remove the instance from the possible collisions. This collision will leave the player behind in mid-air, making it bounce on the platform on its way down. 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. But if we’re carrying it on top of the platform, we need deactivate the platform during player’s collision checking. If we’re going downward, we move the player downward as well via its own move_y script. As usual we return false if the player is stuck (or you might kill it). If the platform is going upward, in case of player collision, we simply try to push it upward as well. The following script is for vertical movement instead. simply slide off its feet (hence we don't return false) Notice how we don't care if the player If player_on_sides & false = move_x(_xdir, true, player_on_sides) Var player_on_sides = coll_x(_xdir, oPlayer) It will simply slide off its feet and continue its movement. This is because the platform doesn’t care about the player being unable to move. The collision with the player standing on the platform, on the other hand, does not return anything. 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). squashed between a moving platform and a solid).
The collision from the sides may return false in case the player cannot move at all (e.g. It should work either way but I prefer to know we always round down the velocities. Other than using the new variables, I decided to go with flooring, instead of rounding. Yvel_int = floor(yvel_fract) // Use yvel_int here Xvel_int = floor(xvel_fract) // use xvel_int here
#Game maker studio 2 tutorial code
There’s one last piece of code I need to alter: round_vel() Round the xvel/yvel while keeping track of fractions Yvel_fract = 0 From now on we use this platformer_init script on our moving objectsĪlso open the oPlayer object and slightly alter the movement lines in the step event to accommodate these changes. 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, platformer_init() Maybe my code is super naive and I’m not doing it right either, but moving platforms don’t have to be difficult.
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.
I’ve seen a lot of bad implementations of moving platforms in GameMaker Studio, especially the vertical moving platforms. But to this date, I still haven’t found it.
It might very well be a sneaky bug in my code. I’m confident that YoYo will get back to me with some good news but in the meantime I’m publishing this article anyway… because this is how I make moving platforms ?♂️ If I had to make a wild guess, I’d say that the MacOS runner has some weird bug about nested context and recursion that makes it lose track of who’s doing what, eventually crashing without any warning. Along with YoYo Games we are currently investigating the culprit. The following code will probably break on MacOS.