[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pygame] PCR & other notes




2. Associated with the paths should be an Obstacle object that isa rect. Then the path algorithm should have some implementations for obstacle avoidance.

I think keeping paths and collision detection seperate is probably a good idea. There are a number of different ways of doing collision detection, and I think some are pretty game specific. Implementing them seperately will allow people to easily drop in their own collision detection if wanted.

Collision detection is already provided through the rect interface. What I meant was an Obstacle rect that reroutes paths around the rect. This sort of path adjustments can be tricky and there are a variety of ways of doing this. I think that the rerouting of paths around obstacles is something that would be a useful extension, and is strongly coupled with both rects and paths.


3. It would also be nice if paths could be visible. This is useful in a number of games (missle trails, etc), and very useful in debugging.

With my class I made a path_draw.py. I've also done bezier_draw.py It's good to keep drawing seperate imho. As some people may like to use opengl to draw sometimes, and sdl other times. Also different ways of drawing the path as you say.
This isn't necessarily hard to do given the OO nature of python. Provide a base implementation and allow developers to extend the drawing function. More of what I'm getting at is a framework for the various objects and some generalized implementations, not a kitchen sink. But you're probably right -- I generally agree that algorithms should exist independently of their renders.

I guess so. Basically a way so that scrolling can be fast. For games like the bomberman game, c&c type games etc. This should be able to be generalised so that it can accomodate different ui/game needs. Eg make variable scroll speeds, variable tile sizes etc. There are some game types which lead to very nice optimizations(eg c&c where the map doesn't allways move), I think some of these should be able to be taken into account fairly easily too. There's a number of different codes for this around, just needs someone to clean them up and make a nice reusable implementation.
Paralax scrolling would be cool too, I think someone had a demo of that with acceptable speeds?

Perhaps a good initial step is to take a survey of interesting implementations that are currently available coupled with, as you mentioned earlier, what sort of things turn up as pieces that are frequently reimplemented project to project. Having a variety of implementations makes it easier to pick and choose the best parts of all of them. I'll try to allocate some time to start on this this week.

As far as bezier curves go, I would love to share implementations. I submitted mine to the PCR a while back but I guess it's going to be a while before it shows up. In the meantime, however, you can find my current bezier class at:
http://www.waughonline.com/bezier.tar.gz The algorithm is bezier_curve.py. It's rendered with bezier.py.

robert