# AABB for a tile based world

I'm on my way with a tiled based game. I have correctly implemented scrolling, position handling etc.

I have (before) had a simple collision system that is a really bad one, and now I'm going to switch from simple x and y checks to AABB.

The real problem isn't really about AABB itself, since I've made a simple application demonstrating the technique - it works like intended. This is for singular, independent objects that is static.

Since I know the technique and how to resolve collisions correctly I wanna apply this AABB technique to my tile world. It is now the real problem (or question?) arises.

Since the world is built on tiles and the world's objects is built together to a world, how would I implement the AABB? Before it was only for single static objects, now for a whole world. Is it possible to create a single world static object or are there any better idea out there?

Should I create a single box for every single tile in the world? It doesn't sound well, but how should I fight this problem down?

Any help is appreciated!

Considering what you've said about how you previously had a "simple collision system that was a really bad one", I assume you want the latter.

That's correct. The previous collision system made my character get stuck in tiles and it wasn't working properly.

So you can see how it will haphazardly overlay your four tiles. Your AABB for the object then is a rect with x=7, y=10, w=12, h=15. Let's say this is your only obstacle in the world.

I understand, I think. Does this necessarily mean I have to create a single AABB for every tile?

You can see that due to his width and height, he now overlaps the top left of your obstacle at {7,10}. So resolve the collision. That's all there is to it.

Yep, that part I understand. For now, the world is built from a single 2D array, but is it really efficient to create an AABB for every obstacle?

Oh, I think it does not really matter if I only loop through the obstacles and tiles in the area where the player is..

• (1) The difference between the 1st approach and the 2nd is that in the 1st, you use tiles for collision. In the 2nd (AABB-based), tiles are no longer the basis for collision -- entities are. If you want obstacles that are laid exactly as tiles are, you create static, collidable entities over those tiles. By default, tiles are usually like open space: They allow the player to move freely, so there is no need to check for collisions on those. (2) Re your last sentence, 100% correct, but that is an optimisation and should not enter the discussion while you're still assimilating the basic idea. Oct 1 '11 at 15:44
• Also -- you can see that by using axis-aligned obstacles, you can very easily create massive obstacles (far larger than a tile) or small ones without overhead, unlike the scenario where you have many small tiles each as a single obstacle that needs to be processed for collisions. One large obstacle, or a fewer larger ones, work even better since they are faster to process. Oct 1 '11 at 15:49
• @Nick: Thank you, all is much clearer now! I'll now start implementing the ideas presented here. Thanks again. Oct 1 '11 at 15:50
• A pleasure, @Julian. GLHF :) Oct 1 '11 at 15:52

I think you're misunderstanding the nature of collision detection using AABBs, as a whole, thereby confounding your question.

Tile-based collision: Use if you're only ever going to have obstacles that cover complete tiles, never just parts of tiles. This typically restricts your character to moving jerkily from tile to tile, also.

AABB-based collision: Use if you want obstacles (and characters) that can partly cover tiles, for example, stand your character on the border between tile {0,0} and {1,0}. Now he's covering part of each. This also allows "free movement" for mobile entities.

Considering what you've said about how you previously had a "simple collision system that was a really bad one", I assume you want the latter.

AABB collision detection is simple. You have N objects in your world. Because you must check every object against every other object, you have the following funadmental code:

for each entitiy in entityList
for each otherEntity in entityList
if entity != otherEntity
if (entity.overlaps(otherEntity))
resolveCollision(entity, otherEntity)

//resolveCollision applies new vector forces to cause objects to bounce off one another, or stop dead, or some such.


In your empty world, begin placing obstacles. These need not fit your ground tiles exactly. That is, an obstacle like a fallen tree may completely cover some ground tiles, while it may only partially cover others. When you place the object, calculate your AABB. Let's say your 10x10 pixel tiles are placed at {0,0}, {0,10}, {10, 0} and {10,10}, so you have a small square of four tiles. You don't need to place your obstacle at any of these points, you could instead place it at {5,5}. If it has a width of {7,10} then it would run to {12,15}. So you can see how it will haphazardly overlay your four tiles. Your AABB for the object then is a rect with x=7, y=10, w=12, h=15. Let's say this is your only obstacle in the world.

Now put your player character in the world. He starts moving. Every update, potential collisions must be check for. At some point, your player walks down and right. His AABB is w=3, h=3, and he is now standing at 6, 9. You can see that due to his width and height, he now overlaps the top left of your obstacle at {7,10}. So resolve the collision. That's all there is to it.

Using AABBs, you can now use floating point values for your positions, allowing finer control, whereas with a tile-collision approach, you have a quantised space (a 2D array) that restricts positioning to only the exact indices into that array.

• Thanks for the answer, Nick. Let me take some minutes to edit my question for comments to some of the things you mention in your answer. Oct 1 '11 at 15:05
• I have made some comments in my question. Oct 1 '11 at 15:16
• Voila! Two hours later, and a successfully implemented solution. Thank you so much! Oct 1 '11 at 17:20
• This is good, but I'd love to hear more detail about resolving the collision. May 18 '14 at 20:59
• @jackrugile Thanks Jack, but that's not within the scope of the OP's question, which is about AABBs == collision detection (not collision resolution). Feel free to ask a new question if there is something specific you want to know. May 21 '14 at 18:51