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, <[EMAIL PROTECTED]> 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 >
