Re: Writing games in interpreted languages

[Bert Peers <rat@larian.com>]

Steve Baker wrote:

> Don't get me wrong though.  There is a place for interpretive
> languages in the upper levels of game code - and in fact the
> PrettyPoly project I'm working on right now is heavily into
> Python.

<rant>
I agree.  I don't understand why some people are still
referring to timings as the authorative decision factor
as to what language to use.  It depends on the project.
The language is only a vehicle for writing down a way to
solve a problem, and if the problem is mostly about
manipulating text, then awk or perl is the choice,
if not for speed reasons then for ease of development and
robustness.  If it's about webbased client/server computation,
Java might be best.  If the solution is easily expressed with
functional decomposition, C is the way to go, and for a
more direct mapping between real world objects and their
computer representation, C++ might be best.

This is so clear cut I don't understand people still miss
out on this one :)  Or am I myself missing something :)
</rant>

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

Or am I too optimistic :)

Bert
-- 

-=<Short Controlled Bursts>=-