Re: [pygame] Collision Resolver module

["Brian Fisher" <brian@xxxxxxxxxxxxxxxxxxx>]

first off I think it's great that you are sharing this code and your
experience on how to handle collisions. I'm sure it will help some
people on the list and possibly help you find ways to improve and
evolve it.
----

In my mind there are 3 issues with including something in pygame

first is it ought to have some synergy with pygame features that gives
a reason why it shouldn't be a seperate module or extension or simply
reference code. Like if the code does x there should be some reason
why a user can do x better or easier or simpler when the code is
included with pygame.

second is it ought to be useful in the way it appears to be useful.
Meaning it should lets users accomplish what they want faster or
easier when they think it's what they want, and it shouldn't lead
people down a path of trying to use it only to find it won't work or
uses a bad approach or something

third (and this is really the most important thing) is someone needs
to do the work to make it in and stable and tested

---
applying those to the code example you sent -

for the first thing (synergy with pygame) - I can see how a swept
bounding rect function could be a logical extension of the pygame
sprite collide or rect collide functions like you suggest, so I can
see there would be some synergy in terms of it being a more feature
rich replacement for spritecollide or groupcollide stuff - but I don't
see an interface in your code that seems well integrated with either
rects or sprites to me. So if it were part of pygame would you expect
the interface to just be the "resolve_collisions" function that the
example uses, or something different?

for the second thing (being useful in a way that solves problems it
aims to solve)... I guess I'm not necessarily the audience for this
because I rarely use axis aligned rects in collision for anything but
a "broad phase" of collision before doing some more accurate test (in
which case the rect that contains the swept rect/hexagon would be just
as good as using the swept rect itself) - for instance, you mentioned
this could be good for a racing game, but I can't imagine a racing
game that wouldn't want to rotate the rects as you turn (does this
handle that?)

But trying to put myself in a place where rect collision is sufficient
- I feel compelled to say I disagree that this problem (colliding
along the swept movement path) "must be solved" for all the types you
mentioned in that category - in particular I think puzzle and rpg
games would be worse if you solved them that way than if you didn't.
In my opinion, those games are usually better off having those game
types use a grid and instantaneously move to any grid point that is
free, and then just animate the movement over time after having
changed grid positions, rather than trying to collide during the
movement animation. I can see accurately finding collisions along move
paths as being an important issue to solve for platformers and
shoot-em-ups - however, I'm not sure the example demonstrates how the
collision resolver code as it is now properly solves things. In
particular the code only seems to support one moving object at a time
- and I'm sure in most shoot-em-up's all objects would be moving.
Also, I don't think the code as it is properly resolves the problems
that I thought you said you want it to solve. Running the example I
can make it report a collision with multiple objects where it seems it
should only collide with one of the objects (like it would only hit
the second one if it would "pass through" the first), and I don't see
the example demonstrating how this handles "if you displace the rect
due to a collision inside the sweep hexagon" and the displacement
would make follow on collisions.

of course I'm sure any objection I'd have could be solved, which
brings me to the third thing (someone having to do the work to
include) which is related to you saying "we shouldn't be content to
rest, providing just a wrapper to SDL" - basically providing "just a
wrapper to SDL" is a considerable thing, both in what it enables in
terms of game creation and in terms of the work involved. As I'm sure
most people are aware, we don't have precompiled binaries of pygame
for all platforms and python versions for the latest SDL right now, so
in my opinion there is a lot of pygame work that is more important
than this in my mind - I'm not saying that it wouldn't be good to add
something that solves the problem you are mentioning, and I'm not
saying we shouldn't add something great just because other work isn't
finished. My point is simply that practically speaking, I can't
imagine that any patch or change to include your collision resolver
module would actually get incorporated unless it was so obviously done
and finished and ready that it was really easy to commit.

----
of course I could be missing the point on all this, so bottom line, I
think it would be much easier to be convinced that the module was both
useful in the context of making a complete game if there was a
complete game that uses the thing that you could point to and play
with, and that it would be much easier to be convinced that it
wouldn't cost a lot to integrate and keep bug-free if it had unit
tests and/or stress tests.


On Jan 1, 2008 10:49 AM,  <sjbrown@xxxxxxxxx> wrote:
> 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
>