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
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. I'm aiming to write this mostly from scratch, but to save time a few native GML extensions are used.The following code will probably break on MacOS. When the game is complete - or complete-ish - whenever that happens - the major version number will change from 0 to 1 and any subsequent updates will continue from there. This means that the Week 1 project will be 0.1, Week 5 will be 0.5, Week 12 will be 0.12, etc. Each release has two numbers - a major and a minor version number - with each week being the minor version number. If you're following the series, I'm creating a release each week so that the state of the project at the end of a video can be marked. Individual tutorials are fun, but developing a game from start to finish is also fun. Bombadier - a 3D Tower Defense Game in GameMaker Studio 2.3