Re: [pygame] Collision Resolver module

[sjbrown@xxxxxxxxx]

I don't think it's bloat, nor does it belong in a specific game engine.  A
game engine is something designed to work for a particular genre of game. 
This is a general problem that will be seen in many types of game.

Genres that this problem *must* be solved for:
Platformers, Shoot-em-up, Any top-down with a continuous map (racing,
puzzle, rpg), Any game with rectangle (as opposed to point) projectiles

Genres that could optionally use this algorithm:
Puzzles, simulations, adventure (any 2D "walking" game, including
beat-em-ups), etc...

In fact, I see it as the next logical step from the Rect.collide* and
Sprite.*collide* functions.

I started using Pygame because it was the only library that provided the
tools to let me think about the interesting parts of creating a game, and
took care of the boring details.  Plus, it provides a rich API that lets me
write a game *well*.  This is what attracts people to Pygame, IMHO, so we
shouldn't be content to rest, providing just a wrapper to SDL, instead,
Pygame should aspire to providing a very rich (while being consistent, lean,
and elegant) set of tools.

-sjbrown

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