Crash Bandicoot as a Startup (part 7)

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 and subscribe to the blog (on the right), or follow us at:

Andy:  or blog

Jason:  or blog

Also, if you liked this, vote it up at at Reddit or Hacker News, and peek at my novel in progress: The Darkening Dream

or more posts on

GAMES or BOOKS/MOVIES/TV or WRITING or FOOD.

Making Crash Bandicoot – part 3

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

more on GAMES or BOOKS/MOVIES/TV or WRITING or FOOD

Crash was never suave