It's free to join Gamasutra!|Have a question? Want to know who runs this site? Here you go.|Targeting the game development market with your product or service? Get info on advertising here.||For altering your contact information or changing email subscription preferences.
Registered members can log in here.Back to the home page.

Search articles, jobs, buyers guide, and more.

By James Hague
Gamasutra
August 13, 1999

Printer Friendly
Version Available

Letters to the Editor:
Write a letter
View all letters


Features

 

Contents

Introduction

What Are the Benefits, Exactly?

The Tale of An Abused Bandicoot

Yes, but Are You Really Serious About All This?

Yes, but Are You Really Serious About All This?

The real question is when any of this language research is going to finally make its way into a full-fledged game. The concepts have been proven, the productivity gains are real, but it's easy to get deluded into thinking that better technology always wins (something that whoever ported Resident Evil from the PlayStation to the Game Boy probably thought about on a daily basis). What's been keeping Objective Caml and Haskell and ML and Dylan and even good ol' Lisp out of the mainstream?

First, it can take a significant amount of time to unwarp your C-riddled mind enough to be able to wrap it around some very different concepts. Think about how strange some things seemed when you were first exposed to them in Computer Science 101. Even linked lists might have seemed a bit heady back then. When you start reading about currying and lazy lists and finding out that variables now have a reputation similar to that of the GOTO, you'll be back in that dizzy state of mind.

Then there's Java. Java has been hyped as a simpler alternative to C++. And it certainly is, except that it's still the same sort of language with the same general features, style, and shortcomings. It's close enough to C++ in principle that the performance difference is more striking than that between C and Lisp. In Lisp, you're willing to trade a few performance points for the interactivity and language benefits. In Java, there's this nagging thought that you should just write in C++ and be done with it. Even so, Java has taken over as the easy and portable language.

Finally, C can live in a vacuum, but most of the languages I've mentioned can't. You can write the game engine in C. You can write the level editor in C. You can use C for scripting. But while ML is great for many things, it doesn't let you do the bit-level mucking about that's needed to write a good LZW compressor or to manipulate a 16-bit frame buffer. You need to write at least small bits of C code that can be hooked into the language of your choice. The bottom line is that you can learn C++ and be done with it, but you can't do the same with most of the languages I've mentioned. You still need to dip into the lower-level bit bucket every once in a while.

Back when most games were programmed entirely in assembly language (and even 1993's hugely popular and oft-ported NBA Jam was written in assembly), there were endless debates about how necessary or pointless this was. Over the years, the former point of view has been greatly eroded, leaving only the occasional misguided newbie — Game Boy programmers excepted. Modern languages are still at the beginnings of these debates. "They're too slow! C++ is the only way to go!" might be the current battle cry, but it's sounding awfully familiar…

References

Graham, Paul. ANSI Common Lisp. New Jersey: Prentice-Hall, 1996.

Pessaux, Francois. "OCamlDoom: ML for 3D Action Games," 1998.

The Haskell web site: http://www.haskell.org

James Hague (jhague@dadgum.com) became addicted to wacky, alternative viewpoints after starting his own Mac-only software company in 1996. He's currently very happy doing programming for Volition's upcoming Summoner RPG.


[Back to] Introduction


join | contact us | advertise | write | my profile
news | features | companies | jobs | resumes | education | product guide | projects | store



Copyright © 2003 CMP Media LLC

privacy policy
| terms of service