cyhawk on 2014/10/27 08:41:

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 pygame.org :).

Cosmologicon on 2014/10/27 17:00:

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

blakeohare on 2014/10/27 17:55:

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

Tee on 2014/10/27 19:12:

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.

assertivist on 2015/02/26 22:02:

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.