# Boundaries in game development: How do “professionals” do it?

How do professionals do boundaries in a 2D game? The way I do is say I don't want the sprite to move into a certain area:

``````//Example
if ((playerPosX >= 825) && (playerPosX  <= 910)&& (playerPosY >= 170) && (playerPosY <= 255)) {
//do nothing
}else{
//move
}
``````

But some games out there have a lot of boundaries so I'm wondering, is there an easier way. I don't think there is any way someone would use the above method throughout a whole game, just to block of movement.

EDIT: My question is mainly regarding a game where you can walk around, similar to Pokemon or final fantasy

-
Cross-posted from StackOverflow with an accepted answer, the two should probably be merged somehow: stackoverflow.com/questions/14080005/… – Robert Rouhani Dec 29 '12 at 13:04

Nothing wrong with that, at all. We do whatever is the simplest, that works.

Having said that, what you describe in your code is a means to bound objects into a rectangular playing field, eg. Robotron or Gremlins, or to keep a bouncing ball inside the screen. On the other hand, if you want to collide with many separate boundaries, or for objects to collide with other objects, you need to look into collision detection.

There are two broad approaches to detecting collisions:

1. Cell/tile-based collision detection
2. Geometric collision detection

Some games, like PacMan, use cell-based collision detection. The entire map is represented as cells which are either filled or open(boolean value). The characters (ghosts & PacMan) can only move between cells that are open.

However, nearly all collision detection you see in modern games is geometric. The geometric collision detection category breaks down into:

• Axis-aligned rectangular collision detection, one application of which you've described above; however your whole world may be made out of axis-aligned rectangles which either keep things in, or keep things out, or both.
• Circular collision detection, where a collision occurs when the distance between Circle1 & Circle2 is less than their combined radii (extends to spherical collision detection in 3D).
• Polygonal (line-based) collision detection (e.g. Box2D); this also works for non-axis-aligned rectangles / boxes. Extends (with a considerable amount of extra mathematical effort) to polyhedral (line- & plane-based) collision detection in 3D (eg. ODE). It is costly because it takes processing time proportional to the number of lines in each of the two colliding polygons.
• 3D parametric surface collision detection, which is a whole other ball game and isn't really used in games but rather in eg. CAD software and raytracers. There is probably a parallel for this in 2D (using splines and the like) but I've never seen it's like in use.

It is also worth noting that there is a clear hierarchy of cost in the list above. Axis-aligned rectangular is cheaper than circular collsion detection is cheaper than polygonal collision detection is cheaper than more accurate parametric line or surface methods. For this reason, collision detection algorithms often consist of a "broadphase" and a "narrow phase", the broadphase being where a cheaper algorithm is used to check for "early fail". For instance, in 3D it is far easier to first determine what the maximum spherical bounds of two objects are, and see if these overlap, and then only if they do overlap, to check the individual planes, edges and vertices to see if a real overlap occurs.

-
One minor point I think worth adding to your great post is that we usually use data-driven techniques, rather than hard-coding positions. – Sean Middleditch Dec 29 '12 at 17:47
Could you explain what you mean by data-driven? – Christian Dec 29 '12 at 20:07
@Christian Sean means that it's generally not a good idea to hardcode in constant values as you have done there. What you should do is to have a set of variables / constants kept separate -- either at the top of your class file or in a separate file dedicated to this purpose -- where you will keep all your numbers. So instead of coding in `825` as you do above, instead set a variable called `rightBoundary` and set it equal to `825`. Then replace the `825` in your code above with `rightBoundary`. Rinse, repeat. These numbers are what we call magic numbers, and they often cause havoc later on. – Arcane Engineer Dec 29 '12 at 20:16
@Christian what that does is, later on when you come back to a section of code, instead of staring at numbers and wondering what they mean, you instead see names telling you what the numbers represent. This is crucial. If you don't do it, it's only a matter of time before you wind up with practically unmaintainable code. – Arcane Engineer Dec 29 '12 at 20:18

What I have done before is generate a specific tile around the edge of the map and check constantly if the player is on one of those tiles. I then tell it to pretty much not let it to go past those tiles. I usually assign an ID to each type of tile to help checking if the player is on the tile. I also generate black or "void" tiles around the map and I don't let the player move on them.

-

Yeah for a game like pokemon I'm sure a tile based approach would be best. Every peice of the game is represented as a square sprite with large items like buildings usualy a few seperate tiles. I've made a few with a separate layer for movement tiles that don't get drawn at run time, but show up in the editor. Then when moving it checks to see if that is a tile you can move to, otherwise you just bump into a wall. Simmalerly you could have tiles where you could swim, or use other special abilitys. There are many great books on tile based games, and probably a lot of good resources online too

-