[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