Perhaps the collission-resolver module should be included in a "Game Engine" leaving PyGame as is?
The collission-resolver is a really nice module, but adding it to PyGame seems like the beginning of creeping feature bloat? I'd rather see it added to a Game Engine, and have a nice tutorial written on how to implement it in several different types of game senarios. Happy Programming! -- b h a a l u u at g m a i l dot c o m http://www.geocities.com/ek.bhaaluu/python/index.html On Dec 31, 2007 2:50 PM, <[EMAIL PROTECTED]> wrote: > > > >> Here's a "collision resolver" module I've been working on. > >> > >> A common problem in 2D games is trying to move a sprite in a direction > >> (deltaX, deltaY) and then discovering that there is a solid object in the > >> new position it wants to occupy, so you have to move it back to the edge > >> of that solid object. > > > > > > This kind of problem -- checking a _sprite_ for collisions -- is why I > > don't think it's a good idea to have game objects based around sprites. > > We're trying to represent a physical space, so having objects recorded in > > terms of screen coordinates blurs the distinction between where something > > is drawn and where it _is_. What if the screen scrolls? Suddenly all the > > objects "move" even if they're not supposed to be moving. > > > > What I've been doing is decoupling sprites from game entities. Doing that > > has already paid off in an unexpected way. When I changed the tile size I > > was using, making one unit of space represented by fewer pixels, I noticed > > that my character seemed to run slower. It didn't, actually; its apparent > > speed had automatically adjusted to the new tile size, without my having to > > re-code it! > > If you take a look at the code, particularly at the resolve_collisions > function, it doesn't actually care about sprites, it can work generically > with the rects alone, or with any object that has a .rect attribute. > > -sjbrown > >