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

Re: [pygame] PyGame Runtime



Cameron Blackwood wrote:
> How about "if you build it, they will come"?
> 
> If someone _did_ gather and build a 100% stand alone 
> 
>   python + pygame + opengl + openal + ogre + etc 
> 
> 'tree' for windows, mac and linux then I think you'd
> find that a lot of people would start to use it in preference
> to the current 'roll your own/install lots of packages' system.
> 
> No dependancy hell, no more downloading libfoo-1.2.3 too. If you finish
> with it, just 'nuke' the tree (no registry hell, no package tracking).
> That would make creating 'game cd's very easy too.

Don't you still have dependency hell with this system? i.e. I write a
game with features in today's Ogre, and it's not in the "tree"
(repository), so the suer has to retrieve it and build it separately.

If I got to pick one impossible dream to fulfill, I would definitely
prefer dbcad's solution of a standalone apt repo which is dedicated to
maintaining builds of whatever versions of whatever libraries are
needed. For PyWeek games, you can probably guess that most of them are
built using fairly similar versions of the above tools.

I think in the ultra-casual market, Pygame is going to forever lose to
Flash. Flash games run straight from the browser with no download. I
don't think we can beat that, at least not with a technology like the
one proposed by Will McGugan. Do we want to try to undercut Flash? If
so, what we need to do is start thinking about how to effectively
sandbox Python (widely accepted as impossible?) and get pygame apps to
run in the browser (deep magic?). I'm not sure this is a worthy goal
for us in any case -- it certainly doesn't excite me personally.

Ethan

Attachment: signature.asc
Description: OpenPGP digital signature