Rubygame 3: Day 17

I've got two competing ideas bouncing around in my head, and they've been tumbling around and switching which one is on top. I need to make some sort of (permanent) decision here!

Idea #1:

  • Sprites map onto Body.
  • Sprites have an image, a Body, and some Shapes.
  • The Shapes belong to the Body.
  • The Shapes are invisible, and are only used for collision detection.
  • Sprites can be made static by removing their Body from the simulation and changing its mass/moment to infinity.

Idea #2:

  • Sprites map onto Shape.
  • Each sprite has an image and one Shape.
  • Sprites belong to a Sprite Body, which maps onto Body.
  • Sprite Body is invisible, while Sprites are visible with their image.
  • Sprites can be static by having no Sprite Body (in which case the shapes belong to a behind-the-scenes Body with infinite mass and moment).

In both cases:

  • Shapes can be made phantom but still generate collision events by using a new Ruby-side Shape attribute and a carefully constructed collision function (which Rubygame will set up)
  • Shapes can be made phantom without collision events by using collision groups and layers in Chipmunk.

Yesterday, I was convinced #2 was superior. Today it seems obvious that #1 is the better option. Tomorrow, I might favor #2 again, or perhaps come up with yet another option! It's madness!

The reasons I currently think #1 is better are:

  • It's similar to Rubygame 2 sprites (image + shapes vs. image + rect), so is less of a jump for porting.
  • It feels like it fits more naturally on top of Chipmunk, too.
  • It feels natural and robust to be able to "freeze" (make static) sprites by manipulating the Body, than by doing secret reassigning of Shapes to new Bodies behind the scenes.
  • Static sprites can be moved around without changing the Shape's verts.

The reason I had in favor of #2 was that it would allow construction of objects from multiple parts. E.g. a Sprite Body has an arm sprite-shape, a head sprite-shape, and so on.

But that's stupid. You couldn't even move the parts independently without modifying the Shape's verts, which is non-kosher. It just makes the most common use case — a sprite with one part, one image — more complicated to set up.

I think the multi-part idea could be better implemented with multiple Sprites/Bodies with pin joints, and that would also allow cool ragdoll type things. If you didn't want the floppy ragdoll thing, but instead wanted the parts to keep their relative positions and rotations until you said otherwise, you could manage the rotation of the parts to keep them set right. (Sorry if this is incoherent to other people, I'm in stream of conciousness mode now.)

Keeping the rotation of parts in line would be more easy with a rotational slew method, analagous to the positional slew method. Whereas positional slew changes the body's velocity such that it will be at the given position next frame, a rotational slew would change the body's angular velocity such that it will be at the given rotation next frame.

I think I'll go implement that now. (Yay, I get to get my hands dirty some more.)

P.S. What's up with the word "slew"? I have no idea what it means in this context. Perhaps slembcke can give us some insight? ;)


Have something interesting to say about this post? Email your thoughtful comments to