Some basic skeleton mapping

Just in time for Halloween, 3spoopy.

Used in many games, skeleton mapping (also like to call it ghost mapping) is the idea of giving properties to blocks that are otherwise normal.

Here’s an example of Super Metroid. The triangles allow you to walk up hills, red blocks can be destroyed, some blocks have different heights, some can be jumped through, not all of these are shown in the image.

hqdefault (1)-1

Although you can see these blocks when editing the game, in the final release, they are all onced 0 alpha, and can only be seen in debug.

In this short example, you will be misdirected through fake walls, fake ground, hills, wind, and passable ground. I was going to make red blocks trigger the block behind to be destroyed, but they can’t seem to proximity each other and crash the screen white. I don’t know why. I’ll look into it. For now, try it out. Get through the level with the debug on, then when you get to the end, redo it with the debug off, and see if you can remember where the collisions were.

http://flowlab.io/game/play/742026

3spooky5me

cool demo - when I have a few minutes I want to figure out how you did the blocks that can pass through from underneath :slight_smile:

@grazer

I though of a solution for making a triangular hitbox.

Because A^2(the base)+B^2(the side)=C^2(the diagonal line)

^Pythagorean theorem

You can create two lines at the bottom and a side (adapted to the sprite) then use my equation above to get the diagnol lines length (rounded to the nearest pixel) then rotated and placed to connect the base and side

An alternative:
The equation
Y=MX+B
M= the rate at which Y goes up (determines the angle, and is an independent variable)

X= the X axis, is a independent variable

Y= where the pixel should be located, as far as the Y axis is concerned. Is the dependent variable

B= the Y intercept, or what Y is when X is 0. (Is determined by where the bottom corner of the sprite is)

Take the top leftmost pixel (or rightmost) and record it… say… ( 30, 30)

Take the bottom rightmost pixel,
Say… (2, 2)

The slope, or M, would be 1, because

2/30 - 2/30 is 1/1… which is 1,

So now

Y= 1x+b

Because the lowermost corner is 2,2, we pay attention to the Y intercept, or B. B would be 0, in this case, because 2-2 is 0… (Im not entirely sure on this part…)

So now every time X increases by 1, Y increases by 1 too…

So now Y = 1X + 0

Simplified: Y = X

Actually you may need both,

Y = MB+B for deciding the angle at which it is drawn, and A^2+B^2=C^2 for deciding the length at which it is drawn

@“Mhx Ar” do you think my hypothesis on this may work?

@grazer
After a few hours of messing around, I found that y position - proximity actually changes depending on gravity. I found the number 16 was the number for under collision while using 35 gravity. -15 and -16 are the above numbers, changing depending on how you land.

Filtering =16 to on a switch and up to in, will do an ease from -20 pixels to 3 pixels position in a very short time frame, so you appear to jump through and land while holding up. You can press down to clip underneath 20 pixels, and because the player is 32x32, the clipping give the illusion of slipping off instead of teleporting. If I use a jump and drop animation with these frames, it will seamlessly blend in for Shifter. Since Shifter won’t use gravity, I’ll have to figure out what numbers to filter instead.

Also, I forgot to mention that I had to fix jumping. The run and jump behavior allows all directions, so I set it to bottom only. Using proximity, it doesn’t detect a collision, so you can’t jump again after letting go of up. I removed up to off, and looped impulse out back to off, and I set proximity y out to turn jump back on, so you can jump again after clipping.

@CrimsonBlackGames grazer did a poll last year for what people wanted most, and PC app exporter won. I wanted triangles and more layers. Those were the other options. grazer probably already had a plan for how to make them, but nobody seemed interested, so he didn’t. I’d love to have slopes. Doing it my way works, but sucks.

Yeah…

I feel like triangular hitboxes are really important, and the addition of them (along with a hitbox editor) would be pretty cool too…

Hitbox edit is desperately needed for crouching

Added fully functioning angled hills!
Thanks to the suggestion from @CrimsonBlackGames on rotation, single pixel lines can be angled to connect blocks, and used to make any shaped hills or angles that you desire. You can even make interesting tubes and you fit right through them, no dragging or clipping. No more waiting for @grazer to make triangle collisions, now you can do it all yourself! Give them alpha 0 or hide them underneath nonsolid hill shaped objects. Try it out here:

Just walk left off screen to teleport to the ramp area.
http://flowlab.io/game/play/742026
a

1 Like

Uhhhh nice

@PixelPizza it doesn’t look like much, but theoretically I could make hills and loops as smooth as a Sonic game, and use forward velocity instead of x so holding right or left with proximity to hill angle rotation will let me continuously run on any hill regardless of the angle or loop. I have more testing to do, but it should work.

1 Like

@“Mhx Ar”

I might be on fire as far as the ideas go.

Why not make all of the angled blocks emit the hitboxed lines- and said lines move themselves to align properly. This way mapping would be twice as fast and less tedious

Well for one, I don’t trust emit. Also, mass emits might lag. Emits may also not spawn off screen.

Worth a shot.