I’ve always wanted to create an old-fashionned 2D Role-Playing Game like Star Ocean, Final Fantasy, Sword of Mana and even the “Tales of” series, and I guess a lot of people do. But before even writing a single line of code I did a lot of research, drawing and tryouts.

I've found almost all the answers to my questions but there is a problem I haven’t been able to solve: How do you create a realistic but yet simple collision detection, like in the games I named before?

I already know several ways of calculating collision detection, look at the following examples:

Collision detection examples

None of these satisfy my needs.

  • Tile-based collisions are way too simple and suits more a Zelda than a Star Ocean. Plus, the drawing of each tile needs to fill up all space in order to look realistic.
  • Pixel-perfect has too many constraints. If your tile has some pixel here and there, the player will most likely get stuck in the midle of nowhere(ie: in some games you get stuck on a 2 pixels width tree root).
  • And binary masks uses too much memory and settings imo.

I've read alot of documentation but I never found something that looked good to me. And all my tryouts didn't look close to what I used to play with. So if you have any good links or tutorials on how evolved 2D RPG work please let me know.

  • 2
    \$\begingroup\$ What environment are you developing for that collision masks take too much memory? That's really not a concern for most modern systems, and collision masks really do sound like what you're looking for. \$\endgroup\$ Apr 25, 2011 at 13:57
  • \$\begingroup\$ I am developping on PC most of the time with XNA, but recently I've been thinking to start a project on WP7. The problem I had with collision masks was that using a small resolution it acted exactly like pixel perfect would do, by making my character stuck in a corner for example. So unless you use Bézier curve for smooth movement you need to be very carefull on how you create the mask. \$\endgroup\$
    – Aymeric
    Apr 25, 2011 at 15:15

1 Answer 1


The N Tutorials may help here. Admittedly, they're for an arcade-style platformer, but they'll work just as well for a top-down view RPG; just don't apply gravity. The premise is testing for collision in a collection of basic shapes -- circles, axis-aligned bounding boxes, lines, points, etcetera.

You then somehow either decorate your world with these (perhaps via a custom level editor), or automatically generate them (fit a closest box or circle) -- or both (default to auto generated box/circle, and allow a designer to tweak).

Where I work, we have done quite a few platformers and some top-down exploration games. We've been doing them since the GBA days. We most often use AABBs for characters and objects, tunable in a sprite editor -- and we go crazy here, allowing a ton of boxes per sprite, some with different purposes. We might have:

  • one or more collision boxes, describing the shape of the object for running into things;
  • possibly many "attack boxes" that only come into being when you're in the middle of an attack (and animate with the sprite), perhaps even two or three per weapon, depending;
  • a few "vulnerable boxes" that will take damage when hit by others' attack boxes -- by default, we use the collision box, but the vulnerable boxes tend to feel better when they're smaller than the collision box, and we can allow for location-aware damage this way
  • one or more "activation box" on AI that describes the sense region for the AI -- they'll attack if the player is in this region, for example.

The levels are mostly strings of line segments; we have a bit of metadata per segment to describe damaging or slippery surfaces, etc.

So most of the collision detection and response becomes AABB-vs-AABB or AABB-vs-segment. Occasionally we toss in a circle-vs-something for a projectile, although often an AABB will do here as well.

You don't need a lot of basic shapes to make things look good and behave well -- a few will do, provided you can tweak and iterate on them.

Also, don't feel bad about blending systems together; tile-based collision may be excellent in some areas (representing the majority of your world) but horrible for object-object interactions. That's fine; use a different system for object-vs-object! Writing for interactions between the two systems may be easier than you think.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .