Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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.

share|improve this question
2  
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. –  Gregory Avery-Weir Apr 25 '11 at 13:57
    
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. –  Ephismen Apr 25 '11 at 15:15

1 Answer 1

up vote 9 down vote accepted

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.