Re: [pygame] making game distribution easier, part 1.

[René Dudfield <renesd@xxxxxxxxx>]

On Tue, Dec 8, 2009 at 9:56 PM, Patrick Mullen <saluk64007@xxxxxxxxx> wrote:
> I like this idea. Ever since I can remember I have always used a
> similar method for distribution of my games. I went through the py2exe
> pain once, creating a minimal setup.py that would import all of the
> dependancies I need, along with some fine tuning to eliminat stuff
> that it always pulls in that I never actually need, recompressing
> things with better compression, etc. But the actual game code is run
> from a separate directory. It means I never have to run setup.py again
> to release new versions, just pop new source files in there and it's
> done. (And patch using the same patch files on multiple platforms!)
>

yeah, cool.  Good to hear it works out well already :)

> It wasn't very well planned or thought out, nor had as many targets as
> you are going for, but I think this is something that should be
> available to people. It's a missing piece of the puzzle. "Ok, I
> learned all this stuff. How do I distribute my game? py2exe? setup.py?
> WHAT?"

indeed.

>
> Some issues:
> Not only do you have to target different OS, but when making a general
> launcher, you have to think about the various versions of python. So a
> separate set of launchers for each python. Not a big deal probably,
> you download the launcher set for the python you are using. Just can't
> forget it. Probably 2.5 and 2.6 are the only important targets at the
> moment. Does any game lib work on 3.0 yet? Probably not enough at the
> moment to worry about it.
>

I think sticking to one version of python is probably a good idea to
start with.  However, I can see people making suitable launchers for
different python versions easy enough.  In that case people can choose
from the available launchers.


> Also, different versions of libraries. Probably using the most stable
> version available by default is fine. But I know of a few cases where
> the "right" version of a library is not constant across platforms. I
> can't remember what those cases are but I've run into it :P Probably
> not as much of an issue, as long as it is easy for people to add
> libraries that are on systems they don't have access to.
>
> Also, I'm confused. You say that it should include useful libraries,
> but not pygame, because pygame is too big? I would think pygame is one
> of the most important things to include. It doesn't really matter how
> big the "toolkit" is, as long as the resulting zip file are as small
> as they can be. Libraries not needed can be deleted from the result,
> or maybe the build function can take a list of libraries used. The
> py2exe method of guessing libraries doesn't really work that well.
>

Ah, yeah I meant to include pygame on that list.

> I think it's wise to not focus on the "it could be like steam!"
> aspect. If that comes as a result, so be it, but it's somewhat beside
> the point. I still expect a lot of people would wind up only making a
> windows release or using py2exe thinking it hides their source, but
> probably less if there was something like this available. Lol.
>
> Hope this works out.
>


thanks for your comments.