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

AW: [pygame] cleaner pygame



Title: AW: [pygame] cleaner pygame

Hi,

  in my experience it's better to write another game with a similar context (say space invaders), and compare the requirements and the implementation to get to a higher abstraction level. From there you can tell what would be a framework for these types of games.

Dirk

-----Ursprüngliche Nachricht-----
Von: Pete Shinners [mailto:shredwheat@mediaone.net]
Gesendet: Freitag, 4. Mai 2001 03:35
An: pygame-users@seul.org
Betreff: Re: [pygame] cleaner pygame


> Maybe it would make a good project to see how pygame can be
> improved in ways that help make the python code more clean.

this is something i've had on my mind from time to time..
how can it be cleaner. i've been working with the guy doing
the ruby port of SDL, and we've gone over the decisions i
had made and what he might do differently. as it turns out
we've been deciding everything is actually quite good.

from what i've found, pygame is still pretty low level.
aside from blit, everything i did in in solarwolf had an
insulated layer over pygame. i have my own "gfx","snd", "input"
modules to do my own slightly higher level abstraction of
these components. i think if i was doing an even larger project
i'd want to really create a thicker level of insulation between
my game code and pygame.

lately i've been thinking about building some sort of python
game framework on top of pygame, but i don't know if it's possible
to take things much higher than pygame currently is and still be
very generic.

the things that could make pygame easier to use at this point
might be some helper modules that take care of some of the usual
game development gruntwork, but i don't know exactly what these
should be. i plan on going back through the solarwolf code and
trying to isolate some good generic classes that i might want
to mold into something included with pygame (or at least in the PCR)

i almost get more out of looking at other people's game code
so i can see how they interpreted the interfaces and where the
code ends up getting tangled. :]

anyways, at this point i don't really plan on changing the pygame
interfaces at all, but there is definitely room for enhancement.

but anyways, it is a good idea ray, and i'll plan on looking through
the pygame code with 'new eyes', seeing if i can find spots that are
rough (or spots that could just be smoother) in relation to pygame.

i'm also wide open to ideas and suggestions


____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org