next »

[Eiffer]

I'm working on the map format for my game and I'm trying to decide on how to handle collision. I want to build my maps out of non-gridded 2D tiles that can be rotated and scaled and exist on several layers (like in Aquaria). Obviously the layers are irrelavant to the collision.

Basically I'm wondering if I should just have collision polygons for all the objects on the same layer as the player and use those, or if I should have a separately defined collision layer.

If I use the polys associated with graphical objects, I could create ploygons that conform closely to the shape of the graphics, or I could use axis aligned boxes that size to contain the whole sprite for a broad collision sweep, then check for collision on a per pixel basis if there is a collision in the broad phase.

If I go with a collision layer, should I use pre-defined primatives (squaresm triangles etc), custom polys (create a series of convex polygons one vertice at a time. Much larger memory overhead I think) or a series of collision lines?

I guess thiss is mostly just me thinking out loud, but I would love to hear from anyone who has done a map like this and see if I can learn from their experience. Better yet, if Derek wouldn't mind sharing some info on how the collision map in Aquaria is handled that would be a huge help, as it's the closest I can think of to how I want to do my maps.

[digitalgibs]

Personally I'd imagine that it depends completely on the type of game you are making, but generally speaking, polygon collision would probably give you the best results.  Some kind of recursive box collision that resorts to pixel tests could get hairy when you start talking about rotated objects.

A separate collision layer would be nice for static environmental stuff.  It would also allow you to do things like hidden walls that may appear visually, but have no collision.

Worst case with polygon collision is that your character may appear to float off the ground if you don't properly line up the polygons with the visual representation.  This isn't much of an issue if you are doing something that doesn't involve 90% of your time touching the floors and walls.

[Eiffer]

Yeah I'm leaning towards polygons. I'm doing a dual-stick, exploratory shooter. So you'll never be resting on the floors or walls, just running into them and bouncing off/ blowing up.

I am considering some sort of line based system though, where I could just draw collision as a series of line segments in the map editor. I couldn't think of how to do this till earlier today when I had one of those "how the hell didn't I think of that before" moments. My problem was that I wasn't sure how to tell which side of the line it was ok to be on, then I figured out that I just needed to store a pre-calculated Normal for each segment that points in the direction the line is "facing". having the normals pre calculated for the static line segments would possibly speed up collision detection as well, since I'm using a SAT based algorythm.

[capnmikey]

If your polygons are wound in a consistent direction (e.g. all clockwise or all counter-clockwise) it's pretty easy to find the "out" normal.  For each line segment on the poly (x,y) the normal is (y,-x) or (-y,x) normalized.

Which of the two it is depends on the direction you chose, and whether your Y-axis points up or down (i.e. the "handedness"), but it will be the same for everything.

[Will Vale]

I'm slowly putting together pieces for the same kind of game, and I was going to use Box2D's new edge chain primitives. These aren't in any of the released versions, but they are in the subversion trunk. Edge chains seemed like a better fit for this kind of game than anything else.

Maybe worth looking at?

Will