• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

Best way to make line segment platform collisions?

I put this in Game Design since I can probably figure out how to code this myself once I wrap my head around the concept, it's just extremely confusing to figure out.

From my studying, modern 2D platformers such as Sonic Rush and New Super Mario Bros. Wii do not use pixel based bitmasks for collision; they use vector line segments and polygons instead.
The idea seems to be that the player character objects have a single pixel that "attaches" itself to a vector line segment when you land on one. You move along the line segment until you have passed one of the edges, in which case you "attach" to the next line segment if there is one, and fall off if there isn't. In the case of ledges (which are always completely flat), there's always a special ledge floor that the player has a longer ledge collider for, so they can stand farther out on the ledge.

On top of that, the player objects typically have line sensors that check for walls (which are just line segments at a steep angle) and push you out of them.

Somehow, they also combine this system with tiles, and I have no idea how that even works.


I made some progress with it but I just need some help trying to figure out the best way to do this?
 

Attachments

D

dannyjenn

Guest
I'm bumping this. Anyone have any thoughts?

I tried doing something like this in the past (mixing lines segments with tiles), but I gave up on it because it was having problems and I figured tilemaps were just an overall better way of doing it. But maybe I'll need to try it again now that I'm a little more experienced.
 
Last edited by a moderator:
If you want a line collision:

collision_line( x1, y1, x2, y2, obectj, precision, notme );

As for that specific example you're citing with lots of angles, you probably want to do a 90 degree like collision in front of the player where it does the collision_line several times say 10 times starting at the lowest point and going to the highest. Someone else can write the pseudo code for that.

The sprite itself is a rectangle, but its drawn as what the player sees. With 3D games its just a round cylinder. So Mario's sprite is a square, but what's drawn is Mario.
 
I actually found a breakthrough as far as how the tiles work in these games.

I was looking at some code in NSMB DS and it turns out each tile has four corner points with heights you can set for each, and I believe checking for tile collisions just involves running a rectangle check with flat ground or a triangle check with a slope. You would just use the tile's corners (and their set heights) to check, either way.
I believe Sonic Rush uses the same idea, since there's a test level buried in the game with extremely similar 8*8 collision tiles that are pieced together to form 64*64 "metatiles" that make up each level.



The curved slope tiles at the bottom actually don't have round arcs at all, they use the same idea of triangles made of corner points. This is actually easily observable when not boosting (or in Sonic 4 which uses the same engine).
If you want a line collision:

collision_line( x1, y1, x2, y2, obectj, precision, notme );

As for that specific example you're citing with lots of angles, you probably want to do a 90 degree like collision in front of the player where it does the collision_line several times say 10 times starting at the lowest point and going to the highest. Someone else can write the pseudo code for that.

The sprite itself is a rectangle, but its drawn as what the player sees. With 3D games its just a round cylinder. So Mario's sprite is a square, but what's drawn is Mario.
I might try that method. It'll have to be coded differently since I'm colliding with tiles with imaginary hitboxes and not sprite objects but I can still use the idea behind it.

Another method I thought of is to let the player move to the end of the tile, check for any tiles right next to it and attach to that one. Checking for upcoming walls might be a pain with this method though but I could figure something out maybe?
 
D

dannyjenn

Guest
What I did in my past attempt was I came up with a piecewise function representing the top of the ground (flat areas were simply y=b and slopes were y=mx+b) and a second piecewise function representing the bottom of the ground (allowing for platforms and caves and stuff), and then when I wanted to check whether the player was colliding with the ground I would plug his x into both ground functions and check whether the first result was less than his y and the second result was greater than his y. Same for walls except sideways, plugging in the y and checking the x. (Or I suppose you could do them the exact same way as the ground, with y=mx+b, but just with a very high number for m...) This way seemed to work, but I gave up on it before I perfected it.
 
Top