N
Neil Toronto
So I've recently had a stroke of insanity, deciding that what the
open-source Quake III engine *really* needs is a good, healthy dose of
Python.
Here's the quick version: The Q3 engine is split into the engine
(responsible for rendering, sound, networking, input, and collision
detection) and the game logic. Currently, the game logic can be loaded
as a shared object file (usually for development) or this crazy thing
called a QVM: a bytecode file which is either interpreted or
JIT-compiled. Using ioquake3 (ioquake3.org) as a base, I added Python to
the list.
Frankly, I'm not amazed at how much easier it is to code game logic in
Python, but some people might be.
I'm working on the client game, and
I'm about 30% done with that part. It looks like it's going to work out
very well. It's the coolest thing to be able to pull down the console
and type "/py print cg.data.pps.origin" and have it print out your
current position.
Now that the background is out of the way, I have two questions:
1) Is there a good guide for distributing applications with embedded Python?
I'm planning (so far) on putting libpython2.4.so in the executable
directory, along with everything from
/usr/lib/python2.4 that the interpreter complains about not having.
(I'll try to put them in a zip file - sans zipfile.py - if I possibly
can.) Is there a nicer way to do this?
2) Is there any way to restrict Python modules from accessing files
outside of a sandbox?
One of the nice things about Quake 3's QVM files is that they are very,
very restricted. They have no concept of a standard C library. This
makes some things rather tricky, but also very secure: if the engine
doesn't support it, you can't do it. If you download a Quake 3 mod from
someone, you can be fairly sure it won't hose your system.
In particular, it won't let you access files outside of the game
directory. Is there a way I can accomplish something similar in an
embedded Python application? I probably only have to make it secure on
systems that don't have Python installed.
Neil
open-source Quake III engine *really* needs is a good, healthy dose of
Python.
Here's the quick version: The Q3 engine is split into the engine
(responsible for rendering, sound, networking, input, and collision
detection) and the game logic. Currently, the game logic can be loaded
as a shared object file (usually for development) or this crazy thing
called a QVM: a bytecode file which is either interpreted or
JIT-compiled. Using ioquake3 (ioquake3.org) as a base, I added Python to
the list.
Frankly, I'm not amazed at how much easier it is to code game logic in
Python, but some people might be.
I'm working on the client game, and I'm about 30% done with that part. It looks like it's going to work out
very well. It's the coolest thing to be able to pull down the console
and type "/py print cg.data.pps.origin" and have it print out your
current position.
Now that the background is out of the way, I have two questions:
1) Is there a good guide for distributing applications with embedded Python?
I'm planning (so far) on putting libpython2.4.so in the executable
directory, along with everything from
/usr/lib/python2.4 that the interpreter complains about not having.
(I'll try to put them in a zip file - sans zipfile.py - if I possibly
can.) Is there a nicer way to do this?
2) Is there any way to restrict Python modules from accessing files
outside of a sandbox?
One of the nice things about Quake 3's QVM files is that they are very,
very restricted. They have no concept of a standard C library. This
makes some things rather tricky, but also very secure: if the engine
doesn't support it, you can't do it. If you download a Quake 3 mod from
someone, you can be fairly sure it won't hose your system.
In particular, it won't let you access files outside of the game
directory. Is there a way I can accomplish something similar in an
embedded Python application? I probably only have to make it secure on
systems that don't have Python installed.
Neil