Python in game development?

[Rainer Deyke]

"Moritz Voss" <nospam at buzzoff.com> wrote in message
news:8l7f69$bon$1 at fermi.tro.net...
> Maybe I don't get the python concept. Do you link it statically? Or is the
> interpreter *.exe invoked every time?
> We came from dos, counting every clock we spent using 90% assembly in our
> software. Until we were struck that our texturing algorithm sucked (and
> anyway, 3d accelerators were coming up and I already had one...)...

The Python interpreter is available as a DLL.  You link your C/C++ with the
Python library, then call python code with PyRun_String or something
similar.

Python is really easy to extend in C, although extending in C++ could be
difficult, especially if you use C++ exceptions.

> > >> From a game programming perspective, you can probably consider Python
> to
> > >> be dirt-slow, though. The trade-off is a lot of power for speed, but
> > >> that power can help you gain back speed because you can be a lot
> smarter.
>
> Yes and no. Just because I have encapsulation and overloaded operators,
that
> does not mean my program is going to be faster than a program that
performs
> the same task in assembly or C.

Python is horribly slow and memory-consuming compared with C or C++.  It is,
however, extremely flexible and easy to program.  However, this probably
doesn't matter if you only use Python where appropriate.  Don't write a
path-finding function in Python; write it in C or C++ and access it from
Python.

> > > 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. Look at all the various
>
> 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.

Sounds messy and slow.  An indirect function call per instruction?  Could be
slower than Python, especially since you'd need lots of instructions to do
anything useful when programming assembly style.

> > application specific scripting languages for examples. It's even
possible
> > your own design will be slower in many cases than the equivalent code
> > in Python, as you don't have as much time to polish it.
>
> That is the problem - python is oblect-oriented. Most AI scripts are tiny,
> though, just 15 lines or so with my assembler code.
> Something for a missile would be
> "CheckTarget-<calcangles>-Steer-IfCloserThanX-Detonate". The script knows
> how toget closer to what it wants - but does so not my reall playing god
and
> moving the missile, but just setting off a command "Steer" that tells the
> physics engine "ThrustvectorAngleChange (angles)"... This is unlike the
> scripts in the Quake engines that allow to do unrealistic things - in my
> project, each script can only do what is physically possible - otherwise,
> the missile will crash or the tank will tip over in a curve.

This type of thing is possible in Python.  To prevent the script from doing
something naughty, override __builtins__.

> A caveat here: The unit scripts will be lengthy, having units check engine
> and gun temperature (and move into the shade or cease fire), check whether
> they can go down that hill after it has started rainign, have them
> communicate targetting info or even orders to other units, calculate the
> lead for their next shots, return to a repair base via the safest way....
>
> And it MUST all be user definable for the player, that point is muission
> critical for the project. Otherwise, we'd hardcode it.

All no problem in Python.  If you use classes to represent unit types, you
can override any attributes or behavior through subclasses.

> 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 would typically do things the other way around - change Python variables
from C.  If you must change a C variable from Python, you would have to
write a function that changes the variable and write a built-in module that
contains the function.  Python programs can then access import the module
and call the function.

> > > Or: Isn't it feasibble to pull of a stunt like ID software did with
> their VM
> > > files? These contain compiled C code that is loaded dynamically - and
of
>
> > If you want to script your game in C there isn't any problem. :)

Actually there is.  It's impossible to prevent a DLL from crashing the host
computer and doing other bad things.


--
Rainer Deyke (root at rainerdeyke.com)
Shareware action/role-playing games      -      http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor