Simon Wittber (Maptek) wrote:
It seems to me as if pygame is getting to be a rather stable and mature
gaming library.
So, where to next?
break it of course! :]
i've had many a long session trying to think what would push pygame to
the next levels. pages and pages of notes are sitting around my desk.
in some ways there are some neat ideas, other ways i'm not so sure.
there's no way i can get deep into the specifics, but i'll just throw
out some of the more main features i've been thinking of.
first off would be a break from SDL. currently pygame isn't much more
than a cleaner version of SDL. i don't think much more can be done for
pygame unless it becomes its own api. SDL would be pushed back as just
one of the available backends for pygame. The other obvious backend
would be opengl. From there i'd also like to see some other backends
that really embed into other libraries. this has huge implications, it
is perhaps even too much of an undertaking?
pygame is still a very 'lowlevel' game api. i've noticed it's
impossible to make much of a game without wrapping just about every
part of pygame into more specialized classes for your own game. at
some levels this is good, but on many levels it requires a lot of "cut
& paste" code reuse. it's also the 'laborious' part of creating games,
i'd always much rather get into the 'fun stuff' than deal with image
loading and resource management.
along this line i've spent a lot of time trying to think of ways to
create a highlevel game library for python. something that could still
be used for any style of game, with prebuilt engine parts for popular
types of game.
so far the thing that i see with the most potential is a sort of
'scene graph'. for a long time i couldn't really find a way to make
this work and kind of wrote it off. later i started digging into other
scene graph libraries. i became very inspired by the old SGI Open
Inventor scene graph (and more recently, COIN). after several
'enlightenments' on how to treat scene graph nodes, i think there is a
potentially good idea here.
hard to explain it all here, open inventor is more specifically
designed for 3d scenes. at first i thought we could use the exact same
scenegraph, just adding a few of our own nodes. but playing with
sample game scenegraphs, i think we would be better served by creating
our own unique set of nodes.
i've got many iterations of sample pygame games written in a new
scenegraph style pygame. this is surely the best way to go about
creating some new game library. write the games first and create the
library to fill them in. i like this because we really get a clear
picture of what we will end up with. very easy to see the
repercussions of different decisions.
in any event, i still don't have all the answers. i've not found any
magic design that seems to solve all the problems. i still have many
questions and doubts about even trying to move forward.
the biggest question is would it really matter? would we find people
are able to create better games? i don't think games would get better
on there own, but i do believe people could create games quicker, and
it would be much more accessable to new programmers. in the end those
two factors could create better games after awhile.
can it even be done? it's a huge undertaking to get all these ideas
implemented. on the other hand many of these ideas could be built on
top of existing pygame, and some things are only incremental changes
or enhancements. i think the only feasible way to do anything like
this is to map out an incremental development path that gets from
pygame to pygame3000 with a working game library all the way through.
the cool thing about the scenegraph, i believe it answers just about
all the requests and ideas people have had for pygame over the years.
grouped rendering primitives, map rendering nodes, very cool filters
and special effects. there's tons of rooms for possibilities, but it's
probably good not to get ahead of things.
personally, the part that gets me most enthusiastic is creating the
software rendering engine to handle the scenegraph. when the game
engine has knowledge of the entire scene before rendering, every pixel
can be optimized quite handily. rendering would be done with 0
overdraw. the "update rectangles" of pygame old would be handled
completely automatic by the SDL backend and also be optimized down to
each pixel. of course all this will be unnecessary for most of the GL
optimized backends ;]
well there's part of the dream. i haven't even begun to try
implementing anything. it's just to much to dive into. the only way it
could get started is with a clear development path. every step would
need to be planned out in detail before starting, otherwise it just
cannot get done.
Some random comments on various posts...