Collision Detection in a big map?

Question

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.

Answer 1

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.

Answer 2

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/

Answer 3

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.

Answer 4

for pokemon platinum, heart gold, black, black 2, etc they used a mix of 3d collisions and 3d array checks, which was built into the DS APIs The map is not made of tiles, it is made of 3d models.

I wrote a program to convert those models into a glb file and used them in my own game (only for private use)