> We see more major titles written in Flash and ActionScript than we see written in Python.
People want to write games in Python (myself included). They really do. The problem is, try to get pyopengl/pyglew/pygame/pyogre/pysdl or whatever running on your development machine. Now try to make it work on five different machines, across Windows/OSX/Linux. Then try to create a reliable distribution scheme for it.
I've tried it. Even the first step is painful, often requiring intimate knowledge of C, autoconf/make/whatever build systems and the system you're targeting, jus tto get you going. It's such a pain I just end up writing stuff in C, and only maybe plug in the python stuff later on, if at all.
Really, the lowest levels like PyOpenGL should have been part of the official Python distribution, just like tkinter, even if they are thin ctypes-like wrappers.
As a counter example, I once had a hard time getting pygame running on OS X. I don't remember exactly what the issue was, it may have had something to do with multiple versions of python installed on my machine, but it was enough of a pain that after a couple of hours trying to figure it out I decided I didn't care enough about checking out pygame to work it out. This might have been the kind of thing that someone more experienced in python would have known how to solve immediately, but for me at the time it was too much.
On the other hand, on other machines it was a breeze to set up.
which works, although installing from pygame's HEAD doe snot sound engaging. What's more, note the date and title.
Pyglet's master branch still uses Carbon, so you have to use a years-old experimental Cocoa branch, which won't be merged because it requires pyobjc[1]. This in turn requires pyobjc, which requires a little trickery to install:
export MACOSX_DEPLOYMENT_TARGET=10.6 # else it'll fail at finding some libs, and stubbornly tries to stay in 32-bit land
easy_install pyobjc-core==2.3 # else pyobjc fails to build this by itself
easy_install pyobjc==2.3 # finally
Really? Because I couldn't get the Ubuntu package or the one from pip to work. And the last article on HN that mentioned it has the author having to install it from a bundle on the pygame site, which is also what I ended up doing before moving on.
Didn't the author mean using python as a scripting language for gameplay with a C game engine for the other stuff? Do you really need all those opengl / ogre / sdl whatevers; is it not possible to just have a python interpreter running in your game engine and only running vanilla Python code?
That's how we've done it before with LUA and other scripting languages in game dev. You don't expose anything low level to the gameplay scripting beyond simple primitives. You certainly don't touch anything to do with OpenGL - even the C++ game code rarely goes that deep.
You can, but I've been told that integrating Python is a lot more involved than integrating Lua. People who've done it mostly seem to complain about (a) the relative complexity of Python's object model, and (b) how obnoxious it is to maintain reference counts efficiently.
I've done both, and neither seemed all that difficult, but then again our scripting requirements were pretty primitive.
> is it not possible to just have a python interpreter running in your game engine and only running vanilla Python code?
Sure, but it means much bigger swaths of C/C++ code
and your game app is no longer a python program that
imports some extension modules for performance critical
tasks or third party lib bindings.
Yeah, the freely available Python libs may not seem polished enough. [edit: not that I have experience trying to ship multiplatform games with them] But: if you flip it around embedding Python in your C++ framework as a "scripting engine", it's pretty crappy
too compared to a natively Python-driven system. And
since most people aren't starting from scratch it's
not so easy to configure the custom engine as a bunch of Python
extensions either.
I haven't tried it myself, but have you experimented with Panda3d? It's a game engine that supports code written in Python, but it has a much more coherent story for getting set up for development, and for distributing your game when you're done.
Oh goodness. This. I used to work with a friend on a port of a game to Python. PyGame installation was fine - but pygame also had horrendous performance! The library we ended up using was really, really difficult to set up for development.
We briefly had to make our own library for reasonable 2D performance.
People want to write games in Python (myself included). They really do. The problem is, try to get pyopengl/pyglew/pygame/pyogre/pysdl or whatever running on your development machine. Now try to make it work on five different machines, across Windows/OSX/Linux. Then try to create a reliable distribution scheme for it.
I've tried it. Even the first step is painful, often requiring intimate knowledge of C, autoconf/make/whatever build systems and the system you're targeting, jus tto get you going. It's such a pain I just end up writing stuff in C, and only maybe plug in the python stuff later on, if at all.
Really, the lowest levels like PyOpenGL should have been part of the official Python distribution, just like tkinter, even if they are thin ctypes-like wrappers.