[quake3] Python game code

[Neil Toronto]

LinuxManMikeC wrote:
> On 11/21/06, Thilo Schulz <arny at ats.s.bawue.de> wrote:
>> Looks pretty neat. Someone who wanted to use this will have to write 
>> the mod
>> code all over again, though. Isn't that a bit large task to do 
>> compared to
>> actually get python stuff running?
>>
>> -- 
>> Thilo Schulz
>>
>>
>>
>
> Well I think this binding was meant for non-programmers who want to
> mod the engine, but this brings up a question that I've had since I
> first read this thread...  Wouldn't it be possible to mix C and
> Python?  What would interest me is using Python for scripting
> character AI and other things that could be changed between maps in a
> game (like in Star Trek Elite Force and Call of Duty).  I would prefer
> to do the rest of the more common code in C for speed.  I know you can
> mix C and Python, but the design of this binding would decide how hard
> it would be to implement (I would imagine).  Please consider this in
> your design Neil.
>
> Mike Cerveny

In general, it's a huge PITA to mix C and Python. There are helpers like 
SWIG and Pyrex, but you'd want to keep the interface between the two 
languages as small as possible. There are a couple of ways I can think 
of that this could work out well:

1) Lots of C game code that calls a few Python hooks.

2) Lots of Python code that calls C code to do a few speed-critical things.

#1 looks like what you're proposing. The two biggest advantages here are 
that I'd have less to write since the game code is already in C, and 
that it should run faster. There are a couple of disadvantages as well: 
you can't hook into anything and everything (you can with #2), and I 
haven't figured out how to get both a shared library and the QVM to call 
Python code without making a big mess of it. At minimum, it would 
require a bunch of new engine callbacks to wrap a good portion of the 
Python C API, and mirroring quite a few game C structs as Python classes.

#2 is most flexible just because a mod author doesn't have to have an 
already-established hook in order to do something. The game code is also 
much shorter and more abstract, and easier for people with a passing 
familiarity with programming to change and package. The big downside 
(besides the drain on my time) is that it's potentially a lot slower.

How much? I'm not sure there's anything in the game code that takes a 
great amount of CPU. There aren't any especially hefty algorithms. Most 
frames just change a few things in a few data structures (advancing 
moving entities, moving players and such). The biggest CPU hogs, 
collision detection and rendering, are mostly done in the engine. The 
particle system could take a lot of time, and is probably a good 
candidate for C. All the math functions and vector operations will be in C.

At least, I *think* that's how the performance landscape looks. Though I 
did the Alternate Fire and UFT mods, both of which required some fairly 
major changes to the bot AI code, there's a lot of it I left alone out 
of sheer terror - but I think the story is the same there. The mover 
code is also pretty opaque to me. Maybe someone here with more 
experience could chime in?

Neil