Thinking with Slopes & Platforms

I recently tried my hand at making a platforming game using GameMaker: Studio because of how much its changed, gained popularity and apparently is much less restrictive since the last time I tried to use it back in the 2000s.

The first thing about making a platformer is to consider what you want to go for at a later stage. This is important, especially in studios like GameMaker which only provide the basics, since it helps a lot to have support for things down the line - like if you want something to be moddable you do away with some things you'd usually make constants and instead assign them to variables. Not hard but can be a bit finicky at times if you plan to do it for a lot of variables. Plus it avoids brute forcing a problem (which is almost always a bad idea down the line, or immediately), and helps to avoid every build having a patch note along the lines of *tweaked X* or *fixed bug/exploit regarding X* or *fixed ctd caused by X*
For example, in my case I decided pretty early on that I'd use some slightly awkward things for my soon to be platformer engine to handle - namely slopes and one-way platforms like the ones in Sonic. This means things taking into account checking for single pixels increases in elevation and acting accordingly for slopes, and just generally awkwardness for one-way platforms.

Slopes aren't too difficult for my pixel platformer - the concept runs as follows:

The box wishes to move one space/pixel to the right.
However, doing so would cause it to run into a one pixel high collision with a "wall", but is in actuality a ramp that box should be able to traverse.
However, if a successful checks shows that moving up a pixel would solve the issue, then as the box moves to the right, it also moves up. Otherwise it's a wall, or a ramp too steep for poor ol' box.
A similar concept can also be applied to moving down a slope without constantly falling - this is done by reversing the order that the checks are made:
  1. Box moves forward.
  2. There is no space below so ordinarily you'd put in something to make it begin falling (and play a falling animation).
  3. However in the case of a step or slope there is ground a pixel down. if the box checks for a grounded space below and finds that there is, then it is on a slope.
  4. The box, if on a slope, moves down to meet the ground without ever having truly left it.
So slopes weren't too hard to implement, but one-way platforms took a bit of imagination. Since the character is a box, you can't just say collide with platforms when falling and don't collide when rising (from a jump or whatever), since if you begin to fall halfway through a platform you get stuck. My solution (not necessarily the correct one mind you but it works for me) was to have another hitbox, but this one only being a single pixel thick whilst sharing the same width as the normal character hitbox. 

With this set up, you can allow the box to land on a platform when falling, but not get stuck trying to land in the middle of one.

No comments:

Post a Comment