Re: [pygame] Collision Resolver module
On Mon, Dec 31, 2007 at 10:20 AM, [EMAIL PROTECTED] wrote: Hi all. Here's a collision resolver module I've been working on. Don't you have a reference web page for this useful piece of code? -- -- luca
Re: [pygame] Collision Resolver module
Brian, Thanks for your thoughtful response. This is exactly the kind of feedback I am looking for. My comments inline. 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. Hmm. Would you say the Sprite and SpriteGroup classes meet that criterion? I guess my argument here would be that it would be that resolving a collision is a logical next step from detecting a collision (which pygame already provides the functions for), so it dovetails nicely. I think it would be easier when it's included because it would be right there staring them in the face. I think it is a somewhat difficult problem, that seems simple on the surface, so users might not think to search out an external module, thinking it's easy to hack an algorithm out in 1 hour (I remember going down a couple dead ends trying to do the collision resolution in Subterraneman) 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 In my opinion, yes. But I'm pretty close to the code, so I'm open to criticism of the API and documentation. third (and this is really the most important thing) is someone needs to do the work to make it in and stable and tested Agreed. I can do more work here. ... 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? yeah, resolve_collisions is the only necessary interface to the module. Now as to how to integrate this into pygame, I think it could either be a method of Rect (first argument, movingRect becomes self) or as a standalone module somehow. Suggestions? 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) This broad phase check could easily be implemented as a Strategy that looks like one of the CheckHexagon* Strategies, but only checks for collisions in bigRect and then returns. Though that might necessitate changing the return values of resolve_collisions -- there'd be multiple xLimiters and yLimiters that you would then want to examine in the narrow phase. - 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?) A new Strategy would need to be created, but all one should have to implement is the run_step method. 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 agree, but I would categorize that as a top-down with a discrete map, not a continuous map. It's the best terminology I could come up with. 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. The design is such that each moving rect would take a turn. I know this allows for the rare case of two very fast moving objects to pass through each other logically. I don't have a solution for this that is reasonably efficient. 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), Are you referring to the
Re: [pygame] Collision Resolver module
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
Re: [pygame] Collision Resolver module
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, [EMAIL PROTECTED] 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
Re: [pygame] Collision Resolver module
In a message of Tue, 01 Jan 2008 04:46:08 EST, bhaaluu writes: Perhaps the collission-resolver module should be included in a Game Engi ne 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 severa l different types of game senarios. Happy Programming! If it isn't to go into pygame I would rather have it as another module to load, included as a library. Thank you for writing this sjbrown. Laura
Re: [pygame] Collision Resolver module
did anyone look into box2d? (http://www.box2d.org/) i think this also could be nice for using it with pygame. is there a python wrapper for it? sorry for being slightly offtopic... On 1/1/08, Laura Creighton [EMAIL PROTECTED] wrote: In a message of Tue, 01 Jan 2008 04:46:08 EST, bhaaluu writes: Perhaps the collission-resolver module should be included in a Game Engi ne 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 severa l different types of game senarios. Happy Programming! If it isn't to go into pygame I would rather have it as another module to load, included as a library. Thank you for writing this sjbrown. Laura
Re: [pygame] Collision Resolver module
This looks like a python binding for an extremely similar 2d physics engine, chipmunk (it even uses some of the same algorithms from box2d) http://www.pyweek.org/d/932/ On Jan 1, 2008 7:29 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: did anyone look into box2d? (http://www.box2d.org/) i think this also could be nice for using it with pygame. is there a python wrapper for it? sorry for being slightly offtopic... On 1/1/08, Laura Creighton [EMAIL PROTECTED] wrote: In a message of Tue, 01 Jan 2008 04:46:08 EST, bhaaluu writes: Perhaps the collission-resolver module should be included in a Game Engi ne 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 severa l different types of game senarios. Happy Programming! If it isn't to go into pygame I would rather have it as another module to load, included as a library. Thank you for writing this sjbrown. Laura
Re: [pygame] Collision Resolver module
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, [EMAIL PROTECTED] 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
Re: [pygame] Collision Resolver module
On Jan 1, 2008 7:49 PM, [EMAIL PROTECTED] wrote: Pygame should aspire to providing a very rich (while being consistent, lean, and elegant) set of tools. I'm not a smart pygame user yet so my opinion can be very poor, but what I quoted here is true, and important. This is true for all engine in general, not only pygame. I've not tested the example and the library that generated this thread, but for what I see and tryed from the Pygame base tutorial, a Sprite collision is already present. The tutorial itself says ...but probably this will be enough for you use. So you are talking here of something that pygame already do... but not well?
Re: [pygame] Collision Resolver module
This is awesome; it certainly will save me a lot of trouble, and I agree that including it as part of PyGame would be a smart move.
[pygame] Collision Resolver module
Hi all. 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. Further complicating matters, just checking the end position is sometimes not enough. When a rectangle moves it sweeps through a hexagonal shape, and there might be solid objects that collide with this sweep hexagon that don't collide with the end position. This issue is more pronounced the bigger (deltaX, deltaY) gets. An even further complication: if you displace the rect due to a collision inside the sweep hexagon, it may then collide with a new solid object that lies outside the original sweep hexagon. This module provides a function that you can call, resolve_collisions() that will sort all this mess out for you. I think this is a general enough problem in 2D games that the resolver function be considered for inclusion in pygame itself. I have included a program that demonstrates what it does. Just run: python collision_resolver_example.py options are printed to the terminal. -sjbrown collision_resolver.tar.gz Description: GNU Zip compressed data
Re: [pygame] Collision Resolver module
On Mon, 31 Dec 2007 03:20:43 -0500 (EST), [EMAIL PROTECTED] wrote: Hi all. 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!
Re: [pygame] Collision Resolver module
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
