[quake3] Python game code

Neil Toronto ntoronto at cs.byu.edu
Sat Nov 18 14:25:24 EST 2006

Matthew R. Dempsky wrote:
> (Please don't mark messages as In-Reply-To other unrelated posts.)


> On Sat, Nov 18, 2006 at 01:43:14AM -0700, Neil Toronto wrote:
>> What sort of interest is there for an option to code the game (not the 
>> engine) entirely in Python?
> Isn't there a Python-to-C compiler?  Can you just use that?

It's called Pyrex, and I'd absolutely use that for the Python-C thunking 
layer because it's aware of C structs and such. (Before I knew about 
Pyrex, I attempted a Python interface using just C, and the result was 
pure evil and prone to reference counting bugs.) It outputs C code, so 
people who build Quake 3 from source wouldn't even need Pyrex installed 
if it were used for something static. I'd hesitate to use it to compile 
the game code for a few reasons:

- When you're not doing numerical stuff you don't get much speedup, if 
any. When your function is mostly non-C types like lists (Python's 
arrays - you know this, but some don't) and dicts (Python's hash tables) 
and custom types (vectors, colors, rotation matrices, models, traces), 
the bytecode interpreter can often run bytecode faster than the 
equivalent Python C-API code. One reason is that Python's slowness isn't 
usually due to the interpreter - the language features are just CPU-heavy.

- It would be harder to modify the game without a compiler. It would be 
too easy for a mod to be less cross-platform than the Quake 3 engine.

- It's not as bug-free as Python. In particular, sometimes it barfs on 
syntax when it shouldn't, and sometimes (though rarely) it generates 
incorrect code.

I expect there wouldn't be much speedup in general, because game logic 
usually isn't heavy on numerical stuff. Pyrex is always an option in 
case some mod needs it, though.


More information about the quake3 mailing list