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 PLATFORMER 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. value depends on the size of the sprite.The following code will probably break on MacOS. _offset = 15 //moves the collision point away to check in front of the sprite. Something like this: // Horizontal collision Keep in mind that the origin point is at the center of it's collision mask, to avoid been stuck in a wall.ĮDIT: Another possibility: the collision point still checks inside the sprite.įor that, you could also try using an offset that keeps the collision point away from the sprite collision, but to let that work, you'll need to keep the inverse direction away from your horizontal speed. that way I've a visible view of the 'collision point'.Īnother cause could be the sprite's origin point, that determines at which position the x and y appears, and that the sprite by turning collides with the wall itself. When I face with collision problems, I'll use a crosshair sprite, and draw it at the same position as where it should be colliding. Is it turning back to the wall after a short while, or is it stuck and is flickering to left and right rapidly? Both could involve that the collision point isn't updating well.
0 kommentar(er)
