[quake3] Python game code

Neil Toronto ntoronto at cs.byu.edu
Tue Nov 21 12:34:49 EST 2006


Daniel Lord wrote:
>
> On Nov 18, 2006, at 22:09, Neil Toronto wrote:
>
>> Matthew R. Dempsky wrote:
>>> On Sat, Nov 18, 2006 at 06:09:16PM -0500, JoeHill wrote:
>>>
>>>> On Sat, 18 Nov 2006 13:11:04 -0700 Neil Toronto got an infinite 
>>>> number of monkeys to type out:
>>>>
>>>>> Place the script in a .pk3 file, somehow notify the server that 
>>>>> you want it loaded (cvar?), and viola! You can even chain these 
>>>>> little things.
>>>>>
>>>> Seriously. That's it??!! That's all you need to code a basic mod?
>>>>
>>>
>>> I got the impression he was presenting a hypothetical scenario
>>> supposing someone had spent the time to replace Quake 3's existing VM
>>> with Python's.
>>>
>>
>> I got the impression that Joe was saying that tongue-in-cheek. ;-)
>>
>> But yes, *if* someone had spent the time modifying the Quake 3 engine 
>> to load Python game files (I'm starting that now, by the way), that's 
>> all you'd need to code a basic mod. Is that not nifty?
>
> Yes it is 'nifty'. If you get a prototype, you should post it to the 
> python and Mac-Python groups.
> Being a hard-core Python fan boy and hacker, I'd love to get my hands 
> on it.
>
> Daniel
>

Will do. I was considering doing that already but wondering which lists 
to target. I can get this to build only under Linux, so having other 
people bash it against the Mac would be great.

As long as I'm writing, I'll give a status update. :D I've got the 
engine loading Python files and using them as entry points now. (You set 
vm_cgame and friends to 3.) It can call them to initialize the game, 
render frames, etc. -  not that the Python game does anything right now 
- and it receives return values. One especially nice thing is that 
Python can use zip files in its system path, so the first thing it does 
after initializing the interpreter is add the engine's search path to 
sys.path. When a Python game file does something like "import cengine" 
(the client engine wrapper), the interpreter loads cengine.py from 
baseq3/pygame.pk3 (or an overriding file).

It turns out that it's *really* easy to wrap engine callbacks in a 
Python module using SWIG. All I have to do is create cengine.h and 
cengine.c (simple wrapper functions to replace the Quake 3 callback 
handlers) and a really simple cengine.i (which basically just includes 
cengine.h), define a make rule that runs "swig -python cengine.i", and 
I've got a proper Python module that mirrors the functions in cengine.c. 
SWIG makes a private C-language Python module and a public 
Python-language facade module. I statically link the private module to 
the Quake 3 executable and call its initialization function after 
initializing Python, and all the game code gets access to it. Out of, 
like, 100 client engine functions, I've done wrappers for, um... 3 of 
them. :) So, yeah, I can make the client game print stuff to the 
console. Sweet.

The next steps are to organize this a little better and then get the 
Python game to render something.

Neil




More information about the quake3 mailing list