I don't know if this is #Indie_Game_Impressive anymore, but for a long time a lot of pixel platformers made by small devs would not include slopes in their game. Often citing how difficult it is. With the advent of more modern code bases, tutorials, and example projects I don't know how true that is anymore. Regardless, they're actually pretty easy to do. Folks were just trying to be too clever with them.
Essentially all you do is check if there's collision by the bottom of your character and not one pixel up and over when moving up a slope, and basically the opposite when moving down. No clue how to do that in 3D games, but I don't make those!
There is a fun little quirk of doing it this way and that's that the character kinda "magnetizes" to the slope. This is only really obvious when jumping on to a steep downward slope. This method also only works for things that are a single pixel tall. If it were two or more pixels than it would treat that like a wall. Fine here, of course.
Here's the code:
// Horizontal
repeat( abs(hspd_new) ) {
// Slopes:
// Floor UP:
if( place_meeting(x+h_dir,y, collision_object) && !place_meeting(x+h_dir,y-1, collision_object) ){
y--;
}
// Floor DOWN:
if( !place_meeting(x+h_dir,y+1, collision_object) && place_meeting(x+h_dir,y+2, collision_object) ){
y++;
}
// Move X:
if( !place_meeting(x+h_dir,y, collision_object ) ) {
x += h_dir;
}
else {
hspd_previous = hspd;
hspd = 0;
break;
}
}
Notice it's in the horizontal section of the movement code and there's only code for when on the ground/floor. Hitting a sloped ceiling doesn't make the character move along the slope at all. I didn't think that would make a lot of sense for the physics of my game, also it could cause issues where the character gets stuck in the ground.
