[quake3] Python game code

[LinuxManMikeC]

On 11/21/06, Neil Toronto <ntoronto at cs.byu.edu> wrote:
> 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
>
>
That #1 sounds like what I'm thinking.  I would like to use Python
only for AI.  Being able to also do scripting for all entities would
be nice, but at that point most of the game code would be in Python
anyway.  Now your idea of just using Python for everything would work
as I would be able to make my AI scripts for the various levels (also
Python) and dynamically load it into the characters based on which map
is loaded.  I would also have the option of doing complex scripting
with all world entities seeing as how the code for it is already in
Python (opens up some really wild possibilities).  I haven't even
modded the Q3 game code yet (only browsed), so I was just thinking out
loud.  I wouldn't mind doing it all in Python, just that I like C more
:-).  Guess I'll just wait and see how your Python binding works out
both code and performance wise.  If it doesn't work for what I want to
do then at least I have somewhere to start from.  In the mean time I
need to start playing with that C code.

Mike