[SOLVED]: Retro pixel-quantized platform engine using loops

EDIT: DONE! This is a working engine. Huge thanks to Magistross retrodude and newt

Features:

* Always integer pixel positions

* Always fall down when trying to cross a gap of equal width to the player, at any horizontal speed

* Jumpthrough platforms

* loop-based movement

* framerate independent (takes dt into account)

* controllable speed (no acceleration, on/off)

* collision detection with walls

_______________

Original Post:

So I revisited this ( https://www.scirra.com/forum/viewtopic.php?f=147&t=81757). It's a very old-school platform engine suitable for pixel games, that moves the player one pixel at a time using loops, always integer positions (unlike the built-in platform behavior). The player can fit inside gaps that are the same size as itself without horizontal or vertical wiggle room.

One thing I haven't been able to fix is falling through gaps when moving. If player.horizontalSpeed is high enough, player never registers the gap under its feet.

I could try to solve this by using R0J0hound 's solution https://www.scirra.com/forum/how-do-i-fall-between-blocks_t125214?&hilit=platform+gaps, since horizontal walls work flawlessly with this engine.

However I wonder if it can be solved another way, since there's already a loop in place. Anyone?

Here is the CAPX:

CAPX

Well, I think you're making it harder than it needs to be.

For one, what about using the custom movement behavior and just working with integer values?

Then, about the gap issue, I'd use an FSM to solve it

if (player.state === "running")

--- move him on the x axis first and push him out of solids to the nearest available position.

--- then check if he's on the ground to determine whether or not the character should go to the falling state

Or you can use a collider that's a bit longer than the character and that you use for collisions when the player is running.

In any case, even if you shouldn't use the official platform behavior, there's a nice plugin available on the forums (platform + i think) as well as the custom movement behavior to do the job.

Good luck!

Valerien I'm trying that right now Thank you!

I modified the capx a bit. Unified the loop, and added an event to force the y movement to happen if the player is moving horizontally while "floating".

Magistross again, pure genius. Thank you! I couldn't see where to place that condition for the y axis.

Ok, this is a pretty robust engine for games like Bubble Bobble, Rick Dangerous and the like. I'm calling it done.

Valerien I tried with the custom movement. Try as I might, I can't get it to increment by integer amounts of pixels. It always has a floating point. Can you get it to behave? The only way I know how is to control XY position using loops.

The loops first had to be unified, that's why you couldn't see it !

When I grow up I want to be just as math-savvy as you

Magistross When I grow up I want to be just as math-savvy as you

Playtesting this, I see it doesn't play well with tight corners, damn.

Here I'm trying to go left past the gap, but it won't let me. Any idea how to fix this?

I mean it's pretty much done, and I could make the player 1 pixel shorter, but this is theoretical curiosity for me now.

Sounds like what your engine needs is edge nudging,

a kind of "behind the scenes help".

its pretty much because the player is falling at such a speed where one frame he is above the hole and the next he is below the hole a solid (the left wall in that instance) is always colliding with the player.

you need to check when ever the player is not on the ground and wall is to left or right is there an open space or closed space and if open "boost" (or move) the player into that open space. i do it with the built in platform behavior all the time. it pretty much just checks on grid the game is built on (normaly 16x16 if pixel art) one above one below the player -8 as the speed i had was the player would fall past at a speed that made him only ever infront of the opening and half the grid height. if the check returned an open tile the player would move into it i also had a variable to ensure it only happened once per jump (would have to land on the floor again before it reset and would "boost" the player again) to not let the player know this was happening.

Ledge forgiveness is the same, in pixel games the characters sometimes move faster than the grid lines up making the player think they pressed jump when they were on the floor but in reality the player moved so fast they pressed it after the player left the platform but had yet to begin decent. in this instance i would have events in place to still have the jump action performed so the player would not feel like "this game is cheap and just didn't let me jump"

so while the engine is good, extra things can go in to help it. if i get time later i can try and look at the capx and see if i can add edge nudging.

Try removing the "player: Set xLoopIndex to 0 " on line 21. It seems to do the trick... most of the time :\</p>

Magistross :S hmm not with smaller xSpeed values. I may have to rethink this, damn

BACLog sounds interesting! I'm not sure how to implement this in the engine's current form

Fixed this by making the player's bounding box shorter and adding a head collider, so you can't jump and wiggle if you have a wall right above your head

Here's the CAPX

christina : ah true! I thought you could - well, I haven't been using c2 for a while, sorry

No problem — Loops seem the only way to get C2 to do what we need for a proper retro engine.

It's ready!! Please playtest it and tell me what you think. I added jump-through platforms, and everything is behaving great! Ashley a RetroPlatform behavior like this would really serve everyone who tries to work in low resolutions and doesn't need slope detection but does need super-tight retro platformer controls.

CAPX

christina isn't it framerate dependent though? You can create super tight controls with floating point values as well, and use pixel rounding to only render at integer positions. All in all, we're only speaking of an error margin of +/- 0.5 px. I don't see a case where you'd absolutely need corridors that are of the exact size of the character's collider. And I highly doubt that any modern pixel art game uses such an approach - raycasting, captors or C2's collision polys work just very well.

No offense meant though, you achieved a nice demo! Congrats