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

I understand SGV images are used in 2D games to store shape data for the physics engine of the game. I'm unsure though, should the raster sprite also be stored in the SVG or should it be separate?

Also, what about animated sprites? In a non-skeletal-based animation system, how should the shape of the character be handled? Is a simple rectangle enough?

share|improve this question
up vote 4 down vote accepted

SVG is probably not the optimal choice for shape data. The coordinates usually don't align with the ones from the physics engine and require conversion (that's not really hard to do, but you'll have to do it). In addition you'll have to write a special parser to get the shapes out from the SVG file and also make sure all your polygons are actually convex (eg. convert/split concave polygons).

If you plan on using SVG nevertheless, I suggest you just use it for the shape. Your raster image should be packed to a sprite-sheet instead.

There's a specialized tool called PhysicsEditor that can be used to create collision shapes from your raster images. It will make sure your exported polygons are split into convex polygons if necessary. It also allows exporting for different engines.

When it comes to animated sprites: In most cases, you won't need a collision shape for every frame, but rather one that encloses all animation frames. For a player character it might be enough to just have an enclosing circle or rounded rectangle as collision shape. Maybe with additional sensor shapes if needed (front, bottom, top etc.)

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.