Re: Writing games in interpreted languages

[Christoph Reichenbach <jameson@linuxgames.com>]

Hi,

On Mon, 27 Dec 1999, Steve Baker wrote:

> Christoph Reichenbach wrote:
> > 
> > On Mon, 27 Dec 1999, Davis, Daniel wrote:
> > 
> > > Perl isn't a compiled language and therefore not suitable for gaming.
> > 
> > I disagree. The fact that Perl (or Python, Scheme, etc) code is
> > interpreted in software rather than being executed on an actual processor
> > just means that this particular piece of code will need a few more
> > processor cycles to be executed.
> 
> A *few* more?!?  Try 50 times slower than C or C++ !!  (For python at least).

That's acceptable, but it's possible to use embedded interpreted languages
that are more optimized towards performance, if this is neccessary.

> If most of the execution time in your game is spent in some other library
> (which *is* written in a compiled language), then you may not lose too badly,
> but in a sense, that's cheating!

Why's that? Any interpreted language /has/ to use machine executable code,
and I don't see much of a difference between that code being in the
interpreter main loop and it being in a separate library (it's still
called from the main loop).

> > On the other hand, it will give you all
> > the advantages of sand-boxed development, like powerful in-game
> > debugging, increased stability, and portability (if done right).
> > Of course, it's too slow for doing high-performance graphics "manually".
> > But running the actual game logic in an interpreter makes a lot of sense
> > and has been done in many historic games (All of Sierra's AGI and SCI
> > games, LucasArts SCUMM games, Quake 1 and 3, and IIRC all Infocom
> > adventures).
> 
> For the very top levels of the logic, that's true - but that's a long
> way from saying that you should write games in an interpretive language.

I define "writing a game" as the process of creating code and data to get
that game up and running (plus design and testing, but that's not
important here). If the binary code for the external libraries already
exists (as it does nowadays), you don't have to write them, so it's
easily possible to write a game by programming in interpreted languages 
only.

> > (Binary compatibility is another reason for interpreting code. But Binary
> > compatibility is a kludge, and hardly worth mentioning).
> 
> If you rely heavily on compiled language libraries, then those won't
> necessarily be portable,

If they aren't portable, then either the library design is flawed or the
platform you're trying to port it to is inappropriate for the library in
question.

> be developable in a sand-box, have in-game
> debugging or any of the other things you advocate.

Yep, that's right. I never said that the world should be re-written in
Perl, I just wanted to point out that, with the library bindings available
today, you can write good games without having to resort to compiled
languages, because someone else has already done that part of the work for
you.

> In the end, you'll just be re-scripting someone else's game - that's
> about the limit of what you can do with interpretive languages -

OK, so there seems to be a definition conflict here- you appear to use the
term "game" for what I refer to as "game engines". For example, I consider
the classics "Space Quest 4" and "Jones in the Fast Lane" to be separate
games, even though they run on the same game engine.

> except
> in the rare case of a game where performance is not an issue.

Unless you want to frobnicate pixels manually, you'll rarely get a major
performance loss by using interpreted code. Pixel or vertex operations
still take most of the time required by most games today, so it's
generally sufficient if you use optimized compiled code for those.

Of course, the situation is different if your game relies heavily on
complex computations (maybe neural networks, a particle system, or SW bump
mapping). You'll have to write compiled code for those and encapsulate
them for the interpreted code to use.

llap,
 Christoph