Re: [pygame] Collision Resolver module

[bhaaluu <bhaaluu@xxxxxxxxx>]

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,  <sjbrown@xxxxxxxxx> 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
>
>