Phython as In-Game scripting language

[Alexander Staubo]

In article <20000222211406.41743.qmail at hotmail.com>, 
wrlddomprod at hotmail.com gawked pleasuredly...
> My team and I are thinking about embedding Python into our
> game engine on the Windows platform. The basic idea would be that the
> major entities, including enemies, would have a script attached to
> them to control behavior. This would allow the level/content designers
> to concentrate more on the game design side of things, since
> behaviors would be outside of the main game engine. 

Scripted game logic is an excellent idea, and a proven one (albeit not 
with Python, that I know).

>Is it
> possible to have multiple scripts running at the same time?
> Would this involve creating multiple interpreter objects? According
> to the docs, this is possible but it isn't totally safe to do.
> What would be a good strategy for this?

Python's problem is with its global interpreter lock. Only one piece of 
Python code can execute "at the same time" (on a single processor this 
means within the same time slice). Multi-threaded performance of Python 
definitely suffers, and depending on the code, you'll usually find almost 
no discernible improvement on SMP systems.
 
> My other question was one of performance. Is it crazy to have
> ~10 different objects with each an individual script and hoping
> the game will be running at 30 frames per second? The question might not be 
> valid, since I'm not sure how to implement it in the first
> place.

Crazy it isn't, but perhaps a tad ambitious -- it certainly depends on 
the system requirements of your game. I've been down the same path of 
research as you have, and my conclusion was that for now, I cannot 
recommend Python for game-scripting purposes.

Instead, you might want to take a look at EiC, the free, open-source, 
embeddable C interpreter. (Although this borders on heresy, I mention 
this openely in this newsgroup because I know the Python crowd is 
generally pragmatic and will buy any solution as long as it works, even 
one that isn't Python.)

It's a very impressive engine that compiles to (and optimizes) bytecode 
on the fly, and supports an excellent API for mixing native code -- even 
non-C -- with scripted code. It supports most of the C language, runs on 
most platforms including Win32, supports multithreading (afaik), and is 
also darn fast -- much faster than Python, partly because it interprets a 
statically-typed, early-bound language.

Otoh, it is not object-oriented, nor is it Python. ;-)

-- 
A.