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.
If you liked this post, follow me at:
    My novels: The Darkening Dream and Untimed |
Crash was never suave
