[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Growing Pygame



Hey,

My conclusion, in case you don't want to read the ensuing ramble:

- I prefer pygame to stay as is being only enhanced with C-land extensions, etc. 
- Other stuff can be shipped as separate libraries on the pygame site (see, pgu, ocempgui, lgt, pygext etc...)   "release early, release often"
- If there are certain needs on the website that will help people better communicate or share their stuff, please get your suggestions in :)  An update will be coming pretty soon.

Ensuing ramble:

I suppose I'll put my 2c in now.  I've been thinking over this for the last few days.  This might be a bit rambly as I'll just sort of cover a lot of my thoughts on the matter.

I *like* pygame not having any game logic / scene rendering / etc in it.  (Which is why, if I had my way, we'd deprecate pygame.Sprite .. and pygame.Movie since it isn't shipped with pygame half the time anyway.)

I like when pygame gets new features that are *impossible* to add via python code -- such as the clipboard feature which I can start utilizing in pgu after the next version of pygame comes out.  The blit blending modes are also really nice, as that was impossible with pygame before.  The addition of jpg, png saving is great. 

So, I think in the past few months illume has done some great work getting in a few *much needed* features into pygame.  The few features that I still really want are things like audio-in and multiple windows, both of which depend on SDL releasing SDL 1.3, so I'll just have to wait :)

The limiting factors for me, lately, have been speed and graphical tricks.  The blending modes are a helpful addition, but I do think getting openGL in there would be nice as well (looks like the next SDL may have that, so again, nothing needs to be done for pygame.)

On the speed front, rendering some stuff or doing fully custom graphical tricks or having 10,000 objects on screen is just not very possible with python+pygame, so lately I've been building games that depend on some custom C/SWIG extensions I've made.  I wouldn't mind seeing pygame include a souped up version of this:
http://www.cs.tut.fi/~ask/cinpy/
(If I get excited enough about it, I might just work on getting it all working.)  That would allow any user to compile C-code on the fly which would be a huge help for people creating pygame libraries that support high intensity particle systems, massive collision detection, 10,000 objects, crazy graphical effects, etc...)  It would make many things possible which at present are not possible without pre-compiling the extensions.

Regarding a pygame-contrib helping people code more, I think the pygame projects on the website do that already.  Over the last year I found by releasing a new pgu package about once a week for a few months kept people sending in suggestions and requests and bug fixes non-stop for quite some time, until now it is getting fairly stable.  I suggest you start releasing your code and see what kind of response you get.  I think pgu has 200+ users now.

(As a side note, I've written down all the website requests and will probably implement all of them when I have a spare moment here soon :))

On the template code front that pete suggested (having basic engine parts people can use to customize), I think a great place for that would be the pygame wiki.  Just slap your code between <code> </code> tags and there you go.  The wiki is open to just about anything and if someone wants to start up a code-snippet with tutorials section in it that would be fine.  Feel free to even add project releases onto the pygame site to point to your wiki pages.  If a few people join in and really get that going on the wiki, I'd be glad to add a top-level link directly to it.  Or if the wiki format won't fit the bill I could probably whip up another module for the site to support the specific need here if there was notable interest...

Regarding generic "engines" that anyone can use, I don't think they exist.  I created pgu with some thoughts that it might be somewhat possible.  pgu includes a tile engine, a isometric engine and a hex engine.  People have used these with some success, but I've found personally, that I usually take one and hack it up and re-work it for any new games I made (except for the simplest ones) just because it gives me more control over the graphical effects and look of the game.  (Again, see my stuff about cinpy above.)

The real nice thing about keeping the core of pygame as slim as possible is it isn't contraversial.  If pygame -- say -- added the pgu.gui, because it needs a gui, there would be a lot of debate about it, I suspect.  I mean, it doesn't do x, y, z, it does a,b,c in a weird way, it this and that ... etc ...  So what's the value of having it as part of pygame?  Not a whole lot, really, since people can download pgu and add it to their game with no trouble at all. 

For me, I'm thinking about reducing pgu to mostly just the gui, since a lot of it's parts would probably better serve people as code snippets in a tutorial.  (Don't hold your breath though, I doubt I'll ever have time to do that! )

Regarding concerns that pygame isn't getting used enough or isn't "big" enough -- I think it's quite popular -- search for "game development" on google -- its in the top 10. 
Usage of the website is up over 40% since one year ago.  pygame gets about 9000 downloads per month!

Anyway, that's more than enough blabbing from me.  The bottom line is:

- I prefer pygame to stay as is being only enhanced with C-land extensions, etc. 
- Other stuff can be shipped as separate libraries on the pygame site (see, pgu, ocempgui, lgt, pygext etc...)   "release early, release often"
- If there are certain needs on the website that will help people better communicate or share their stuff, please get your suggestions in :)

Hope that helps!
Phil

Marcus von Appen <mva@xxxxxxxxxxxx> wrote:
On, Mon Jul 24, 2006, Simon Wittber wrote:

[...]
> 1) Lots of pygame development is happening, lots of people want to
> share their work, but it is usually not immediately accessible and
> usually slips under most peoples radars. Pygame has not grown much in
> the last few years, even though people do see to want more. See this

Does it need to grow? "Lots of pygame development" is happening so how
and why should it grow? And in which ways should it?

Phil did a great job with the new pygame website, the instant addition
of projects and the wiki. In my opinion it really brings pygame forward,
because many more people now register their projects there to show, what
they have done. So it surely fits the most basic needs people have to have
to realize their ideas, not?

> Not a whole lot has happened since.

Hm, let me see. Clipboard support is on the way, a mature and stable API
exists and a more or less full backwards compatibility is maintained so
far. I would call that a lot, if you think about pygame as a wrapper of
SDL with several nice additions.

>
> 2) It will help build better games faster. I'm reinventing the wheel
> all the time, (its a bad bad bad habit) however, I always use

Why do you reinvent the wheel all the time?

> officially blessed tools rather than my own. Having an officially
> blessed set of tools will help lots of people make easier decisions
> about what to use. A tool from the contrib module would become blessed
> when it moves into the pygame namespace.

Will it? Having an officially blessed set of tools does not mean, that
there no others, which might do the job better for that particular
case. It means: we recommend those, because they fit for our subjective
needs (without possibly looking to the left or right).
Once its in an official tree and you encounter a better tool with the
same approach, you only have the decision to stick with the blessed one
OR to break compatibility and import the new one. That can become
critical.

> A pygame contrib trunk could be created which is expected to work with
> the pygame svn head. When pygame is branched/tagged for release, so is
> pygame-contrib.
>
> Barriers to entry for coders should be minimal. Eg. Plain ascii
> docstrings, tests using the unittest module and new style classes
> should be enough to get a piece of code considered for inclusion in
> pygame-contrib. The pygame-contrib maintainer(s) would vet submissions
> for correctness, consistency and usefulness. Once a piece of code
> proves its usefulness for general pygame development, it would be
> considered for inclusion into the pygame namespace by the pygame
> maintainer(s).

This would limit the contrib module to only small bits, not tools, but
helpers, like e.g. that A-star algorithm, someone made for pygame and
stuff. I wonder, if that does not lead to more problems than it will
solve..

> So, who is with me? :) If the pygame maintenance crew thinks this is a
> good idea, I have an implementation plan ready for discussion.
> Otherwise, I'll just keep reinventing my wheels :)

I am a bit concerned. Not because I do not like that idea, but because
of the problems, it adds.
Instead of adding a new contrib package I would recommend to directly
add sufficient and well designed code into pygame's HEAD tree, add one
or two people with plenty of time to keep the code up to date and stable
and that's it as someone already suggested. A different branch, which
possibly can get out of sync with the pygame development does not bring
any value or pygame forward.

Regards
Marcus


How low will we go? Check out Yahoo! Messenger?s low PC-to-Phone call rates.