How to create a realistic 2D Role-Playing game collision detection?

Question

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:

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.

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.