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

[Patrick Mullen <saluk64007@xxxxxxxxx>]

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!)

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

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.

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.

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.

On Tue, Dec 8, 2009 at 10:54 AM, René Dudfield <renesd@xxxxxxxxx> wrote:
> Hi,
>
> I've been working on plans to make distributing games easier.  So
> people can more easily let their friends and families play games they
> have made.
>
> Part of this plan is to make binary creation easier(zip files
> containing your game for each platform specifically).
>
> The current situation is that people need to get py2exe py2app,
> cx_freeze and other modules setup, and working in their setup.py file.
>  Then they have to adjust things for how their game works, and then
> get access to every platform.  Unfortunately each of these things
> changes occasionally, so old setup.py files do not work for other
> people.  This results in people not making binaries for every
> platform, and makes it hard to share games with your friends and
> family.
>
> So the plan is to make our lives easier creating distibutables for
> every release of some game we make.
>
>
>
> Basic idea:
> ===========
>
> To be able to copy your game into a directory for each platform and
> your job be done.
>     `cp -r YOUR_BITCHIN_GAME game_launcher_macosx/games/`
>     `cp -r YOUR_BITCHIN_GAME game_launcher_win_x86/games/`
>     etc...
>
> Then you can zip up that directory and send it to a friend.  There
> will be a python module available to automate this stuff.
>
>
>
> Make a game_launcher package for each platform.
> ===============================================
>
> Where this bundle would be something like:
>   - game_launcher_macosx
>   - game_launcher_linux_x64
>   - game_launcher_linux_x86
>   - game_launcher_linux_arm
>   - game_launcher_win_x86
>   - game_launcher_win_x64
>   - game_launcher_win_symbian
>
> That is have a directory with binaries for each platform.
>
> Then you can easily make your game work for that platform by copying
> your game files into a directory like this:
>     `cp -r YOUR_BITCHIN_GAME game_launcher_macosx/games/`
>
> Your game would have to have a run_game.py script which calls your
> games main function and starts up.
>
>
>
> Libs.
> =====
>
> Most commonly used python game libs would be included (numpy,
> pyopengl, pyaudio, PIL etc).
>
> These generic bundles would have many of the common modules used for
> making games included.  You can just copy in any other libs you need.
> If the module requires platform specific code, then that can either be
> made independantly or otherwise.
>
>
> It would allow people to create 'game_launchers' for various platforms.
>
>
>
> Automating distributable generation.
> ====================================
> This would just involve some scripts to copy your game files to the
> game_launcher directory
>
> This would be a library, like:
>     pygame_distribute.make(my_game_path, output_path)
>
> Or it could be a distutils command part of peoples setup.py scripts...
>     python setup.py pygame_distribute
>
> (which would copy the distributables into dist/)
>
>
> I don't think it should come with pygame, since it would be quite
> large... like easily 200MB for many platforms.
>
> With extra config it should be possible to upload releases as well.
>
>
>
> What about debian, rpm, macports, archlinux, other distros?
> ============================================
>
> We should be able to make this easier somehow.  For example, arch
> linux, and macports just require a text file with a link to the
> source, and a few dependencies listed.
>
> Although creating packages for these systems is not the initial aim,
> it would be good to consider them.
>
> How can this work with symbian?  Any ideas Jussi?  I'm not sure it
> will work, as apps need to be signed I think.  Or maybe there is
> someway around that for use on your own devices maybe.
>
>
>
> What does it give us?
> =====================
>
> This would let people make distributables for their games on multiple
> platforms without being on those platforms.
>
> As an example, to make windows binaries without being on windows.
>
> No python dependency.  People will not have to download python and
> install it to play your games.
>
>
>
>
> What does this plan not do well?
> ================================
>
> It won't make installers for all platforms.  The idea is to create a
> zip folder if possible for each platform, or an installer for platform
> that does not require running on the target platform.  It should be
> possible to make packages for some platforms without being on those
> platforms too.
>
> Most suitable for open source games.  This is because the source code
> will be more easily obtainable than using something like py2exe.
> However games can still be commercial, and release the source code.
> However commercial games may need to use another solution (or pay
> someone to have a solution made for them).
>
>
>
>
> Why not distutils, py2exe, cx_freeze?
> ============================
> We will use it to create each launcher on each platform.  However
> distutils does not work to create distributables on each platform.
> eg, I can not create osx binaries from linux with distutils.
>
> This way is more robust, as the launcher can be made and tested once.
> Then reused by many people on every platform.
>
>
> Is this a launcher/player?
> ==========================
>
> No.  Also yes.  The idea will be to create distributables for your own
> games.  The launchers will not be generic pygame players - where you
> download many different pygame games to play on the launcher.
>
> The launchers will make it easier for work to be distributed and
> tested easily. However they will be to make separate game
> distributables, not to share games in one launcher.
>
> Although a pygame player is not the aim, it could be an extension in
> the future.  There have been many attempts at creating pygame players
> in the past, and none have been too successful - so making a pygame
> player is an anti-goal (for now).
>
> Instead we will concentrate on making a library, and folders for
> simplistic distribution.
>
>
>
>
>
> Status
> ======
>
> In planning and prototyping so far.  Looking for ideas.
>
> I have a working setup.py script for win, linux x86, and osx for some
> games - like many games have since 2004 or so.  These would be changed
> to make game_launcher_* directories.
>
> A python module with hundreds of megs of data would be made available.
>  Also platform specific launchers could be gotten.  This will allow
> separate maintainers to upload launchers for different platforms.
>
> I hope to try out a prototype for the coming ludumdare.com 48h
> competition this weekend.  Hopefully other people using pygame for the
> competition will be able to help test it out this weekend too.
>
> Once generating zip files/binaries is completed ok, then other factors
> for distribution can be discussed.
>
>
>
>
> Thoughts?
>