# Collision Detection in a big map?

So I've been wondering lately... on games like pokemon (on ds and gba), How did they handle the collision of all those tiles in the map? Should all those collision checks running in the background slow down the game? Do they have it where the collision activates from a certain distance? Do they have a player event where the player is next to a tile that is not able to be walked on? If it is not possible to know the answer, could you give me a solution to that problem?

I guess what I am really asking is how to handle collision of almost every tile in a big map.

• When you tiles, you can simply check the tile which the player/object is on/touching... Thereby you can also check the tiles next to, you don't have to check every single tile every time. Mar 10, 2014 at 7:26
• There are several dozens of question relating to collisions with tiles. Did you try searching first? What did you come up with? What did you find missing in the existing answers? Mar 10, 2014 at 7:49
• possible duplicate of Tile map collision is not working properly Mar 10, 2014 at 7:53

Well, in most handheld Pokemon games, moving objects can only move within a grid. So, each character can only occupy tiles in the grid, and they cannot rest between tiles. If there's an occupied tile where something wants to move, then it will simply not move to that tile in the grid. Collision checks only need to occur when something moves.

In a game where objects are not locked to a grid like this. I'd imagine that they'd only check for collisions with tiles that are onscreen, and maybe even only with tiles close to the moving object.

• And will only check for neighbor tiles. Mar 10, 2014 at 7:29

To detect collision against any possible tiles/obstacles, you first calculate the object's desired movement and where position on the tile map that movement would cause the object to end up if immediately applied.

You then perform a lookup of the tile map (generally via a 2D array representation) of the object's desired position along the x and y axes, and obtain the tile information. If it's a collidable tile, you alter the desired movement appropriately to prevent moving.

To summarize, you essentially look ahead to the position the object wants to move in, and determine if it can move there or not.

This excellent article by Rodrigo Monteiro goes into great depth on how to implement 2d platformers, but can be adjusted for top-down games as well. http://higherorderfun.com/blog/2012/05/20/the-guide-to-implementing-2d-platformers/

As for many things within game programming you only calculate what you need to calculate and discard the rest. For collision detection on a tilebased game it is as simple as just checking the tile you or any entity wants to move too, if that tile has a blocking flag you disallow moving to that location.

It is likewise for the tiles you see on screen, only those that you visually see will get calculated and rendered the others will be discarded. You would not load the gameover screen until it is needed right?

Same goes for NPC's, if they do not need to move outside the screen then do not calculate that, if you do want some variation off screen you just calculate a couple of tiles outside the screen.

The same rules apply for modern (FPS) games, you put many parts of a level inside invisible blocks, if you cannot see that block from your current location and angle you do not render it. Only if the player is within a block you need collision detection on the objects within that same block, first you check the collision with a simple cube or sphere around the player and if something hits that boundary you go check for mesh/object collision which is very expensive.