Making Crash Bandicoot, by Andy Gavin and Jason Rubin | Hacker News Reader

Making Crash Bandicoot, by Andy Gavin and Jason Rubin

naughtydog.com

136 pointsslackito25 comments

NDI didn't ditch GOAL because I left. In fact they used it for JakX and they also ported it to the PSP (successfully). However, the PS3 development didn't get started on porting it early, so they went with a different tact. Christophe (co-president and lead tech honcho there now) lamented to me on several occasions that they should have ported it to the PS3.

Not that the process hasn't gone well for them -- Uncharted and UC2 are totally awesome, and watching the UC3 trailer gives me goosebumps. Dan (head gameplay programmer) did miss it so bad that he went with Scheme for their scripting :-) There are many ways to skin a cat, and the truth is that as long as you have good people (which they do in spades) and make decent decisions decisively, things tend to work out. Forward progress is one of the most important things.

Direct links, submitted page is just linking to them:

http://all-things-andy-gavin.com/2011/02/02/making-crash-ban...

http://all-things-andy-gavin.com/2011/02/03/making-crash-ban...

http://all-things-andy-gavin.com/2011/02/04/making-crash-ban...

http://all-things-andy-gavin.com/2011/02/05/making-crash-ban...

http://all-things-andy-gavin.com/2011/02/06/making-crash-ban...

http://all-things-andy-gavin.com/2011/02/07/making-crash-ban...

http://all-things-andy-gavin.com/2011/02/08/making-crash-ban...

Part 7: http://all-things-andy-gavin.com/2011/02/10/crash-bandicoot-...

Quote from part 3:

Our motto was “bite off more than we could chew, then figure out some crazy complicated way to make it work.”

What a great motto to have for anything you're working on, clearly it paid off.

And what's even more wonderful is that you might expect that this trait would been tempered with so-called "experience" - but they continued being "overly-ambitious" throughout their next decade at Naughty Dog and into their ventures beyond.

This is fascinating. Naughty Dog has developed for Sony consoles since Crash, so they might have low visibility if you're not in touch with the Playstation ecosystem, but they're renowned for their total mastery of successive generations of the Playstation hardware.

HNers might be sad to learn that they gave up writing games in their home-grown Lisp with the advent of the PS3 era. It was called GOOL, and later, GOAL: http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

Don't worry. They used PLT Scheme in their latest. http://www.gameenginebook.com/gdc09-statescripting-uncharted... [PDF]

I read an article a while back that said after the engineer that wrote GOAL left the company, they stopped using it and went back to pure C++ or something.

Hearing that they use Racket now, that just makes me all happy inside.

They were acquired by SCE. The mandate to use C++ came from above, most likely.

They are using Racket to generate C++ code.

For what it's worth, I interviewed with them shortly after their acquisition by Sony. The gentleman I talked to told me that Sony corporate had dictated that they give up GOAL for C++ so that their code would be interoperable with the rest of the company.

Using languages with runtime code generation is also quite difficult with modern consoles that don't let you change executable memory pages, or allocate new ones, which means you're stuck compiling offline. Even though changing PPU code is off limits, the PS3 does let you generate SPU code on the fly but it seems to be a capability that few (if any) use.

That's only a problem if you are using JIT compilation. Otherwise a VM (whose executable doesn't change) would just handle the runtime stuff, which is mostly going to be game logic and not super-high-performance stuff (like rendering or audio).

Ahh, but the beauty of GOAL was that the entire game was built using it, including the super-high performance stuff.

GOAL compiled to native code, which made this possible. It also made it easy to mix and match assembly primitives in with your existing code, using the same syntax (much nicer than GCC's intrinsics).

This was before the days of LLVM, so the code generation phase was actually enormous amount of work (Andy spent a lot of time on the register coloring, for example) - not to mention having to write a debugger.

This isn't quite the same thing. The Jak games were built entirely using GOAL (other than a tiny microkernel in C) - gameplay, collision detection, rendering, AI, you name it.

Uncharted is using a LISP-like scripting language for gameplay scripting. Most large games use scripting these days (LUA is pretty common), this just happens to be a lisp-flavored variant of that. There's a huge difference between writing your gameplay scripting in a lisp and building your entire game in it.

I had the pleasure of going through a fairly extensive (and certainly my most intimidating) phone interview with Andy once for one of his more recent ventures. The amount of smarts and insight this fellow has really can't be overstated.

Ah, Crash Bandicoot. My younger brother hogged our Playstation with it all day, when I wanted to play Metal Gear Solid.

Well, at least until I told my Fundamentalist mother that there were Satanic symbols in the game. That put an end to that...

How did your brother retaliate?

I got away scot-free. Good times.

Part 3 contains the most interesting technical details. They really milked the absolute max out of the Playstation through a combination of pre-calculating visual occlusion and a custom (Lisp, of course!) programming language that was designed to make use of the hardware directly.

An early inspiration for our precomputation approach was Seth Teller's 1992 Ph.D. thesis (bio at http://www.csail.mit.edu/user/1544).

Seth worked out the (5D) math to trace the propagation of light through portals and precompute the set of visible polygons from any point in a so-called "architectural walkthrough" -- i.e., traversal of a space with lots of walls.

We knew that would never work for something as low-power as the PS1, but we were intrigued enough by Teller's work to try a very watered-down brute force variant.

As Andy describes in the article, this is what led to our precomputing the visible set of polygons (and their relative sort order) for every frame of the game. This was actually hard for three reasons:

- we had to distribute the precomputation work across all the artists' SGI workstations to get it done in under an hour per level - we had to store a sorted list of polygons per frame in a compact enough way that it would fit - we had to weave the foreground elements, which were not precomputed, into the background, which was

It was a really fun, but very challenging, project to get this all to work.

Here's a link to the brief mention of the Lisp they used for some kind of scripting inside the game. I've often heard of this so it's too bad there isn't a little more info on it:

http://all-things-andy-gavin.com/2011/02/04/making-crash-ban...

There is now a part 7 and part 8.

http://all-things-andy-gavin.com/2011/02/10/crash-bandicoot-...

http://all-things-andy-gavin.com/2011/02/16/crash-bandicoot-...

I've started learning Common Lisp because of them :) and I don't regret it. I can now program better in languages with closures, macroses, tagged data, interfacing with FFI, etc.

I learned a lot by making that step, and there is way more to be learned.

We hates your nasty, cruftsy, tricksy hard-to-read macroses! We hates them!

this is awesome, especially from the perspective of a programmer who was 9 when he first played crash. how full circle.

Reply on news.ycombinator.com