Python in game development?

[Martijn Faassen]

In comp.lang.python Moritz Voss <nospam at buzzoff.com> wrote:
> "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.

There's not a real 'concept' involved, it's just that since most of the
CPU time is spent in 10% of the code, you can do the 90% of the *rest* of
the code in something that's easy to program in. :)

> Do you link it statically? Or is the interpreter *.exe invoked every time?

You can link it dynamically or statically. You just invoke the right
C function, which calls the interpreter.

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

This would be an example of 10% of the code taking up lots of the time,
right? 

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

No, especially not when you have it in C++. :) If you have a
*rapid prototyping language*, in which it is very easy to set up something
complicated or change around your code, you have more time to experiment
with different algorithms and strategies than if you do it all in,
say, C, or assembler.

>> > 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.
[snip]

All right, I wouldn't call this a 'scripting language' so much as a 
virtual machine language, then. It won't be easy to program in, and if
I want to do high-level things you'll at best be limited to something
you thought of to put in, and at worst I'm going to be frustrated.

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

I understand the concept. The last such language I did though was designed
to be optimized by the *machine* in an artificial life context; and I certainly
had a hard time reading the result. :)

Python is about humans.

[snip]
> 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....

[snip]
> So that kinda requires a language that is not absolutely basic,
> like my ASM concept. :)

Agreed, a higher level language would be convenient in this case. It
basically depends on how often you expect the Python functions to be
called. And on measurements; sometimes you expect something's too slow
and it isn't, and the other way around.

> 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 do that through a C wrapper API. You write a bunch of wrapper functions
in C, and Python can talk to those wrapper functions to manipulate your
program state (or access it).

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

[snip]
>> 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.

All right, if it's the type of thing you describe it makes sense to
use somekind of assembler like code. Still, I'd like to see some benchmarks
first; perhaps it'll be okay.

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

Right; I don't think much time will be lost if you do this. Though you're
on a learning bump now, I don't think Python's that hard to embed, and I
think that it's fairly easy to swap out the parts that Python's too slow
for with your ASM concept.

Regards,

Martijn
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?