Hi Oliver,
Thanks for the compliments. It's really only my personal preference to
structure stuff that way. Often times I think it makes the code easier
to get into for someone else. But really I would suggest going with
what ever structure you think best for a particular game. In 99sheep I
don't use that structure because games won't ever be networked,
recorded, logged or anything else that would benefit from a separation
of the display and mechanics. For instance I don't really feel like
creating two classes for each character (shepherd, sheep, wolf etc);
but for snowballz that's a whole different story. :)
I have never used pyglet's sprites so I can't compare the two. I've
used rabbyt since before pyglet 1.0. I like rabbyt because it is very
fast (all the GL calls, animations etc are done in C) and has a simple
API. Extending the sprite works very well (all the xy, x, y, rot, rgb
and so on integrate very well for many many use cases). It's small;
which is good on so many levels. My brother develops it so that makes
it even easier to use (and I have made a couple suggestions that have
gotten implemented so it fits my taste too).
But what I like most about it is the anims. If you haven't checked out
rabbyt.lerp/ease/ease_in/ease_out then you absolutely need to - It's
the best thing since sliced bread. There are some good examples
demonstrating their use in the rabbyt examples directory.
And yes, the collision detection is nice and fast enough.
Reticently, Alex implemented some batch stuff which - unless I've
misunderstood it's purpose - speeds up pyglet's sprite render quite a
bit. But I haven't looked at it yet.
Pretty much the only disadvantage for me with using rabbyt is
distribution. Last time I tried it took some work to get it packaged
with py2exe. But I think that's inherit with not being pure python. I
also had a small hick-up when trying to package it with cx_Freeze in
linux; but it didn't take more than a couple minuets to fix.
/me steps down from soap box. :)
~Joey