Suitability for games?

[Martijn Faassen]

Rev. Jon Harford <dubious at jonjh.freeserve.co.uk> wrote:
> How suitable would Python be for games that move faster than Solitaire?

I've done some thinking about this, though I have little practical
experience.

It depends on what kind of game you're talking about, to start with. A whole
lot depends on that.

Python probably isn't fast enough to do a vast amount of 3d calculations,
but it's fast enough to *drive* these calculations. This is the general
principle -- Python can still perform quite well as a higher level
controlling system (which can include a lot -- GUI, loading/saving,
scripting of in-game objects and events, etc), even when it's not
fast enough to do low level graphics manipulation. You use a C or C++
library for that, but you can wrap those with Python.

For object scripting, there are some interesting developments. Python does
not have 'simulated threads' by default. These are non-OS threads where
the Python interpreter itself does the switching, first executing for
instance 100 bytecodes of 1 thread, then 100 of another, and so on. But,
Will Ware has released MicroThreads which does accomplish this. So look
into this if you're interested in driving a lot of objects in your game with
Python scripts. Microthreads seem to be better suited for this purpose
than the usual threads, which usually don't assume that large an amount of 
threads.

Microthreads can be found at:

http://world.std.com/~wware/uthread.html

There was talk about integrating MicroThreads into Christian Tismer's 
'stackless Python', and there is also talk about integrating *that* with
Python proper, but that's of course a lot of assumptions. :)

So I'd recommend Python for game scripting, and for the code that 
structures and drives lower level speedy code. For the lower level code
Python isn't very suited though.

Regards,

Martijn