Re: [pygame] Where to next?

[Jasper Phillips <jasper@peak.org>]

On Sun, 13 Jul 2003, Pete Shinners wrote:

> 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! :]

Heh. :-)

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

Whistle.  That sounds like a bunch of work, is it really worth it?  IMHO this
is the sort of thing that might get added by an interested outside party,
were the rest of pygame compelling enough.

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

The lowlevelness of pygame can be very frustrating.  From my standpoint it
provides some nice media access -- but that's it.  Alot of time is spent
working out mundane details.

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

Yes!  Although I think a framework is far preferable to a library.

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

This sounds interesting, but somewhat vague.  What exactly is a scengraph?
Is it essentially a graphics optimization?

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

IMHO a high level library/framework absolutely would bring better games, as
more time could be spent on game evolution and playtesting.  Plus, you would
attract people who are more serious about game development, and not just
doing it as a hobby.

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

Especially if you can get people onboard to use it during development,
and to talk about areas of code they have in common.

> 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 ;]

Hmmm.  Now this sounds alot like optimization to me, which is all well and
good, but not exactly high level...  Shouldn't this sort of thing be added
later?

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

The real question is how many people do you have that are interested in
actually helping out?  It would be a mammoth task for one person.

-Jasper