Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What sort of tools/processes are used for setting up hitboxes and make them move/resize/appear/disappear to match the character animations? I'm working in 2d, so attaching collision volumes to the character in a modeling program are no good for this case :).

share|improve this question
up vote 2 down vote accepted

This may be much heavier than you need, but here's how we do it. We stick to AABBs for simplicity... (The terrain is more arbitrary than AABBs, but almost all objects stick to AABBs. They might be bigger or smaller than the sprite, but it works quite well with some tuning!)

The pipeline supports several types of box:

  • collision, a single 2D AABB for interacting with terrain features (a relatively simple SAT engine)
  • attack, zero or more numbered 2D AABBs for determining where damage will occur
  • vulnerability, an optional 2D AABB for overlap testing with attack boxes (if A's attack box connects with B's vuln box, it's a hit!)
  • attack select, zero or more numbered boxes tested against either collision or vulnerability boxes to determine if AI should trigger a specific attack type
  • (you can also add additional named box params if this doesn't suit your needs)

Each of these boxes is per-frame, per-animation. If they don't change across an entire anim we only store them once with the first frame and a note that they repeat.

The artist/designer-facing tool, which aggregates all the sprites and a bunch of metadata, will help you with the collision box. In automatic mode it will simply snap the collision box to the "outermost non-transparent pixels" in a given sprite frame. In manual mode you can tweak the box however you like. There's a "magic wand" button for snapping it back to the outermost non-transparent pixels again.

You don't have to have any given box for any given frame if you don't want it.

(Note: it's also useful to track a "reference point" for sprite placement -- you can treat your character coordinates as bottom-center, or maybe you're dealing with a button and you want to place based on the center of the sprite, etc... Helps with setting up UIs and uniformity in moving characters around -- characters are usually hauled around by bottom-center.)

This info is exported into an intermediate xml-based format, and then baked by a subsequent tool into a binary format appropriate for the target platform.

All of these reach the game and then use a simple quadtree-like space partition system to do their testing vs. one another.

It's definitely possible to add a deeper pass to do pixel vs. pixel tests after the AABB pass if you need it.

share|improve this answer
While I appreciate the accepted answer, wait a bit: you're likely to get even better stuff within the next day or so... =) See for example jpaver's answer, which would let you do all of this without a hand-rolled frontend tool, just a data baking tool. – leander Aug 13 '10 at 20:32

What tool are you using for authoring your sprites? If you're using GIMP or Photoshop, you can easily have the artists paint hit areas as a separate named layer. You would then write a tool as part of your content pipeline to:

  • extract the layer in question from each sprite sheet directly from the PSD/XCF file.
  • for each sprite area in the sprite sheet, search for the non-zero pixels in that sprite area and generate a bounding box
  • associate the bounding box with the sprite descriptor.

The PSD format can be found here:!

Of course, you could always have the artists export the layer manually to a standard file format that's easier for your tool to read, but we all know how artists love having manual processes forced down their throats :)

share|improve this answer
+1. This is a great idea. We used this approach (separate layer, possibly exported to a separate image) to encode terrain height in a fixed-perspective isometric game, matching up the in-engine conception of the height with the visuals. It's not necessarily the smallest solution if you don't bake it down (which you recommend anyway), but great for when you need per-pixel accuracy for metadata. – leander Aug 13 '10 at 20:28
Thanks. The technique can also work well for placing the sprite centre points, attachment points eg. for attaching a helmet to a head, or a gun to a hand, bullet exit points etc. – jpaver Aug 13 '10 at 20:34
Wow, I'd never thought of using a .xcf file directly either. Is there code out in the wild to literally display an .xcf directly? Or do you use it only to extract the layer from it? – JustBoo Aug 13 '10 at 20:44
Sadly, none that I know of. GIMP is open source so surely you can extract the relevant portions from there. More on the format here: – jpaver Aug 13 '10 at 22:03

One easy/semi-hacky solution is to not use hitboxes but instead do a pixel test for you given sprite. Basically you set up some alpha threshold and if the alpha value of a given pixel closest to the area you need to test against is greater than that, you've collided with it.

A better approach I've used in the past is to just set up an array of points per tile (in your case, per frame) that signifies where the edges are. You generate line segments out of that and do arbitrary n-gon testing for your collision.

Barring that, you'll probably have to write your own solution to save out exactly what you're suggesting, i.e. bounding volume type x with properties y at location z for sprite w. It heavily depends on what your specific needs are.

share|improve this answer
ClanLib has a nice example of this alpha cutting technique (hulling a sprite to a polygon to use for collision). – coderanger Aug 13 '10 at 18:10

I would use an aabb-point test to single out which model(s) that I'm potentially hitting, and then do a pixel-test on those models.

share|improve this answer

Your Answer


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.