Python in game development?

[Moritz Voss]

"Martijn Faassen" <m.faassen at vet.uu.nl> schrieb im Newsbeitrag
news:8l74db$hs6$1 at newshost.accu.uu.nl...
> In comp.lang.python Moritz Voss <nospam at buzzoff.com> wrote:
>
> I was pointing out that it is often *not* a problem. Premature
optimization,
> even in game programming, is not a good idea. While Python is slow
> compared to C code, if the same algorithm is used, you can:
>
>   * use smarter algorithms much more easily in Python. Especially since
>     Python allows rapid prototyping.
>
>   * offload the time critical bits to C.

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...)...


> >> 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.


> > 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.

> 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.

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.

So what my C program would do is call a python function "main" or so that
runs and makes all these decisions, even calling subroutines and so on - and
modifes the unit state that it shares with the C program. (Which, then, will
run the atomar part of the physics engine, the one that does things like
accelerate and so on over time, according to the unit's desired speed
states.) So that kinda requires a language that is not absolutely basic,
like my ASM concept. :)

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.


> Of course you can do it right too, but it'll cost lots of time and is
> definitely not easier.

I agree. I don't want to reinvent the wheel.

>
> > 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. :)
>
> The idea of using a higher level language however is that you can use
> higher level constructs. Which, believe me, is often a lot easier than
> using C or C++.

Yes. Like [[ SELECT * FROM CoWorkers WHERE SEX="F" ]] is easier than finding
your possible future spouse in C or Assembler.


> I think this focus on speed is even for a game programmer the wrong
> approach. It's only too slow when you find it's too slow. You haven't
> found out Python's too slow for your purposes yet.

Hey! We coded a long time to get the engine to run at 300 fps with some
graphics load. We don't want the micro-AI scripting part to slow it down.

That is the AI clients's job. :-)

I think I'll go with Python, and if the performance problems become
dominant, I'll check that ASM concept of mine.




Thank you for the links! I'll have a closer look at them.

> Regards,
>
> Martijn


--
--
Moritz "Thygrrr" Voss
Client-Server & OpenGL Coder
spirit.link.studios - http://o2.ods.org