Lisp in Jak and Daxter
Dan Liebgold from Naughty Dog did a talk on using Racket during development for the PlayStation 3 at Racketcon a few years ago [0].
Please add 2012 in the title. Also this was previously submitted without comments.
The topic was old... but I am glad someone commented on the downsides of implementing your own language/tooling and what happens next to the team; for example:
> Also, it took over a year to develop the compiler, during which time the other programmers had to make do with missing features, odd quirks, and numerous bugs.
That makes me thing only ultra-flexible teams or huge companies fit the bill into the approach of creating such a technical debt as a compiler can be.
The first link in the article is not correct anymore, I think it's supposed to point to this one. http://www.gamasutra.com/view/feature/131394/postmortem_naug...
I remember running into GOAL and GOOL a ways back and was fascinated with it. One thing I never got good info on was how they handled their memory. Generally game developers frown upon garbage collection, so I'd love to find out if GOOL/GOAL did anything to target that specifically. I tried reaching out to one of the developers on his blog about it but never got a response
Wow, I remember reading that postmortem when it first came out.
I was still in university at the time and at the time I was only marginally aware that Lisp existed as an alternative to the Java/C++/Pascal we've been taught.
After reading the postmortem I became very interested in this mysterious Lisp language that was being used by the experts.
Curious about the Yahoo Store debacle that was mentioned a few times.
Another Lisp based game was Abuse.
A. Using Lisp with a couple of minor convenience macros can be a very good idea.
Z. Writing an entire language and ecosystem just for a game is insane.
These are not binary choices: there is a very smooth continuum between these two, and is one of the major advantages of Lisp. Naughty Dog just took too many steps from A towards Z. Each step probably seemed reasonable at the time...
This comes up on HN periodically. Here are few points to keep in mind:
- In 1994, when Andy started on GOOL, the tools around C/C++ were far more limited. Basically all we had was GCC; there wasn't even a decent debugger in the beginning if I recall correctly. So it was less crazy to make a whole DSL for game control code then than it may seem now.
- There was no GC; the PS1 only had 2MB of RAM so we had to be incredibly careful and precise with memory management. It was also slow (33Mhz) so GC pauses were obviously not going to be OK.
- At least in Crash Bandicoot (I didn't work on Jak), lisp was not used for the rendering engine, the collision detection, or the camera control code -- that was all written in C (or MIPS assembly). Lisp was used for character control logic and various non performance intensive tasks, like the load/save interface.
- It really wasn't that hard to "make a whole new language" in our case because Andy used Allegro as the basis for the compiler -- and of course with lisp, code is data. :)
It was a labor saving device and a boon to rapid prototyping of character behaviors to have a simple very high-level language for this. This advantage was ultimately offset over time as the platforms got faster and gained more RAM. But at the time, there was no Python, Lua, etc. -- and even if there were, they'd be too RAM-intensive to use. (Maybe embedded variants of these languages would have worked, though.)