Even better (high speed) moving platforms

(Probably) Not compatible with GameMaker Studio 2.3

The following article is for pre 2.3 versions of GameMaker Studio. It doesn’t take advantage (and it’s probably incompatible) with functions, chained accessors and other new features of GML/GMS2.3 IDE. An updated series is already in the works 🙂

There’s an oversight in my previous article (i.e. there’s a bug) where if you increase the xvel or yvel of the moving platforms above 1, strange things start to happen. Let’s fix high speed moving platforms.

Increasing the platform’s speed will cause bugs.

Why is this happening

This is happening because, as I said in the article, xprevious and yprevious get automatically set before the begin step event and they get set just once, never to be updated with the new positions we give to the players during the platform’s moving cycle.

So if the platform is cycling 10 times to move upward (yvel = -10, cycling pixel by pixel) and it stops right after the 5th cycle iteration (due to a collision like in the image above), it resets the players position back to where they were at the very beginning of the cycle, even if they successfully moved for 5 whole cycles, effectively putting the instances back inside the platform itself.

That’s because we forgot to update the xprevious and yprevious upon each successful movement cycle completion.

How to fix it

Let’s create a simple script called instances_update_previous_position, very similar to instances_reset_position.

///@func instances_update_previous_position(instances_to_move)

var instances_to_move    = argument[0]
var num_of_instances     = ds_list_size(instances_to_move)
var index                = 0

repeat(num_of_instances)
{
    var instance              = instances_to_move[| index]
    instance.xprevious        = instance.x
    instance.yprevious        = instance.y
    index++
}

This script accepts a list and it cycles the list to update the xprevious and yprevious variable.

Now inside the move_platform_y and move_platform_x scripts, just before destroying the ds lists, call this script passing a list of successfully moved objects. In our case we should already have one. It’s called instances_to_move but if you look into the code you’ll realize that, at this point in the code, it holds the instances that successfully moved. Instances for which we should update the xprevious and yprevious variables.

Bug fix for vertical moving platform
move_platform_y
Bug fix for horizontal moving platform
move_platform_x

This should really give us pixel perfect movement. If you find any other bug, please don’t hesitate to leave a comment. Thanks for your patience 🙂

Buy Me a Coffee at ko-fi.com

4 thoughts on “Even better (high speed) moving platforms”

  1. Good tutorial! I’ve modified the moving platform code to follow paths and move in a circular motion – I’m curious to see how you’d implement such cases. Where can you go from here with the series?

    Reply
    • Well you just gave me two interesting ideas to explore. I am still experimenting with moving blocks (pushables) but I’m not satisfied with the results so I’ll take a break from that topic and explore these circular/path following platforms instead. Then I guess it’s time to implement some input mapping, game mechanics, enemies, doors, pickups/powerups, world design, a proper camera, room transitions and more. I’ll probably start to use some graphics as well (very soon indeed). I know this doesn’t sound like a plan, but I want to make a simple action/adventure platformer people can use as a base to build their own games from. Nothing really complex but I’d love to give it a polished feel with menus and so on. Sounds cool?

      Reply
      • No worries, the least I could give. You’ve done the majority of the hard work needed for the base of a platformer so everything on top of this is just a bonus really. I look forward to seeing where you’re going with all this

        Reply

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.