9
\$\begingroup\$

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.

\$\endgroup\$
2
  • 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 '11 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 '11 at 15:15
9
\$\begingroup\$

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.

\$\endgroup\$

You must log in to answer this question.

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