Re: Writing games in interpreted languages

[Michael Dartt <mad96@hampshire.edu>]

I've been working with Python a lot lately, and it strikes me as a great
language for--well, darn near anything, including game programming.  One
of its most useful aspects for a program like a game, where certain
parts are going to need optimization (even if that just means "being
compiled") is that Python works almost transparently with C and C++. 
(And Java, too, if you use JPython.)  This means that you can write the
entire program in Python, taking advantage of the *much* faster
development time (and other VHLL benefits), and then, if you find that
pieces of your game need to be faster, you can rewrite those modules in
C or C++ and get that speed increase, without having to change the rest
of your code.  You can also embed Python in C, C++, or Java, too.

Python also has bindings to a lot of popular libraries (OpenGL, QT, and
GTK, to name a few), runs on virtually every platform still in use, and
is very easy to learn, read, and maintain.

Take a look at the Python Language website at http://www.python.org;
it's got a wealth of good documentation and downloads.

I realize my enthusiasm might sound artificial, but the more I learn
about this language, the more I prefer using it to others.  :-)


--Mike


Erik wrote:
> 
> On 27-Dec-1999 Christoph Reichenbach wrote:
> > Hi,
> >
> > 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. 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).
> >
> 
> quake1 used a compiled script, you had to have 'qcc' and it was a near-C
> language... But interpreted languages are often fast enough to handle that
> kinda activity :) I know that perl and scheme, once loaded up, are pretty fast.
> perl is a jit language iirc. Plus perl and scheme (guile) are very easy to
> imbed, and if you design the program well, you can easily rip out one scripting
> format and drop another in.
> 
> > (Binary compatibility is another reason for interpreting code. But Binary
> > compatibility is a kludge, and hardly worth mentioning).
> >
> 
> binary compatability is an important element of java, and was one of the
> reasons why q1 kicked q2's ass :) If the game is going to run on multiple
> os/arch, then the scripts/mods should have that portability, and if any kind of
> binary material is presented, it should be portable... if someone is set on
> compiled scripts, then they should concern themselves with binary
> compatability.
> 
> > llap,
> >  Christoph
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: linuxgames-unsubscribe@sunsite.auc.dk
> > For additional commands, e-mail: linuxgames-help@sunsite.auc.dk
> >
> >
> 
>         -Erik <erik@smluc.org> [http://math.smsu.edu/~br0ke]
> 
> The opinions expressed by me are not necessarily opinions. In all
> probability, they are random rambling, and to be ignored. Failure to ignore
> may result in severe boredom or confusion. Shake well before opening. Keep
> Refrigerated.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: linuxgames-unsubscribe@sunsite.auc.dk
> For additional commands, e-mail: linuxgames-help@sunsite.auc.dk