>> 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
