[quake3] Python game code
ntoronto at cs.byu.edu
Tue Nov 21 19:03:27 EST 2006
> 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?
More information about the quake3