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