On Tue, Dec 8, 2009 at 9:56 PM, Patrick Mullen <saluk64...@gmail.com> 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.
