Re: [pygame] PCR & other notes

[Rene Dudfield <illumen@yahoo.com>]

Robert Mark Waugh wrote:

> > I think a good idea would be to look at a few games and see any areas 
> > where their functionality overlaps.  Then take that code from them to 
> > make modules which all the different games can use instead.  This way 
> > it is likely that whatevar code is made will be quite useful for yet 
> > more games.  Even more likely that the code will be fairly efficient 
> > and correct, as it is being used allready.
> >
> > Such things as animation, path, map scrolling, vector classes I've 
> > seen in a number of different games.  So those would be a good place 
> > to start. Be also neat to get the different transition effects in the 
> > pcr into an 'transitions' module.  Things like fade to black/white, 
> > the pixelized thing, wipes, warps, etc. 
>
>
> Some ideas on paths:
> 1. My submission to the PCR that launched this thread was a bezier 
> curve submission.  This is a good way of implementing non-linear paths. 
Well there you go.  I just implemented a bezier class myself recently. 
Also I think at least one other person has done one.  How about we 
start there?  I propose we get the two classes put each others 
functionality together, document them the pygame way, change method 
names to use pygame style, update the unittests etc.


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



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

> I think that some basic physics would be a good place to start. * 
> Friction
> * gravity
> * collisions
> * energy transference
> The beautiful thing about physics is that so many things have such a 
> strong relationship that by just implementing a few functions most of 
> the other relationships are implicit.  It may be useful to provide two 
> classes of physics and the ability to specify an degree of unreality 
> by manipulating constants and turning off different physical 
> relationships.
> As to the two classes to consider, interstellar physics (gravitation, 
> etc) is not needed in normal physical interactions.  However space 
> games would benefit from interstellar physics.  These are much harder 
> since you start getting into factorial algorithms since everything 
> interacts with everything else.  I imagine that quantum physics is not 
> required though.  :)  Although it may be kinda neat to have a quantum 
> universe game.
Sounds good.  I think there are a few games/frame works using various 
types of physics.  Be good to have a look at them and see if anything 
looks reusable.

> One game that I've toyed with from time to time is a game where you 
> control an interstellar probe being catapulted from one region of 
> space to another and you have limited ability to steer the object.  
> This is fun because all the objects in game interact with each other 
> and it's not a war based game.  I think that war based games are 
> pretty fun, but the key to independent game development is creativity 
> that would be squashed under the need to make a dollar.

I love physical simulations.  They are really fun toys.  I spend ages 
swinging on ropes, or throwing cubes around ;)


> Transitions is great.  I think that there are a number in the PCR and 
> those could be reassembled into an object framework.
>
> Map scrolling falls into the UI category, right?  Or were you thinking 
> of something else?
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?