Similar Posts

6 Comments

  1. Great tutorial! Instead of setting the moving platform’s x/y velocity in the instance’s creation code inside the room editor, you could set it in the “variables” menu.

    You can define an object’s “variables” in the object editor, then overwrite those values in the room editor per instance.

    1. You’ll need to remove their declaration inside of platformer_init(), though, because it seems like the Create event runs after variables are assigned. Or, write the code so the velocity variables are only set if they don’t already exist, using something like:

      /// platformer_init()
      if !variable_instance_exists(id, “x_velocity”) {
      x_velocity = 0;
      }
      if !variable_instance_exists(id, “y_velocity”) {
      y_velocity = 0;
      }
      x_velocity_fraction = 0;
      y_velocity_fraction = 0;
      x_velocity_int = 0; // Integer x speed
      y_velocity_int = 0; // Integer y speed

      1. Yep! I don’t use the variables GUI panel at all but I guess some might be more comfortable using it. I prefer to have init code in the create event and override vars in the creation code only because of habit, I guess, but it could be done 🙂

  2. Hi Nikles!

    Great tutorial, pretty neat ‘clean code’ vibes there 🙂
    Just one thing (of course) :3

    After I implemented your project to mine (because I had problems with moving platforms) and started using ‘normal’ sprites, I found out, that the movement in either directions are a little shaky. If I start to use whole numbers for velocities, the movement becomes smooth, so that was an easy fix to it, but I can’t use a whole number for gravity :/ So every time I jump with my character, there is a little bit of shakiness. Any thought about that? 🙂 Thank you, and for your cool tuts!

  3. Great tutorial, I confess that initially I don’t like to use objects as a collision source, I think it is better to leave this task for the tilemaps to do it, but I have to admit that their method seems more stable and less subject to small bugs that always happen.

    Congratulations,

    I’m trying to adapt to the standard. but I still have resistance

    1. Thank you! Overall, tilemap collisions should indeed be faster (less overhead in running lots of objects). Of course moving platforms really are objects with their own behavior and they need their own events to run and react correctly. Maybe one could try and mix some tile collisions (e.g. for static walls and slopes) with some object collision (e.g. moving platforms). Personally, I tried and failed; I gave up and once I started using object collisions for everything, I found it to be pretty versatile. Using less, bigger objects can boost performance as well (or I guess out-of-view collision objects could be disabled).

      Having said that, there is no standard way of doing things. As long as it does what one intended it to do, it just works.

      Btw if you find any other interesting method you feel like sharing, I’m always willing to learn new things 🙂

      PS Sometimes I draw collisions with tiles in my room editor. Once the room starts, I spawn collision objects where collision tiles are, then simplify/merge collision objects with adjacent ones, then hide all the collision layers. So I still draw with tiles in the GMS room editor (it’s faster), and then use object collision at runtime.

Leave a Reply

Your email address will not be published.

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