[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