Re: Writing games in interpreted languages

[Pierre Phaneuf <pp@ludusdesign.com>]

Bert Peers wrote:

> Getting back on topic, I'd say that you should take a
> similar all-options-open look to every component a game
> needs, and take the right language for the right part.
> If we had a perfect world where interconnectivity between
> different languages is not an issue, I'd be happy to use
> MFC/C++ for the in-game server browser, C for the offline
> numbercrunching tools, C/C++ to write the game engine,
> a custom or off-the-shelf scripting language like Python
> to write the game logic, Perl for the in- and output
> of scores and stats in XML for online stat tracking, and
> Java to write an applet that allows you to see who's
> on a server from your browser without going through XML...

I would mostly agree with you! The only thing I would critic is that you
do some pigeon-holing...

Very little of the Perl I write is XML/HTML/CGI or even web related. I
like using the Curses module to do a menu system and Gtk+ for some X
applications (where the main performance bottleneck is the user moving
the mouse). ;-)

Some very fine APPLICATIONS (no "pplet" here!) are done in Java, but the
virtual machines for Java are quite slow (I do not know if this is a
design problem or an implementation problem), even compared to pure-Perl
code, let alone C/C++.

Not too many people do object-oriented Perl, I wonder why, it is quite
simple and powerful, leans itself very easily to expressing game-type
concepts, would be very nice for game logic!

Just to give you an idea of how ironic this is, the Perl XML module is
actually mostly C code! :-)

-- 
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/
"First they ignore you. Then they laugh at you.
Then they fight you. Then you win." -- Gandhi