Python in game development?

[Steven D. Majewski]

On Thu, 20 Jul 2000, Moritz Voss wrote:

> Now, my own language would be an assembler-style thing. The concept is as
> follows - every instruction corresponds to an index. Each of these indices,
> after compilation, are then translated, during runtime, into direct function
> addresses. So what I have is my program that consists of a huge bunch
> pointers to C functions (which can have any level of complexity). These
> would just be loaded, and called, loaded, and called. I'm not going into the
> depths of this here but passing parameters and references is not a problem.

If that's your ideal, then look at FORTH. 
The inner interpreter or VM is just a small loop that executes threaded
code. It can be direct-threaded  (i.e. pointers) but usually indirect 
or token threaded is more portable. However, FORTH is really like a 
high-level typeless interactive assembler: it's good as an implementation
language but it's not great as an end-user extension language: game users 
could crash the game and the computer with pointer bugs. Something like
Python provides more insulation: scripting level bugs shouldn't be able
to crash the interpreter, not to mention the game or the computer. 



> > > Thanks :) So designing my own scripting language is easier.
> >
> > That's of course not true; designing your own scripting language will
> > most likely result in an ad-hoc broken design. 

Read John Ousterhout's original paper on Tcl (on whatever name/URL Scriptics 
is currently going by ;-) which does a good job of describing the motivation
of embedded scripting languages. Typically, folks don't start off trying
to design a language, they just want to add "language features" to an 
application, and so they end up doing a half-assed job of it. ( We won't 
get into the fact that a few folks think that tcl itself is a good example 
of the syndrome John describes! ;-) 




> [ Other stuff deleted ... ] 


Take a look at Alice -- it's not a game, it's a virtual reality scripting
environment, but it's not a bad example of the sort of system you're 
describing: Python isn't used to power the low level graphics engine, but
to write interaction rules for the objects in the VR world. 

( Before Randy Pausch moved to CMU, I used to take my kids to Alice demo
 days here at UVA where they could don helmets and gloves and fight with
 VR light sabers or walk thru a Doom-like dungeon. ) 


> Maybe I don't get the python concept. Do you link it statically? Or is the
> interpreter *.exe invoked every time?

> I'll play around with python, but I found the way to embed it totally
> confusing. (That is, of course, because I have never worked with embedded
> languages yet). Also, I find no tutorial that clearly tells me how to change
> my C variable "X" from within my Python program "Y" that is invoked by the C
> Program.

You wrap lower level elements of your game in the Python API to make them
into Python callable objects and functions. The you can either write the
top-level in Python, or embed the interpreter (statically or as a shared
library) in your application, and make calls to the interpreter at 
appropriate times.  It's usually this second style that confuses people,
as it mixes the hierarchy up a bit: C calling Python calling C calling 
Python...  However, the same mixing goes on in the interpreter itself, 
which is one of the reasons folks bring up terms like "stackless" and 
"microthreads" in this discussion. 

---|  Steven D. Majewski   (804-982-0831)  <sdm7g at Virginia.EDU>  |---
---|  Department of Molecular Physiology and Biological Physics  |---
---|  University of Virginia             Health Sciences Center  |---
---|  P.O. Box 10011            Charlottesville, VA  22906-0011  |---

"There's a new programming language called C+++. It's 50% better than C++, 
         but every time you compile, your modem hangs up."