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

Re: [pygame] PyGame Runtime

On 5/6/07, Will McGugan <will@xxxxxxxxxxxxxxx> wrote: 
> [Runtime is step backwards]

Surely it is better than the current situation where there all these
great games on pygame.org that are only ever played by other PyGame
coders.

This assertion isn't continuing the argument - it's claiming some goal
is good and presuming your proposal accomplishes that goal. I was
arguing that the proposal wouldn't accomplish the goal you originally
stated.

In your blog you proposed a specific technical option for distribution
in order to help pygame-based games "launch it on the internet, and
perhaps even profit from it". And in your last paragraph you
implicitly suggested that your distribution proposal would make
pygame-based games competitive in the "Casual games" market. My post
was arguing that the distribution proposal you made (a seperate
runtime install) wouldn't help significantly in getting pygame based
games into the mass market hands on windows.

I may have been a little extreme saying a runtime would be "a step
backwards", but my rationale in that is that if you've got some option
that people are led to believe solves some problem, when it doesn't
really solve that problem, then it's just distracting noise. And
because there are already solutions that solve those problems
(installers over packaged apps) it seems a step backwards, even if it
does improve in other areas.


Personally I wouldn't mind a runtime, but I'll grant you that a
lot of potential end users would baulk at having to download an extra
dependancy

This comment seems to miss the point of what I was saying. It's not
about "minding" a runtime, or people "baulking" at having to have an
extra download. Most people won't "mind" the extra download either,
even though they won't go do that extra download. It just comes down
to that if things don't work, most people (in the downloadable market
anyways) will not go figure out how to fix it. It just simply won't
happen.

In the PC downloadable market, you used to see this a lot with DirectX
9 vs. DirectX 8.1 (Win XP originally came with 8.1, although SP2 comes
with 9.0). It killed distribution, so people determined to stick with
9.0 mitagated it with either included runtime installers and special
windows with links to download and all that. That stuff worked pretty
good, i.e. people didn't seem to "mind" the extra install terribly
much.... But with a zip file renamed to an unrecognized extension?
well you can't do any of that hand holding at all. It would ust look
broken. And that would absolutely devastate your download to run rate
on distribution. I'm talking taking it down by like 90+%


I know installers aren't that difficult to create. I've used Inno-setup
myself, it's an excellent system - but its still a hurdle that most
PyGame coders don't want to tackle unless they have something
particularly impressive that they want to distribute. It is also more of
a hassle if you want the game to run on multiple platforms.

I get the multiple platform thing, and I agree it would be great to be
able to build a single package to work on all platforms - but I don't
see the idea of a runtime being a great solution to the multiple
platform thing. So does the runtime include pyOpenGL? Does it include
pyOpenAL? The fmod wrapper the devs compiled themselves? the extension
they wrote themselves? Lets say the runtime includes every extension
you need - what about version of the runtime? If you need a newer
python will the runtime auto update? If it does auto update, does it
break the game that was tested only on 2.4? Basically how do you know
the environment you tested on is the way it will run when distributed?
Granted all of these problems can be solved  with a runtime - but
py2exe or py2app type approaches to packaging solve all these
complexities well.


A runtime wouldn't preclude creating your own install package, coders
would be free to chose one or both methods of distribution. How about a
compromise where the game is attached to a small stub exe that checks
for the presence of the runtime, and offers to download it if it isn't
present? Although that does kind of defeat the cross-platform benefit.

That does sound like an improvement - but it is also a step in the
direction of just packaging the whole thing as an executable with all
it's dependencies in it.