Re: Scripting

[Jan Ekholm <chakie@infa.abo.fi>]

On Thu, 18 Apr 2002, Steve Baker wrote:

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

Oh, please. You can't possibly say that C++ is easier to use than a
script language? Sure, for you it is, you have invested a decent maount of
years doing fulltime C/C++, but for us normal hobbyhackers C++ is much
harder. I don't dislike C++, it's my language of choice for stuff that
just can't be done using a scripting language, I even know C++ fairly
well, so I think that when I say it's harder to do stuff in C++ I'm not
too much off.

Just think about stuff like memory management, references, pointers,
operaor overloading, cumbersome containers (STL is powerful, but
cumbersome), header files, memory corruption (what use is a stack trace
when the memory was corrupted a minute ago?) and so on.

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

You have a hard time doing anything i C/C++ without pointers. Especially
if you plan to do a game and use some external library.

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

Yes, this works to some degree. But not always, and not when you need it
most. I've used the GDB way a few times.

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

Yes, I don't disagree here. Python is slower, someone could even say it's
dog slow.

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

Not necessarily. It all depends on how much extra stuff your game needs to
do. Most Linux games don't really need to do that much extra beside
drawing the scene, accept user input, update some objects, check for some
special condition.

>> 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 wouldn't mind the speed, I'm not stupid. But if I can make my game run
decently on that hardware, then players will have a good gaming
experience, and may not even notice it's actually a interpreted game.

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

True. But more and more of the actual gfx is just a call to OpenGL/DX to
draw some pre-setup vertex array or display list. Which can be done as
fast in any language. So for static data the difference isn't huge. 

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

Depends. I'd rather tell a newbie to start doing his/her first few games
in some interpreted language. After those first simple Tetris-games the
developer can decide wether to take on something larger. Chances are still
very good that the same scripted language will do just fine for the larger
project. Eventually the developer becomes skilled enough after many years
of game development and wants to do something huge where the scripted
language just doesn't have the grunt. Then he/she should go compiled.

But if that same developer tries to immediately start big and go C++ the
chances are huge that the game never gets released. 

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

99% of games aren't too complex. Does that sound better? Your games would
probably fall into that last 1%, but you don't really represent the
average developer either.

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

Oh, I know you know a lot more, I haven't disputed that. But I do dispute
the fact that eveything you say about game development is The Truth. I
know enough about general development in various languages that I know C++
is horribly more complex than Python (or Perl for that matter).

And trying to ridicule about my lack of knowledge is really a silly form
of discussion. Always attack the arguments, not the person (sorry couldn't
resist).

-- 
                        "Bingeley bingeley beep!"
               -- The Personal Disorganizer, Terry Pratchett in Feet of Clay