Image
  • Writing
    • Andy Gavin: Author
    • About my Novels & Writing
    • All Writing Posts
    • The Darkening Dream
      • Buy the Book Online
      • Sample Chapters
      • Reviews
      • Info for Reviewers
      • Press Coverage
      • Awards
      • Cast of Characters
    • Untimed
      • Buy Untimed Online
      • Book Trailer
      • Sample Chapters
      • Reviews
      • Info for Reviewers
      • Press Coverage
      • Awards
      • Cast of Characters
    • Scrivener – Writer’s Word Processor
    • iPad for Writers
    • Naughty Dark Contest
  • Books
    • Book Review Index
    • Favorite Fantasy Novels
    • Andy Gavin: Author
    • The Darkening Dream
      • Buy the Book Online
      • Sample Chapters
      • Short Story: Harvard Divinity
      • Reviews
      • Info for Reviewers
      • Press Coverage
      • Awards
      • Cast of Characters
    • Untimed
      • About the Book
      • Buy Untimed Online
      • Book Trailer
      • Sample Chapters
      • Reviews
      • Info for Reviewers
      • Press Coverage
      • Awards
      • Cast of Characters
    • Naughty Dark Contest
  • Games
    • My Video Game Career
    • Post Archive by Series
    • All Games Posts Inline
    • Making Crash Bandicoot
    • Crash 15th Anniversary Memories
    • World of Warcraft Endgames
    • Getting a Job Designing Video Games
    • Getting a Job Programming Video Games
    • Naughty Dark Contest
  • Movies
    • Movie Review Index
  • Television
    • TV Review Index
    • Buffy the Vampire Slayer
    • A Game of Thrones
  • Food
    • Food Review Index
    • Foodie Club
    • Hedonists
    • LA Sushi Index
    • Chinese Food Index
    • LA Peking Duck Guide
    • Eating Italy
    • Eating France
    • Eating Spain
    • Eating Croatia
    • Eating Vietnam
    • Eating Australia
    • Eating Israel
    • Ultimate Pizza
    • ThanksGavin
    • Margarita Mix
    • Foodie Photography
    • Burgundy Vintage Chart
  • Other
    • All Posts, Magazine Style
    • Archive of all Posts
    • Fiction
    • Technology
    • History
    • Anything Else
  • Gallery
  • Bio
  • About
    • About me
    • About my Writing
    • About my Video Games
    • Ask Me Anything
  • Contact

Archive for pt_crash_history

War Stories: Crash Bandicoot

Feb27

Ars Technica — the awesome technical website — put together an equally awesome video interview with me about the making of Crash Bandicoot as part of their War Stories series detailing how various video games were created.

You can check it out here:

This interview gets into the nitty gritty of various problems we faced and overcame at Naughty Dog in our quest to realize the goal of making one of the first 3D Platform Action Adventure games. When we started, no one had ever made a Character Action game in 3D and we were forging boldly (insanely?) into new territory. We were young. 3D graphics were young. The Playstation was young. Gaming was young (or at least younger than it is now). So Jason, I, and the rest of the team had to figure everything out from scratch and just try to make the best game possible.

Speaking of teams, the one at Ars did an awesome job animating and editing my detailed story so that it actually makes sense!

And on 3/26/20 Ars cut a second episode from my footage for their “Extended Interview” series:

Check out the full Ars article here. or the second one here.

If you liked this post, follow me at:

My novels: The Darkening Dream and Untimed
or the
video game post depot
or win Crash & Jak giveaways!

The series begins here: Making Crash Bandicoot

For more articles detailing the making of Crash Bandicoot, click here.

Related posts:

  1. Crash Bandicoot Reunion
  2. Making Crash Bandicoot – part 1
  3. Making Crash Bandicoot – part 5
  4. Crash Bandicoot – Interviews “R” us
  5. Crash Bandicoot – Teaching an Old Dog New Bits – part 1
By: agavin
Comments (1)
Posted in: Games
Tagged as: Ars Technica, Crash Bandicoot, Game design, Naughty Dog, Programming, pt_crash_history, Technical, Video Games

Crash goes to Japan – part 1

Jan11

It’s probably hard for younger gamers to recognize the position in gaming that Japan occupied from the mid eighties to the late 90s. First of all, after video games rose like a phoenix from the “great crash of ’82” (in which the classic coin-op and Atari dominated home market imploded), all major video game machines were from Japan until the arrival of the Xbox. Things were dominated by Nintendo, Sega, Nintendo, Sony, Nintendo, Sony… you get the picture.

And in the days before the home market eclipsed and destroyed the arcade, Japan completely crushed everyone else. Only the occasional US hit like Mortal Kombat even registered on the radar.

Miyamoto, creator of Mario, playing Crash 1. I’m standing behind him off frame

All of this, not to mention the cool samurai/anime culture and ridiculously yummy food (see my sushi index!), made us American video game creators pretty much all Miyamoto groupies.

But on the flip side, American games, if they even made it to the land of the rising sun at all, almost always flopped.

Japanese taste is different the wisdom went. Special. Foreign games even had a special name over there (which I have no idea how to spell). These “lesser” titles were stocked in a seedy back corner of your typical Japanese game store, near the oddball porn games.

So it was with great enthusiasm and limited expectations that we approached the mutual Naughty Dog, Mark Cerny, and Sony decision that we were going to take  the Japanese market really seriously with Crash. Sony assigned two brilliant and dedicated producers to us: Shuhei Yoshida and his then assistant Shimizu (aka Tsurumi-0600). They sat in on every major planning meeting and we scheduled the whole fall for me to localize the game in exacting detail (while we were simultaneously beginning work on Crash 2!).

For the most part, Yoshida-san made things happen and Shimizu, who has literally played like every video game ever made and read like every manga, worked the details. I (with a bunch of help from the artists) had to put in the changes.

Yoshida-san front and center, Shimizu on the far left, Rio (joined the team during Crash 2) on the far right

Somehow Yoshida-san was able to maneuver the game into being not one of those funny foreign games, but an official bona fide release of Sony Computer Entertainment, Inc. the first party Japanese studio. And it was to be sold and marketed pretty much like it had been made in Japan! Wow!

So to pull off this cultural masquerade Jason and I decided that Shu (as Yoshida-san was affectionately known) and Shimizu got pretty much whatever they wanted. They after all, knew the mysterious Japanese market. Which turned out to be pretty darn true. And, besides, both are really really smart and crazy hard workers (Shimizu is famous for sleeping under his desk) and so we all got along famously.

The gameplay itself wasn’t really too much of an issue. Shimizu did help us smooth out some sections and make them easier (often by adding extra continue points − opposite of Europe). But there were a lot of other changes.

The Crash 1 main titles, in Japanese

First of all, we had to translate the text. Some of this wasn’t so bad. But the main logo was a 3D object and Jason had to painstakingly create a version of the paper design the Japanese provided us — which required lots of checking from Shimizu as he doesn’t speak Japanese.

Above is the opening in Japanese.

And things got even harder (for me) with the in game text. The Playstation didn’t have a lot of video memory and we were using a medium resolution 512 pixel wide mode anyway. What little there was, we had pretty much consumed. But the Japanese language has four alphabets! One is Latin, two are similar but different looking phonetic alphabets, and the last is the giant Kanji pictographic database. Kanji would’ve been impossible, but we needed to cram the two extra phonetic sets in. Plus the characters are more intricate than the Latin alphabet and need more pixels. I can’t remember what I did to squeeze them in, but I do remember it was painful. One part I do recall was implementing the sets of letters that vary only by an extra dot or ” mark by drawing them with two sprites (hence saving video ram).

Once the font was installed we had to input the crazy looking “shift JIS” text. One of the problems in those days was that the text editors all 8-bit, unlike today were 16-bit typesets dominate. And with a European language you can usually tell if a line of text had gotten swapped or mangled, but in Japanese… and even worse, in shift JIS it just looks like a bunch of garbage characters.

So again, Shimizu had to check everything. A lot.

Our opening and closing cut scene dialog was recorded in Japanese using very high profile Japanese actors (so they told me). We replaced those audio files (using one of my automated systems of course!). There were also a good number of cases throughout the game where we had placed text in textures. The configuration screens, loading screens, load/save screens and all sorts of other ones. These all needed new versions. We collected all of these textures, shipped them out to Japan and got back Shimizu certified versions in exactly the same sizes with the Japanese text. I used and upgraded the system that I had built for the European version so that any file (texture, audio, etc) in the game could be “replaced” by a file of the same name in the same directory with a .J on the end (or a .S, .E, .F, .G, .I for various European permutations). The level packaging tool would automatically suck up the most appropriate version and shove it in the J versions of the levels. I’m not sure we left ANYTHING untranslated. Even Japanese games usually had more Engrish. Achem, English. I so remember a Castlevania with “Dlacura’s grave.”

Then the Japanese came up with this idea of having Aku Aku explain various gameplay mechanics to you when you break his boxes, much like the raspberry boxes in Super Mario World. This was a great idea, except it meant that the game was suddenly filled with about 200 extra paragraphs of text. Undecipherable text. I had to squeeze that into the levels too. More problematic was the seemingly simple fact that when a big block of text comes up on the screen the game effectively needs to pause so the player can read it. You can’t just “hit pause” but need a separate state. This simple feature caused a lot of bugs. A lot. But we stomped them out eventually.

Above you can see a walk through of the first level. A lot of the PITA localization work was in the save screens (big fun: character entry screen in three Japanese alphabets) and the various statistic screens at the end of the level. I think the Japanese allowed us to do away with the horrible password system and use memory card only.

The Japanese box and CD with its very strange Crash and Eve painting — it was nice and colorful

The Japanese also had some famous actor record a whole collection of really zany sounding grunts and noises that Crash was to make. Shimizu lovingly crafted long lists of extremely specific places in the game where exactly such and such exclamation was to be uttered. He was never one to spare either of us from a great deal of work 🙂 But his willingness to tackle any task himself, no matter how tedious, made him hard to refuse. I also had to squeeze all these extra samples into the extremely tight sound memory, mostly by downgrading the bit-rate on other sounds. This caused Mike Gollom, our awesome sound design contractor to groan and moan. “3.5k is pure butchery” he’d complain. I found this SGI tool that used a really advanced new algorithm to downgrade the sounds, they sounded twice as good at any given bit-rate than the Sony tool.

Anyway the really funny bit about these Crash sounds was the subjective feel they left us Americans with. Strange! They made Crash sound like a constipated old man. But the Japanese insisted they were perfect. I guess they were right because the game sold like crazy over there.

Another weird audio difference was that five of the songs were swapped out for new ones. Josh Mancell the composer put it this way:

An 11th hour decision made by the Sony people in Japan. They felt that the boss rounds needed to sound more ‘video game-like’. The only reference they gave was music from the Main Street Electrical Parade at Disneyland. I only had a day or so to write all those themes. My favorite comment was about the original Tawna bonus round music. It roughly translated into ‘the sound of the guitar mixed with the tree imagery is too nostalgic-sounding’. I’m still scratching my head on that one.

You can find the different tracks here.

There were also a host of minor but strange modifications we needed to make. One was that a few characters originally had four fingers, which is typical of most American cartoon characters. Apparently the Japanese have a more than usual dislike of disfigured humanoids. Fingers were added (to make them the normal five). There were a whole bunch of little visual, audio, and gameplay changes Shimizu had us make to the game. Most of these I felt were neutral, different but not really better or worse, so I just trusted him and put them in. Occasionally if they were a really pain I pushed back.

Eventually, right around Thanksgiving, just in time for Jason and I to head to Japan to promote it, the Japanese version was ready!

Coming soon, I plan on a part 2 covering Japanese marketing and promotions!

If you didn’t catch it, I have a similar detailed post in the European localization of Crash.

If you liked this post, follow me at:

My novels: The Darkening Dream and Untimed
or the
video game post depot
or win Crash & Jak giveaways!

Latest hot post: War Stories: Crash Bandicoot

Cover of the hint guide in Japan

Related posts:

  1. Crash Bandicoot – An Outsider’s Perspective (part 8)
  2. Parlez vous Crash
  3. Making Crash Bandicoot – part 5
  4. Making Crash Bandicoot – part 1
  5. Making Crash Bandicoot – part 2
By: agavin
Comments (141)
Posted in: Games
Tagged as: Atari, Crash Bandicoot, Japan, Japanese Localization, Mark Cerny, Mortal Kombat, Naughty Dog, Nintendo, pt_crash_history, Sega, Shimizu, Shuhei Yoshida, Sony, Sony Computer Entertainment, Super Mario World, Video game, Xbox

Parlez vous Crash

Jan06

In the mid to late 90s, Playstation games had three SKUs: SCUS, SCEE, and SCEJ, being respectively the US NTSC version, the European PAL version, and the Japanese NTSC version.

The American version shipped in early September 1996. We finished it in early August (manufacture took a month). From my perspective — and it’s worth noting that during the Crash period I personally did most of the localization work — the European version was finished at the same time. I’d killed myself getting it ready during July. But Europe itself liked to drag matters out with a leisurely testing schedule. I wanted it done, because until it was, I couldn’t do much else.

At Naughty Dog, we pioneered the idea of simultaneous international release. By Crash 2 and Crash 3 the same exact code, conditionalized very slightly, ran all three versions. Jak & Daxter was one of the first games where the American version included the European languages. By Jak II you could switch languages on the fly in the menu anytime. We wanted one code base, one art base, one thing to debug. We wanted it for sale simultaneously world wide. I wanted one gold master.

This goal and the tools to do it began on Crash 1, and were fairly well in place by Crash 2. The international groups weren’t quite as on board and year after year dragged out the European and Japanese editions for extra testing. As best I can tell this resulted mostly from a “this is the way it’s always been done” kind of mentality. Jason and I have never been big on that type of reasoning. Still, that personal caveat aside, even from Crash 1, Sony’s international teams did an awesome job, putting in a tremendous effort to ensure the product was really polished for each territory.

The front of the original PAL edition

Anyway, each territory had its own quirks. With the European version, they stemmed from PAL, the old European video standard. PAL actually has a slightly higher resolution and better color fidelity than NTSC (the US standard). But the kicker is that it runs at 50 hertz instead of 60. For Crash this meant that the frame rate would be 25 frames per second instead of 30.

The resolution itself wasn’t much of a problem. Crash was mostly a 3D game and it wasn’t hard to adjust the projection matrix in the engine to render the game to a different resolution. But the aspect ratio of PAL pixels is also a little different and Crash did have a certain amount of bitmap graphics like the powerups and font. The PAL frame buffers were larger and the machine had the same video RAM so increasing the resolution of the sprites was rarely an option. Generally, we just had to live with a slight aspect shift or stretch them to fit. I developed notation in the original data so that different kinds of sprites could go either way in a fairly uniform manner.

The real kicker was the frame rate. One of the reasons why the animation in Crash is so so much better than most of its contemporaries is that we stored every vertex for every frame — then compressed the living crap out of it. This meant that each segment of animation was sampled from Alias PowerAnimator at 30 fps. I modified the tools to support making a second copy of every animation where the step rate was adjusted to 25fps. The pal version used these files instead of the originals. This worked about 80% of the time.  Sometimes it became necessary to notate a particular animation segment as having a strange or custom step for PAL, or even hand code certain frames. I added special constructs to my custom language (GOOL) which made this stuff as automatic as I could.

It often came in these enlarged boxes to fit all those languages!

But the physics and collision systems also needed to adjust to the different frame rate. I had done PAL conversions for Rings of Power and Way of the Warriorand having every great programmer’s hatred for tedium had developed the notion when starting Crash that I would notate all “time and space based” units not in the traditional game programmer manner of “moves X pixels per frame” but in a kind of neutral space. Hence everything in Crash was measured in meters, seconds, and the like. I built into GOOL constructs like (meters 5) or (meters-per-second 2.5). The compiler or the runtime (depended) would convert these on the fly into the appropriate pixel per frame units.

This had a number of big advantages. First of all, even without the PAL issue, it allowed the physics (and the enemies) to move in a fairly frame rate independent way. Special functions were used to deal with velocity and acceleration which took into account the current frame’s estimated real time (based usually on how long it took the previous frame to compute and render). This meant that the code which propelled Crash in a parabolic arc as he jumped would move him further per frame if the frame rate slipped to 20 or 15 (which, unfortunately, it sometimes did). This wasn’t a perfect solution, 15 fps still played worse than 30, but it helped.

And it really paid off with the PAL conversion. The hard work — and it was incredibly tedious — really only took me about five days. After running all the automatic convertors and debugging those I had to go through the entire game and check every single level, every creature, every behavior of every creature or object and make sure it stilled played and looked okay in PAL. If it didn’t I had to play with the numbers, or in the worst case add some special “if PAL do it a little differently” clauses to the GOOL code.

But this was in a world where most American games just played 16% more sluggishly in Europe and most European games 16% fast in America.

Crash played great in both — and looked great in both. The Euro version actually even looked a little better (higher resolution and better color) although the feel at 25hz was slightly inferior. But we didn’t invent the TV standard.

The final tricky bit with localization was the language(s). Crash 1 didn’t really have any voice (which was to become a huge deal in later games). But it did have some text.

This is Crash 2, which is the only picture I could find, but Crash 1 was similar, just with the C1 title page

In typical programmer fashion, I invented another system for this. All of the text was generated by literal strings in the GOOL code, and since I controlled the compiler, I added a feature where a mapping file could be created for each language specifying the English text and the equivalent phrases in each of our five languages (English, French, Spanish, German, Italian). I changed the way strings were handled to index into a table and to have five files on disk for the string buffer. This is typical now, but was very unusual then. Even on Crash 1 you could change the language on the fly. But Europe made me put the toggle only at the main menu because they didn’t want to have to test for weird bugs that came up when you switched languages in the middle of a level.

I systemized all of this stuff by having the tools and the game itself both have separate notions of: video rate (NTSC, PAL), territory (which country’s disc it actually was), and language. This separated the concept of language from territory, opening up the possibility of foreign languages in the American versions (which didn’t happen until Jak 1 for logistical and legal reasons).

As requests came in from Europe to do peculiar and territory specific things like “make the game harder because European gamers like a challenge” (after Crash 1 we refused to acknowledge this “truism”) I modified the tools to allow territory specific overrides in the files that controlled the game data. For example, CONTINUE_POINT_64_32 in the jungle level, “hide in europe.” While I’m not sure the frustrated Euro gamer appreciated it, the system did make serving the producer’s requests easier.

In any case, the Euro version of Crash was lavished with the same attention to detail with which we did everything, and Sony Europe did the same. This was one (if not the) first product for which the whole international organization was behind and where they controlled the worldwide rights. Each Sony territory really pulled out all the stops in supporting and promoting the game as “made here.” It was highly localized, not just the game itself but each little country in Europe doing its own advertising and marketing campaign. Even the Irish filmed their own ads with Irish accented actors. Traditionally game players were highly “nationalistic” with, for example, French games selling better in France. The attention paid by both us and at all levels of the Sony infrastructure to selling a worldwide product aimed specifically at each and every consumer group really paid off.

The game sold like wildfire everywhere. Although we had certain champion territories like France and Australia (Crash’s virtual birthplace) who really poured on the love.

The story continues with Crash goes to Japan!

If you liked this post, follow me at:

My novels: The Darkening Dream and Untimed
or the
video game post depot
or win Crash & Jak giveaways!

Latest hot post: War Stories: Crash Bandicoot

Yes, Crash really took to the old country.

Related posts:

  1. Crash Bandicoot – An Outsider’s Perspective (part 8)
  2. Making Crash Bandicoot – part 5
  3. Making Crash Bandicoot – part 6
  4. Making Crash Bandicoot – part 1
  5. Making Crash Bandicoot – part 3
By: agavin
Comments (51)
Posted in: Games
Tagged as: Crash Bandicoot, Europe, Games, Localization, Naughty Dog, NTSC, PAL, PAL region, pt_crash_history, SCEE, Sony Computer Entertainment, United States

Crash Launch Commercials

Sep15

In honor of the recent 15th Anniversary of my baby Crash Bandicoot, I present collected together the original suite of American TV Ads which premiered in September of 1996. It’s the suit that helped make the Bandicoot what he was.

Thanks to Playstation Museum for collecting and uploading these. You’re hurting my elbow!

If you liked this post, follow me at:

My novels: The Darkening Dream and Untimed
or the
video game post depot
or win Crash & Jak giveaways!

Latest hot post: War Stories: Crash Bandicoot

Related posts:

  1. Crash Memories
  2. Making Crash Bandicoot – part 6
  3. Making Crash Bandicoot – part 1
  4. Crash Bandicoot – An Outsider’s Perspective (part 8)
  5. Making Crash Bandicoot – part 5
By: agavin
Comments (29)
Posted in: Games
Tagged as: Characters of Crash Bandicoot, Crash Bandicoot, Naughty Dog, Playstation, pt_crash_history, Television Ads, Video game

Crash Memories

Sep09

In honor of Crash’s 15th Anniversary I wanted to make a post whose primary purpose is to serve as a repository for comments from you — the fans — about your first and favorite Crash Bandicoot impressions. Please make them in the comments. This is the place to tell that story of how you got your Playstation and Crash Bandicoot for Christmas when you were five, etc. etc. So to that effect, I’ll start it off with a brief tale that begins the night Crash Bandicoot launched.

In September 1996 all of Naughty Dog flew to New York for the combined Crash Bandicoot / Playstation 1 year anniversary party. It was on a big rooftop deck in the meat packing (hehe Beavis, you said meat packing) district. All of us got pretty drunk. There was a loud band. Very loud. Simultaneously, Ken Kutaragi (father of the Playstation!) decided to engage me in a highly technical discussion — against the 120 decibel background — using his rather broken English and my exactly zero command of Japanese. But in any case I didn’t sleep — we saw dawn in some New York greasy spoon.

About four hours later, Jason and I were on a plane to London. I didn’t sleep — why waste good reading time.

We arrived in London for ECTS and various Crash launch promotional meetings. We were immediately conducted to small hot smoky cubicles and interviewed by a variety of game journalists in numerous European languages for about eight hours — also against about 100 decibels of trade show. We then went to the bar (scotch). Then to dinner (wine). Then to a night club (more booze). Then a cigar bar (more scotch). Then to our hotel room (with about 15 or so European marketing and sales folk). There we consumed every single item in our minibar. We called down to the desk (4 in the morning) and had them bring us a NEW minibar. Yes, a complete refill of all items at 4 in the morning. We consumed that. Except for two miscellaneous tiny liquor bottles I can’t remember. The cost of just one minibar was 800 pounds sterling. We ate/drank two.

We didn’t sleep.

But we did spend another eight hours giving interviews. Then we went out again. That night I think we got 2-3 hours of sleep. But interviews again starting at 8am.

Somewhere in there I visited Westminster Abbey.

By day three we discovered that a number of our new friends (English) had never left the Island of Great Britain. So we all boarded the Chunnel and went to Paris (from Waterloo to Napoleon stations specifically, which is amusing). In Paris we started drinking at 10am. We kept drinking (many bars). We ate dinner (more wine). We went to someone’s apartment (more drinks). There was no sleep involved. After staying out all night (drinking) after the day of (drinking) we boarded the Chunnel back to London. I might have dozed. We went straight from there to the airport and got on a flight back to LAX.

Ah, first class. There were scones with clotted cream. And perhaps an hour or three of sleep. But we landed in LA at 7am. I was on the beach jogging by 8:30am. In the office at 10am. Back to work on the Japanese version of Crash. I went home early that day. Midnight.

Making video games builds stamina.

Don’t forget to put your own Crash memories in the comments section!

If you liked this post, follow me at:

My novels: The Darkening Dream and Untimed
or the
video game post depot
or win Crash & Jak giveaways!

Latest hot post: War Stories: Crash Bandicoot

Related posts:

  1. Making Crash Bandicoot – part 1
  2. Old Crash 20 Questions
  3. Crash Bandicoot – An Outsider’s Perspective (part 8)
  4. Making Crash Bandicoot – part 6
  5. Crash Bandicoot as a Startup (part 7)
By: agavin
Comments (184)
Posted in: Games
Tagged as: Andy Gavin, Beavis, Crash Bandicoot, Crash Bandicoot Launch, Ken Kutaragi, London, Naughty Dog, New York, Playstation, pt_crash_history

Crash Bandicoot – Teaching an Old Dog New Bits – part 3

Mar28

This is the twelfth of a now lengthy series of posts on the making of Crash Bandicoot. Click here for the PREVIOUS or for the BEGINNING of the whole mess.

The text below is another journal article I wrote on making Crash in 1999. This is the third part, the FIRST can be found here.

_

The Crash Bandicoot Trilogy: A Practical Example

The three Crash Bandicoot games represent a clear example of the process of technology and gameplay refinement on a single platform.  Crash Bandicoot was Naughty Dog’s first game on the Sony Playstation game console, and its first fully 3D game.  With Crash Bandicoot 2: Cortex Strikes Back and Crash Bandicoot: Warped, we were able to improve the technology, and offer a slicker more detailed game experience in successively less development time.  With the exception of added support for the Analog Joystick, Dual Shock Controller, and Sony Pocketstation the hardware platforms for the three titles are identical.

Timely and reasonably orderly development of a video game title is about risk management.  Given that you have a certain amount of time to develop the title, you can only allow for a certain quantity of gameplay and technology risks during the course of development.  One of the principle ways in which successive games improve is by the reuse of these risks.  Most solutions which worked for the earlier game will work again, if desired, in the new game.  In addition, many techniques can be gleaned from other games on the same machine that have been released during the elapsed time.

In the case of sequels such as the later Crash games there is even more reduction of risk.  Most gameplay risks, as well as significant art, code, and sound can be reused.  This allows the development team to concentrate on adding new features, while at the same time retaining all the good things about the old game.  The result is that sequels are empirically better games.

Crash Bandicoot   –   how do we do character action in 3D?

Development: September 1994 – September 1996

Staff: 9 people: 3 programmers, 4 artists, 1 designer, 1 support

Premise: Do for the ultra popular platform action game genre what Virtua Fighter had done for fighting games: bring it into 3D.  Design a very likeable broad market character and place him in a fun, and fast paced action game.  Attempt to occupy the “official character” niche on the then empty Playstation market.  Remember, that by the fall of 1994 no one had yet produced an effective 3D platform action game.

Gameplay risk: how do you design and control an action character in 3D such that the feel is as natural and intuitive as in 2D?

When we first asked ourselves, “what do you get if you put Sonic the Hedgehog (or any other character action game for that matter) in 3D,” the answer that came to mind was: “a game where you always see Sonic’s Ass.”  The entire question of how to make a platform game in 3D was the single largest design risk on the project.  We spent 9 months struggling with this before there was a single fun level.  However, by the time this happened we had formulated many of the basic concepts of the Crash gameplay.

We were trying to preserve all of the good elements of classic platform games.  To us this meant really good control, faced paced action, and progressively ramping challenges.  In order to maintain a very solid control feel we opted to keep the camera relatively stable, and to orient the control axis with respect to the camera.  Basically this means that Crash moves into the screen when you push up on the joypad.  This may seem obvious, but it was not at the time, and there are many 3D games which use different (and usually inferior) schemes.

Technical risk: how do you get the Playstation CPU and GPU to draw complex organic scenes with a high degree of texture and color complexity, good sorting, and a solid high resolution look?

It took quite a while, a few clever tricks, and not a little bit of assembly writing and rewriting of the polygon engines.  One of our major realizations was that on a CD based game system with a 33mhz processor, it is favorable to pre-compute many kinds of data in non real-time on the faster workstations, and then use a lean fast game engine to deliver high performance.

Technical risk: how do the artists build and maintain roughly 1 million polygon levels with per poly and per vertex texture and color assignment?

The challenge of constructing large detailed levels turned out to be one of the biggest challenges of the whole project.  We didn’t want to duplicate the huge amount of work that has gone into making the commercial 3D modeling packages, so we chose to integrate with one of them.  We tried Softimage at first, but a number of factors caused us to switch to AliasPower Animator.  When we began the project it was not possible to load and view a one million polygon level on a 200mhz R4400 Indigo II Extreme.  We spent several months creating a system and tools by which smaller chunks of the level could be hierarchically assembled into a larger whole.

In addition, the commercial packages were not aware that anyone would desire per polygon and per vertex control over texture, color, and shading information.  They used a projective texture model preferred by the film and effects industry.  In order to maximize the limited amount of memory on the Playstation we knew we would need to have very detailed control.  So we created a suite of custom tools to aid in the assignment of surface details to Power Animator models.  Many of these features have since folded into the commercial programs, but at the time we were among the first to make use of this style of model construction.

Technical risk: how do you get a 200mhz R4400 Indigo II to process a 1 million polygon level?

For the first time in our experience, it became necessary to put some real thought into the design of the offline data processing pipeline.  When we first wrote the level processing tool it took 20 hours to run a small test case.  A crisis ensued and we were forced to both seriously optimize the performance of the tool and multithread it so that the process could be distributed across a number of workstations.

Conventional wisdom says that game tools are child’s play.  Historically speaking, this is a fair judgment — 2D games almost never involve either sophisticated preprocessing or huge data sets.  But now that game consoles house dedicated polygon rendering hardware, the kid gloves are off.

In Crash Bandicoot players explore levels composed of over a million polygons.  Quick and dirty techniques that work for smaller data sets (e.g., repeated linear searches instead of binary searches or hash table lookups) no longer suffice.  Data structures now matter — choosing one that doesn’t scale well as the problem size increases leads to level processing tasks that take hours instead of seconds.

The problems have gotten correspondingly harder, too.  Building an optimal BSP tree, finding ideal polygon strips, determining the best way to pack data into fixed-size pages for CD streaming — these are all tough problems by any metric, academic or practical.

To make matters worse, game tools undergo constant revision as the run-time engine evolves towards the bleeding edge of available technology.  Unlike many jobs, where programmers write functional units according to a rigid a priori specification, games begin with a vague “what-if” technical spec — one that inevitably changes as the team learns how to best exploit the target machine for graphics and gameplay.

The Crash tools became a test bed for developing techniques for large database management, parallel execution, data flexibility, and complicated compression and bin packing techniques.

Art / Technical risk: how do you make low poly 3D characters that don’t look like the “Money for Nothing” video?

From the beginning, the Crash art design was very cartoon in style.  We wanted to back up our organic stylized environments with highly animated cartoon characters that looked 3D, but not polygonal.  By using a single skinned polygonal mesh model similar to the kind used in cutting edge special effects shots (except with a lot less polygons),  we were able to create a three dimensional cartoon look.  Unlike the traditional “chain of sausages” style of modeling, the single skin allows interesting “squash and stretch” style animation like that in traditional cartoons.

By very careful hand modeling, and judicious use of both textured and shaded polygons, we were able to keep these models within reasonable polygon limits.  In addition, it was our belief that because Crash was the most important thing in the game, he deserved a substantial percentage of the game’s resources.  Our animation system allows Crash to have unique facial expressions for each animation, helping to convey his personality.

Technical risk: how do you fit a million polygons, tons of textures, thousands of frames of animation, and lots of creatures into a couple megs of memory?

Perhaps the single largest technical risk of the entire project was the memory issue.  Although there was a plan from the beginning, this issue was not tackled until February of 1996.  At this point we had over 20 levels in various stages of completion, all of which consumed between 2 and 5 megabytes of memory.  They had to fit into about 1.2 megabytes of active area.

At the beginning of the project we had decided that the CD was the system resource least likely to be fully utilized, and that system memory (of various sorts) was going to be one of the greatest constraints.  We planned to trade CD bandwidth and space for increased level size.

The Crash series employs an extremely complicated virtual memory scheme which dynamically swaps into memory any kind of game component: geometry, animation, texture, code, sound, collision data, camera data, etc.  A workstation based tool called NPT implements an expert system for laying out the disk.  This tool belongs to the class of formal Artificially Intelligence programs.  Its job is to figure out how the 500 to 1000 resources that make up a Crash level can be arranged so as to never have more than 1.2 megabytes needed in memory at any time.  A multithreaded virtual memory implementation follows the instructions produced by the tool in order to achieve this effect at run time.  Together they manage and optimize the essential resources of main, texture, and sound RAM based on a larger CD based database.

Technical/Design risk: what to do with the camera?

With the 32 bit generation of games, cameras have become a first class character in any 3D game.  However, we did not realize this until considerably into the project.  Crash represents our first tentative stab at how to do an aesthetic job of controlling the camera without detracting from gameplay.  Although it was rewritten perhaps five times during the project, the final camera is fairly straightforward from the perspective of the user.  None of the crop of 1995 and 1996 3D action games played very well until Mario 64 and Crash.  These two games, while very different, were released within two months of each other, and we were essentially finished with Crash when we first saw Mario.  Earlier games had featured some inducement of motion sickness and a difficulty for the players in quickly judging the layout of the scene.  In order to enhance the tight, high impact feel of Crash’s gameplay, we were fairly conservative with the camera.  As a result Crash retains the quick action feel of the traditional 2D platform game more faithfully than other 3D games.

Technical risk: how do you make a character collide in a reasonable fashion with an arbitrary 3D world… at 30 frames a second?

Another of the games more difficult challenges was in the area of collision detection.  From the beginning we believed this would be difficult, and indeed it was.  For action games, collision is a critical part of the overall feel of the game.  Since the player is looking down on a character in the 3rd person he is intimately aware when the collision does not react reasonably.

Crash can often be within a meter or two of several hundred polygons.  This means that the game has to store and process a great deal of data in order to calculate the collision reactions.  We had to comb through the computer science literature for innovative new ways of compressing and storing this database.  One of our programmers spent better than six months on the collision detection part of the game, writing and rewriting the entire system half a dozen times.  Finally, with some very clever ideas, and a lot of hacks, it ended up working reasonably well.

Technical risk: how do you program, coordinate, and maintain the code for several hundred different game objects?

Object control code, which the gaming world euphemistically calls AI, typically runs only a couple of times per frame. For this kind of code, speed of implementation, flexibility, and ease of later modification are the most important requirements.  This is because games are all about gameplay, and good gameplay only comes from constant experimentation with and extensive reworking of the code that controls the game’s objects.

The constructs and abstractions of standard programming languages are not well suited to object authoring, particularly when it comes to flow of control and state.  For Crash Bandicoot we implemented GOOL (Game Oriented Object LISP), a compiled language designed specifically for object control code that addresses the limitations of traditional languages.

Having a custom language whose primitives and constructs both lend them selves to the general task (object programming), and are customizable to the specific task (a particular object) makes it much easier to write clean descriptive code very quickly.  GOOL makes it possible to prototype a new creature or object in as little as 10 minutes.  New things can be tried and quickly elaborated or discarded. If the object doesn’t work out it can be pulled from the game in seconds without leaving any hard to find and wasteful traces behind in the source.  In addition, since GOOL is a compiled language produced by an advanced register coloring compiler with reductions, flow analysis, and simple continuations it is at least as efficient as C, more so in many cases because of its more specific knowledge of the task at hand.  The use of a custom compiler allowed us to escape many of the classic problems of C.

Crash Bandicoot 2: Cortex Strikes Back  –   Bigger and Badder!

Development: October 1996 – November 1997

Staff: 14 people: 4 programmers, 6 artists, 1 designer, 3 support

Premise: Make a sequel to the best selling Crash Bandicoot that delivered on all the good elements of the first game, as well as correcting many of our mistakes.  Increasing the technical muscle of the game, and improving upon the gameplay, all without looking “been there done that…” in one year.

For Crash 2 we rewrote approximately 80% of the game engine and tool code.  We did so module by module in order to allow continuous development of game levels.  Having learned during Crash 1 about what we really needed out of each module we proceeded to rewrite them rapidly so that they offered greater speed and flexibility.

Technical risk: A fancy new tools pipeline designed to deal with a constantly changing game engine?

The workstation based tools pipeline was a crucial part of Crash 1.  However, at the time of its original conception, it was not clear that this was going to be the case.  The new Crash 2 tools pipe was built around a consistent database structure designed to allow the evolution of level databases, automatic I/O for complex data types, data browsing and searching, and a number of other features.  The pipe was modularized and various built-in restrictions were removed.  The new pipe was able to support the easy addition of arbitrary new types of data and information to various objects without outdating old information.

We could never have designed such a clean tool program that would be able to handle the changes and additions of Crash 2 and Warped at the beginning of the first game.  Being aware of what was needed at the start of the rewrite allowed us to design a general infrastructure that could support all of the features we had in mind.  This infrastructure was then flexible enough to support the new features added to both sequels.

Technical/process risk: The process of making and refining levels took too long during the first game.  Can we improve it?

The most significant bottleneck in making Crash 1 was the overall time it took to build and tune a level.  So for Crash 2 we took a serious look at this process and attempted to improve it.

For the artists, the task of surfacing polygons (applying texture and color) was very time consuming.  Therefore, we made improvements to our surfacing tools.

For both the artists and designers, the specification of different resources in the level was exceedingly tedious.  So we added a number of modules to the tools pipeline designed to automatically balance and distribute many of these resources, as well as to auto calculate the active ranges of objects and other resources that had to be controlled manually in the first game.  In addition, we moved the specification of camera, camera info, game objects, and game object info into new text based configuration files.  These files allowed programmers and designers to edit and add information more easily, and it also allowed the programmers to add new kinds of information quickly and easily.

The result of this process was not really that levels took any less time to make, but that the complexity allowed was several times that of the first game.  Crash 2 levels are about twice as large, have integrated bonus levels, multiple branches, “hard paths,” and three or four times as many creatures, each with an order of magnitude more settable parameters.  The overall turn around time for changing tunable level information was brought down significantly.

Technical/Design risk: can we make a better more flexible camera?

The camera was one of the things in Crash 1 with which we were least satisfied.  So in order to open up the game and make it feel more lifelike, we allowed the camera to look around much more, and supported a much wider set of branching and transition cameras.  In addition, arbitrary parameterized information was added to the camera system so that at any location the camera had more than 100 possible settable options.

If the two games are compared side by side, it can be seen that the overall layouts of Crash 2 levels are much larger and more complicated.  The camera is more natural and fluid, and there are numerous dynamic camera transitions and effects which were not present in the first game.  Even though the Crash 2 camera was written entirely from scratch, the lessons learned during the course of Crash 1 allowed it to be more sophisticated and aggressive, and it executed faster than its predecessor.

Optimization risk: can we put more on screen?

Crash 1 was one of the fastest games of its generation, delivering high detail images at 30 frames per second.  Nevertheless, for Crash 2 we wanted to put twice as much on screen, yet still maintain that frame-rate.  In order to achieve this goal we had one programmer doing nothing but re-coding areas of the engine into better assembly for the entire length of the project.  Dramatically increasing performance does not just mean moving instructions around; it is a complex and involved process.  First we study the performance of all relevant areas of the hardware in a scientific and systematic fashion.  Profiles are made of cache latencies, coprocessor parallel processing constraints, etc.  Game data structures are then carefully rearranged to aid the engine in loading and processing them in the most efficient way.  Complicated compression and caching schemes are explored to both reduce storage size (often linked to performance due to bus bandwidth) and to speed up the code.

Simultaneously we modularized the game engine to add more flexibility and features.  Crash 2 has more effects, such as Z-buffer-like water effects, weather, reflections, particles, talking hologram heads, etc.  Many annoying limitations of the Crash 1 drawing pipeline were removed, and most importantly, the overall speed was increased by more than two-fold.

In order to further improve performance and allow more simultaneous creatures on screen, we re-coded the GOOL interpreter into assembly, and also modified the compiler to produce native MIPS assembly for even better performance.

Technical risk: if we can put more on screen, can we fit it in memory?

We firmly believe that all three Crash games make use of the CD in a more aggressive fashion than most Playstation games.  So in order to fit the even larger Crash 2 levels into memory (often up to 12 megabytes a level) we had to increase the efficiency of the virtual memory scheme even more.  To do so we rewrote the AI that lays out the CD, employing several new algorithms.  Since different levels need different solutions we created a system by which the program could automatically try different approaches with different parameters, and then pick the best one.

In addition, since Crash 2 has about 8 times the animation of the first game, we needed to really reduce the size of the data without sacrificing the quality of the animation.  After numerous rewrites the animation was stored as a special bitstream compressed in all 4 dimensions.

Design risk: can we deliver a gameplay experience that is more than just “additional levels of Crash?”

We believe that game sequels are more than an opportunity to just go “back to the bank.”  For both of the Crash sequels we tried to give the player a new game, that while very much in the same style, was empirically a bigger, better game.  So with the increased capacity of the new Crash 2 engine we attempted to build larger more interesting levels with a greater variety of gameplay, and a more even and carefully constructed level of difficulty progression.  Crash 2 has about twice as many creatures as Crash 1, and their behaviors are significantly more sophisticated.  For example, instead of just putting the original “turtle” back into the game, we added two new and improved turtles, which had all the attributes of the Crash 1 turtle, but also had some additional differences and features.  In this manner we tried to build on the work from the first game.

Crash himself remains the best example.  In the second game Crash retains all of the moves from the first, but gains a number of interesting additional moves: crawling, ducking, sliding, belly flopping, plus dozens of custom coded animated death sequences.  Additionally, Crash has a number of new control specs: ice, surfboard, jet-pack, baby bear riding, underground digging, and hanging.  These mechanics provide entirely new game machines to help increase the variety and fun factor of the game.  It would be very difficult to include all of these in a first generation game because so much time is spent refining the basic mechanic.

Technically, these additions and enhancements were aided by the new more flexible information specification of the new tools pipeline, and by additions to the GOOL programming language based on lessons learned from the first game.

Crash Bandicoot: Warped!  –   Every trick in the book!

Development: January 1998 – November 1998

Staff: 15 people: 3 programmers, 7 artists, 3 designers, 2 support

Premise: With only 9 months in which to finish by Christmas, we gave ourselves the challenge of making a third Crash game which would be even cooler and more fun than the previous one.  We chose a new time travel theme and wanted to differentiate the graphic look and really increase the amount and variety of gameplay.  This included power-ups, better bosses, lots of new control mechanics, an open look, and multiple playable characters.

Technical/Process risk: the tight deadline and a smaller programming staff required us to explore options for even greater efficiency.

The Crash Warped production schedule required that we complete a level every week.  This was nearly twice the rate typical of Crash levels.  In addition, many of the new levels for Warped required new engines or sub-engines designed to give them a more free-roaming 3D style.  In order to facilitate this process we wrote an interactive listener which allowed GOOL based game objects to be dynamically examined, debugged, and tuned.  We were then able to set the parameters and features of objects in real-time, greatly improving our ability to tune and debug levels.  Various other visual debugging and diagnostic techniques were also introduced as well.

Knowledge from the previous game allowed us to further pipeline various processes.  The Crash series is heavily localized for different territories.  The European version supports five languages, text and speech, including lip sync.  In addition, it was entirely re-timed, and the animation was resampled for 25hz.  The Japanese version has Pocketstation support, a complete language translation, and a number of additional country specific features.  We were able to build in the features needed to make this happen as we wrote the US version of the game.  The GOOL language was expanded to allow near automatic conversion of character control timing for PAL.

Technical/Art risk: could the trademark look of the Crash series be opened up to offer long distance views and to deliver levels with free-roaming style gameplay?

In order to further differentiate the third Crash game, we modified the engine to support long distance views and Level of Detail (LOD) features.  Crash Warped has a much more open look than the previous games, with views up to ten times as far.  The background polygon resource manager needed some serious reworking in order to handle this kind of increased polygon load, as did the AI memory manager.  We developed the new LOD system to help manage these distance views.  These kinds of system complexities would not have been feasible in a first generation game, since when we started Crash 1, the concept of LOD in games was almost completely undeveloped, and just getting a general engine working was enough of a technical hurdle.

Similarly, the stability of the main engine allowed us to concentrate more programmer time on creating and polishing the new sub-engines:  jet-ski, motorcycle, and biplane.

Gameplay risk: could we make the gameplay in the new Crash significantly different from the previous ones and yet maintain the good elements of the first two games?

The new free-roaming style levels presented a great gameplay challenge.  We felt it necessary to maintain the fast-paced, forward driven Crash style of gameplay even in this new context.  The jet-ski in particular represented a new kind of level that was not present in the first two games.  It is part race game, part vehicle game, and part regular Crash level.  By combining familiar elements like the boxes and creatures with the new mechanics, we could add to the gameplay variety without sacrificing the consistency of the game.

In addition to jet-ski, biplane, and motorcycle levels, we also added a number of other new mechanics (swimming, bazooka, baby T-rex, etc.) and brought back most of Crash 2’s extensive control set.  We tried to give each level one or more special hooks by adding gameplay and effect features.  Warped has nearly twice as many different creatures and gameplay modes as Crash 2.  The third game clocked in at 122,000 lines of GOOL object control code, as compared to 68,000 for the second game and 49,000 for the first!  The stability of the basic system and the proven technical structure allowed the programmers to concentrate on gameplay features, packing more fun into the game.  This was only possible because on a fixed hardware like the Playstation, we were fairly confident that the Warped engine was reasonably optimal for the Crash style of game.  Had we been making the game for a moving target such as the PC, we would have been forced to spend significant time updating to match the new target, and would have not been able to focus on gameplay.

Furthermore, we had time, even with such a tight schedule, to add more game longevity features.  The Japanese version of Warped has Pocketstation support.  We improved the quality of the boss characters significantly, improved the tuning of the game, added power-ups that can be taken back to previously played levels, and added a cool new time trial mode.  Crash games have always had two modes of play for each level: completion (represented by crystals) and box completion (represented by gems).  In Warped we added the time trial mode (represented by relics).  This innovative new gameplay mode allows players to compete against themselves, each other, and preset goals in the area of timed level completion.  Because of this each level has much more replay value and it takes more than twice as long to complete Warped with 100% as it does Crash 2.

Technical risk: more more more!

As usual, we felt the need to add lots more to the new game.  Since most of Crash 2’s animations were still appropriate, we concentrated on adding new ones.  Warped has a unique animated death for nearly every way in which Crash can loose a life.  It has several times again the animation of the second game.  In addition, we added new effects like the arbitrary water surface, and large scale water effects.  Every character, including Crash got a fancy new shadow that mirrors the animated shape of the character.

All these additions forced us to squeeze even harder to get the levels into memory.  Additional code overlays, redundant code mergers, and the sacrifice of thirteen polka dotted goats to the level compression AI were necessary.

Conclusions

In conclusion, the consistency of the console hardware platform over its lifetime allows the developer an opportunity to successively improve his or her code, taking advantage of techniques and knowledge learned by themselves and others.  With each additional game the amount of basic infrastructure programming that must be done is reduced, and so more energy can be put into other pursuits, such as graphical and gameplay refinements.

If you liked this post, follow me at:

My novels: The Darkening Dream and Untimed
or the
video game post depot
or win Crash & Jak giveaways!

Latest hot post: War Stories: Crash Bandicoot

Related posts:

  1. Crash Bandicoot – Teaching an Old Dog New Bits – part 2
  2. Crash Bandicoot – Teaching an Old Dog New Bits – part 1
  3. Crash Bandicoot – An Outsider’s Perspective (part 8)
  4. Making Crash Bandicoot – part 1
  5. Crash Bandicoot as a Startup (part 7)
By: agavin
Comments (181)
Posted in: Games, Technology
Tagged as: Andy Gavin, Central processing unit, Console Games, Crash Bandicoot, Crash Bandicoot 2: Cortex Strikes Back, Crash Bandicoot 3: Warped, game, Jak and Daxter, Naughty Dog, Platform game, Playstation, PowerAnimator, pt_crash_history, Video game console, Video Games

Crash Bandicoot – Teaching an Old Dog New Bits – part 2

Mar27

This is the eleventh of a now lengthy series of posts on the making of Crash Bandicoot. Click here for the PREVIOUS or for the BEGINNING of the whole mess.

The text below is another journal article I wrote on making Crash in 1999. This is the second part, the FIRST can be found here.

 

And finally to the point!

Both the rapid lifecycle of a video game console and the consistency of the hardware promote video game development strategies that are often very different from the strategies used to make PC video games.   A side-effect of these strategies and the console development environment is that video games released later in the life of a console tend to be incrementally more impressive than earlier titles, even though the hardware hasn’t changed.  Theoretically, since the hardware doesn’t change, first generation software can be as equally impressive as later generation titles, but in reality this is seldom the case.  It may seem obvious that a developer should try to make a first generation title as impressive as a last generation title, but actually this strategy has been the downfall of many talented developers.  There are many good and valid reasons why software improves over time, and the understanding and strategizing about these reasons can greatly improve the chances for a developer to be successful in the marketplace.

Difficulties of Console Video Game Development

There are many difficulties that are encountered when developing a console video game, but the following is a list of several major issues:

  • Learning curve
  • Hardware availability and reliability
  • Bottlenecks
  • Operating System / Libraries
  • Development tools
  • In-house tools
  • Reuse of code
  • Optimization

Learning curve

The learning curve may be the most obvious of all difficulties, and is often one of the most disruptive elements of a video game’s development schedule.  In the past, video games were often developed by small groups of one or more people, had small budgets, ran in a small amount of memory, and had short schedules.  The graphics were almost always 2D, and the mathematics of the game were rarely more than simple algebra.  Today, video games have become much more complicated, and often require extremely sophisticated algorithms and mathematics.  Also, the pure size of the data within a game has made both the run-time code and the tool pipeline require extremely sophisticated solutions for data management issues.  Furthermore, 3D mathematics and renderings can be very CPU intensive, so new tricks and techniques are constantly being created.   Also, the developer will often have to use complex commercial tools, such as 3D modeling packages, to generate the game’s graphics and data.  Add into this the fact that Operating Systems, API’s, and hardware components are continually changing, and it should be obvious that just staying current with the latest technology requires an incredible amount of time, and can have a big impact on the schedule of a game.

The console video game developer has the additional burden that, unlike the PC where the hardware evolves more on a component or API level, new console hardware is normally drastically different and more powerful than the preceding hardware.  The console developer has to learn many new things, such as new CPU’s, new operating systems, new libraries, new graphics devices, new audio devices, new peripherals, new storage devices, new DMA techniques, new co-processors, as well as various other hardware components.  Also, the console developer usually has to learn a new development environment, including a new C compiler, a new assembler, a new debugger, and slew of new support tools.  To complicate matters, new consoles normally have many bugs in such things as the hardware, the operating system, the software libraries, and in the various components of the development environment.

The learning curve of the console hardware is logarithmic in that it is very steep at first, but tends to drop off dramatically by the end of the console life-span.  This initial steep learning curve is why often the first generation software isn’t usually as good as later software.

Hardware availability and reliability

Hardware isn’t very useful without software, and software takes a long time to develop, so it is important to hardware developers to try to encourage software developers to begin software development well in advance of the launch date of the hardware.  It is not uncommon for developers to begin working on a title even before the hardware development kits are available.  To do this, developers will start working on things that don’t depend on the hardware, such as some common tools, and they may also resort to emulating the hardware through software emulation.  Obviously, this technique is not likely to produce software that maximizes the performance of the hardware, but it is done nevertheless because of the time constraints of finishing a product as close as possible to the launch of the console into the market.  The finished first generation game’s performance is not going to be as good as later generations of games, but this compromise is deemed acceptable in order to achieve the desired schedule.

When the hardware does become available for developers, it is usually only available in limited quantity, is normally very expensive, and eventually ends up being replaced by cheaper and more reliable versions of the hardware at some later time.  Early revisions of the hardware may not be fully functional, or may have components that run at a reduced speed, so are difficult to fully assess, and are quite scarce since the hardware developer doesn’t want to make very many of them.  Even when more dependable hardware development kits becomes available, they are usually difficult to get, since production of these kits is slow and expensive, so quantities are low, and software developers are in competition to get them.

The development kits, especially the initial hardware, tend to have bugs that have to be worked around or avoided.  Also, the hardware tends to have contact connection problems so that it is susceptible to vibrations, oxidation, and overheating.  These problems generally improve with new revisions of the development hardware.

All of these reasons will contribute to both a significant initial learning curve, and a physical bottleneck of having an insufficient number of development kits.   This will have a negative impact on a game’s schedule, and the quality of first generation software often suffers as a consequence.

Bottlenecks

An extremely important aspect to console game development is the analysis of the console’s bottlenecks, strengths, weaknesses, and overall performance.  This is critical for developing high performance games, since each component of the console has a fixed theoretical maximum performance, and undershooting that performance may cause your game to appear under-powered, while overshooting may cause you to have to do major reworking of the game’s programming and/or design.  Also, overshooting performance may cause the game to run at an undesirable frame rate, which could compromise the look and feel of the game.

The clever developer will try to design the game to exploit the strengths of the machine, and circumvent the weaknesses.  To do this, the developer must be as familiar as possible with the limitations of the machine.  First, the developer will look at the schematic of the hardware to find out the documented sizes, speeds, connections, caches, and transfer rates of the hardware.  Next, the developer should do hands-on analysis of the machine to look for common weaknesses, such as:  slow CPU’s, limited main memory, limited video memory, limited sound memory, slow BUS speeds, slow RAM access, small data caches, small instruction caches, small texture caches, slow storage devices, slow 3D math support, slow interrupt handling, slow game controller reading, slow system routines, and slow polygon rendering speeds.  Some of these things are easy to analyze, such as the size of video memory, but some of these things are much trickier, such as polygon rendering speeds, because the speed will vary based on many factors, such as source size, destination size, texture bit depth, caching, translucency, and z-buffering, to name just a few.  The developer will need to write several pieces of test code to study the performance of the various hardware components, and should not necessarily trust the statistics found in the documentation, since these are often wrong or misleading.

A developer should use a profiler to analyze where speed losses are occurring in the run-time code.  Most programmers will spend time optimizing code because the programmer suspects that code is slow, but doesn’t have any empirical proof.  This lack of empirical data means that the programmer will invariable waste a lot of time optimizing things that don’t really need to be optimized, and will not optimize things that would have greatly benefited from optimization. Unfortunately, a decent profiler is almost never included in the development software, so it is usually up to the individual developer to write his own profiling software.

The testing of performance is an extremely important tool to use in order to maximize performance.  Often the reason why software improves between generations is that the developers slowly learn over time how to fully understand the bottlenecks, how to circumvent the bottlenecks, and how to identify what actually constitutes a bottleneck.

Operating system / Libraries

Although the consoles tend to have very small operating systems and libraries when compared to the operating systems found on the PC, they are still an important factor of console video game development.

Operating systems and support libraries on video game consoles are used to fill many needs.  One such need is that the hardware developer will often attempt to save money on the production of console hardware by switching to cheaper components, or by integrating various components together.  It is up to the operating system to enable these changes, while having the effects of these changes be transparent to both the consumer and the developer.  The more that the operating system abstracts the hardware, the easier it is for the hardware developer to make changes to the hardware.  However, remember that this abstraction of the hardware comes at the price of reduced potential performance.  Also, the operating system and support libraries will commonly provide code for using the various components of the console.  This has the advantage that developers don’t have to know the low-level details of the hardware, and also potentially saves time since different developers won’t have to spend time creating their own versions of these libraries.  The advantage of not having to write this low level code is important in early generation projects, because the learning curve for the hardware is already quite high, and there may not be time in the schedule for doing very much of this kind of low-level optimization.  Clever developers will slowly replace the system libraries over time, especially with the speed critical subroutines, such as 3D vector math and polygonal set-up.  Also, the hardware developer will occasionally improve upon poorly written libraries, so even the less clever developers will eventually benefit from these optimizations. Improvements to the system libraries are a big reason why later generation games can increase dramatically in performance.

Development tools

On the PC, development tools have evolved over the years, and have become quite sophisticated.  Commercial companies have focused years of efforts on making powerful, optimal, polished, and easy to use development tools.  In contrast, the development tools provided for console video game development are generally provided by the hardware manufacturer, and are usually poorly constructed, have many bugs, are difficult to use, and do not produce optimal results.  For example, the C compiler usually doesn’t optimize very well; the debugger is often crude and, ironically, has many bugs; and there usually isn’t a decent software profiler.

Initially developers will rely on these tools, and the first few generations of software will be adversely effected by their poor quality.  Over time, clever programmers will become less reliant on the tools that are provided, or will develop techniques to work around the weaknesses of the tools.

In-house tools

In-house tools are one of the most important aspects of producing high performance console video game software.  Efficient tools have always been important, but as the data content in video games has grown exponentially over the last few years, in-house tools have become increasingly more important to the overall development process.  In the not too distant future, the focus on tool programming techniques may even exceed the focus on run-time programming issues.  It is not unreasonable that the most impressive video games in the future may end up being the ones that have the best support tools.

In-house tools tend to evolve to fill the needs of a desired level of technology.  Since new consoles tend to have dramatic changes in technology over the predecessor consoles, in-house tools often have to be drastically rewritten or completely replaced to support the new level of technology.  For example, a predecessor console may not have had any 3D support, so the tools developed for that console most likely would not have been written to support 3D.  When a new console is released that can draw 100,000 polygons per second, then it is generally inefficient to try to graft support for this new technology onto the existing tools, so the original tools are discarded.  To continue the previous example, let’s say that the new tool needs to be able to handle environments in the game that average about 500,000 polygons, and have a maximum worst case of 1 million polygons.  Most likely the tool will evolve to the point where it runs pretty well for environments of the average case, but will most likely run just fast enough that the slowest case of a 1 million polygons is processed in a tolerable, albeit painful, amount of time.  The reasons for this are that tools tend to grow in size and complexity over time, and tools tend to only be optimized to the point that they are not so slow as to be intolerable.  Now let’s say that a newer console is released that can now drawn 1 million polygons a second, and now our worst case environment is a whopping 1 billion polygons!  Although the previous in-house tool could support a lot of polygons, the tool will still end up being either extensively rewritten or discarded, since the tool will not be able to be easily modified to be efficient enough to deal with this much larger amount of polygons.

The ability of a tool to function efficiently as the data content processed by the tool increases is referred to as the ability of the tool to “scale”.  In video game programming, tools are seldom written to scale much beyond the needs of the current technology; therefore, when technology changes dramatically, old tools are commonly discarded, and new tools have to be developed.

The in-house tools can consume a large amount of the programming time of a first generation title, since not only are the tools complicated, but they evolve over time as the run-time game code is implemented.  Initial generations of games are created using initial generations of tools.  Likewise, later generations of games are created using later generations of tools.  As the tools become more flexible and powerful, the developer gains the ability to create more impressive games.  This is a big reason why successive generations of console games often make dramatic improvements in performance and quality over their predecessors.

Reuse of code

A problem that stems from the giant gaps in technology between console generations is that it makes it difficult to reuse code that was written for a previous generation of console hardware.  Assembly programming is especially difficult to reuse since the CPU usually changes between consoles, but the C programming language isn’t much of a solution either, since the biggest problem is that the hardware configurations and capabilities are so different.  Any code dealing directly with the hardware or hardware influenced data structures will have to be discarded.  Even code that does something universal in nature, such as mathematical calculations, will most likely need to be rewritten since the new hardware will most likely have some sort of different mathematical model.

Also, just as the in-house tool code becomes outdated, so does game code that is written for less powerful technology.  Animation, modeling, character, environment, and particle code will all need to be discarded.

In practice, very little code can be reused between technological leaps in hardware platforms.  This means that earlier generation games will not have much code reuse, but each new generation of games for a console will be able to reuse code from its predecessors, and therefore games will tend to improve with each new generation.

Optimization

By definition, having optimal code is preferable to having bulky or less efficient code.  It would therefore seem logical to say that to achieve maximum performance from the hardware, all code should be completely optimal.  Unfortunately, this is not an easy or even practical thing to achieve, since the writing of completely optimal code has many nuances, and can be very time-consuming.  The programmer must be intimately familiar with the details of the hardware.  He must fully understand how to implement the code, such as possibly using assembly language since C compilers will often generate inefficient code.  The programmer must make certain to best utilize the CPU caches.  Also, the programmer should understand how the code may effect other pieces of code, such as the effects of the code on the instruction cache, or the amount of resources that are tied up by his code. The programmer has to know how to effectively use co-processors or other devices.  He must develop an algorithm that is maximally efficient when implemented. Also, the programmer will need to measure the code against the theoretical maximum optimal performance to be certain that the code can indeed be considered to be fully optimal.

Writing even highly optimized code for specific hardware is time-consuming, and requires a detailed knowledge of both the hardware and the algorithm to be optimized.  It is therefore commonly impractical to attempt to highly optimize even a majority of the  code.  This is especially true when writing a first generation game, since the developer is not familiar enough with the intricacies of the hardware to be very productive at writing optimal code.  Instead, it is more productive to only spend time optimizing the code that most profoundly effects the efficiency of the overall game.  Unfortunately, the identifying of what code should be optimized can also be a difficult task.  As a general rule, the code to be optimized is often the code that is executed most frequently, but this is not always the case.  Performance analyzing, testing, and profiling can help identify inefficient code, but these are also not perfect solutions, and the experience of the programmer becomes an important factor in making smart decisions concerning what code should be optimized.

As a programmer gets more familiar with the intricacies of the hardware, he will be able to perform a greater amount of optimizations.  Also, when developing later generation games, the programmer will often be able to reuse previously written optimized code.  Plus, there is often more time in the schedule of later generation titles in which to perform optimizations.  This accumulation of optimal code is a big reason why games often improve in performance in successive generations.

Other Considerations

There are many other reasons to explain the improvement in performance of next generation software that are not directly related to programming for a video game console.  For example, developers will often copy or improve upon the accomplishments of other developers.  Likewise, developers will avoid the mistakes made by others.  Also, developers acquire and lose employees fairly frequently, which creates a lot of cross-pollination of ideas and techniques between the various development houses.  These and many other reasons are important, but since they are not specific to console video game development, they have not been specifically discussed.

CLICK HERE to CONTINUE to PART 3.

If you liked this post, follow me at:

My novels: The Darkening Dream and Untimed
or the
video game post depot
or win Crash & Jak giveaways!

Latest hot post: War Stories: Crash Bandicoot

Related posts:

  1. Crash Bandicoot – Teaching an Old Dog New Bits – part 1
  2. Crash Bandicoot – An Outsider’s Perspective (part 8)
  3. Making Crash Bandicoot – part 5
  4. Making Crash Bandicoot – part 4
  5. Making Crash Bandicoot – part 3
By: agavin
Comments (9)
Posted in: Games, Technology
Tagged as: Andy Gavin, Application programming interface, Central processing unit, Console game, Crash Bandicoot, Crash Bandicoot 2: Cortex Strikes Back, game, Jason Rubin, Naughty Dog, Operating system, Playstation, Program optimization, Programming tool, pt_crash_history, Video game, Video game console

Crash Bandicoot – Teaching an Old Dog New Bits – part 1

Mar26

This is loosely part of a now lengthy series of posts on the making of Crash Bandicoot. Click here for the PREVIOUS or for the FIRST POST .

Below is another journal article I wrote on making Crash in 1999. This was co-written with Naughty Dog uber-programmer Stephen White, who was my co-lead on Crash 2, Crash 3, Jak & Daxter, and Jak 2. It’s long, so I’m breaking it into three parts.

Teaching an Old Dog New Bits

How Console Developers are Able to Improve Performance When the Hardware Hasn’t Changed

by

Andrew S. Gavin

and

Stephen White

Copyright © 1994-99 Andrew Gavin, Stephen White, and Naughty Dog, Inc. All rights reserved.

Console vs. Computer

Personal computers and video game consoles have both made tremendous strides in graphics and audio performance; however, despite these similarities there is a tremendous benefit in understanding some important differences between these two platforms.

Evolution is a good thing, right?

The ability to evolve is the cornerstone behind the long-term success of the IBM PC.  Tremendous effort has been taken on the PC so that individual components of the hardware could be replaced as they become inefficient or obsolete, while still maintaining compatibility with existing software.  This modularity of the various PC components allows the user to custom build a PC to fit specific needs.  While this is a big advantage in general, this flexibility can be a tremendous disadvantage for developing video games.  It is the lack of evolution; the virtual immutability of the console hardware that is the greatest advantage to developing high quality, easy to use video game software.

You can choose any flavor, as long as it’s vanilla

The price of the PC’s evolutionary ability comes at the cost of dealing with incompatibility issues through customized drivers and standardization.  In the past, it was up to the video game developer to try to write custom code to support as many of the PC configurations as possible.  This was a time consuming and expensive process, and regardless of how thorough the developer tried to be, there were always some PC configurations that still had compatibility problems.  With the popularity of Microsoft’s window based operating systems, video game developers have been given the more palatable option of allowing other companies to develop the drivers and deal with the bulk of the incompatibility issues; however, this is hardly a panacea, since this necessitates a reliance on “unknown” and difficult to benchmark code, as well as API’s that are designed more for compatibility than optimal performance.  The inherit cost of compatibility is compromise.  The API code must compromise to support the largest amount of hardware configurations, and likewise, hardware manufacturers make compromises in their hardware design in order to adapt well to the current standards of the API.  Also, both the API and the hardware manufacturers have to compromise because of the physical limitations of the PC’s hardware itself, such as bus speed issues.

Who’s in charge here?

The operating system of a PC is quite large and complicated, and is designed to be a powerful and extensively featured multi-tasking environment.  In order to support a wide variety of software applications over a wide range of computer configurations, the operating system is designed as a series of layers that distance the software application from the hardware.  These layers of abstraction are useful for allowing a software application to function without concerning itself with the specifics of the hardware.  This is an exceptionally useful way of maintaining compatibility between hardware and software, but is unfortunately not very efficient with respect to performance.  The hardware of a computer is simply a set of interconnected electronic devices.  To theoretically maximize the performance of a computer’s hardware, the software application should write directly to the computer’s hardware, and should not share the resources of the hardware, including the CPU, with any other applications.  This would maximize the performance of a video game, but would be in direct conflict with the implementations of today’s modern PC operating systems.  Even if the operating system could be circumvented, it would then fall upon the video game to be able to support the enormous variety of hardware devices and possible configurations, and would therefore be impractical.

It looked much better on my friend’s PC

Another problem with having a large variety of hardware is that the video game developer cannot reliably predict a user’s personal set-up.  This lack of information means that a game can not be easily tailored to exploit the strengths and circumvent the weaknesses of a particular system.  For example, if all PC’s had hard-drives that were all equally very fast, then a game could be created that relied on having a fast hard-drive.  Similarly, if all PC’s had equally slow hard-drives, but had a lot of memory, then a game could compensate for the lack of hard-drive speed through various techniques, such as caching data in RAM or pre-loading data into RAM.  Likewise, if all PC’s had fast hard-drives, and not much memory, then the hard-drive could compensate for the lack of much memory by keeping most of the game on the hard-drive, and only spooling in data as needed.

Another good example is the difference between polygon rendering capabilities.  There is an enormous variation in both performance and effects between hardware assisted polygonal rendering, such that both the look of rendered polygons and the amount of polygons that can be rendered in a given amount of time can vary greatly between different machines.  The look of polygons could be made consistent by rendering the polygons purely through software, however, the rendering of polygons is very CPU intensive, so may be impractical since less polygons can be drawn, and the CPU has less bandwidth to perform other functions, such as game logic and collision detection.

Other bottlenecks include CD drives, CPU speeds, co-processors, memory access speeds, CPU caches, sound effect capabilities, music capabilities, game controllers, and modem speeds to name a few.

Although many PC video game programmers have made valiant attempts to make their games adapt at run-time to the computers that they are run on, it is difficult for a developer to offer much more than simple cosmetic enhancements, audio additions, or speed improvements.  Even if the developer had the game perform various benchmark tests before entering the actual game code, it would be very difficult, and not to mention limiting to the design of a game, for the developer to write code that could efficiently structurally adapt itself to the results of the benchmark.

Which button fires?

A subtle, yet important problem is the large variety of video game controllers that have to be supported by the PC.  Having a wide variety of game controllers to choose from may seem at first to be a positive feature since having more seems like it should be better than having less, yet this variety actually has several negative and pervasive repercussions on game design.  One problem is that the game designer can not be certain that the user will have a controller with more than a couple of buttons.  Keys on the keyboard can be used as additional “buttons”, but this can be impractical or awkward for the user, and also may require that the user configure which operations are mapped to the buttons and keys.  Another problem is that the placement of the buttons with respect to each other is not known, so the designer doesn’t know what button arrangement is going to give the user the best gameplay experience.  This problem can be somewhat circumvented by allowing the user to remap the actions of the buttons, but this isn’t a perfect solution since the user doesn’t start out with an inherent knowledge of the best way to configure the buttons, so may choose and remain using an awkward button configuration.  Also, similar to the button layout, the designer doesn’t know the shape of the controller, so can’t be certain what types of button or controller actions might be uncomfortable to the user.

An additional problem associated with game controllers on the PC is that most PC’s that are sold are not bundled with a game controller.  This lack of having a standard, bundled controller means that a video game on the PC should either be designed to be controlled exclusively by the keyboard, or at the very least should allow the user to optionally use a keyboard rather than a game controller.  Not allowing the use of the keyboard reduces the base of users that may be interested in buying your game, but allowing the game to be played fully using the keyboard will potentially limit the game’s controls, and therefore limit the game’s overall design.

Of course, even if every PC did come bundled with a standard game controller, there would still be users who would want to use their own non-standard game controllers.  The difference, however, is that the non-standard game controllers would either be specific types of controllers, such as a steering wheel controller, or would be variations of the standard game controller, and would therefore include all of the functionality of the original controller.  The decision to use the non-standard controller over the standard controller would be a conscious decision made by the user, rather than an arbitrary decision made because there is no standard.

Chasing a moving target

Another problem associated with the PC’s evolutionary ability is that it is difficult to predict the performance of the final target platform.  The development of video games has become an expensive and time consuming endeavor, with budgets in the millions, and multi year schedules that are often unpredictable.  The PC video game developer has to predict the performance of the target machine far in advance of the release of the game, which is difficult indeed considering the volatility of schedules, and the rapid advancements in technology.  Underestimating the target can cause the game to seem dated or under-powered, and overestimating the target could limit the installed base of potential consumers.  Both could be costly mistakes.

Extinction vs. evolution

While PC’s have become more powerful through continual evolution, video game consoles advance suddenly with the appearance of an entirely new console onto the market.  As new consoles flourish, older consoles eventually lose popularity and fade away.  The life cycle of a console has a clearly defined beginning:  the launch of the console into the market.  The predicted date of the launch is normally announced well in advance of the launch, and video game development is begun early enough before the launch so that at least a handful of video game titles will be available when the console reaches the market.  The end of a console’s life cycle is far less clearly defined, and is sometimes defined to be the time when the hardware developer of the console announces that there will no longer be any internal support for that console.  A more practical definition is that the end of a console’s life cycle is when the public quits buying much software for that console.  Of course, the hardware developer would want to extend the life cycle of a console for as long as possible, but stiff competition in the market has caused hardware developers to often follow up the launch of a console by immediately working on the design of the next console.

Each and every one is exactly the same

Unlike PC’s which can vary wildly from computer to computer, consoles of a particular model are designed to be exactly the same.  Okay, so not exactly the same, but close enough that different revisions between the hardware generally only vary in minor ways that are usually pretty minor from the perspective of the video game developer, and are normally transparent to the user.  Also, the console comes with at least one standard game controller, and has standardized peripheral connections.

The general premise is that game software can be written with an understanding that the base hardware will remain consistent throughout the life-span of the console; therefore, a game can be tailored to both exploit the strengths of the hardware, and to circumvent the weaknesses.

The consistency of the hardware components allows a console to have a very small, low level operating system, and the video game developer is often given the ability to either talk to the hardware components directly, or to an extremely low hardware abstraction layer.

The performance of the components of the hardware is virtually identical for all consoles of a given model, such that the game will look the same and play the same on any console.  This allows the video game developer to design, implement, and test a video game on a small number of consoles, and be assured that the game will play virtually the same for all consoles.

CLICK HERE FOR PART 2

If you liked this post, follow me at:

My novels: The Darkening Dream and Untimed
or the
video game post depot
or win Crash & Jak giveaways!

Latest hot post: War Stories: Crash Bandicoot


Related posts:

  1. Crash Bandicoot – An Outsider’s Perspective (part 8)
  2. Making Crash Bandicoot – part 5
  3. Crash Bandicoot as a Startup (part 7)
  4. Making Crash Bandicoot – part 4
  5. Making Crash Bandicoot – part 1
By: agavin
Comments (29)
Posted in: Games, Technology
Tagged as: Andy Gavin, Application programming interface, Central processing unit, Crash Bandicoot, Crash Bandicoot 2: Cortex Strikes Back, DirectX, Jak and Daxter, Naughty Dog, Personal computer, pt_crash_history, Stephen White, Video game, Video game developer, Video Games

Making Crash Bandicoot – GOOL – part 9

Mar12

This is part of a now lengthy series of posts on the making of Crash Bandicoot. Click here for the PREVIOUS or for the FIRST POST. I also have a newer post on LISP here.

I’m always being asked for more information on the LISP based languages I designed for the Crash and Jak games. So to that effect, I’m posting here a journal article I wrote on the subject in 1996. This is about GOOL, the LISP language used in Crash 1, Crash 2, and Crash 3. GOOL was my second custom language. Way of the Warrior had a much simpler version of this. Jak 1,2,3 & Jak X used GOAL, which was a totally new vastly superior (and vastly more work to create) implementation that included a full compiler. GOOL (the subject of this article) was mostly interpreted, although by Crash 2 basic expressions were compiled into machine code. But I’ll save details on GOAL for another time.

[ Also I want to thank my reader “Art” for helping cleanup an ancient copy of this article — stuck in some mid 90s Word format that can no longer be read. ]

_

Making the Solution Fit the Problem:

AI and Character Control in Crash Bandicoot

Andrew S. Gavin

Copyright (c) 1996 Andrew Gavin and Naughty Dog, Inc.

All rights reserved.

Abstract

Object control code, which the gaming world euphemistically calls AI, typically runs only a couple of times per frame. For this kind of code, speed of implementation, flexibility, and ease of later modification are the most important requirements. This is because games are all about gameplay, and good gameplay only comes from constant experimentation with and extensive reworking of the code that controls the game’s objects. The constructs and abstractions of standard programming languages are not well suited to object authoring, particularly when it comes to flow of control and state. GOOL (Game Oriented Object LISP) is a compiled language designed specifically for object control code that addresses these limitations.

Video games are the type of program which most consistently pushes the machine and programmer to the limit. The code is required run at blinding speeds, fit in tiny memory footprints, have no serious bugs, and be completed under short schedules. For the ultra high performance 5% of functions which run most frequently there is no substitute for careful hand coding in assembly. However, the rest of the program requires much more rapid implementation. It is this kind of code which is the subject of this article.

Object control code, which is euphemistically called AI in games, typically runs only a couple of times per frame. With this kind of code, speed of implementation, flexibility, and ease of later modification are often more important than maximizing execution time. This is because games are all about gameplay, and achieving good gameplay is about writing and rewriting object code time and time again. Programming languages are not immutable truths handed down from on high, but tools created by people to solve particular tasks. Like any tool, a programming language must be right for the job. One would not attempt to turn a hexagonal nut with a pentagonal wrench, neither is it easy to write a program in a language not well suited to the problem. Sadly, most programmers have only been exposed to a small set of similar and inflexible languages. They have therefore only learned a small number of ways to customize these languages to the task at hand. Let us stop for a second and take look at the abstractions given to us by each of the common choices, and at what price. But first a word about assemblers and compilers in general.

Assemblers and compilers are programs designed to transform one type of data (the source language) into another (the target language). There is nothing particularly mysterious about them, as these transforms are usually just a bunch of tabled relationships. We call one of these programs a compiler when it performs some kind of automatic allocation of CPU resources. Since most commonly found languages are fairly static, the transform rules are usually built into the compiler and can not be changed. However, most compilers offer some kind of macro facility to allow customizations.  In its most general form a macro is merely a named function, which has a rule for when it is activated (i.e. the name of the macro). When it is used, this function is given the old piece of program, and can do whatever normal programming functions it wishes to calculate a new expression, which it returns to be substituted for the old. Unfortunately, most languages do not use this kind of macro, but instead create a new tiny language which defines all the functions which are allowed to run during macro expansion (typically template matching of some sort). With general purpose macros, any transform is possible, and they can even be used to write an entire compiler.

Almost all programmers have had some exposure to assembly language. An assembler basically serves the purpose of converting symbolic names into binary values. For example, “add” becomes 20. In addition, most allow simple renaming of registers, assignment of constants to symbols, evaluation of constant expressions, and some kind of macro language.  Usually these macro languages consist of template substitutions, and the ability to run simple loops at expansion time. Assembly directly describes the instructions interpreted by the processor, and as such is the closest to the chip which a software engineer can get. This makes it very tedious and difficult to port to a different a machine. Additionally, since it consists primarily of moving binary words between registers and memory, and performing simple operations on them, most people find it tedious and difficult to use for large programs. In assembly, all details must be tracked by hand. Since knowledgeable humans are smarter than compilers, albeit much slower, they are capable of doing a substantially better job of creating smaller more efficient code. This is true, despite the claims of the modern OS community, compilers are still only about half as good as a talented assembly programmer. They just save a lot of time.

Many programmers learned to program with Basic. This language has an incredibly simple syntax, and typically comes with a friendly interactive environment. These features make it easy to learn and use. It however has no support for abstractions of any sort, possessing only global variables, and no macro system. Globals are great for beginners because the whole abstract arena of scope becomes a non issue. However, the absence of lexical scoping makes the isolation of code (and its associated bugs) nearly impossible. There is however an important lesson in basic which has been lost on the programming community: interactive is good. Basic typically has an interpreted listener, and this enables one to experiment very quickly with expressions to see how they work, and to debug functions before they are put into production.

The standard programming language of the last few years is C. First and foremost C provides series of convenient macros for flow control, arithmetic operations, memory reference, function calling, and structure access. The compiler writer makes expansions for these that work in the target machine language. C also provides expression parsing and simple register allocation for assembler grade data objects (i.e. words). C code is reasonably portable between machines of a similar generation (i.e. word size). As an afterthought a preprocessor provides rudimentary textual macro expansion and conditional compilation. The choice not to include any of the hallmarks of higher level languages, like memory management (aka garbage collection), run time typing, run time linking, and support for more complex data types (lists, true arrays, trees, hash tables etc.) is a reasonable one for many tasks where efficiency is crucial. However, C is crippled by an inconsistent syntax, a weak text based macro system, and an insurmountable barrier between run time and compile time name spaces. C can only be customized via the #define operator and by functions. Unfortunately, this makes it impossible to do many interesting and easy things, many of C’s fundamental areas, structures, setting, getting, expressions, flow of control, and scope are completely off limits for customization. Since functions always have a new scope, they are not useful creating flow of control constructs, and #define is so weak that it can’t even handle the vagaries of the structure syntax. For those who know C very well it is often a convenient language, since it is good at expressions and basic flow of control. However, whenever complicated data structures are involved the effort needed is obscene, and C in unable to transfer this effort from one data type to another similar one.

Modern operating system and fancy programs are filled with scripting languages.  MS DOS batch language, the various Unix shell languages, perl, tcl etc. are all very common.  These are toy languages. They often have inconsistent and extremely annoying syntaxes, no scoping, and no macros. They were invented basically as macro languages for operating system shells, and as such make it fairly easy to concatenate together new shell commands (a task that is very tedious in assembly or C). However, their ambiguous and inconsistent syntaxes, their slow interpreted execution speeds, and the proliferation of too many alternatives has made them annoying to invest time in learning.  Recently a new abomination has become quite popular, and its name is C++. This monstrosity of a language attempts to extend C in a direction it was never intended, by making structures able to contain functions.  The problem is that the structure syntax is not very flexible, so the language is only customizable in this one direction. Hence one is forced to attempt to build all abstractions around the idea of the structure as class. This leads to odd classes which do not represent data structures, but instead represent abstract ways of doing. One of the nice things about C is that the difference between pointer and object is fairly clear, but in C++ this has become incomprehensibly vague, with all sorts of implicit ways to pass by reference. C++ programs also tend to be many times larger and slower than their C counterparts, compile much slower, and because C++ compilers are written in C, which can not handle flexible data structures well, the slightest change to the source code results in full compiles of the entire source tree. I am convinced that this last problem alone makes the language a severe productivity minus. But I forgot, since C++ must determine nearly everything at compile time you still have to write all the same code over and over again for each new data type.

The advent of the new class metaphor has brought to the fore C and C++’s weakness at memory management. Programmers are forced to create and destroy these new objects in a variety of bizarre fashions. The heap is managed by the wretched malloc model, which uses wasteful memory cookies, creates mysterious crashes on overwrites, and endless fragmentation.

None of these problems are present in Lisp, which is hands down the most flexible language in common use.  Lisp is an old language (having its origins in the 50s) and has grown up over the last 30 years with the evolution of programming. Today’s modern Common Lisp is a far cry from the tiny mainframe list of 30 years ago. Aided by a consistent syntax which is trivial to parse, and the only full power macro system in a commonly used language, Lisp is extremely easy to update, customize, and expand, all without fighting the basic structures of the language. Over the years as lexical scoping, optimized compilation, and object oriented programming each came into vogue Lisp was able to gracefully adopt them without losing its unique character. In Lisp programs are built out of one of the language’s built in data structure, the list.  The basic Lisp expression is the form. Which is either an atom (symbol or number) or a list of other forms. Surrounded by parentheses, a Lisp lists always has its function at the head, for example the C expression 2+2 is written as (+ 2 2). This may seem backwards at first, but with this simple rule much of the ambiguity of the syntax is removed from the language. Since computers have a very hard time with ambiguity, programs that write programs are much easier in Lisp.

Let me illustrate beginning with a simple macro.

(defmacro (1+ value)
	"Simple macro to expand (1+ value) into (+ 1 value).
	Note that backquote is used.  Backquote is a syntax
	sugar which says to return the 'quoted' list, all
	forms following a comma however are evaluated
	before being placed in the list. This allows the
	insertion of fields into a template.
	1+ is the operator which adds 1 to its operand
	(C uses ++ for this)."
  `(+ 1 ,value))

The above form defines a function which takes as its argument the expression beginning with 1+, and returns a new expanded expression (i.e. (1+ 2) > (+ 1 2)). This is a very simple macro because it merely fills in a template. However, if our compiler did not perform constant reduction we could add it to this macro like this:

(defmacro (1+ value)
	"Smarter macro to expand 1+.  If value is a number,
	then increment on the spot and return the new
	number as the expansion."
  (if (numberp value)
      (+ 1 value)
    `(+ 1 ,value)))

The form numberp tests if something is a number. If value is, we do the add in the context of the expansion, returning the new number as the result of the macro phase. If value is not a number (i.e. it is a variable or expression), we return the expanded expression to be incremented at run time.

These full power macros allow the programmer to seamlessly expand the language in new ways. For example, the lisp form cond can be implemented from if’s with a macro. Cond is a special form which is like a C “switch” statement except that each case has an arbitrary expression. For example:

(cond
  ((= temp 2)
   (print 'two))
  ((numberp temp)
   (print 'other number))
  (t
   (print 'other type)))

Will print “two” if temp is 2, “other number” if it is a number (other than 2), and “other type” otherwise. A simple implementation of cond would be as follows:

(defmacro cond (&rest clauses)
	"Implement the standard cond macro out of nested
	'if's and 'when's. t must be used to specify the
	default case, and it must be used last. This macro
	uses backquote's ,@ syntax which splices a list
	into the list below it. Note also the use of progn.
	progn is a form which groups multiple forms and has
	as it's value, the value of the last form. cond
	clauses contain what is called an implicit progn,
	they are grouped together and the value of the
	last one is returned as the value of the cond."
  (if (eq (length clauses) 1)
      (if (eq (caar clauses) t)
          `(progn ,@(cdar clauses))
        `(when ,(caar clauses)
            ,@(cdar clauses)))
    `(if ,(caar clauses)
         (progn ,@(cdar clauses))
       (cond ,@(cdr clauses)))))

This expands the above cond into:

  (if (= temp 2)
      (progn (print 'two))
    (cond
      ((numberp temp)
       (print 'other number))
      (t
       (print 'other type))))

After a single pass of macro expansion. The macro will peel the head off of the cond one clause at a time converting it into nested ifs. There is no way to use C’s #define to create a new flow of control construct like this, yet in a compiled language these compile time transforms are invaluable to bridging the gap between efficient and readable code.

GOOL (Game Oriented Object LISP) is my answer to the difficulties of using C and assembly for object programming. It is a compiled Lisp dialect designed specifically for the programming of interactive game objects. As a language it has the following features: Consistent syntax, full power macros, symbolic names, orthogonal setting/getting, layered computation, multiple ultra light threads, grouping of computations into states, externally introduced flow of control changes (events), small execution size, retargetable backend, and dynamic linking. The GOOL compiler is embedded in Allegro Common Lisp (an ANSI Common Lisp from Franz Inc. which I run on an Silicon Graphics workstation running IRIX). Common Lisp provides an ideal environment for writing compilers because you start off with parsing, garbage collection, lists, trees, hash tables, and macros from the get go. As a language GOOL borrows its syntax and basic forms from Common Lisp.  It has all of Lisp’s basic expression, arithmetic, bookkeeping, and flow of control operators.  These vary in many small ways for reasons of speed or simplicity, but GOOL code can basically be read by the few of us lucky enough to have been exposed to Lisp. GOOL is also equipped with 56 primitives and 420 macros which support its advanced flow of control and game object specific operations. Additional ones can be trivially defined globally or locally within objects, and are indistinguishable from more primitive operations.

The GOOL compiler is an modern optimizing compiler with all sorts of smarts built into various macros and primitives. It is a fully forward referenced single pass compiler. Unlike some other programming languages with single letter names, GOOL does not require you to define something textually before you use it, and you never need tertiary declarations (like prototypes). Computers are good at remembering things, and a compiler is certainly able to remember that you called a function so that it can check the arguments when it gets to the declaration of that function. GOOL is fully relocatable and dynamically linked. So it is not necessary to include code for objects which are not nearby in memory. C is so static, and overlays so difficult and incompatible, that almost no effort is made to do dynamic binding of code, resulting in much wasted memory.

The programming tasks involved in creating game object behaviors are very inconvenient under the standard functional flow of control implied by most programming languages. In the programming of game objects it is necessary for each object to have a local state. This state consists of all sorts of information: type, position, appearance, state, current execution state (program counter), and all types of other state specific to the type of object. From the point of view of a particular object’s code all this can be viewed as an object specific global space and a small stack. This state must be unique to a specific object because it is often necessary to execute the same code on many different copies of the state. In either C or assembly it is typical to make some kind of structure to hold the state, and then write various routines or code fragments that operate on the structure. This can be accomplished either with function syntax macros or structure references. GOOL on the other hand allows this state to be automatically and conveniently bound to variable names for the most straightforward syntax. For example the C:

object >transx = object >transx + immediate_meters(4);

becomes in GOOL the similar expression:

(setf transx (+ transx (meters 4)))

However if in C one wished to add some new named state to each instance of a particular object one would have to create new structure records, accessors, initializers, memory management etc. GOOL on the other hand is able to easily allocate these on the object’s local stack with just one line of code, preserving the data there from frame to frame as well. A standard programming language like C only has one thread of control. While this is appropriate for the general case, it is inappropriate for objects, which are actually better expressed as state machines. In addition, it is extremely useful to be able to layer ultra light weight threads of execution, and to offer externally introduced transfers of control (events). While threads typically complicate most applications programs with few benefits, they are essential to the convenient programming of game objects, which often have to do several things at once. For example, an object might want to rotate 180 degrees, scale up toward 50%, and move toward the player character all at once. These actions do not necessarily take the same amount of time, and it is often useful to dynamically exchange and control them. In traditional code this is very awkward.

The basic unit of code in GOOL is a code block (or thread). These often do simple things as above. An arbitrary number of these may be combined into a state, they may be borrowed from other states, and activated and deactivated on the fly. For example:

(defgstate turn scale and move toward
	:trans	(defgcode (:label turn 180)
		; set the y rotation 10 degrees closer to 180 degrees
			(setf roty (degseek roty (deg 180) (deg 10))))
	:trans	(defgcode (:label scale to 150 percent)
		; set the x,y, and z scales 10% closer to 150% scale
			(with vec scale
				(seekf scale (scale 1.5) (scale .1))))
	:trans	(defgcode (:label move toward target)
		; set the x,y, and z position closer to the target's
		; (another object) position at a rate of 5 meters per second
			(with vec trans
				(seekf trans (target trans) (velocity (meters per sec 5)))))
	:code	(defgcode (:label play animation)
		; play the animation until this object is colliding with
		; another, then change states
			(until (status colliding)
				(play frame group animation))
				(goto collided)))

A :trans block is one which runs continuously (once per frame), and a :code block is one which has a normal program counter, running until suspended by a special primitive (frame), as in “frame is over.” These code blocks can be run as threads (as above), called as procedures, converted to lambda’s and passed to something (function pointers), and assigned to be run under special conditions (events or state exit). In this example is also illustrated the kind of simple symbolic notation used in GOOL to make object programming easier. Vectors like rotation, translation, and scale are bound to simple symbolic names (e.g. roty is the y component of the rotation vector). Many new arithmetic operations have been defined for common operations, for example, seek, which moves a number toward another number by some increment, and seekf its destructive counterpart.

GOOL also has a sophisticated event system.  It is possible to send an event (with parameters) to another object or objects. The object may then choose to do what it wishes with that event, run some code, change state, ignore it, etc., and report something back to the caller. These event handlers can be bound and unbound dynamically, allowing the object to change its behavior to basic events very flexibly.  For example:

:event	(defgcode (:params (event params))
		(reject-event-and-return
			((and (event is hit on the head)
				(< (interrupter transy) transy)))))

Says to ignore the hit on the head event when the interrupter (sender) is below the receiver in the y dimension.

Another feature illustrated here is the indirect addressing mode, (interrupter transy), in which a variable of another object (whose pointer is in the variable interrupter) is accessed. Operations can locate and return object pointers, which can be used as parameters. For example:

(send event hit on the head (find the nearest object))

which sends hit on the head to the nearest object or:

(let ((target (find the nearest object)))
	(when (and target (type target turtle))
		(send event hit on the head)))

which sends hit on the head to the nearest object only if it is a turtle.

It is the GOOL compiler’s responsibility to turn this state into code that executes the abstraction (the above state becomes about 25 words of R3000 assembly code).  GOOL code is typically much smaller than traditional code for similar tasks because the compiler does all the book keeping for this interleaving, and it is all implicit in the runtime product.  In addition it has a degree of code reuse which is practically unachievable in a normal language without extremely illegible source.

GOOL has full power macros which allow the language to be brought up to the level of the problem.  For example, many game programming tasks are more descriptive than a language like C is designed for. The following code causes a paragraph of text to appear on the bottom of the screen and scroll off the top.

(credit list (1 14)
	("AFTER THE")
	("DISAPPEARANCE")
	("OF HIS MENTOR,")
	("DR. NITRUS BRIO")
	("REDISCOVERED HIS")
	("FIRST LOVE:")
	(blank 1)
	("TENDING")
	("BAR"))

It does this by expanding into a program which creates a bunch of scrolling text objects as follows:

(defgopm credit list (params &rest body)
	"This macro iterates through the clauses in its
	body and transforms them into spawn credit line
	statements which create new credit line objects.
	It book keeps the y position down ward by height
	each time."
   (let ((list)
        (y 0)
        (font (first params))
        (height (second params)))
     (dolist (i body)
        (cond
          ((listp i)
           (case
             (car i)
             (blank (incf y (second i)))
             (t (push (append '(spawn credit line)
                               (:y ,y :font ,font :h ,height))
                      list)
                (incf y 1))))))
     `(progn ,@(reverse list))))(defgopm spawn credit line (line &key (y 0) (font 0) (h 18))
  "This macro is purely syntactic sugar, making the above macro somewhat easier."
  (spawn 1 credit line
     (frame num ,line)
     (unit ,(* y h)) ,font))

The following state is the code for the actual credit line.  When one of these credit line objects is spawned it creates a line of text. It then proceeds to use it’s trans to crawl upward from the starting y position until it is off the screen, in which case it kills itself.

(defgstate credit line (stance)
  :handles (spawn credit line)
  :trans (defgcode ()
           (unless first frame
              (setf transy ((parent transy) transvy))
              (when (> transy (unit 140))
              (goto die fast))))
  :code  (defgcode (:params (text frame y font))
           (stomp action screen relative)
           (set frame group text)
           (setf transvy y)
           (setf transy ((parent transy) transvy))
           (sleep text frame)))

As a conglomerate the above code manages to create a scrolling paragraph of arbitrary length from a descriptive block of code.  It does this by using the macro to transform the description into a program to create a cluster of new line objects.  This line objects take their simple behavior and amplify it into a more substantial effect when they are created in concert. In a conventional language it would be typical to create some kind of data structure to describe different actions, and then interpret that. C in particular is a very poor language for description. Because C’s only complex data type, the structure, can not even be declared in line (e.g. “struct foo bar={1,0}” is not legal except as a global) it is extremely awkward to describe complex things. It must be done with code, and the poor textual macro expander is not up to this. Witness the wretchedness of descriptive APIs like that of X windows. The contortions necessary to describe widget creation are unbelievable. Is it no wonder that people prefer to do interface work with resource files or Tcl/Tk which are both more descriptive in nature?

Overall, having a custom language whose primitives and constructs both lend themselves to the general task (object programming), and are customizable to the specific task (a particular object) makes it much easier to write clean descriptive code very quickly. GOOL makes it possible to prototype a new creature or object in as little as 10 minutes. New things can be tried and quickly elaborated or discarded. If the object doesn’t work out it can be pulled from the game in seconds without leaving any hard to find and wasteful traces behind in the source. In addition, since GOOL is a compiled language produced by an advanced register coloring compiler with reductions, flow analysis, and simple continuations it is at least as efficient as C, more so in many cases because of its more specific knowledge of the task at hand.  The use of a custom compiler allows to escape many of the classic problems of C.


A new 10th Crash post can be found HERE.

If you liked this post, follow me at:

My novels: The Darkening Dream and Untimed
or the
video game post depot
or win Crash & Jak giveaways!

Latest hot post: War Stories: Crash Bandicoot

Related posts:

  1. Making Crash Bandicoot – part 4
  2. Making Crash Bandicoot – part 1
  3. Making Crash Bandicoot – part 5
  4. Making Crash Bandicoot – part 6
  5. Making Crash Bandicoot – part 3
By: agavin
Comments (167)
Posted in: Games, Technology
Tagged as: Andy Gavin, Artificial intelligence, Central processing unit, Common Lisp, Compiler, Crash Bandicoot, Crash Bandicoot 2: Cortex Strikes Back, Crash Bandicoot 3: Warped, Gool, Languages, Lisp, Lisp Programming, Machine code, Macro, Macro (computer science), Naughty Dog, Programming, Programming language, pt_crash_history, Run time (computing), Scope (programming)

Crash Bandicoot – An Outsider’s Perspective (part 8)

Feb16

This is part of a now lengthy series of posts on the making of Crash Bandicoot. Click here for the PREVIOUS or for the FIRST POST .

After Naughty Dog Jason and I joined forces with another game industry veteran, Jason Kay (collectively Jason R & K are known as “the Jasons”). He was at Activision at the time of the Crash launch and offers his outside perspective.

Although I would not meet Andy and Jason until after Crash 3 was released, the time around the launch of Crash Bandicoot was a fascinating time in the game business, and I believe that the launch of Crash, which was so far ahead of every other game of its generation in every aspect – technical achievement, production values, sound/music, design and balancing – caused everyone I knew in the business to rethink the games they were working on.

Warhawk: One of the best looking early PS1 games

It seems hard to imagine given the broad scope of games today — Console Games costing $50+ million, Social Games on Facebook with 100 Million monthly average users, gesture controlled games, $.99 games on iPhone – how troubled the industry was before the release of Crash, which heralded the rebirth of console games after a dormant period and ushered in the era of the mega-blockbuster game we know today. In the year that Crash Bandicoott released, only 74 Million games were sold across all platforms in the US – of which Crash accounted for nearly 5% of all games sold in the US. By 2010 – more than 200 Million games were sold, with the number one title, Call of Duty: Black Ops selling “only” 12 million copies in the US – about 6% of the total market. In some ways, adjusted for scale, Crash was as big then as Call of Duty is today.

Twisted Metal – Another of the better early PS1 games

After the incredible success of Super Mario World and Sonic the Hedgehog, the game business was really in the doldrums and it had a been a boatload of fail for the so-called “rebirth of the console”. Sega had released a series of “not-quite-next-gen” peripherals for the incumbent Sega Genesis system (including the 32x and the truly awful Sega CD), and made vague promises about “forward compatibility” with their still-secret 32 bit 3D Saturn console. When the Saturn finally shipped, it was referred to by many people as “Two lies in One”, since it was neither compatible with any previous Sega hardware, and nor was it capable of doing much 3D. Sega further compounded their previous two mistakes by giving the console exclusively to then-dominant retailer Toys “R” US, pissing of the rest of the retail community and pretty much assuring that console, and eventually Sega’s, demise in the hardware business.

Wipeout – at the time it looked (and sounded) good

The PlayStation had shipped in Fall of 1995, but the initial onslaught of games all looked vaguely similar to Wipeout – since no one believed that it was possible to stream data directly from the PS1 CD-Drive, games were laboriously unpacking single levels into the PS1’s paltry 2 MB of ram (+ 1 meg vram and 0.5 meg sound ram), and then playing regular CD (“redbook”) audio back in a loop while the level played. So most games (including the games we had in development at Activision and were evaluating from third parties) all looked and played in a somewhat uninspiring fashion.

When Crash first released, I was a producer at then-upstart publisher Activision – now one of the incumbent powerhouses in the game business that everyone loves to hate – but at that time, Activision was a tiny company that had recently avoided imminent demise with the success of MechWarrior 2, which was enjoying some success as one of the first true-3D based simulations for the hardcore PC game market. To put in perspective how small Activision was at that time, full year revenues were $86.6 Million in 1996, versus over $4.45 Billion in 2010, a jump of nearly 50x.

MechWarrior 2: 31st Century Combat DOS Front Cover

Jeffrey Zwelling, a friend of a friend who had started in the game business around the same I did, worked at Crystal Dynamics as a producer on Gex. Jeffrey was the first person I knew to hear about Crash, and he tipped me off that something big was afoot right before E3 in 1996. Jeff was based in Silicon Valley, and a lot of the former Naughty Dogs (and also Mark Cerny) had formerly worked at Crystal, so his intel was excellent. He kept warning me ominously that “something big” was coming, and while he didn’t know exactly “what” it was, but it was being referred to by people who’d seen as a “Sonic Killer”, “Sony’s Mario”, and “the next mascot game”.

As soon as people got a glimpse of the game at E3 1996, the conspiracy mongering began and the volume on the Fear, Uncertainty and Doubt meter went to 11. In the pre-Internet absence of meaningful information stood a huge host of wild rumors and speculation. People “in the know” theorized that Naughty Dog had access to secret PlayStation specifications/registers/technical manuals that were only printed in Japanese and resided inside some sort of locked vault at Sony Computer Entertainment Japan. Numerous devs declared the Naughty Dog demo was “faked” in some way, running on a high-powered SGI Workstation hidden behind the curtain at Sony’s booth. That rumor seems in hindsight to have been a conflation of the fact that that the Nintendo 64 console, Code-Named “Project Reality” was in fact very similar to a Silicon Graphics Indigo Workstation and the Crash team was in fact writing and designing the game on Silicon Graphics workstations.

Tomb Raider – Crash contemporary, and great game. But the graphics…

Everyone in the business knew how “Sega had done what NintenDONT” and that they had trounced Nintendo with M-Rated games and better titles in the 16 bit Era, and most of the bets were that Nintendo was going to come roaring back to the #1 spot with the N64. Fortunately for Nintendo, Sega’s hardware was underpowered and underwhelming and Nintendo’s N64 shipped a year later than the Playstation 1. With all the focus on many people’s attention on this looming battle, and the dismissive claims that what Naughty Dog was showing was “impossible”, most people underestimated both the PlayStation and Naughty Dog’s Crash Bandicoot.

Since no one that I knew had actually gotten a chance to play Crash at the show – the crowds were packed around the game – I fully expected that my unboxing of Crash 1 would be highly anti-climatic. I remember that Mitch Lasky (my then boss, later founder of Jamdat and now a partner at Benchmark) and I had made our regular lunch ritual of visiting Electronics Boutique [ ANDY NOTE: at Naughty Dog this was affectionately known as Electronic Buttock ] (now GameStop) at the Westside Pavilion and picked up a copy of the game. We took the game back to our PS1 in the 7th Floor Conference Room at Activision, pressed start, and the rest was history. As the camera focused on Crash’s shoes, panned up as he warped in, I literally just about sh*t a brick. Most of the programmers we had talked to who were pitching games to us claimed that it was “impossible” to get more than 300-600 polygons on screen and maintain even a decent framerate. Most of the games of that era, a la Quake, had used a highly compressed color palette (primarily brown/gray in the case of Quake) to keep the total texture memory low. It seemed like every game was going to have blocky, ugly characters and a lot of muted colors, and most of the games released on the PS1 would in fact meet those criteria.

Mario 64 – Bright, pretty, 3D, not so detailed, but the only real contender — but on a different machine

Yet in front of us, Andy and Jason and the rest of the Crash team showed us that when you eliminate the impossible, only the improbable remains. Right before my eyes was a beautiful, colorful world with what seemed like thousands of polys (Andy later told that Crash 1 did in fact have over 1800 polygons per frame, and Crash 2 cracked 3,100 polys per frame – a far cry from what we had been told was “a faked demo” by numerous other PS1 development teams). The music was playful, curious and fun. The sound effects were luscious and the overall game experience felt, for the first time ever, like being a character in a classic Warner Brothers cartoon. Although I didn’t understand how the Dynamic Difficulty Adjustment (discussed in part 6) actually worked, I was truly amazed that it was the first game everyone I knew who played games loved to play. There was none of the frustration of being stuck on one spot for days, no simply turning the game off never to play it again – everyone who played it seemed to play it from start to finish.

For us, it meant that we immediately raised our standards on things we were looking at. Games that had seemed really well done as prototypes a few weeks before now seemed ungainly, ugly, and crude. Crash made everyone in the game business “up their game.” And game players of the world were better off for it.

These posts continue with PART 9 HERE.

If you liked this post, follow me at:

My novels: The Darkening Dream and Untimed
or the
video game post depot
or win Crash & Jak giveaways!

Latest hot post: War Stories: Crash Bandicoot

Detailed and Colorful – but most important fun

Certainly varied

Sorry for the lousy screen shots!

Related posts:

  1. Making Crash Bandicoot – part 1
  2. Making Crash Bandicoot – part 6
  3. Making Crash Bandicoot – part 2
  4. Making Crash Bandicoot – part 5
  5. Crash Bandicoot as a Startup (part 7)
By: agavin
Comments (29)
Posted in: Games
Tagged as: Activision, Andy Gavin, Crash Bandicoot, Crash Bandicoot 3: Warped, Crystal Dynamics, game, GameStop, Jason Kay, Jason Rubin, Naughty Dog, Playstation, pt_crash_history, Sega, Sony Computer Entertainment, Super Mario World, Video game

Crash Bandicoot as a Startup (part 7)

Feb10

This is part of a now lengthy series of posts on the making of Crash Bandicoot. Click here for the PREVIOUS or for the FIRST POST .

Dave Baggett, Naughty Dog employee #1 (after Jason and I) throws his own thoughts on Crash Bandicoot into the ring:

This is a great telling of the Crash story, and brings back a lot of memories. Andy and Jason only touch on what is to me the most interesting aspect of this story, which was their own relationship. When I met them, they had been making games together — and selling them — literally since middle school. I remember meeting Andy for the first time in April 1992, at an MIT AI Lab orientation. He knew as much as I did about games and programming, was as passionate about it as I was, and was equally commercially-minded. I just assumed meeting someone like this was a consequence of the selectivity of MIT generally and the AI Lab in particular, which accepts about 25 students each year from a zillion applicants.

In the long run I found that assumption was wrong: Andy and Jason were ultimately unique in my experience. None of us on the Crash 1 team realized it, but as a team we were very much outliers. At 23, Andy and Jason had commercial, strategic-thinking, and negotiating skills that far exceeded those of most senior executives with decades of experience. These, combined with their own prodigious technical talents and skillful but at times happenstance hiring, produced a team that not only could compete with Miyamoto, but in some ways outdo him. (More on this in a moment.)

I still remember the moment I decided to bail on my Ph.D. and work for Andy and Jason as “employee #1”. I don’t think they saw themselves this way, but my archetype for them was John and Paul. (The Beatles, not the saints!) They were this crazy six-sigma-outlier yin/yang pair that had been grinding it out for literally years — even though they were still barely in their 20s. I knew these guys would change the world, and I wanted to be the George Harrison. One problem with this idea, however, was that they had been gigging together for so long that the idea of involving someone else in a really deep way — not just as an employee,but as a partner — was extremely challenging for them emotionally, and, I think, hard for them to conceptualize rationally from a business standpoint. This ultimately led to my leaving after Crash 2 — very sadly, but mostly for dispassionate “opportunity cost” reasons — though I continued to work with Josh Mancell on the music for Crash 3 and CrashTeam Racing, and remained close friends with all the ‘Dogs.

Andy and Jason had evolved a peculiar working relationship that the rest of the team found highly amusing. Jason would stomp around raging about this or that being terrible and Andy would play the role of Star Trek’s Scotty — everything was totally impossible and Jason couldn’t possibly appreciate the immense challenges imposed by what he was really asking for.  (As a programmer myself, I generally took Andy’s side in these debates, though I usually hid in my office when the yelling got above a certain decibel level.) Eventually when matters were settled Andy usually pounded out the result in a 1/10th of the advertised time (also like Scotty). The rest of us couldn’t help but laugh at these confrontations — at times, Andy and Jason behaved like an old married couple. The very long work hours — literally 100-hour weeks — and the stress level definitely amplified everyone’s emotions, especially theirs.

Andy and Japanese Crash in the NDI offices

On the subject of Mario 64, I agree more with Andy than with Jason, and think that Jason’s view highlights something very interesting and powerful about his personality. At the time I thought — and in retrospect, I still think — that Mario 64 was clumsy and ugly. It was the work of a great genius very much making a transition into a new medium — like a painter’s first work in clay. Going from 2D to 3D made all the technical challenges of games harder — for both conceptual and algorithmic reasons — and Miyamoto had just as hard a time as us adapting traditional gameplay to this new framework. The difference was that Miyamoto was an artist, and refused to compromise. He was willing and able to make a game that was less “fun” but more aggressively novel. As a result, he gave gamers their first taste of glorious 3D open vistas — and that was intoxicating. But the truth is that Mario 64 just wasn’t that fun; Miyamoto’s 2D efforts at the time — Donkey Kong Country and Yoshi’s Island — were far more fun (and, in fact, some of my personal favorite games of all time, though I never would have admitted that out loud at the time). As Andy said, the camera algorithms were awful; we had an incredibly hard time with camera control in our more constrained rails environment, and the problem wasn’t really technically solved for open environments like Mario 64’s until many years later. Mario 64’s collision detection algorithms were crap as well — collision detection suffers from a “curse of dimensionality” that makes it much harder in 3D than in 2D, as we also found. At Naughty Dog, we combined my ridiculously ambitious octree approach — essentially, dividing the entire world up into variable-sized cubes — with Mark’s godlike assembly coding to produce something *barely* fast enough to work — and it took 9 months. This was the one the one area on Crash when I thought we might actually just fail — and without Mark and I turning it into a back-and-forth coding throw-down, we probably would have. (As an aside, some coders have a savant-like ability to map algorithms onto the weird opportunities and constraints imposed by a CPU; only Greg Omi — who worked with us on Crash 2 — was in the same league as Mark when it came to this, of the hundreds of programmers I’ve worked with.)

But Jason was tormented by Mario 64, and by the towering figure of Miyamoto generally. Like Andy Grove, Jason was constantly paranoid and worked up about the competition. He consistently underrated his — and our — own efforts, and almost neurotically overrated those of his competitors. I saw this trait later in several other great business people I worked with, and it is one I’ve found that, while maddening, correlates with success.

Fifteen years later, I’m now on my third startup; ITA Software followed Naughty Dog, and now I’m doing a raw startup again. The Naughty Dog model set the mold for all my future thinking about startups, and so far each one has followed a similar pattern: you must have a very cohesive, hard-working, creative team early on. This team of 6-12 sets the pattern for the company’s entire future — whether it grows to 50, 500, or — I can only assume — 5000 employees. The Crash 1 team was one of those improbable assemblages of talent that can never quite be reproduced. And unlike our contemporaries, our team got lucky: as Andy said, we were able to “slot in” to a very low-probability opportunity. Yes, Andy and Jason, with Mark, had identified the slot, and that was prescient. But many things had to go our way for the slot to still be genuinely available. The Crash team was an improbably talented team that exploited an improbable opportunity. As a life-long entrepreneur, I’ve lived to participate in — and, now, try to create — teams like that. There’s nothing more gratifying in business.

Part 8 CONTINUES here with another guest post.

If you liked this post, follow me at:

My novels: The Darkening Dream and Untimed
or the
video game post depot
or win Crash & Jak giveaways!

Latest hot post: War Stories: Crash Bandicoot

Related posts:

  1. Making Crash Bandicoot – part 6
  2. Making Crash Bandicoot – part 1
  3. Making Crash Bandicoot – part 5
  4. Making Crash Bandicoot – part 4
  5. Making Crash Bandicoot – part 3
By: agavin
Comments (51)
Posted in: Games
Tagged as: Andy Gavin, Crash Bandicoot, Crash Bandicoot 2: Cortex Strikes Back, Dave Baggett, George Harrison, Jason Rubin, Josh Mancell, Naughty Dog, pt_crash_history, Startups, Super Mario 64, Video game, Video Game Design, Video Games

Making Crash Bandicoot – part 6

Feb07

PREVIOUS installment, or the FIRST POST.

[ NOTE, Jason Rubin added his thoughts to all the parts now, so if you missed that, back up and read the second half of each. ]

 

Not only did we need to finish our E3 demo, but we needed a real name for the game — Willie the Wombat wasn’t going to cut it. Now, in the Naughty Dog office proper we knew he was a Bandicoot. In fact, we liked the idea of using an action name for him, like Crash, Dash, Smash, and Bash — fallout from the visceral reaction to smashing so many boxes.

Dr N. Cortex goes medieval on Universal Marketing

But the Universal Marking department (of one) thought differently. They had hired one of those useless old-school toy marketing people, a frumpy fortyish woman about as divorced from our target audience – and the playing of video games – as possible. This seems to be a frequent problem with bigger companies, the mistaken idea that you can market an entertainment product if you aren’t also an enthusiastic customer of said product. On the other hand, everyone making the game played constantly. We had regular Bomberman tournaments, we could all debate the merits of control in Sonic vs Mario, and Dave was even a former Q*Bert world champion.

In any case, this obstacle (the marketing woman) wanted to call the game “Wuzzle the Wombat,” or “Ozzie the Otzel.” Fortunately, after much yelling we prevailed and Crash Bandicoot became… Crash Bandicoot.

Crash's hot girlfriend, Tawna

It’s also worth mentioning that she objected to Crash’s rather busty girlfriend (or Bandicoot-friend) on basic sexist principles. Now, Tawna wasn’t the most inspired of our character designs, more or less being Jessica Rabbit as a Bandicoot, and without the cool personality. But remember who generally played games like Crash. The same kind of guys we had been 5-10 years earlier.

The music also had to be cobbled together before E3 – and in classic video game development fashion had been left to the last minute. This task had been assigned to our nominal producer at Universal, a gentleman who mostly sat in his office and played Sexy Parodius. While of dubious benefit to the project, at least he loved video games. However, he proposed that instead of conventional music we create something called “the urban chaotic symphony” in which the programmer (me) would cause random sound effects such as bird chirps, car honks, grunts, and farting noises (actually listed and underlined), to be randomly selected and combined. When we rejected this innovative proposal, we were introduced to Mark Mothersbaugh of Devo and more recently Mutato Muzika. He and (mostly) Josh Mancell composed all the music for the games, produced by music aficionado and Naughty Dog programmer Dave Baggett.  Besides, Dave actually knew the game inside and out.

Finally we arrive at E3, and the debut of the N64 and Mario 64. Gulp.

Jason (right) and I (left) at E3 1996

Mario was a bit of a two edged sword for us. First of all, the attention it garnered helped force us into the limelight. Sega was engaged in the slow process of killing themselves with bad decisions and bad products, and so Sony and Nintendo found themselves head to head. This literally put Crash and Mario into the ring together. In fact, this was depicted on the cover of at least one game magazine (along with Sonic who declined to enter the ring).

In any case, since Crash released about a month after Mario the press often assumed that we had copied various elements, which always bugged us to no end, as both games were developed with no real knowledge of each other. Crash was nearly beta by the time we saw Mario at E3, and gold mastered by the time the N64 shipped and we could play it. Both games took very different approaches to the then unproven 3D CAG genre.

With Crash we decided to emphasize detailed cartoon visuals and classic Donkey Kong Style gameplay. So we used a camera on rails (albeit branching rails).

With the N64’s VERY limited texture system and poly count, but with its smoothing and z-buffer, Mario chose to go with a very loosely defined polygonal free roaming world and a much more playground style of gameplay.

Mark & I watch Miyamoto play Crash

Personally when I first got my hands on Mario I was like WTF? How is anyone going to know what to do here? And although there was a pretty real sense of marvel in this funny new world, I never found it very fun. The early camera AI was brutally frustrating. And the Mario voiceover. I still cringe, “It’sa me, Mario!” Still the game was brilliantly innovative, although I remain convinced that if anyone but Miyamoto had made the game it would have flopped.

Really, the future lay in the hybrid of the two.

Critics loved Mario. Perhaps because many of them were Nintendo fan boys, perhaps because it was more innovative (and it was). But the players loved both, because they sure bought a LOT of Crash Bandicoots too, approximately 35-40 million of our four PS1 games.

In a lot of ways Crash was the last of the great video game mascot characters, despite the fact that Sony never really wanted a mascot. We set out to fill this void, and made a game to do it, but we never really expected – only hoped – that it would happen. By the era of PS2 and X-box, the youthful generation of video game players had grown up, and the platforms began to appeal to a much wider age range. With this, and increased graphics horsepower that made possible more realistic games, came a shift to more mature subjects. The era of GTA, of Modern Warfare and Halo. Sophisticated and dark games mirroring R-rated action movies.

A part of me misses the simple, but highly crafted comic fun Crash represented.

 

Jason says:

 

There were so many great stories from Crash Development.  I’m sad that this is the last of 6 blog posts.  There is so much that has been missed.

One of my favorite memories relates to the collision detection.  Crash had more detailed environments than most games had attempted at that point, and there was no known solution for such complex collision detection in games.  Even after Crash came out, most developers just let their characters wade through most objects, and stuck to simple flat surfaces, but we wanted the character and the world to interact in a much more detailed fashion.

Andy and Dave called one of their friends at the Media Lab at MIT.  Basically, the Media lab worked on state of the art visual and computing problems.  They were, and still are, some of the most advanced in the world.  They asked their friend what high detail collision detection solutions were kicking around at that time.

The next day the friend called back and said he had the perfect solution.  Unfortunately, it demanded a Cray Supercomputer and hundreds (thousands?) of PlayStations worth of memory to work in real-time.

Andy and Dave hung up and started to come up with something on their own.

Naming Crash was one of the hardest things I have ever had to take part in.  It became so confused, so frustrating, so combative, and so tiring that I remember starting to think that Willie Wombat sounded good!

Credit goes to Taylor and Dave for combining Crash and Bandicoot for the first time.

If Andy and I deserve credit for anything name related, it is for viciously defending our character from the ravages of the Universal Marketing Death Squad.  I remember the name mooted by Universal to be Wez or Wezzy Wombat, but as I said things were very confused, and frankly it doesn’t matter what the alternate name was.

When Universal stated that as producer and they were going to pick the name, Andy and I walked the entire team (all 7 of us!) into the head of Universal Interactive’s office and said, “either we go with ‘Crash Bandicoot’, or you can name the game whatever you want and finish the development yourself.”

I think the result is obvious.

This was not the only time this tactic had to be used with Universal.  With all the “everyone grab your stuff and head to the office at the other end of the hall” moments, I don’t know how we even finished the game.

But we didn’t win every battle.  Crash’s girlfriend Tawna ended up on the chopping block after Crash 1.  We tried to choose our battles wisely.  Unlike the name “Crash Bandicoot”, Tawna wasn’t worth fighting for.

There was so much negativity and dispute with Universal Interactive that it is a miracle it didn’t scupper the game.

For example, Naughty Dog was told that it wasn’t “allowed” to go to the first E3.  This was part of a continuing attempt by Universal Interactive to take credit for the product.  It might have worked if Universal were parents and Naughty Dog was their six year old child, but we were an independent company working under contract.  Nobody was going to tell us what we could or couldn’t do.

There were also some leaked copies of the temporary box cover and press materials for E3, upon which Naughty Dog’s logo had “mysteriously,” and in direct conflict with the letter and spirit of our contract, been forgotten.

My response to both was to draft and print 1000 copies of a glitzy document entitled “Naughty Dog, creator and developer of Crash Bandicoot” ostensibly to hand out in front of the Crash display at E3.  As a “courtesy” I to passed these flyers out “for review” to Universal Interactive beforehand.

The head of Universal Interactive came as close to literally flipping his lid as a person can come.  He stormed into Andy’s office, made some extremely threatening comments, and then promptly went off to a shooting range in order to produce a bullet-riddled target to hang on his office door.

Things did get heated from time to time.

And just for the record, kudos to Mark for surviving all the hassle.  He was an employee of Universal Interactive yet completely uninvolved in any chicanery.  And as I’ve said before, he was always the Nth Dog, so times like these were harder on him than anyone else.

But all this is keeping us from discussing E3!

Ah the big show…

Sony booted one of its own internal products to give Crash the prime spot on the floor.  Walking in and seeing dozens of monitors playing the game was a moment I will never forget.

But I don’t think Andy and I had spent more than a moment looking at our triumph before we went off to fight the hoards at the Mario 64 consoles over at Nintendo’s booth for a chance on the controller.  As amazing as it was seeing our wall of monitors, seeing the lines for Mario made my heart drop.  Could it be that good?

Unlike Andy, I actually think Mario 64 WAS that good.

Mario 64 was a better game than the first Crash Bandicoot.

Miyamoto-san was at the top of his game and we were just getting started.  Crash was our first platformer, remember, and thus it lacked many of the gameplay nuances that Mario had.

Mario 64’s controls and balance were just better.

And then there was our annoying way of making players earn continues.  This was a major mistake.  It makes players that need lives fail while boring players that don’t.  It is the opposite of good game balance.

We were already learning.  We had realized that if a novice player died a lot of times, we could give them an Aku Aku at the start of a round and they had a better chance to progress.  And we figured out that if you died a lot when running from the boulder, we could just slow the boulder down a little each time.  If you died too much a fruit crate would suddenly become a continue point.  Eventually everyone succeeded at Crash.

Our mantra became help weaker players without changing the game for the better players.

We called all this DDA, Dynamic Difficulty Adjustment, and at the time the extent to which we did it was pretty novel.  It would lead later Crash games to be the inclusive, perfectly balanced games they became.   Good player, bad player, everyone loved Crash games.  They never realized it is because they were all playing a slightly different game, balanced for their specific needs.

But for all of our triumphant balancing attempts, we still made many mistakes in the first title.

Miyamoto-san didn’t make these mistakes.  3D Gameplay choice and art aside, Mario 64 was a better game.

And that isn’t to say that we didn’t have some serious advantages of our own.

For example, Crash looked better.  I am sure there will be disagreement with this statement.  But when 100 people were lined up and asked which looked more “next generation” (a term like ‘tomorrow’ that is always just over the horizon), most people pointed to Crash.

If I had to guess what Miyamoto-san was thinking when he was playing Crash in the photo above it was probably “damn this game looks good.”

Of course he had consciously made the decision to forgo the complex worlds Crash contained.  The N64 had prettier polygons, but less of them to offer.  Crash Bandicoot could not be made on the N64.  Of course Mario 64 couldn’t be done on the PlayStation either.  The PlayStation sucked at big polygons, specifically scissoring them without warping textures.  Mario 64 relied on big polygons.

But more fundamentally, the open world he chose would tax ANY system out at that time.   Mario 64 couldn’t be open and any more detailed than it was.  Miyamoto-san had chosen open and that meant simple.

Spyro later split the difference with walled open worlds, but at E3 1996 there was only the choice between the complex visuals of Crash, or the crayon simple expansive simplicity of Mario 64.

Yes, Crash was a throwback to old games and on “rails”.  But Mario 64 just didn’t look (as much) like a Pixar movie.  That created space for an argument, and thus one of the great wars between games, and by proxy consoles, could be fought.

I believe, right or wrong, that Crash won that comparison when it got to the shelves.

And this was just the beginning.

Unlike Miyamoto-san, Naughty Dog was willing to forgo the light of day to bring out a sequel to Crash Bandicoot one year later in September 1997.  By comparison, there wouldn’t be another Mario platformer until “Mario Sunshine” in 2002.

We took what we had learned from Crash 1, and from Mario 64 for that matter, and went back to the drawing board.   Crash 2 was re-built from the ground up.  Everything was improved.  But most importantly we focused on the gameplay.

Crash Bandicoot had taxed us to our limits.  Much of that time had been spent figuring out what the game would be, and then getting it working.

The second game could be built on the platform and successes of the first, but also from its mistakes.  The same would eventually true of Jak and Daxter, and, though I had no hand it the games, is probably true of Uncharted.  While Andy and I led Naughty Dog it had, and seems from outside to still have, a relentless pursuit of improvement.  That has meant historically that the second game in a series tends to be a better game.

Crash 2 would be a MUCH better game than Crash 1.  I would even argue that Crash 2 would end up being as good, if not better, than Mario 64.

But that is as story for another day.

This (sort of) continues with a virtual part 7 by Dave Baggett with his thoughts on Crash.

It also continues more literally with the tale of the European version of Crash.

If you liked this post, follow me at:

My novels: The Darkening Dream and Untimed
or the
video game post depot
or win Crash & Jak giveaways!

Latest hot post: War Stories: Crash Bandicoot

The Limited Edition Launch Poster

Related posts:

  1. Making Crash Bandicoot – part 1
  2. Making Crash Bandicoot – part 5
  3. Making Crash Bandicoot – part 3
  4. Making Crash Bandicoot – part 2
  5. Making Crash Bandicoot – part 4
By: agavin
Comments (391)
Posted in: Games
Tagged as: Andy Gavin, Characters of Crash Bandicoot, Crash Bandicoot, E3, Games, Jason Rubin, Josh Mancell, Mario, Mario 64, Mark Mothersbaugh, Miyamoto, Mutato Muzika, N64, Naughty Dog, Playstation, pt_crash_history, Video game, Video Game Design

Making Crash Bandicoot – part 5

Feb06

PREVIOUS installment, or the FIRST POST.

 

A Bandicoot, his beach, and his crates

But even once the core gameplay worked, these cool levels were missing something. We’d spent so many polygons on our detailed backgrounds and “realistic” cartoon characters that the enemies weren’t that dense, so everything felt a bit empty.

We’d created the wumpa fruit pickup (carefully rendered in 3D into a series of textures — burning a big chunk of our vram — but allowing us to have lots of them on screen), and they were okay, but not super exciting.

Enter the crates. One Saturday, January 1996, while Jason and I were driving to work (we worked 7 days a week, from approximately 10am to 4am – no one said video game making was easy). We knew we needed something else, and we knew it had to be low polygon, and ideally, multiple types of them could be combined to interesting effect. We’d been thinking about the objects in various puzzle games.

So crates. How much lower poly could you get? Crates could hold stuff. They could explode, they could bounce or drop, they could stack, they could be used as switches to trigger other things. Perfect.

So that Saturday we scrapped whatever else we had planned to do and I coded the crates while Jason modeled a few, an explosion, and drew some quick textures.

About six hours later we had the basic palate of Crash 1 crates going. Normal, life crate, random crate, continue crate, bouncy crate, TNT crate, invisible crate, switch crate. The stacking logic that let them fall down on each other, or even bounce on each other. They were awesome. And smashing them was so much fun.

Over the next few days we threw crates into the levels with abandon, and formally dull spots with nothing to do became great fun. Plus, in typical game fashion tempting crates could be combined with in game menaces for added gameplay advantage. We even used them as the basis for our bonus levels (see above video). We also kept working on the feel and effects of crate smashing and pickup collection. I coded them again and again, going for a pinball machine like ringing up of the score. One of the best things about the crates is that you could smash a bunch, slurp up the contents, and 5-10 seconds later the wumpa and one-ups would still be ringing out.

This was all sold by the sound effects, executed by Mike Gollom for Crash 1-3. He managed to dig up the zaniest and best sounds. The wumpa slurp and the cha-ching of the one up are priceless. As one of our Crash 2 programmers used to say, “the sounds make the game look better.”

For some reason, years later, when we got around to Jak & Daxter we dropped the crate concept as “childish,” while our friends and amiable competitors at Insomniac Games borrowed them over into Ratchet & Clank. They remained a great source of cheap fun, and I scratch my head at the decision to move on.

Now, winter 95-96 the game was looking very cool, albeit very much a work-in-progress. The combination of our pre-calculation, high resolution, high poly-count, and 30 fps animation gave it a completely unique look on the machine. So much so that many viewers thought it a trick. But we had kept the whole project pretty under wraps. One of the dirty secrets of the Sony “developer contract” was that unlike its more common “publisher” cousin, it didn’t require presentation to Sony during development, as they assumed we’d eventually have to get a publisher. Around Thanksgiving 1995, I and one of our artists, Taylor Kurosaki, who had a TV editing background, took footage from the game and spent two days editing it into a 2 minute “preview tape.” We deliberately leaked this to a friend at Sony so that the brass would see it.

They liked what they saw.

Management shakeups at Sony slowed the process, but by March of 1996 Sony and Universal had struck a deal for Sony to do the publishing. While Sony never officially declared us their mascot, in all practical senses we became one. Heading into the 1996 E3 (May/June) we at Naughty Dog were working ourselves into oblivion to get the whole game presentable. Rumors going into E3 spoke of Nintendo’s new machine, the misleadingly named N64 (it’s really 32 bit) and Miyamoto’s terrifying competitive shadow, Mario 64.

Crash and his girl make a getaway

For two years we had been carefully studying every 3D character game. Hell, we’d been pouring over even the slightest rumor – hotly debated at the 3am deli takeout diners. Fortunately for us, they’d all sucked. Really sucked. Does anyone remember Floating Runner? But Mario, that wasn’t going to suck. However, before E3 1996 all we saw were a couple of screen shots – and that only a few weeks before. Crash was pretty much done. Well, at least we thought so.

Now, we had seen some juicy magazine articles on Tomb Raider, but we really didn’t worry much about that because it was such a different kind of game: a Raiders of the Lost Ark type adventure game starring a chick with guns. Cool, but different. We’d made a cartoon action CAG aimed at the huge “everybody including kids” market.

Mario  was our competition.

 

Jason says:

 

The empty space had plagued us for a long time.  We couldn’t have too many enemies on screen at the same time.  Even though the skunks or turtles were only 50-100 polygons each, we could show two or three at most.  The rest was spent on Crash and the Background.  Two or three skunks was fine for a challenge, but it meant the next challenge either had to be part of the background, like a pit, or far away.  If two skunk challenges came back to back there was a huge amount of boring ground to cover between them.

Enter the crates.   The Crates weren’t put in to Crash until just before Alpha, or the first “fully playable” version of the game.

Andy must have programmed the “Dynamite Crate/Crate/Dynamite Crate” puzzle 1000 times to get it right.  It is just hard enough to spin the middle crate out without blowing up the other two, but not hard enough not to make it worth trying for a few wumpa fruit.  Getting someone to risk a Life for 1/20th of a Life is a fine balancing act!

Eventually the Crates led to Crash’s name.  In less than a month after we put them in everyone realized that they were the heart of the game.  Crash’s crash through them not only filled up the empty spots, the challenges ended up filling time between Crate challenges!

This isn’t the place for an in depth retelling of the intrigue behind the Sony/Crash relationship, but two stories must be told.

The first is Sony’s first viewing of Crash in person.  Kelly Flock was the first Sony employee to see Crash live [ Andy NOTE: running, not on videotape ].  He was sent, I think, to see if our videotape was faked!

Kelly is a smart guy, and a good game critic, but he had a lot more to worry about than just gameplay.  For example, whether Crash was physically good for the hardware!

Andy had given Kelly a rough idea of how we were getting so much detail through the system: spooling.  Kelly asked Andy if he understood correctly that any move forward or backward in a level entailed loading in new data, a CD “hit.”  Andy proudly stated that indeed it did.  Kelly asked how many of these CD hits Andy thought a gamer that finished Crash would have.  Andy did some thinking and off the top of his head said “Roughly 120,000.”  Kelly became very silent for a moment and then quietly mumbled “the PlayStation CD drive is ‘rated’ for 70,000.”

Kelly thought some more and said “let’s not mention that to anyone” and went back to get Sony on board with Crash.

The second story that can’t be glossed over was our first meeting with the Sony executives from Japan.  Up until this point, we had only dealt with Sony America, who got Crash’s “vibe”.  But the Japanese were not so sure.

We had been handed a document that compared Crash with Mario and Nights, or at least what was known of the games at the time.  Though Crash was rated favorably in “graphics” and some other categories, two things stood out as weaknesses.  The first was that Sony Japan didn’t like the character much, and the second was a column titled “heritage” that listed Mario and Sonic as “Japanese” and Crash as “other.”  The two negatives were related.

Let us remember that in 1995 there was Japan, and then there was the rest of the world in video games.  Japan dominated the development of the best games and all the hardware.  It is fair to say that absent any other information, the Japanese game WAS probably the better one.

Mark presided over the meeting with the executives.  He not only spoke Japanese, but also was very well respected for his work on Sonic 2 and for his years at Sega in Japan.  I could see from the look in Mark’s eyes that our renderings of Crash, made specifically for the meeting, did not impress them.

We took a break, during which it was clear that Sony was interested in Crash for the US alone, hardly a “mascot” crowning.  I stared at the images we had done.  Primitive by today’s standards, but back then they were reasonably sexy renderings that had been hand retouched by Charlotte for most of the previous 48 hours.  She was fried.

I walked over to her.  I think she could barely hold her eyes open.  I had spent the previous month spending all of my free time (4am-10am) studying Anime and Manga.  I read all the books available at that time in English on the subject.  All three!  I also watched dozens of movies.  I looked at competitive characters in the video game space.  I obsessed, but I obsessed from America.  I had never been to Japan.

I asked Charlotte if she could close Crash’s huge smiling mouth making him seem less aggressive.   I asked her to change Crash’s eyes from green to two small black “pac-man” shapes.  And I asked her to make Crash’s spike smaller.  And I told her she had less than 15 minutes.  With what must have been her last energy she banged it out.

I held up the resulting printout 15 minutes later.

Sony Japan bought off on Crash for the international market.

I don’t want to make the decision on their part seem arbitrary.  Naughty Dog would do a huge amount of work after this on the game for Japan, and even then we would always release a Japanese specific build.  Whether it was giving Aku Aku pop up text instructions, or replace a Crash smashing “death” that reminded them of the severed head and shoes left by a serial killer that was loose in Japan during Crash 2’s release, we focused on Japan and fought hard for acceptance and success.

We relied on our Japanese producers, including Shuhei Yoshida, who was assigned shortly after this meeting, to help us overcome our understandable ignorance of what would work in Japan.  And Sony Japan’s marketing department basically built their own Crash from the ground up for the marketing push.

Maybe Charlotte’s changes showed Sony that there was a glimmer of hope for Crash in Japan.  Maybe they just saw how desperate we were to please and couldn’t say no.  Maybe Universal put something in the coffee they had during the break.

Who knows, but Crash was now a big part of the international PlayStation push.  So there were more important things for us to worry about then Sony and the deal:

The fear of Miyamoto was thick at Naughty Dog during the entire Crash development period.  We knew eventually he would come out with another Mario, but we were hoping, praying even, that it would be a year after we launched.

Unfortunately that was not to be.  We started seeing leaks of video of the game.

It was immediately obvious that it was a different type of game: truly open.  That scared us.  But when we saw the graphics we couldn’t believe it.  I know there will be some that take this as heresy, but when we saw the blocky, simple, open world we breathed a sign of relief.  I think I called it I Robot Mario, evoking the first 3D game.

Of course we hadn’t played it, so we knew we couldn’t pass judgment until we did.  That would happen at E3.


CONTINUED in PART 6 or

If you liked this post, follow me at:

My novels: The Darkening Dream and Untimed
or the
video game post depot
or win Crash & Jak giveaways!

Latest hot post: War Stories: Crash Bandicoot

The Big Fight!

Related posts:

  1. Making Crash Bandicoot – part 1
  2. Making Crash Bandicoot – part 2
  3. Making Crash Bandicoot – part 4
  4. Making Crash Bandicoot – part 3
  5. How do I get a job designing video games?
By: agavin
Comments (113)
Posted in: Games
Tagged as: Andy Gavin, Crash Bandicoot, game, Game design, Games, Insomniac Games, Jason Rubin, Mike Gollom, Naughty Dog, Platform, pt_crash_history, Raiders of the Lost Ark, Sony, Taylor Kurosaki, Video game, Video Games

Making Crash Bandicoot – part 4

Feb05

PREVIOUS installment, or the FIRST POST.

[ NOTE, Jason Rubin added his thoughts to all the parts now, so if you missed that, back up and read the second half of each. ]

 

But this brings us to the gameplay. We were forging new ground here, causing a lot of growing pains. I started fairly programming the control of the main character early. This is the single most important thing in a CAG, and while intellectually I knew this from Way of the Warrior, it was really Mark who drove the message home. I did all the programming, but Mark helped a lot with the complaining. For example, “he doesn’t stop fast enough,” or “he needs to be able to jump for a frame or two AFTER he’s run off a cliff or it will be frustrating.” Jason’s also really good flaw detection. Which is a good thing. Internal criticism is essential, and as a programmer who wrote dozens of world class control schemes in the years between 1994 and 2004, I rewrote every one at least five or six times. Iteration is king.

Even after the control was decent, we still had no idea how to build good 3D gameplay with it. Our first two test levels “the jungle, level1” and “lava cave, level2” were abysmal, and neither shipped in the final game. First of all, they were too open with way too many polygons. Level1 had over 10 million, whereas a shipping level tended to have around a million (a lot back then). Level2 was better, but not much.

So during the summer of 1995 we retrenched and tried to figure out how to make a level that was actually fun. The F word is the most important concept in making games. Too many forget this.

But Mark – who served the practical function of producer – never let us.

By this time most of the art design for the game was complete, including the vast layout of possible looks and levels, but we skipped to about 2/3 through and used Cortex’s factory levels to really focus on fun. Our first successful level was essentially 2D (“Heavy Machinery”). It was all rendered in 3D, but the camera watched from the side like a traditional platformer. Here we combined some classic devices like steam vents, drop platforms, bouncy pads, hot pipes, and monsters that tracked back and forth in simple patterns. This was in essence a retreat to success, as it employed the basic kind of techniques that Donkey Kong Country had used so successfully. This palate of objects would be arranged in increasingly more difficult combination.

It worked. Thank God.

Simultaneously, we were working on a more ambitious level where the camera sat above and “Willie” walked both into/out and side to side (“Generator Room”). This factory level included drop platforms, moving platforms, dangerous pipes, and various robots. By using a more mechanical setting, and briefly forgoing the complex organic forest designs we were able to distill this two axis gameplay and make it fun. In both areas we had to refine “Willie’s” jumping, spinning, and bonking mechanics.

We then got our third type of level working (“Cortex Power”). This involved having the camera behind the character, over his shoulder, in the original “Sonic’s ass” POV that had faired miserably with level1 and level2. By taking some of the new creatures and mechanics, and combining them with hot pipes and slime pits we were able to make it work in this more factory-like setting.

Having learned these lessons, we turned back to the jungle design with a new jungle level, known as “levelc” (“Jungle Rollers”). This used some of the pieces from the failed level1, but arranged as a corridor between the trees, much like the over-the-shoulder factory level. Here we utilized pits, skunks on paths, stationary plants, and rollers to create the palate of obstacles. With this level the into-the-screen gameplay really came into its own, and it remains one of my favorite levels. Each element served its purpose.

Rollers (big stone wheels that could crush the player, and rolled from side to side) provided timing gates. They could be doubled or tripled up for more challenge.

Skunks traveled down the path tracking back and forth toward the player, requiring him to attack them or jump over them.

Fallen logs, tikis, and pits needed to be jumped over.

Stationary plants could strike at the player, requiring one to tease them into a strike, then jump on their heads.

Once we had these three level types going things really begun to get on a roll. For each level art design, like jungle, we would typically do 2-3 levels, the first with the introductory set of challenges, and then the later ones adding in a few new twists combined at much harder difficulty. For example in the sequel to the jungle level we added drop platforms and moving platforms. The elements combined with the characters mechanics to form the fun.

It’s also worth noting that we stumbled onto a few of our weirder (and most popular) level designs as variants of the over-the-shoulder. First “Boulders,” aping that moment from Raiders of the Lost Ark when the giant stone ball starts rolling toward Indy. For this we reversed the action and had the character run into the screen. This proved so successful that we riffed on it again in Crash 2 and 3. Same with “Hog Wild,” in which the character jumps on the bag of a wild “hog ride” and is dragged at high speed through a frenetic series of obstacles.

Jason says:

 

Making games is no game.  So many aspiring designers think that all you do is come up with a great idea and the sit around and play.  That may be true if you are aping something that exists, like making just another first person shooter (this time in ancient Sumeria and with Demon Aliens!), or making something small and easy to iterate, but it is certainly NOT true when you are trying something new in the AAA space.

And to make matters worse, the LAST person who can attest to a good game design is the game designer.  Not only do they know what to do when they test it, but they are also predisposed to like it.

Oh no, the proper test is to hand it to a complete noob, in Crash’s case the ever rotating list of secretaries and clerical staff that worked at Universal.   For many of them it was their first time touching a controller, and they succeeded immediately in failing, miserably, to get a single challenge passed.  As they smiled and tried to be positive they were saying “this sucks” with their hands.  Thus a good designer has to both dread and seeks out other people’s advice, especially those most likely to hate the work he has done.  And the designer has to accept the third party opinion over theirs.  Every time.  Only when the noobs start completing challenges and smile WHILE PLAYING do you know you are getting somewhere.

I don’t know why, but I have always had an innate ability to see the flaws in my own projects, even after they are “final” in everyone else’s eyes.   Naughty Dog graphic engine coder Greg Omi, who joined for Crash 2, once said I could spot a single pixel flicker on his monitor at 30 yards while holding a conversation with someone else and facing the opposite direction.  Whatever it is, I get a weird frustrated sweat when I see something wrong.  Mark Cerny has the same “talent.”

The two of us were always unhappy with the gameplay.  I don’t mean just the early gameplay, I mean always unhappy with the gameplay, period.  I know in retrospect that I was to hard on the team quite often because of this, and that perhaps more often than not I was too poignant when voicing my frustration (letting myself off easy here!), but I think a certain amount of frustration and pain is inherent in making gameplay success.

Stripping the game down to familiar 2D, and then building from there to levels that contained only platforms floating in space was the crutch we used to get to the jungle levels that made Crash such a success.  In the end, these levels aren’t that different in gameplay design.  But starting with the Jungle was too big a leap.  We needed simple.  Upon simple we built complex.

Andy has done a good job of compressing a year of design hell into a blog-sized chunk.  With all our technical and art successes, the game could not have succeeded without good gameplay.  This was by far the hardest part of making Crash Bandicoot.

Dave and Andy’s code, Justin’s IT and coloring, Charlotte Francis’s textures, And Bob, Taylor and my backgrounds and characters would have been worth nothing if Crash hadn’t played well.

Jason, Andy, Dave, Bob, Taylor, Justin, Charlotte

CONTINUED in PART 5 or

If you liked this post, follow me at:

My novels: The Darkening Dream and Untimed
or the
video game post depot
or win Crash & Jak giveaways!

Latest hot post: War Stories: Crash Bandicoot

Related posts:

  1. Making Crash Bandicoot – part 1
  2. Making Crash Bandicoot – part 3
  3. Making Crash Bandicoot – part 2
  4. How do I get a job designing video games?
By: agavin
Comments (117)
Posted in: Games
Tagged as: action, Andy Gavin, Character Action Games, Crash Bandicoot, Crash Bandicoot 2: Cortex Strikes Back, Donkey Kong Country, game, Gameplay, Games, Jason Rubin, Level design, Protagonist, pt_crash_history, Raiders of the Lost Ark, Video game, Video Games, Way of the Warrior

Making Crash Bandicoot – part 3

Feb04

PREVIOUS installment, or the FIRST POST.

Crash in the Jungle

While all this art design was going on, I, and then in January 1995, Dave, struggled to build an engine and tool pipeline that would make it possible to render these grandiose cartoon worlds we had envisioned on paper. Since during fall of 1994 Jason was also the only artist, he frantically generated all the source material and banged on my head to make sure it would look incredible.

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

The Playstation had this oddball 512×240 video mode that everyone else ignored, it wasn’t standard (320×240) and ate up video memory others wanted for textures. But it looked SHARP and we found the machine was really good at rendering shaded, but un-textured, triangles. In fact, just as fast in the 512 mode as 320. Jason pointed out — he’s always been the master of seeing the intersection between art and tech — that since polygons on 3D characters our size were just a few pixels, shaded characters actually looked better than textured ones. So we went with more polys on the characters, less texture. This was a highly usual approach, but had lots of advantages. The characters popped, like cartoons are supposed to, we had lots more polygons to work with, and it worked around the Playstation’s lack of texture correction or polygon clipping.

Since the soul of good Animation, is…. drum roll please… animation! We were obsessed with making ours look like that really good Disney or Looney Tunes stuff. In those days, most people used a simple skeleton system with “1 joint” weighting, and very few bones. This gives a very stiff look, so we went instead with vertex animation. This allowed us to use the more sophisticated 3-4 joint weighting available in PowerAnimator, which the Playstation had no hope of matching at runtime (until the PS2), instead we stored the location of every vertex, every frame at 30 frames a second. No one else had the guts, as while this was easy to render, it required inventing some totally hardcore assembly language vertex compressors. First me (three times), then Dave (twice), then finally Mark took a crack at it. Mark’s was the best — being the best assembly programmer of us three — but also the most complicated.

Complexity became the name of the game at Naughty Dog.

We also wanted vast and detailed worlds. Dave, Jason, and I had done a bunch of research “post Doom” on visibility calculation. And Dave and I were convinced that extensive pre-calculation of visibility could allow the renderer to handle A LOT more polygons. So we did experiments in free roaming camera control and settled on branching rail camera + pre-calculation = gorgeous visuals.

The Evolve-o-Ray

The idea was that the camera would follow along next to, behind, or in front of the character, generally looking at him, moving on a “track” through the world. Dave and I experimented with pre-calculating the visibility and sort (the Playstation had no z-buffer, and hence no easy way to sort polygons) ahead of time on the SGI workstations the artists used. Although painful and expensive, this worked really well. As long as you could never SEE more than a set number of polygons (800 for Crash 1, 1300 for Crash 2 or 3) from any given position we could have perfect occlusion and sort, with no runtime cost. We conceived of using trees, cliffs, walls, and twists and turns in the environment to hide a lot of the landscape from view – but it would be there, just around the corner.

So we decided to use an entirely SGI and IRIX based tool pipeline. In fact the game itself even ran on the SGI (with terrible keyboard control). This meant buying programmers $100,000 SGIs instead of $3,000 PCs. Gulp again. No one else did this. No one. And at the time, when a 50mhz Pentium with 8-32 megs of RAM was typical, our 250mhz 64 bit SGIs with 256 or 512 megs of RAM opened up totally different computational possibilities. By 1997 I had 4 gigs of ram in my machine! Of course some of those computational possibilities were so brutal that I had to code tools to distribute the calculations out to the video hardware, and chop it up onto all the office machines, where processing could be done in parallel 24 hours a day. Levels often took several hours to process on our 5-8 machine farm!

This was not easy in 1995!

I also concocted a crazy algorithmic texture packer that would deal with the fact that our gorgeous 512×240 mode left us with too little texture memory. And the even crazier – way crazier – virtual memory system required to shoehorn the 8-16 meg levels the artists created into the Playstation’s little 2megs of RAM. Dave meanwhile had to invent insane bidirectional 10x compressors to help get the 128meg levels down into 12, and figure out some tool for managing the construction of our gigantic 3D worlds.

Our levels were so big, that our first test level, which never shipped and was creatively named “level1” or “the jungle,” couldn’t be loaded into Alias PowerAnimator even on a machine with 256megs. In fact, it had to be cut up into 16 chunks, and even then each chunk took 10 minutes to load!

So Dave created a level design tool where component parts were entered into a text file, and then a series of 10-15 Photoshop layers indicated how the parts were combined. The tool, known as the DLE, would build each chunk of the level and save it out. Artists tweaked their photoshop and text files, ran the tool, then loaded up chunks to look for errors. Or they might let the errors pass through the 8 hour level processing tool, there to possibly pick up or interact with new (or old) programmer bugs. If one was lucky, the result wouldn’t crash the Playstation.

But the craziest thing I did was create a new programming language – with Lisp syntax – for coding all of the gameplay. It had all sorts of built in state machine support (very useful with game objects), powerful macros, dynamic loading etc. It was also highly irregular and idiosyncratic, and in true Naughty Dog fashion “powerful but complicated.”

 

Jason says:

 

The secret to Crash’s success was its Art.  And the secret to its Art was its Programming. [ Andy NOTE: well, and the F-word ]

Andy and Dave broke a lot of rules.  First and foremost, they didn’t follow PlayStation’s library restrictions.  Other developers often complained that Crash was using some sort of secret Sony library.  That is the exact opposite of the truth.  The truth is that Crash used as little as it could of Sony’s library and the programmers basically hacked everything right to the hardware.

Years later Sony tried to create a game called Harry Jalapeño to compete with Crash.  No, I am not making that up.  Besides the name fail, the internal team in San Francisco also utterly failed to create the complex worlds and characters that we created in Crash.  Let me repeat – an internal Sony team couldn’t create Crash.  Let the rumors of “insider information” forever rest.

Hitting the hardware directly was against the rules.  But by the time Sony saw the results they needed a Mario killer.  It was too late for them to complain.

It is easy to underestimate the value of the pre-occlusion and vertex animation hacks.  But let me tell you, this was everything.

The occlusion meant more polygons in the background, and more polygons meant we could do the levels.  Without it we NEVER could have made the world look as good as it did.

Our occlusion worked on a texture level.  That is, if we had a giant polygon with a fern texture on it (think many leaves but lots of empty space) the occlusion could actually get rid of polygons behind the leaf part of the texture but leave the polygons seen through the alpha channel holes.  No other game had that kind of detail in occlusion, and it paid off immensely. Given how small ground polygons could be in the distance, a little fern action went a long way.

We were up against the polygon draw limit at every twist and turn in the game.  We wanted to have as much distance and detail visible as possible, but the minute we went over that limit the game started getting “hitchy.”  We’d build a level over night (really 4am-11am, the only times the office was ever empty) and come in to see the results.  Wherever we had too many polygons we’d add some leaves or whatever to occlude some distance.  Wherever there were more polygons available to draw we’d pull leaves out.

And remember, more foreground (boxes, enemies, platforms) meant we had to have less background.  So just when you had a level perfectly balanced, someone (usually me or Mark) would determine that the level was too hard or easy and we’d have to add a platform or enemy and the level builder (usually Bob Rafei or Taylor Kurosaki) would have to start balancing the background poly count over again.  It was so cruel.

We couldn’t see the result of any change for at least 12 hours, so if we made a mistake we’d make a tweak and then we’d have to repeat the process.   No level was “done” till the game shipped.

Crash was 512 polygons in the first game, with textures only for his spots and his shoelaces, and his model didn’t change much through the 3 platform titles.  It took me a month to settle on the perfect 512.   As Andy said, we went with non-textured polygons instead of textured ones on most of the characters.  Instead of texture, we used corner colors to create the textures that seemed to be there.

There were many advantages to this strategy.  The simplest was that we got more polygons.  But we also solved a texture stretching and warping issue inherent in the PlayStation’s renderer that tended to make textures look terrible.  Since you spent most of your time looking at the character, and he could get quite close to the camera, avoiding texture mess meant a lot for visual quality.

And there was another important issue solved by using polygons instead of textures.  The PlayStation tended to render every polygon as a pixel, no matter how small it got.  Had Crash’s pupils been texture, they might have disappeared when the got smaller than a pixel.  But by making the pupil 2 polygons (a quad), they almost always showed up as long as the total eye, including whites, was more than a few pixels tall.  Subtle, but trust me, it made the game so much more clean looking.  It’s the small things that matter.

The most important advantage of our character system was vertex animation.  I cannot imagine the torture that other game developers went through trying to bend the low polygon arms and legs of their characters using nothing but bone weighting!  When the bones failed for us, and they often did in a character with <1000 polygons, we just grabbed vertices and yanked them around until things were fixed.  This is why Crash doesn’t bend and fall apart when animating.  It meant more mobility and stretchability.

In some of the most stretched or bent poses, we just pulled vertices by hand and forgot the bones altogether, which brought us two additional abilities that nobody else had. [ Andy NOTE: this allowed the same animation techniques then at use at Pixar into our little effort ]

The first is that the characters in Crash had different facial expressions on every single frame.  Forget bones.  I just pulled the vertices until I had what I wanted.  It doesn’t sound like a big distinction, but I could go from a huge smile full of teeth to a whistle mouth that was toothless or no mouth at all just by collapsing vertices on top of each other to make zero volume polygons.   Thus Crash had a more expressive face than any other character had ever had before, and this created emotion that gamers hadn’t felt before.

It was that opening sequence, when Crash pulls his flat face out of the sand, shakes it off, looks confused, leaps up, looks at the camera and does his great big goofy smile that SOLD Crash as a character.  No 2d game could afford the art, and no other 3d game had the facial animation that our vertex system brought.  And thus the main character transformed from emotionless “vehicles” to an emotive friend.

Before Crash characters had no emotion (Pacman, and even Mario), or one dimensional emotions (Sonic was “fast”).  Crash had facial emotions that let him speak to you and gave him personal range.  Crash wasn’t any one emotion.  Crash was Crash.  For example, you could see Crash acting like a mime.  Sonic and Mario weren’t capable expressing even a mimes range of emotion until after Crash came out.  “Itsa me, Mario” just doesn’t cut it, especially when Mario’s face didn’t even animate as he said it!!

Of course it wouldn’t be until much later that the game industry got fully 3 dimensional characters, like Daxter, who had full personalities, and could go beyond mime and do, for example, a scene from Shakespeare, but in their very own way.  But that’s a story for another time. [ Andy NOTE: and when we got there we had to build a special “face engine” and “eye engine” to do it ]

The second thing that vertex animation allowed is total warping of the character beyond bones.  If I wanted Crash to become a balloon, I just animated a keyframe of him wrapped around a sphere (shoes and face usually un-stretched!) and the game tweened to it.  If I wanted to smash him flat into his shoes I just folded his legs and body up into his face and cleaned up the resulting frames as it went.   The animators were free to do anything, and we did.   Again, helped endear Crash as a character.

That made Crash’s characters feel more like the Loony Toons than the stiff 3d bone creatures of the day.  I still have a signed copy of Disney’s “The Illusion of Life,” by Frank Thomas and Ollie Johnson, two of the greatest animators of all time.  It’s dog-eared and beat up.  Bob, Taylor and I read it, absorbed it, and tried to live it.

Again, all this was only possible thanks to some incredibly crafty programming from Andy, Dave, and Mark.

CONTINUED HERE WITH PART 4 or

If you liked this post, follow me at:

My novels: The Darkening Dream and Untimed
or the
video game post depot
or win Crash & Jak giveaways!

Latest hot post: War Stories: Crash Bandicoot

Crash was never suave

Related posts:

  1. Making Crash Bandicoot – part 2
  2. Making Crash Bandicoot – part 1
By: agavin
Comments (123)
Posted in: Games
Tagged as: Andy Gavin, Animation, Crash Bandicoot, Crash Bandicoot (series), Dave Baggett, Games, Hardware, Jason Rubin, Looney Tunes, Playstation, PowerAnimator, pt_crash_history, SGI, Silicon Graphics, Video game, Video Games

Making Crash Bandicoot – part 2

Feb03

CONTINUED FROM PART 1 ABOVE.

So what was it that Sega and Nintendo had in 1994, but Sony didn’t?

An existing competing mascot character. Sega had Sonic and Nintendo had Mario (even if the N64 was just a rumor at that point). But Sony product slate was blank.

So we set about creating a mascot on the theory that maybe, just maybe, we might be able to slide into that opening. I’m still surprised it worked.

The first real Crash

Next we had to find a creature to hang our hopes on. We wanted to do what Sega had done with the hedgehog and Warner Bros had done with the Tasmanian Devil and find some kind of animal that was cute, real, and no one really knew about. We bought a copy of “Tasmanian Mammals – a field guide” and flipped through. The Wombat, Potoroo, and Bandicoot fit the bill. For the meantime we went with Willie the Wombat, as both Jason and I like alliteration. We never considered it a real name as it was too dorky. And just a month or so later someone told us about some other non-game property with the same name, so it remained a working title. By October 1994 the character was a Bandicoot as far as we were concerned.  We loved the word, but we kept calling him Willie, and the game Willie the Wombat until spring of 1996. It wasn’t really worth it to sort out a final name – some marketing department would probably change it anyway.

In September and October of 1994 we were busy trying to figure out who this Willie guy was. We felt he should be goofy and fun loving, and never talk — on the theory that voices for video game characters were always lame, negative, and distracted from identification with them.

But the villain gelled faster than the hero.

Dr. Neo Cortex — pissed

I remember it clearly. The four of us were eating at this mediocre Italian near Universal and I had this idea of an evil genius villain with a big head. Obviously brainy cartoon villains have big heads. He was all about his attitude and his minions. Video games need lots of minions. Jason had become very fond of Pinky and the Brain and we imagined a more malevolent Brain with minions like the weasels in Who Framed Roger Rabbit. A villain, all full of himself, unable to conceive of ever doing anything the simple way, but constantly (in his eyes) betrayed by the incompetence of his henchmen.

I put on my silly villain voice and intoned, “If you had three neurons between you, you couldn’t make a triangle!” With this attitude, his name, Doctor Neo Cortex, popped instantly into our heads.

For “Willie” was to be – in our minds – a game that tried to combine the game play of Mario or Donkey Kong Country with the animation and cartoon sensibility of a Looney Tunes or Tex Avery cartoon.

To that effect, we took the very unusual step of hiring real “Hollywood” cartoon designers to help with the visual part of the production. This was Mark’s idea at first, although Jason and I saw the brilliance of it immediately. In those days we were enamored with the idea blending the best of Hollywood into game making – creative synergy if you will. In the long run, we would be disabused of much of the synergy notion. However, production design, sound design, voice acting, and later motion capture, were to be the areas in which Hollywood resources proved valuable to video game teams.

A Crash that wasn’t

The guys we brought on were Charles Zembillas and Joe Pearson. Charles was principally character, and Joe background. These two were instrumental in developing the look of Crash Bandicoot, particularly prior to us hiring Bob Rafei in January 1995. Bob was an extremely talented young artist who would eventually come to head the art design at Naughty Dog. But in 1994, what Charles and Joe did was provide the fleshing out, or visualization, of ideas pitched mostly by Jason, myself, or Mark. In essence, they translated into cartoon sensibility.

Charles in particular was a very fast sketch artist, with a real knack for capturing cartoon emotion. So we would just say things like, “Cortex has a huge head but a tiny body, he’s a mad scientist, and he dresses a bit like a Nazi from the Jetsons” and in 2 minutes he’d have a gray and blue pencil sketch. We might then say, “less hair, goofier, crazier” and he’d do another sketch. Repeat.

The jungle, concept

Joe did the same for the backgrounds, but as landscapes have more lines, on a slightly longer time scale. Given that “Willie” was Tasmanian we set him on a mysterious island where every possible kind of environment lurked. Evil geniuses like Dr. Cortex require island strongholds. So we had lots of environments to design. Jungles, power stations, creepy castles, evil natives, sunset temples, spooky caves, etc. At some point early on we hit on the “tiki” idea and thus: goofy Easter Island tikis everywhere.

 

Jason’s comments:

When we started designing Crash, or Willie as he was first known internally, we decided that there need be no connection between the real animal and the final design — hey, all mammals, uh marsupials.  A Wombat looks nothing like Crash.  He is closer to a Bandicoot, maybe, but that was pure luck.  Instead the design of the character was determined 51% by technical and visual necessity and 49% by inspiration.

A (very) partial list of the Necessities:

Why is Crash Orange?  Not because we liked it, but because it made the most sense.  First I created a list of popular characters and their colors.  Next I made a list of earthly background possibilities (forest, desert, beach, etc.) and then we strictly outlawed colors that didn’t look good on the screen.  Red, for example, tends to bleed horribly on old televisions.  At the time, everyone had old televisions, even if they were new!  Crash was orange because that was available.  There are no lava levels, a staple in character action games, because Crash is orange.  We made one in Demo, and that ended the lava debate.  It was not terribly dissimilar to trying to watch a black dog run in the yard on a moonless night.

Why is Crash’s face so large?  Because the resolution of the screen was so low.  Some people think we were inspired by the Tasmanian devil.  Perhaps, but it was the necessity of having features large enough to be discernable that caused us to push for the neckless look.  The move made it a little harder to turn his head, and created a very unique way of moving, but it let you see Crash’s facial expressions.  And that was to be very important.

Why does Crash have gloves, spots on his back, and a light colored chest?  Resolution, bad lighting models, and low polygon counts.  Those small additions let you quickly determine what part and rotation of Crash you were looking at based on color.  If you saw spots, it was his back.  Yellowish orange was the front.  As the hands and arms crossed the body during a run the orange tended to blend into muck.  But your eyes tracked the black gloves as they crossed Crash’s body and your mind filled in the rest.

We were wrestling with these design constraints the entire process.  Joe and Charles, with all their talent, were free to do anything that they could imagine on paper.  But Bob and I were the artists that eventually had to ground that back in the reality of calculator strapped to a TV that was the PlayStation 1.

Charles would hand us a sketch and we would start the math:  240 pixel high screen, character 1/6 to 1/4 of the screen height, character 40 to 60 pixels high, proposed hat 1/8 of height of Character, hat 5 to 6 pixels high, hat has stripes.  Striped hat won’t work because the stripes will be less than 1 pixel high.

Take the image Andy posted titled “A Crash that Wasn’t.”  I can tell you immediately that the tail and any kind of flappy strap was immediately shot down because it would have flickered on and off as the PlayStation failed to have pixels to show it.  And that little bit of ankle showing beneath the long pants would have been an annoying orange flicker every few frames around the bottom of his pants and shoes.  Shorter pants would have to prevail.  Crash did end up with a belly button, but it would be about 2x as big.

The first sketches of Crash as we know him

Charles would look at us like we were speaking Swahili.  But then he’d go off and draw something totally cool and all would be well.

Cortex had few of these issues.  We could make him totally improbable, un-animatable, and just keep him bigger on the screen.   He didn’t show up too often anyway.  He could never really walk with those short legs.  He had to do a weird thrusting tra-la-la dance.  But he looked cool so we just kept him stationary most of the time.

Cortex was my favorite.  I think Andy preferred Crash.  They fit our differing personalities!  Andy has the original ink Crash sketches and I have the original Cortexes.  Both are a true testament to Charles Zembillas’ skill as a character designer. [ NOTE from Andy: I love both, but I too have a secret fondness for my brainchild — he’s just funnier, and he takes himself way too seriously to ever dress in drag. ]

 

CONTINUED HERE WITH PART 3 HERE or

If you liked this post, follow me at:

My novels: The Darkening Dream and Untimed
or the
video game post depot
or win Crash & Jak giveaways!

Latest hot post: War Stories: Crash Bandicoot

Caves, concept

Castle Cortex

Related posts:

  1. Making Crash Bandicoot – part 1
  2. How do I get a job designing video games?
  3. On Writing: Passes and Plots
By: agavin
Comments (94)
Posted in: Games
Tagged as: Andy Gavin, Bob Rafei, Character Action Games, Character Design, Charles Zembillas, Crash Bandicoot, Doctor Neo Cortex, Games, Jason Rubin, Joe Pearson, Mark Cerny, Nintendo, Playstation, pt_crash_history, Sega, Sony, Tex Avery, Video game, Video Games, Who Framed Roger Rabbit

Making Crash Bandicoot – part 1

Feb02

Crash Bandicoot cover

In the summer of 1994 Naughty Dog, Inc. was still a two-man company, myself and my longtime partner Jason Rubin. Over the preceding eight years, we had published six games as a lean and mean duo, but the time had come to expand.

In 1993 and 1994 we invested our own money to develop the 3D0 fighting game, Way of the Warrior. In the summer of 1994 we finished it and sold the rights to Universal Studios. At the same time we agreed to a “housekeeping” deal with Universal, which meant moving to LA, and for me bailing out on my M.I.T. PhD halfway. It certainly didn’t turn out to be a bad decision.

Jason and I had been debating our next game for months, but the three-day drive from Boston to LA provided ample opportunity. Having studied arcade games intensely (yeah, in 1994 they were still relevant) we couldn’t help but notice that 2 or 3 of the leading genres had really begun making the transition into full 3D rendering.

Racing had, with Ridge Racer and Virtua Racing. Fighting, with Virtua Fighter. And gun games, with Virtua Cop. Racing was clearly 100% the better in 3D, and while Virtua Fighter wasn’t as playable as Street Fighter, the writing was on the wall.

Sensing opportunity, we turned to our own favorite genre, the character platform action game (CAG for short). In the 80s and early 90s the best sellers on home systems were dominated by CAGs and their cousins (like “walk to the right and punch” or “walk to the right and shoot”). Top examples were Mario, Sonic, and our personal recent favorite, Donkey Kong Country.

So on the second day of the drive, passing Chicago and traveling through America’s long flat heartland, fed on McDonalds, and accompanied by a gassy Labrador/Ridgeback mix (also fed on McDonalds), the idea came to us.

We called it the “Sonic’s Ass” game. And it was born from the question: what would a 3D CAG be like? Well, we thought, you’d spend a lot of time looking at “Sonic’s Ass.” Aside from the difficulties of identifying with a character only viewed in posterior, it seemed cool. But we worried about the camera, dizziness, and the player’s ability to judge depth – more on that later.

Jason, Andy & Morgan on arriving at Universal

Before leaving Boston we’d hired our first employee (who didn’t start full time until January 1995), a brilliant programmer and M.I.T. buddy of mine named Dave Baggett. We were also excited to work closely with Universal VP Mark Cerny, who had made the original Marble Madness and Sonic 2. In California, in 1994, this foursome of me, Jason, Dave, and Mark were the main creative contributors to the game that would become Crash Bandicoot.

We all agreed that the “Sonic’s Ass,” game was an awesome idea. As far as we knew, no one had even begun work on bringing the best-selling-but-notoriously-difficult CAG to 3D. Shigeru Miyamoto, the creator of Mario, was said to be working on Yoshi’s Island, his massive ode to 2D action.

But an important initial question was “which system?”

The 3D0 was DOA, but we also got our hands on specs for the upcoming Sega Saturn, the Sega 32X, and the mysterious Sony Playstation. The decision really didn’t take very long.  3D0, poor 3D power, and no sales. 32X, unholy Frankenstein’s monster – and no sales. Saturn, also a crazy hybrid design, and really clunky dev units. Then there was the Sony. Their track record in video games was null, but it was a sexy company and a sexy machine – by far the best of the lot. I won’t even bring up the Jaguar.

So we signed the mega-harsh Sony “developer agreement” (pretty much the only non-publisher to ever do so) and forked out like $35,000 for a dev unit.  Gulp.  But the real thing that cinched the deal in Sony’s favor though wasn’t the machine, but…

Before we continue to part 2 below, my parter and friend Jason Rubin offers the following thoughts on this section:

Andy and I always liked trying to find opportunities that others had missed.  Fill holes in a sense.  We had done Way of the Warrior in large part because the most popular games of the time were fighting games and the new 3DO system didn’t have a fighting game on it.  Our decision to do a character action game on the PlayStation was not only based on bringing the most popular genre on consoles into the 3D, but also because Sega already had Sonic and Nintendo already had Mario.  Instead of running headlong into either of these creative geniuses backyard, we decided to take our ball to a field with no competition.

Filling a hole had worked to an extent with Way of the Warrior.  The press immediately used Way as a yardstick to make a comparison point against other systems and their fighting games.  This gave it a presence that the game itself might never have had.  And as a result, ardent fans of the system would leap to defend the title even when perfectly fair points were made against it.  The diagonal moves were hard to pull off because the joypad on the 3DO sucked?  No problem, said the fans, Way of the Warrior plays fantastically if you just loosen the screws on the back of the joypad.

Why couldn’t the same effect work with a character action game on PlayStation?

And remember, at the time these games were the top of the pile.  It is hard to look at the video game shelves today and think that only 15 years ago childish characters dominated it.  There were first person shooters on the PC, of course, but sales of even the biggest of them couldn’t compare to Mario and Sonic.  Even second tier character games often outsold big “adult” games.

It’s also easy to forget how many possible alternatives there were along the way.  Most of Nebraska was filled with talk of a game called “Alosaurus and Dinestein” which was to be back to the future like plot with dinosaurs in a 2d side scrolling character action game.  I still like the name.

The “Sonic’s ass” nomenclature was more than a casual reference to the blue mascot turned 90 degrees into the screen.  It defined the key problem in moving a 2d game into the third dimension:  You would always be looking at the characters ass.  This might play well (it had never been tried) but it certainly would not be the best way to present a character.

Our solution, which evolved over the next 2 years, was multi-fold.  First, the character would start the game facing the screen (more on this later).  Second there would be 2d levels that guaranteed quality of gameplay and a chance to see the character in a familiar pose allowing comparison against old 2d games.  And third, we would attempt the reverse of a Sonic ass level – the run INTO the screen – which became the legendary boulder levels. [ NOTE from Andy, more on that in part 4 ]

It may have been this very Sonic’s ass problem that caused Naka-san to “cop out” of making a true 3D game called Nights for Saturn.  I also believe, but have no proof, that he felt so unsure of the move to 3D that Sega didn’t want to risk Sonic on that first experimental title.  Instead they created a new character.  This lost Sega the goodwill that Sonic would have brought to the three way game comparison that eventually ensued.  That ended up working to our favor.

Of course Miyamoto-san did not have this problem.  He created a truly new type of character action game with Mario 64.  The controls and open world allowed you to see the character from all sides.  Eventually this proved to be the future of 3d Character games.  But at the time it had disadvantages.  More on that later.

The concept of making a mascot game for the PlayStation was easy.  The odds of succeeding were next to nil.  Remember, we were two 24 year olds whose biggest title to date had not reached 100,000 units sold!  But if there was something we never lacked it was confidence.

NEXT PART [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13] “parts” 12-13 are brand new Jan 2012.

If you liked this post, follow me at:

My novels: The Darkening Dream and Untimed
or the
video game post depot
or win Crash & Jak giveaways!

Latest hot post: War Stories: Crash Bandicoot

The Crash Bandicoot in-game model. His only texture was the spots on his back, but every vertex was lovingly placed by Jason

Related posts:

  1. How do I get a job designing video games?
By: agavin
Comments (462)
Posted in: Games
Tagged as: Andy Gavin, Character Action Games, Crash Bandicoot, Jason Rubin, Mark Cerny, Naughty Dog, Platform Games, Playstation, pt_crash_history, Sega, Sega 32X, Sega Saturn, Shigeru Miyamoto, Universal Studios, Video game, Video Game History, Video Games, Virtua Racing, Way of the Warrior
Watch the Trailer or

Buy it Online!

Buy it Online!

96 of 100 tickets!

Find Andy at:

Follow Me on Pinterest

Subscribe by email:

More posts on:



Complete Archives

Categories

  • Contests (7)
  • Fiction (404)
    • Books (113)
    • Movies (77)
    • Television (123)
    • Writing (115)
      • Darkening Dream (62)
      • Untimed (37)
  • Food (1,483)
  • Games (100)
  • History (13)
  • Technology (21)
  • Uncategorized (16)

Recent Posts

  • Robo Eats – Szechuan Place
  • Providence Chef’s Table 2022
  • OOToro Double
  • Robo Eats – Anarbagh
  • Fred loves N/Naka
  • Major Major Major
  • Far East – Beijing Tasty House
  • Home Sweet Spicy Home
  • Quick Eats – Bafang
  • Quick Eats – Peking Restaurant

Favorite Posts

  • I, Author
  • My Novels
  • The Darkening Dream
  • Sample Chapters
  • Untimed
  • Making Crash Bandicoot
  • My Gaming Career
  • Getting a job designing video games
  • Getting a job programming video games
  • Buffy the Vampire Slayer
  • A Game of Thrones
  • 27 Courses of Truffles
  • Ultimate Pizza
  • Eating Italy
  • LA Sushi
  • Foodie Club

Recent Comments

Archives

  • March 2023 (11)
  • February 2023 (11)
  • January 2023 (14)
  • December 2022 (11)
  • November 2022 (13)
  • October 2022 (14)
  • September 2022 (14)
  • August 2022 (12)
  • July 2022 (9)
  • June 2022 (6)
  • May 2022 (8)
  • April 2022 (5)
  • March 2022 (4)
  • February 2022 (2)
  • January 2022 (8)
  • December 2021 (6)
  • November 2021 (6)
  • October 2021 (8)
  • September 2021 (4)
  • August 2021 (5)
  • July 2021 (2)
  • June 2021 (3)
  • January 2021 (1)
  • December 2020 (1)
  • September 2020 (1)
  • August 2020 (1)
  • April 2020 (11)
  • March 2020 (15)
  • February 2020 (13)
  • January 2020 (14)
  • December 2019 (13)
  • November 2019 (12)
  • October 2019 (14)
  • September 2019 (14)
  • August 2019 (13)
  • July 2019 (13)
  • June 2019 (14)
  • May 2019 (13)
  • April 2019 (10)
  • March 2019 (10)
  • February 2019 (11)
  • January 2019 (13)
  • December 2018 (14)
  • November 2018 (11)
  • October 2018 (15)
  • September 2018 (15)
  • August 2018 (15)
  • July 2018 (11)
  • June 2018 (14)
  • May 2018 (13)
  • April 2018 (13)
  • March 2018 (17)
  • February 2018 (12)
  • January 2018 (15)
  • December 2017 (15)
  • November 2017 (13)
  • October 2017 (16)
  • September 2017 (16)
  • August 2017 (16)
  • July 2017 (11)
  • June 2017 (13)
  • May 2017 (6)
  • March 2017 (3)
  • February 2017 (4)
  • January 2017 (7)
  • December 2016 (14)
  • November 2016 (11)
  • October 2016 (11)
  • September 2016 (12)
  • August 2016 (15)
  • July 2016 (13)
  • June 2016 (13)
  • May 2016 (13)
  • April 2016 (12)
  • March 2016 (13)
  • February 2016 (12)
  • January 2016 (13)
  • December 2015 (14)
  • November 2015 (14)
  • October 2015 (13)
  • September 2015 (13)
  • August 2015 (18)
  • July 2015 (16)
  • June 2015 (13)
  • May 2015 (13)
  • April 2015 (14)
  • March 2015 (15)
  • February 2015 (13)
  • January 2015 (13)
  • December 2014 (14)
  • November 2014 (13)
  • October 2014 (13)
  • September 2014 (12)
  • August 2014 (15)
  • July 2014 (13)
  • June 2014 (13)
  • May 2014 (14)
  • April 2014 (14)
  • March 2014 (10)
  • February 2014 (11)
  • January 2014 (13)
  • December 2013 (14)
  • November 2013 (13)
  • October 2013 (14)
  • September 2013 (12)
  • August 2013 (14)
  • July 2013 (10)
  • June 2013 (14)
  • May 2013 (14)
  • April 2013 (14)
  • March 2013 (15)
  • February 2013 (14)
  • January 2013 (13)
  • December 2012 (14)
  • November 2012 (16)
  • October 2012 (13)
  • September 2012 (14)
  • August 2012 (16)
  • July 2012 (12)
  • June 2012 (16)
  • May 2012 (21)
  • April 2012 (18)
  • March 2012 (20)
  • February 2012 (23)
  • January 2012 (31)
  • December 2011 (35)
  • November 2011 (33)
  • October 2011 (32)
  • September 2011 (29)
  • August 2011 (35)
  • July 2011 (33)
  • June 2011 (25)
  • May 2011 (31)
  • April 2011 (30)
  • March 2011 (34)
  • February 2011 (31)
  • January 2011 (33)
  • December 2010 (33)
  • November 2010 (39)
  • October 2010 (26)
All Things Andy Gavin
Copyright © 2023 All Rights Reserved
Programmed by Andy Gavin