# Platformer movement and collisions

I'm working on a platformer but I'm stuck at the player movement and collisions.

Right now I'm not including the grid at all in the movement, but it's time I do it. I've read this article on how to do it. But there's no real code examples just theory.

I like the second example and that's the one I'm going for. I want the movement to be smooth, and the player should be able to run in between squares from my map array. This means I have to get tile information from the array, and according to that allow/forbid my player to move in that direction. And that's where I'm stuck.

My array is a bunch of 1's and 0's right now. I know how to calculate a hitbox around the player, but how do I compare that to the array in an efficiant way?

UPDATE: I've been playing around with this for a while now, and the only thing I came up with is using player X and Y which is in pixels, dividing by tile size, and getting a rough estimate on the map. Then I make it an AABB by adding its width and height to get the corners.

This showed to be very unreliable though, and I would really need some help on how to structure this.

-

Well you have to obviously loop through tiles to see what ones are interesting the player and deal with it accordingly.

If your map is not very large it's trivial to loop through all tiles to find the collision. something like `tiles.forEach(function(tile){})`. Once your game and maps start to get larger this of course can be very intensive.

One solution I can think of is to only check the tiles that in the view port. Then all it becomes is a matter of finding what section your character is in and looping though only the tiles in view.

Another way would be to split your tile map into sections, so section 1 might be (0,0) to (20,20). You then determine what section the charter is and loop through only those tiles. That way you can loop through an even smaller number of tiles

-
It crossed my mind, but not as obvious as you try to say. In a platformer I could just go "if direction east check X+1, X+2" or whatever and see what is on that position of the array. Anyway, the collision detection isn't really my problem, the problem is more calculating the player position (which is in pixels) to the level array, if you see the difference. I don't know how to piece the two together in an efficient way. – justanotherhobbyist Jul 21 '12 at 8:05
@hustlerinc I think you need to have him have a position relative to the view port and relative to the level. – Clay Ellis Murray Jul 21 '12 at 8:11
Yeah that is kind of the whole point of my question? A good way to structure such a function. – justanotherhobbyist Jul 21 '12 at 21:49

I think you are on the right track. It sounds like you have two subquestions:

• How do I track the position of the player in tilespace and in viewspace?
• How do I efficiently track collisions in tilespace?

In a platformer that I wrote, my position objects had tileX and tileY fields and fineX and fineY fields to help with this exact problem. fineX and fineY were bounded from [0, TILE_SIZE). My physics code took these positions into account when determining what happened to objects as they moved around: first use tileX and tileY to get info from the game map, then use that in combination with fineX and fineY for drawing. I'd love to find out a better way to do this, though.

You're almost there with the collisions, too. The only optimization I might add is to "chunk up" your collision grid a bit. Your "normal" tile is TILE_SIZE x TILE_SIZE, right? So, your collision grid can track (TILE_SIZE*2) x (TILE_SIZE*2) chunks at a time since moust objects, even when crossing tile boundaries, will fit into that space? Maybe even TILE_SIZE*4 to allow for growth or quick moving objects. That way, you decrease the number of lookups to only when your object is crossing chunk boundaries.

Then again, there's a big YAGNI here. When you talk about efficiency, are you actually seeing slowdowns in your game? Modern browsers are pretty good about optimizing for you, especially around array accesses and nested function calls. Don't write too much code around this stuff, complexifying (complecting? anyway...) your object model, until you've profiled a bit or actually seen some slowdowns.