Adventures in bad game design, brought to you by Naughty Dog

I think you need to register to view the article, so I’ll post the choice parts.

Postmortem: Naughty Dog’s Jak and Daxter: the Precursor Legacy

What went right:

  1. GOAL rules! Practically all of the run-time code (approximately half a million lines of source code) was written in GOAL (Game Object Assembly Lisp), Naughty Dog’s own internally developed language, which was based on the Lisp programming language. Before you dismiss us as crazy, consider the many advantages of having a custom compiler.

What went wrong:

  1. GOAL sucks! While it’s true that GOAL gave us many advantages, GOAL caused us a lot of grief. A single programmer (who could easily be one of the top ten Lisp programmers in the world) wrote GOAL. While he called his Lisp techniques and programming practices “revolutionary,” others referred to them as “code encryption,” since only he could understand them. Because of this, all of the support, bug fixes, feature enhancements, and optimizations had to come from one person, creating quite a bottleneck. 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.

All the programmers repeat after me: what. the. fuck. Writing a lisp compiler for your kiddy platformer???

Oh, also:

Because we were so busy creating the technology for our seamless world, we didn’t have time to work on gameplay code until fairly late in the project.

This is a big problem with many development houses. They spend too much time on the technology and not enough time on the gameplay. That’s why I’m excited that some companies are starting to release increasingly flexible toolsets that remove a large part of the the technology issue from the equation. This probably stems from a desire to make games more accessible to the mod community, but hey, what’s good for the goose is good for the gander.

  • Alan

There’s some serious advantages to using a language like Lisp instead of a more general purpose approach such as C or C++ (look up some general information on LISP on google, there’s stuff aplenty). The advantages become even more clear when you were in ND’s position-the PS2 was barely out, the existing development tools were by all accounts extremely weak, and there was great potential in writing your own custom compiler to interface with the nuances of the PS2’s architecture.

The problem was that their ace programmer who was writing the code was doing so without any sort of peer challenging of his designs. They should have matched him up with another person and worked as a pair from the start-chances are they’d not only have better code to start from, but also have faster bug turnaround when they needed it.

Because we were so busy creating the technology for our seamless world, we didn’t have time to work on gameplay code until fairly late in the project.

All I can say to this is that their project planning sucks. Cutting a few corners with respect to technology in order to free up time for gameplay code would have made a better game. Usually there are more than a few time-consuming features that are in plan that can be cut without much loss to the overall quality of the produced product.

Crash Bandicoot 2 was the best of the three. Crash Warped DID have a good number of different things to do, but it just wasn’t nearly as challenging as 2 was.

Now Crash Team Racing, that’s the only Kart racer I think i’ll ever like. Extremely well done game with fantastic tracks and pulse pounding races.

It does seem awfully silly, huh? But as a programmer, I think programmers should be able to explore ideas like that. If you can stomach the risk, a risk can pay off. Now they have something that lets them easily change code while the game is running.

They all seem to like how it turned out, while simultaneously saying, “Man, we’re lucky that it turned out OK.”

But the more I think about it, I don’t see it as too far separated from creating a game engine in C, really.

Haha, remember on your show last night when the Hamster was doing backflips?

It just goes to show the lengths that some people go to to avoid spending money on development tools.

Ex-id employee Dave Taylor’s way, way out of business game company, Crack-Dot-Com, produced a game called Abuse that according to the FAQ has:

an engine that allows modification to the stock game through such means as a built-in lisp interpreter [and] external game-object lisp code

As I remember, Abuse was pretty fun. I’m not sure how much of the fun was attributable to either lisp or nostalgia. I own a book called “The Little Lisper”.

I believe that the patented “fun-shaders” in Nintendo’s Gamecube chipset have hooks for LISP.

I don’t think it was about the available tools being expensive-certainly they aren’t as expensive as hiring a hotshot programmer and taking the risks involved in writing a game engine from scratch. I think it has much more to do with the tools being suitable and flexible enough to do the job they need to do. And, in the case of ND (which was probably starting up on the game in the middle of 2000, even before the PS2 came out in the states), there weren’t a lot of choices to be made in development tools.

Edit: Doug, I never knew that the fun-shaders had lisps. Now I know why GC games seem to stutter so much in the fun department. :wink:

Sure, I agree, but for a platformer? Maybe they should throw a database engine in there while they’re at it.

Sure, I agree, but for a platformer? Maybe they should throw a database engine in there while they’re at it.

I’m not sure I understand what you mean here. Actually, I don’t understand most of this thread, but does does this programming choice seem so boneheaded because they were working on a platformer? I’m seriously curious.

Well, the advantage of lisp is it makes scripting out levels really easy. The disadvantage is that…well, you’re writing a lisp compiler, which is a non-trivial application.

I can’t imagine how they saved money by doing this.

Because of this, all of the support, bug fixes, feature enhancements, and optimizations had to come from one person, creating quite a bottleneck. 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.

Eventually GOAL became much more robust, but even now C++ has some advantages over GOAL, such as destructors, better constructors, and the ease of declaring inline methods.
A major difficulty was that we worked in such isolation from the rest of the world. We gave up third-party development tools such as profilers and debuggers, and we gave up existing libraries, including code previously developed internally. Compared to the thousands of programmers with many years of C++ experience, there are relatively few programmers with Lisp experience, and no programmers (outside of Naughty Dog) with GOAL experience, making hiring more difficult.

Actually, I don’t understand most of this thread, but does does this programming choice seem so boneheaded because they were working on a platformer? I’m seriously curious.

That’s exactly it. It’s the point Nintendo’s been trying to make for eons, and one of the few things they’re dead-on right about.

Spending your time mucking about with technology to make a PLATFORMER is ludicrous. Simple action titles like that gain their appeal from their mechanics and control, not their ability to display realistic AI behaviors, seamless vistae, or shovel x-million multi-textured polys in from of the player.

Suffice it to say, I don’t think Mario Sunshine or Zelda needed a LISP compiler. It’s too bad that the PS2 is such a punishing system - we’re seeing the same problem with Ratchet and Clank from the Spyro team. It’s pure graphic genius that crushes the Nintendo offerings from a purely technical perspective, yet is a pretty limp sock in the gameplay department. And despite the fact that neither is doing much with textures and polys, Zelda and Mario still have a great aesthetic style.

I should note that Super Mario Sunshine has a hub-based gameplay system instead of “seamless vistae”, the enemies have simple scripted behaviors, and the graphics are technically weak. It also has a gay name, and will own ND’s Jak and Daxter in every way that matters. Why? Because Nintendo realized they were making a PLATFORMER, not bloody Splinter Cell or Unreal. American devs really need to realize that high technology is only useful when it’s, well, APPROPRIATE.

All I can say to this is that their project planning sucks. Cutting a few corners with respect to technology in order to free up time for gameplay code would have made a better game.

So true. Poor corporate practices will kill a game faster than any technology or design issue ever will. It’s no coincidence that better run companies produce better games.

  • Alan

Thanks Doug. That actually made sense.

I agree with Doug, but I’m curious if you’ve seen Super Mario Sunshine in action? The water stuff really blows me away when I see the footage on G4. I can’t wait to play it. I have a hard time believing that Ratchet and Clank is going to look that much better. The gameplay movies at IGN didn’t make the graphics look that good…

–Dave

As a PS2 owner, I have yet to see a PS2 game that I would even qualify as having “great” graphics.

As far as graphics goes, PS2 is the N64 of this console generation. If blurry and pixelated is your cup of tea, you will love it.

Man, there is so much wrong stuff floating around in this discussion. Where should I start?

[ol][li]The idea that creating your own language is somehow bad. It may not be the right choice in many situations, but there are certainly advantages to it – look at Unreal and Quake for two good examples. Unreal added some fantastic scripting features (i.e. replication) that make network-oriented things reliable and much easier to write. QuakeC and its descendents provide a secure, cross-platform way for game scripting and mods to be written. And for the example in question (GOAL), the ability to change game state or code while running the game is fantastic – you really don’t understand how nice it is to be able to do stuff like this. Saves TONS of time in gameplay balancing and debugging.
[/li]
[li]The idea that the genre of the game somehow weighs into this. This is just plain wrong. A platformer can be as complicated technically as any other sort of game. For an example of another impressive technical feat in J&D, try and find a loading screen once you have started playing.
[/li]
[li]The idea that third-party engines will allow developers to focus more on the gameplay. This is true to some degree, but with the tradeoff that games that use 3rd-party engines usually don’t push the hardware to its limits, or take advantage of a platform’s strengths (as much as a home-grown engine might).
[/li]
[li]Saying that Naughty Dog are cheapskates and wrote their own stuff because they didn’t want to license someone else’s. Believe me, they do not have to pinch pennies.
[/li]
[li]“Nintendo does not do things like this.” Ha! No comment.
[/li]
[li]That writing a compiler is impossible or something. It can be hard (depending on the language, features, optimizations, and other factors), but it’s not out of the realm of reason. It is not uncommon for computer science undergraduates, or graduate students, to write one as a semester project.[/ol]
[/li]
BTW, wasn’t J&D widely considered to be a good game?

That’s true, but Unreal and Quake were also created as engines to be licensed. But in the case of J & D (which I didn’t play so no comment on the game itself), they will almost certainly not be licensing the engine in the Quake and Unreal method, so the extra time spent on their custom engine might not produce any revenue which could balance out the extra development time. Now that doesn’t mean it still might not be a good decision for some games, but clearly from the developer quote it was not a good decision for them.