Congrats to the Winners!

Winning games look great - well done guys! :-) Appreciate the feedback on my game too - really priceless stuff to hear from you all. Thank you.

On the negative side, why do judges insist on running games that specify require Python 3 on Python 2? Can I help by adding 'Not tested on Python 2' ? I'd rather you guys were playing other games than debugging mine :-)

Also yet again I have to point out that an is optional for a Python namespace package.

Take care,

(log in to comment)


I made my game abort if people tried to run it with Python 2. Only safe way to do a Python 3 game given how bad people are at reading READMEs.

Yeah, I had to comment out that check in mauve's game :). It's easier to backport the games to Python 2 than to install Python 3 + PyGame sadly.

It really hurts PyWeek I think. Not just the Python 3 situation, but the state of portability of Python games in general. Even us developers fail to run a large number of each other's games. There is not a chance I can let my mom or sister try my PyWeek games. They can never get them working. And the competition is very strong. If I write a game in JavaScript, I can just send the link to my mom and she does not even have to download anything.

A benefit of competitions like PyWeek is to draw attention to such issues and let the libraries and tools improve. But I don't see this happening. It gets worse every year while other platforms get better. I don't mean to complain, just say that maybe it's up to us, game authors to fix this. In between two PyWeeks we could try to figure out the best way to improve this situation.

TL;DR — If you have a Mac OS X PyGame binary for Python 3, please upload it to :).

I agree with cyhawk's comment on the portability of Python games. In particular, it would be very nice if there were an easy way to convert/port, say, a Pygame game into anything that is web playable. I believe there were Pyweek games ported to JS, but from the little that I understand, it is very difficult to do that automatically. If I'm not mistaken it looks like the easiest way is still to port it manually.

Can anyone with experience on porting Python games to the web comment on this? How much extra effort and time did you spend on doing that, compared to the time you spent implementing the game in Python? Did you rewrite everything manually or were you able to rely on anything automated?

I have some experience with that. It's not easy.

I've ported two PyWeek games to JavaScript: Mortimer the Lepidopterist from pygame to HTML5 canvas, and Robot Underground from pyglet to HTML5 canvas + webGL. Mortimer the Lepidopterist is a pretty simple game, so that was probably done with a week of effort. Robot Underground took me about six weeks of effort over the course of five months, but I didn't work on the original and I wasn't at all familiar with the codebase beforehand. I'm also in the process of making a version of Obb, which was originally pygame, to canvas + webGL, but it's not a port so much as a new version, and I'm expecting it to take well over a year. I can estimate that a straight-up port would take at least a couple months.

In all cases I've completely rewritten everything. I mostly kept the same functions and some of the same classes, and in some cases I was able to more or less do a direct translation line by line, just changing the syntax. But I rewrote every line by hand. Core python is actually quite similar to JavaScript, but there are just too many python features that don't have JavaScript equivalents. Some of the gaps, notably comprehensions, are being filled with ES6, but I don't expect it ever to be possible to take one of my PyWeek games and automatically convert a significant fraction. The graphics, sound, and input APIs are all completely different, so I don't think a direct translation will ever be possible here, but I can see a compatibility wrapper being put in place around them.

blakeohare has had more success with automatic conversion, though I'm having trouble finding/remembering which games he's ported. He manages this by writing using a limited subset of python that avoids a lot of the features without JavaScript equivalent, and he uses conversion tools of his own design. alex also ported Goodnight Mr President to the web. I don't know if this can be done with other Bacon games.

I myself have given up on automatic conversion, and python game development in general (with the exception of PyWeek).

I believe it's really important that we improve the landscape for Python game development. Python is used in education and it's a natural target for teachers and school-age pupils. Teachers at the Python UK education track were bemoaning a couple of issues: easy of installing a Python stack (mostly on Windows); and the lack of consistency and clarity about Python 2 vs Python 3 (and we should have courage to say that the answer is Python 3).

It's partly because of those conversations that I wanted to target Python 3 and avoid "complicated" dependencies this Pyweek. I actually found Python3 + Pygame pretty easy to install if you can locate binaries, and my README includes the URLs I used on Windows and Linux. It is evident from the review comments that some people didn't read the README, and simply continue believing that Pygame doesn't work under Python 3 or that it's necessarily going to be complicated to install.

I don't ideologically support cyhawk's attempt to port to Python 2; I think the effort would be far better spent building a simple Pygame package for Mac, because that's the only target I wasn't able to track down. I don't imagine it's hard to compile, but I don't know Mac at all (or own one).

If we can build Pygame binaries, another reachable goal would be to build a simple installer for a Python + Pygame (+ other well known or binary libraries), so that it's easy for schoolchildren and teachers to pick up, and to enable us to share our Pyweek creations with friends and family.

Back in my Microsoft years, I ported my entry for the "Mutate" PyWeek to C#/Silverlight (Moonlight-friendly). This was done by renaming the file extensions from .py to .cs and fixing all the "syntax errors" which took several days. Since then, I've become a programming language hobbyist and I've been working on better ways to either write things in Python and automatically generate something that can be played in the browser or vice-versa. I wrote a programming language called Crayon that compiles to byte code and has JavaScript and Python interpreters. However I didn't finish this before the 30 day cut-off for the competition. Furthermore, even though a Python VM that I wrote isn't technically against the rules (after carefully reading the wording of the official rules), I'm not 100% sure if it's still in the spirit of the competition. So what I did instead was I wrote a Python to Crayon translator right before the competition. Since the translated code wasn't what I was turning in for my official submission, I didn't feel too bad about this. What Cosmologicon said was correct. I carefully wrote in a limited subset of features of Python and PyGame (mouse, keyboard, image blits, rectangles, and nothing else). Unfortunately the translator was written in such a way that it was aware of my typical program structure so I don't think it will be particularly useful if shared. I could possibly clean it up, document it, and add features to it, though, if anyone is interested. Several weeks ago I ported my previous PyWeek entry to JavaScript (the one we did in an hour for the "8-bit" challenge) since the code for that was super short and simple. I did that manually by renaming the file extension from .py to .cry (Crayon) and fixing the "syntax errors" and then exporting to JS. "Mutate" challenge - Shape Shifter - hand ported to C#/Silverlight - (works with Moonlight on all OSes/browsers) "8-Bit" challenge - Saving Sylvia - hand ported to Crayon and compiled to JavaScript "One Room" challenge - Sentient Storage - automatically translated to Crayon and compiled to JavaScript Crayon on Google Code
My line breaks! Vanished! D:

Cosmologicon: Thanks for the comment. It's unfortunate that it takes so much effort to port a Python game. I feel much more comfortable writing in Python than any other language, but I guess if you want to write a web-based game it is probably better to use a web-based language directly (especially since if you port it you'll end up having to rewrite the conveniences of Python anyway).

blakeohare: That's very interesting. Even if you have to code it in a specific way and the set of features is limited, I find it really nice that you can automatically convert a fairly complex game such as Sentient Storage. I wish I had more time to look into that further - my question was mostly out of curiosity.

mauve: About building a simple Python+Pygame installer: while that goal is reasonable, it is also not very hard for us to do a py2exe on our games in order to share it with friends and family (at least those who use Windows, which as you said is common). I guess I don't do it out of laziness, but it does sound like a better solution since they don't have to download anything extra. I used to not like the fact that it inflated the size of the game, but maybe nowadays it's not something that people care about. Maybe a more interesting goal is to turn py2exe and variants into a single easy-to-use program that generates binaries for all main platforms.

I must say that this is a constant dilemma for me also.

I want to develop Python games because I love the language and love developing as Open Source, but if I want non-developers to play my games then I better develop in Unity instead.

In the past I've done some Python + py2exe but now I don't have a Windows machine and so that route is a shot in the dark. I'm on OSX with Linux as a back-up so, like others, I made a conscious choice to keep it simple and limit dependencies because I did not have time to check them.

Perhaps we need a PyPort-Week - a week long contest to develop the best portability solution for Python games!
it is also not very hard for us to do a py2exe on our games in order to share it with friends and family I actually found it a nightmare. The closest I came to distributing binaries was a successful run of py2app on OSX--but even this required me to manually edit some paths that it wasn't able to set up correctly (for assets). But yes, I tried everything, on every platform, py2exe, PyInstaller, py2app, cx_freeze--they all had some problem with some dependency (for me personally it was the NumPy requirements of some PyGame features) that I couldn't get around.

The scripts in the skellington package are very helpful in setting this kind of thing up (this is the only reason I got py2app to work that one time), but they are out of date and didn't work without some massaging--perhaps some kind soul could share their cross-platform python binary distribution wizardry? Then we could update skellington and make it easier for entrants to make at least one or two binaries.

I myself have given up on automatic conversion, and python game development in general

Its super sad to hear this from someone as talented as Cosmo, but I echo the sentiment--I don't even think about python anymore when looking to do new games or programs that I actually want people to see or play.