Making Pygames more easily runnable.

There are a few things which would allow pygames to be run more easily. I had a little chat with Phil the other day about where pygame could be heading. So these are some of the things we talked about. In case anyone else is interested.

First though, the why. Why should pygames be easier to run? So all of the people making games can have their friends and family play them. So they can get more feedback about them. People like feedback - feedback is an engine which drives people to work on something for fun. They create things in a way, and want to show the world. Or sometimes people make things to just show their friends and family. Or their peers. However do you want opinionated, uneducated game players giving you feedback? Isn't a nice little community of game developers a worthwhile thing? I don't want to lose our nice little pygame community of artistic folks. People interested in making small games, rather than working on engines - and 3D MMORPG web browser plugins (as their first game). Do we want people to install pygame, so they can modify the games themselves? Tweaking games is the most fun part of games for some creative people. So making pygames more easily run-able should be for those who want non pygame programmers to play their games - however we should still try and let people modify games. Once people modify games, then they can create new games themselves - or continue to modify existing games.


So here is the list of things which could make pygames more easily runnable. Most of these are _not_ new ideas - these ideas just need to be done well.


* installer maker scripts which work. So people can go python setup.py make_executables and it would generate executables for each platform it supports. Failing that it could make it for just the platform it is running on. It should work out of the box on at least MacOSX, Windows, and Linux. There's been installer scripts around since 2001 - however they are just not polished enough. Recently Phil of Galcon fame has worked out a lot of the issues for macosx, windows, and linux binary generators. I think these will be a great start - however they'll need a bunch of tweaking to support other popular difficult libraries - like pyopengl, pyode, and pyogre. A common game skeleton would help too.


* a common game skeleton(or using convention). Richard plans to make a skeleton for the next pyweek. So each game would have common directories. Eg. a data/images data/sound data/music directories. It would be run with a main.py script, or something similar. It would have screen shots in the screenshots/ directory with file names: screenshot001.png screenshot002.png screenshot00x.png It might have a .ini file with meta data like game instructions, name of game, authors, etc. Stuff like that. People have been proposing a common skeleton since 2000. However it needs to designed quite well, and we need the pygame, and pyweek site to document it well, and encourage people to use it. So we first need to design a skeleton which will work for everyone - and then update all the tutorials, and documentation to use it.

* a portable pygame runner. Something which could take a .zip file or a directory, and run the game. The runner should be able to run on at least macosx, windows, linux, freebsd etc. There have been a few attempts at this over the years - and it's been suggested about 100 times. However it's quite hard work getting this done. Phils work with the installer scripts will help out a lot here. I can't remember the other efforts to get this working. Something which used OS level protections would be great too. Things such as jail, chroot, ulimit, capabilities etc. There is work on safer python which works quite well. However OS level protection would be great too. Also a way for people to inspect games before they can be played on the runner - giving quality control and trust to the games available.

* Converting to flash swf, AND/OR javascript. Pypy is a great little python which has backends for javascript. Haxe is a javascript/actionscript compiler that can generate .swf files, or run javascript. So write the pygame api in flash/javascript(with the canvas tag) then have pypy pipe its output into haxe - which would generate the swf file. Phil has done a manual conversion from a pygame to actionscript - using basically the same api. So theoretically it should work quite well.

* More games getting into distributions. There's heaps of pygames these days. Good quality pygames. If more of them get out into the world, then there's going to be more pygame installs around. There's only 3 pygames in debian for example!!! If more pygames get out there - then people are more likely to install pygame. So we need to make it easier for people to publicise their games. Help them to port their games. Help people to announce them on freshmeat, and big game portals.

* Getting pygame installed by default in OSX. Python is installed on OSX by default- so why not pygame too? OSX is supposed to be about letting people do things easily - making games easily would be a good fit for them. Even getting SDL installed on OSX by default would be great - since then it's much easier to get pygame working. Especially with Alex's great work on pygame-ctypes (if ctypes is to be on OSX too). It'd be great to start an effort to get at least SDL installed by default. Does anyone have connections within Apple? Who are the Apple python people? Who are the Apple game people?

* The OLPC project will increase pygame usage a lot. However I'm quite scared about millions of kids using pygame - how will this change the community? It would be great if the OLPC people could come to a pygame mini sprint - we really need to start working on the issues. I'm not sure who the OLPC people are who are working on pygame? So if anyone knows - please let me know?





Written by a Melbourne web developer. Available for your projects - php, mysql, e commerce, javascript, CMS, css, flash, actionscript, python, games, postgresql, xml.