I think you need to register to view the article, so I'll post the choice parts.
http://www.gamasutra.com/features/20020710/white_02.htm
All the programmers repeat after me: what. the. fuck. Writing a lisp compiler for your kiddy platformer???????Postmortem: Naughty Dog's Jak and Daxter: the Precursor Legacy
What went right:
5. 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.
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.
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.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.
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:
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".an engine that allows modification to the stock game through such means as a built-in lisp interpreter [and] external game-object lisp code
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.Originally Posted by Anonymous2
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.
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.Sure, I agree, but for a platformer? Maybe they should throw a database engine in there while they're at it.
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.
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.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.
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.
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.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.
- 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?
- 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.
- 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.
- 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).
- 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.
- "Nintendo does not do things like this." Ha! No comment.
- 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.
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.
I think it's unlikely that the tech developed for J&D won't be reused in sequels or possible unrelated games from Naughty Dog.
And, come on, do you guys really think the game would've been better had they license lithtech or unreal tech? Creating their own language probably cause lots of headaches and some delays, but as has been mentioned above, these guys aren't sweating the cash flow like some houses might be. Aside from having an extremely successful franchise in their past, they're extremely high profile as PS2 exclusive so Sony probably keeps the money coming too.
I didn't say they should have licensed third party software; I linked to the article because I think it's a textbook example of what's sometime wrong with game development: over-engineering the problem. Maybe they're reuse it in the future, but the part where he says they THREW AWAY a ton of tools they'd previously been using because they weren't compatible with the new LISP stuff is a big red flag.
Posting Permissions
Reply With Quote