Rikifive

Well it turned out pretty anyway! :3

Yeah, thanks.

Oh I thought I might be missing something obvious and overcomplicating things, but now that you mention it this way, I suppose it is what it is. I know some old games had a simpler approach to slopes - by basically limiting them to only the ground, keeping all ceilings square - and also keeping enough of space in tight passages to avoid going up into the ceiling. That was like the limitation of level design. It was in Metroid or something...

That indeed saves all the hassle, as the problem arises when the character starts touching ground and ceiling at the same time. Some sorcery has to be put to prevent from getting stuck. Given how much extra code I need to cover the scenarios shown above, I'm wondering if it really will be needed. Perhaps I too, should just keep the minimum space between ground and ceiling, so that any of this wouldn't be needed. ..But well, since for now it all works, I'll leave it be and try to take advantage from it in level design. Should the game happen to be a bit too demanding for older hardware, I'll consider simplifying the logic.

These are tiles, that have a limited amount of slope shapes. Using only full block, 1:1 slopes, 2:1 slopes and 4-pixel-tall-step stairs. To make it work though, precise pixel based collision has to be put to work.

Well precise pixel based collision makes it much easier, at leas in some ways. I don't even know how to start if you do tile based stuff. I think the way I did it was to check each pixel from foot to head in the direction the player was moving and simply have a max number of pixels that could be moved up and if there was enough space to move up. Or something. Point was if you had a situation where the player was touching ground and ceiling at the same time it would basically treat it as a solid wall. Did have code to keep you ducking if you didn't have room to unduck but I don't remember if it ever ducked automatically otherwise.

Also, honestly, maybe it's just me but don't you think most of the time when code exists to unstick the player from inside a wall it's exploited in the wrong way?

Basically I have something like this. The stepping up while moving forward is what requires a bit more attention. I might continue toying with this to wrap it all better or something.

Yeah, speedrunners will always find fancy ways.  But I suppose it's better than just getting stuck and having to quit. Guess I prefer having someone abuse it and me patching it eventually, than someone complaining they keep getting stuck once in a while, losing progress and everything. There's no perfect solution for that, other than writing collision properly, so that there's no way to find yourself inside a wall in the first place. Until I get to this point, it's better to have something ready to handle this, to at least try to prevent from potential frustration.

So many bouncy stars!

Lots of bouncy things, and 'pew-pew-pew!' lolz

What no individually bound directions? What if someone wants to use some odd thing like okl; for directions? Yes okl; is a thing. I played a game that only had wasd and okl; as options the other day. Weird!

Listen, I ran out of budget, okay? Lmao I had to pick the movement bundle because it was cheaper. 

I actually recall a game with similar, if not the same movement keys you've mentioned. Hmm no idea what it was, but I think these were the keys for the second player? 

Well anyway, I hope this will suffice. Initially I planned to have like two presets for all actions and that's it, but while I was there, I just made it more customizable instead, as it required a similar amount of work. Though I kind of ran out of space in that window, so had to wrap movement into one setting containing presets. I don't really expect anyone to have different preferences than these two, but I can always add more movements layouts, should other keys be demanded.

Budget... Riiiiight.

I'm sure it will be fine. :3