Canvas/WebGL & Python

Löve game engine has a crude but already working webplayer - it produces HTML5 games that make use of WebGL (https://github.com/ghoulsblade/love-webplayer) Some recent Ludum Dare games used it.

Does anyone know of something similar but based on Python? Pyglet already used OpenGL... but it seems dead. Any clue?

(log in to comment)

Comments

Running Python in a browser is really hard! I've tried, for my https://github.com/jtruscott/pytality library. I can tell you what my research has found, at least.

Jython used to have applet support, but removed it before they even started supporting python 2.5.

I was able to get it to work by running IronPython inside Silverlight, but it was a huge resource hog and nobody likes Silverlight.

From some research I've done, it might be possible to embed IronPython in the Unity engine, but it looks like nobody's done the dirty work yet.

Similarly, it might also be possible to run Python via Google Chrome's NaCL stuff - but I can't find any working examples of that to build off of, either.
pyglet is not dead. The community is just struggling to put out a new release. It's not going to help you get Python in the browser though.
Rectifier: Unity uses Boo, which is Python (a smaller set), although most people stick to UnityScript and, even better, C#. Why would you embed IronPython? : )

Richard: Those are good news. I just tried to run the latest version (2010?) on a Mac and it won't work because of Cocoa... and it's a hell to configure it. I truly hope there's a new version soon. In relation to browsers, I just said it because it uses OpenGL... and somehow I related it to WebGL. Not because I was expecting it. 
Woodwolf, until the cocoa port of pyglet is released, you can do: 
arch -i386 python run_game.py
to run pyglet apps on snow leopard/lion. This will make sure that the 32-bit version of python is executed from the universal binary, which is a requirement to interface with Carbon.


 
Woodwolf: Because it implements the whole CLR to do C#, presumably IronPython would run without issues. And if you do it that way, you have full Python 2.7 support, not a small, python-ish language.

My personal motivation is to have a library that works either natively or in-browser with the same code, hence why I don't like Boo. And I don't want to require any game-specific downloads, because the LD48 crowd really likes fully in-browser games (otherwise, a local Python webserver plus a JS drawing bridge would be viable).
I actually got one of my PyWeek entries to work in the browser without making any code changes by using IronPython+Silverlight. I did however have to create a mirror implementation of the PyGame API that wrapped calls to Gamelight (a Silverlight game library I made a while back).
Wow, excellent. I'm not sure I remember that. Do you have a link to the web version?
It was a proof-of-concept prototype that was on a work laptop (oops) that I no longer have. :(

Although I've been itching to revisit the concept...perhaps after this pyweek is over.
Oh wait, I found it!
http://blakeohare.com/projects/SoulShenanigans/ 

Unfortunately what I said in my previous post is still true about the source code for it :\
Thats pretty awesome, but the game itself has too high a frustration value
It's actually impossible to jump over the hole at the beginning of the 2nd level since I didn't get to implementing all the keyboard constants in that prototype and therefore you can't run. The native Python version is a bit more fulfilling and easier and doesn't cause netbooks to catch on fire: http://pyweek.org/e/np/ (press Z to run, X to shoot enemies, iirc)