| |
|
|
||||
![]() |
||||||
| |
|
|||||
|
The Tale of An Abused Bandicoot Crack-dot-com's Abuse, released in 1995, was one of the first games to look to a higher-level language for much of the gameplay-related code. Jonathan Clark chose to use Lisp as the scripting language, which although one of the oldest programming languages in existence, still has the features to classify it as modern. Says Clark: Being a C/C++ junkie all my life, I quickly found myself fascinated by Lisp. Here was something totally different: a functional language where data and code are the same thing, an environment where experimentation and incremental development was a way of life. He offers a comparison of some simple C++ code: typedef void (*draw_function_ptr)(); struct my_struct{ color_class *color; char *name; draw_function_ptr ptr; }; my_struct array[4]; void init() { array[0].color = new color_class(255,0,0); array[0].name = "Blue Guy"; array[0].ptr = blue_draw_function; // etc. } and the equivalent code in Lisp, taken directly from the Abuse source: (setq my_list `( ( ,(new-color 0 0 255) "Blue Guy" blue_draw_function) ( ,(new-color 255 0 0) "Red Guy" red_draw_function))) The current games that show the power of a Lisp-like language are Naughty Dog's Crash Bandicoot titles. Andy Gavin, self-admitted Lisp fanatic, developed his own Lisp-like language that could efficiently be compiled to machine code for the PlayStation's processor. This may sound Herculean, but the compiler was also written in Lisp (on a PC) and the symbolic manipulation needed for compilation is one of Lisp's strengths. Jonathan Clark also wrote his own Lisp interpreters for Abuse and Golgotha ("the language is simple enough that I had a fairly complete system in a week," he says). The Crash Bandicoot graphics engine was coded in C, of course, but the Lispish GOOL was used for the sequencing and data handling that defines the playable aspects of the game. C is brilliant for operating on rigidly structured values in an efficient manner, but isn't nearly as nice when it comes to slinging around data in the loose manner needed for gluing together bits of rendering into something fun. The scripting in Crash is about as complex and slick as ever attempted: Crash can run, fly a plane (and shoot down other planes), drive a boat, use a jetpack, swim underwater, and perform endless specialized actions. Oh, and the series has sold over ten million copies. Chalk one up for Lisp. Beyond Scripting Scripting is one thing, but can the benefits of languages like Lisp and Dylan (a Lisp-like language with a more familiar syntax) be used for the tricky bits of a 3D engine? Researcher Francois Pessaux was curious as well, so he set out to write a Doom-style engine directly in Objective Caml, an ML dialect that's been in development for fifteen years. Admittedly, 2.5 dimensional graphics are a thing of the past, but there are still a lot of interesting problems involved, including BSP generation and traversal, and a level-editor. Objective Caml is an interesting language. It feels a lot like Haskell, but the implementers have given efficient compilation a higher priority than most groups doing language research. So, it's a good way to see how higher-level languages stack up to old standbys, like C. Francois wrote his code twice, once in Objective Caml, and once in C, for just this reason. In the end, he had 1000 non-blank lines of C and 700 of Objective Caml. The former code ran at 125 frames per second and the latter at 100, both running on a 333 MHz Pentium II. Yes, C technically "won," but the margin was awfully close. And Francois admitted that the Objective Caml version was much easier to write and debug. As a final comment on this test, note that the Objective Caml compiler was at version 1.0x when Francois wrote his paper. It's been stepped a full version and greatly improved since then. The general goal has been to get more elegant languages to within a factor of two of C. Once inside that range, the next processor generation or some general tweaking is enough to close the gap. Being able to interactively diddle with data structures and algorithms might be more than enough to make up for a measured speed hit in toy benchmarks. |
|
|