Re: Scripting

[Steve Baker <sjbaker1@airmail.net>]

Jan Ekholm wrote:

> Oh, you do really mean that doing stuff in C++ is so much easier than
> doing it in, say, Python (popular in this thread)? Good for you then. :)

Not necessarily easier - just no harder.   And if it's no harder to
write in C++ than in a scripting language, you should use C++ because:

  a) You only have to have expertise in one language.

  b) It runs faster.

However, (struggling back on-topic) there ARE good reasons to use
an interpreted scripting language for things like AI and scenario
setup...but IMHO, those reasons are nothing to do with some idea
that development is somehow easier because you are using an interpreter.

> I tend to introduce a few bugs in my C++ every now and then, and some of
> them can be pretty scary to track, especially those where memory is
> corrupted by some totally unrelated part of the code (also mentioned in
> this thread).

That can happen in any language that's sufficiently powerful to do the
things most games need to do. Unless you are prepared to go without
pointers, you are going to see these kinds of issues.

> Using an interpreted language I can at least get an
> immediate stack trace when something goes wrong, which enormously shortens
> the time it takes to track the bug.

You can do that in C++ too.  Either run your program under GDB while
you are debugging - or toss in a call to 'backtrace_symbols_fd' in
a signal handler that's triggered for all the common error signals.
It takes about 20 lines of code and it'll cause an automatic stack
backtrace to happen for all common crash conditions without any
kind of debugger running.

> As for speed, you do lose some, and in some cases lots and lots of speed.

In tests we did at work, Python ran between 40 and 200 times slower
than C++ for a 'typical' set of operations (which is something you
could argue about *forever* - but we thought it was typical code).

It's possible to find cases where it seems fast - for example:

  while ( 1 )
    call_honking_great_slow_library_function () ;

...because all the time is spent in the library function which isn't
written in Python.  Then your run times can be very close to C/C++ because
(in effect) that's all you are running.  However, for programs that call
no non-Python code, expect them to be horrifically slow compared to
compiled languages.

You might have better performance for different interpreted languages,
but it's never going to be better than maybe 10x slower...just think
about the minimum set of machine-code instructions it takes to execute
one byte-code instruction.

There are interpreters that span the gap between compiler and interpreter
by compiling code on the fly and caching the resulting machine code.  That's
OK if your program spends all it's time inside loops - but no better than
a real compiler for code that never loops or branches.  Many AI scripts
are like that - so one of these contraptions is likely to be even slower
than a conventional interpreter.

> I don't really care that much about that. I develop using low end machines
> (lack of euros), so what runs ok on my machine flies on machines everyone
> else has.

But on a slow machine, don't you feel even *more* need to run a fast
language?

> I could never harness all the power of a modern machine anyway,
> so I rather "waste" it on the interpreter than "save" it as idle time.

In action games, you tend to want to use all of the resources you
possibly can to get better graphics.  Graphics are never "good enough".

So, whilst you may be happy to write everything to run at 2% of the
speed it could be going at - it's clearly not good advice for
everyone.

> >I'd also object to the idea that games that get developed for Linux aren't
> >too complex...if we give into that idea then it will become a self-fulfilling
> >prophesy.  Games I'm working on certainly *do* use all the resources of a
> >modern PC.  I *want* to write the most complex game I can within the mental,
> >temporal and physical resources at my disposal.
>
> Well, Linux games aren't too complex. It's a fact of life. Especially true
> for hobbyist games. There are the notable few exceptions to this rule,
> such as some of your games, FlightGear, FreeCiv and some others.

So your statement "Linux games aren't too complex" ...with exceptions...
really translates to "Those Linux games that aren't complex aren't complex"
which is a content-free message.

There are a LOT of Linux games that would not run at acceptable speeds
on typical CPU's if they were written in Python.

> Well, I've never written a game using either C++ or Python, so my opinions
> don't really matter. But if I'd write a game I'd do it in Python.

So taking the advice of someone who'se never written a game over someone
who has written lots of them would be a good idea?

----------------------------- Steve Baker -------------------------------
Mail : <sjbaker1@airmail.net>   WorkMail: <sjbaker@link.com>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net