Trying to figure out collision with tiles in platformer game

[waffleturtle]

Hello! I am new to Love2d and trying to make my first little platformer game.

I am trying to keep it somewhat simple so I am avoiding advanced 3rd party libraries and such for now to get a better basic understanding of concepts and such.

I figured I start with a 2d platformer and it is going well thus far. I have a player running and jumping around using x, y positions with velocities for both axises as well. Currently I have randomly generated tiles that I store in a table and draw onto the game canvas.

Now I am curious how I can get my player to collide with the tiles and stop moving. Most of what I can find seem to use physics libraries for this which I am trying to avoid for now.

I did find some things, like AABB collision detection. Though I am not certain what to do once I have detected a collision as I cannot seem to figure out how to push the player in the correct direction after intersecting a tile.

Does anyone have any good ideas/tips for me here?

[BrotSagtMist]

If you simply use tiles that is super easy:
if tiles[math.floor(x/tilesize)][math.floor(y/tilesize)] then print("collision")

Problematic is you either need to init all possible x positions in _tiles_ or put a meta table in it so you wont get a nil access error at the map edges.

Also the method for moving on tiles is to create a temporary position by applying the physic, then check for collisions and only apply it to the real position if it is not colliding so you dont get stuck in walls.

[waffleturtle]

Hey thanks for replying - I am not sure I am getting the idea though.

Would that work for like a platformer like Super Mario? Where does the player come into the collision calculation there?

Not sure if it matters but the tiles I have are stored in this format:

Code: Select all

tiles = {
	tile1 = {
	x
	y
	width
	height
	},
	tile2 = {
	x
	y
	width
	height
	},
	etc...
}

The idea was that I loop through them all and check against the player's position, who is currently 32x48 pixels, not sure if that complicates things...

[BrotSagtMist]

That is not a tile format.
You are NOT doing tiles.
Tiles use a grid, you are defining positions on the other hand.
Free positioning needs a physics lib.
This is a tile map:

Code: Select all

Map={
{1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,},
{0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2,0,},
{0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,},
{0,0,0,1,0,0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,},
{0,0,0,0,0,1,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,},

[waffleturtle]

I see - I should probably have said blocks instead. But are you sure a physics library is the only way? I am sticking to square shaped collisions if that makes it simpler.

[RNavega]

I posted these two articles in another thread, but the subject was different so I'll repost them here instead of linking there.
Tutorials on how to make tile maps and handling tile collisions:
- https://sheepolution.com/learn/book/18
- https://jonathanwhiting.com/tutorial/collision/

[BrotSagtMist]

If these are all quadratic blocks you can indeed Just check if your next physics step would be inside any of them.
This is just a simple range check after all.
But this will really struggle once you do have huge maps or many objects to jump on.
You can do a few clever precheck filters that throw out checks which are obvious, eg not in the screen or not near your char.
But if you scale up to a proper game this will be massively harder to code than just simple tiles.

[waffleturtle]

Thanks guys!

I will switch my idea so it follows a proper tile system for the world collision instead like you suggest BrotSagtMist. I see the issue with performance is going to be bad for me. I will check out those articles too, this evening, RNavega!

[vilonis]

Honestly don’t worry about performance at first, there re ways to make collision checking faster later (using some kind of spatial partitioning data structure for everything your player could collide with).

Having blocks that each have their own dimensions and a position that isn’t necessarily snapped to a grid is perfectly reasonable, so don’t feel like you have to go with a tile map if that’s not what you had in mind.

And you’re right that a physics library isn’t needed to check rectangle vs rectangle collisions, when all the rectangles are axis aligned (i.e., not rotated).

For basic collision checking, compare your player to all of the platforms they could possibly hit. Do this by first determining where the player will be (their position plus velocity times the time step), then see if that new position intersects with any of the blocks.

If it does, don’t allow the move at all.


Once that works, improve it by allowing a partial move, up to the point that the player would be up against the object.

After that, platformers are a whole bunch of tweaks and special cases to make the collision feel good.

You got this!

[waffleturtle]

Thanks! I'll keep it in mind to not fret too much over optimization at this stage!

I got something sort of working now. It's still a bit wonky but at least going in the right direction now.

I ended up checking the direction of the player velocity and then test the closest two tiles towards that direction and applying a pushback based on player's world coordinates vs the tiles grid-position, if the player would end up inside the tile.

So I went with tile-based for the collision map for the world itself. But I think I will use a system more similar to what you describe for the objects in the world interacting with each other though!

Next on my list to think about is probably
- Slope-tiles
- Enemies walking around in the level using the same tile-based collision system the player does

Will see if I figure anything out there!