Way of the Warrior – The Lost Interview

A Twitter friend of mine dug up this ancient and forgotten interview that I gave from my Cambridge Mass apartment in 1994, during the development of our 3DO fighting game, Way of the Warrior. The original post can be found here, but he gave me permission to repost the whole thing here. It’s certainly one of my older interviews on record. I did a number in the 80s but those are pre-web and certainly long lost (unless I comb through my parent’s basement for old copies of EGM and the like!).

_

Back in May I had a chance to interview Andy Gavin, one half of the team that makes up Naughty Dog Software. The other half consist of Jason Rubin who’s a graphic arts specialist. These guys are based in Cambridge, MA., where I happen to be from, and have created what may be the best fighting game for the 300. I played Way of the Warrior and it definitely blows the first Mortal Kombat away easily. The game is similar to Mortal Kombat in many ways. The digitized characters, fatalities, combos, blood galore, hidden characters, and special attacks are all here. What Way of the Warrior does is take if a step further with an amazing AI(Artificial Intelligence), characters that shrink and grow, over 50 attack moves for each character, 100% 3D scrolling, hidden weapons, interactive backgrounds, bonus items, and so much more. Let’s have a talk with Andy and see what he has to say about Way of the Warrior.

VGT: When did you first start programming video games?
Andy: About 1 0-12 years ago, the first game we made was Ski Crazed on the Apple II, which came out in 1986. It sold a couple thousand copies. Dream Zone was our next game that sold about 15000 copies. Keef the Thief, from Electronic Arts, did much better and sold about 50,000 copies on various machines. We then did Rings of Power, which was our only Genesis cartridge. It’s was very complex and sophisticated and took about 2 1/2 years to produce.
VGT: When was Naughty Dog founded?
Andy: Well , Naughty consists of mainly Jason Rubin and myself . Naughty got its names from a cartoon character that Jason drew. (Andy showed me a picture of an old Naughty Dog logo). Their new logo is on their flyers. The character was created about 8 years ago.
VGT: Is there any downside when programming on the 300 with their CO’s? Does access time and RAM space affect your games?
Andy: Well, first of all the 3DO has 3 megabytes, not mega bits of RAM, which is bigger then the largest SNES cartridge. The CD itself is 660 megabytes . There are technical issues that need to be addressed when programming on the 3DO. One has to use clever designs to reduce and eliminate load times. In Way of the Warrior the entire program was designed in what we call, Asynchronous. The loading is done while you play, by anticipating what needs to be loaded’ in advance with a hardware process called DMA (Direct Memory Access) . There ‘s a short pause going into a fight, but once the action has begun, there is no pause. Players can perform all their moves, with fatalities, 3D scrolling and the stereo music blaring, but with no load time.
VGT: So even though we’re playing continuously, there’s no slow down what’s so ever.
Andy: Yes, the 3DO is capable of loading stuff without any slow down. However, many previous CD games, including the 3DO, have had notable slow delays.

VGT: Like the Sega CD for instance?
Andy: Yes, this is due to sloppy, programming and not being aware of how to program on CD’s. It’s a difficult issue when writing programs that can actually play and load at the same time. It’s a technical challenge. With good program design the load time can be minimized. In turn, the quality of the sound effect, music, FMV, and game play surpass any cartridge game. Cartridge games only have a limited amount of memory in which you can program. CD’s only cost a dollar to manufacture, while cartridges can cost anywhere from 20-30 dollars. CD’s have enormously superior cost to storage ratio.
VGT: Can the access time for the Sega CD be reduced with technical design programming?
Andy: They can definitely reduce the access time. I don’t know that much about the Sega CD though. I don’t think their DMA is better than the 3DO. The 3DO has 4-5 times more memory. It also has a CD drive that’s twice as fast. It has decompression hardware that effectively doubles the speed. It has a unique and extremely powerful custom DMA architecture that can move graphics from disk to memory to screen and back without effecting game play.
VGT: What makes Way of the Warrior different from all the other fighting games?
Andy: As I mentioned before, I have an Artificial Intelligence Graduate degree from MIT. The computer players in WOTW are much more sophisticated then in other fighting games. Whereas they often resorted to patterns to beat the human players, there are no patterns programmed in for WOTW. It uses research grade AI that learns the best way to beat you. It’s extremely cunning and different and actually looks like a real player fighting by adapting to the situation and using all it’s moves.
VGT: Is it always learning consistently more and more each time you play it?
Andy: Yes.
VGT: What about the characters? What makes them so special.
Andy: The characters have around 50 normal moves and about 15-20 special moves. These moves reflect their styles and personalities. There are many secrets that use the background area and hidden characters can also be found.
VGT: So is each character equal in sense or are some stronger then others?
Andy: All the normal human characters are designed to be equal even though they’re different.
VGT: Well, I remember the first Street Fighter II game had very uneven characters. Some had a major advantage over others.
Andy: It’s tough to get the characters exactly even. We tried to get them as close as possible. People also developed different strategies for beaten the other characters. There are a lot of unique techniques and abilities for each character. Like Konotori, which means “stork” in Japanese, can flap and stay in the air longer. Major Gaines has special steroids’ implants that can change his size and therefore the amount of damage he receives become minimal. Nikki Chan is a Chinese Kung Fu artist who can do flips with special moves. She’s very fast and agile. Crimson Glory has close in grabs and special multi-missles that can be fired. Some character has special weapons. Nabu Naga has a sword and throwing stars. Shaky Jake has a staff.
VGT: There seems to be a little bit of everything from all the other fighting games in this game.
Andy: The other fighting games are very narrow. Most of them are to much alike. What we tried to do was take everything good from all the other fighting games and combine them all into WOTW. We’ve added unique features with better graphics, sounds, 3D backgrounds, special magic and potions, panning and zooming, background interaction, and larger more detailed characters.

VGT: Was the process of digitizing the characters the same as Mortal Kombat.
Andy: There are similarities. We’ve never seen them actually doing it. We have seen photos in magazines. They are actually a little more regimented then ours. Their fighting engine is much less sophisticated then WOFW. It requires that every characters moves line up to the exact same position. When each character does a high punch in Mortal Kombat, they high punch at the exact same point. So when they digitize their characters they have to line up perfectly. In WOTW, every character has its own information so not all characters need to have a high punch. Some of the characters punch high, some low, while others are tall, short, big and small. There’s no requirement that the character be the same size. We built the character the same way the actor would appear, rather then force them to convert to our pre-requirements.
VGT: With the 300 having such a small user base at this point, do you think it can increase sales and become successful?
Andy: We think it has a good chance. All game systems start off with a small user base. People forget the Genesis came out in August of 1989 and 2 years later when the Super Nintendo was released it only had 700,000 machines out there and only 23 games after the first year. 300 already has more then that. The 300 is the first of the 32/64bit machines and the difference is academic. Sony, Sega, and Nintendo have all announce 32/64bit systems that won’t be available until 1995. The 300 will be the only significant 32bit machine when Christmas comes. It will have a year of development by then and the price will probably drop some more. So I think it’s in good shape. We hope WOTW with help sell systems.
VGT: Are there any other projects being worked on for the 300?
Andy: We have 2 other projects we’re working on, but we can’t comment on them at this point.
VGT: Do you think that CD’s are the way to go for our future programmers?
Andy: I think this year is the year of the CD’s. It already has the PC market. It offers so many advantages in cost and amount of storage . The access time disadvantage can be overcome with well-designed machines and good programming techniques.

VGT: Are there any other types of games that Naughty Dog will be working on besides fighting?Andy: We signed a deal to put WOTW in the arcades.
VGT: If WOTW does come to the arcade, will it be different then the 3DO version.
Andy: It would be a bit different. The basis of it would be the same. There are different constraints for the arcade version. The 3DO is capable of producing arcade quality games.
VGT: What’s the most outstanding achievement you’ve seen in video games today? What games really blow your mind?
Andy: I have favorites over the years. I tried Ridge Racer which was very impressive looking, but had mediocre game play. In the PC world, “DOOM!” was very good looking. It shows us that 3D games are here and can be produced very well, even on PC’s.
VGT: Well, that’s about it for the questions. Thank you very much for taking the time to be interviewed by VGT. We all hope that Way of the Warrior is very successful and we look forward to reviewing it and any other games that are produced by Naughty Dog.
Andy: Your welcome. Thank you for choosing Naughty Dog as your first interview. We look forward to reading VGT when it’s released.

This is back to 2011 Andy. It’s so worth watching the totally hilarious video from our 1994 masterpiece (LOL). As you can see, we went for over the top.

For more info on my video game career, click here.

For what I’m up to now, click here.

Untimed – The Second Cover

Just finished up a new “working cover” for my second novel, Untimed. Thanks a million to my friend and long time business partner Jason Rubin for concocting the excellent logo. He is a true Photoshop wizard.

If any of you have thoughts on the cover (the book’s a YA time travel adventure), post them in the comments.

Now back to working on the second draft.

I will use powers of superhuman concentration to ignore the fact that I have A Dance with Dragons sitting on my iPad — more or less unstarted.

I will.

Not reading during working hours!

All Your Base Are Belong to Us

Title: All Your Base Are Belong to Us

Author: Harold Goldberg

Genre: Video Game History

Length: 306 pages

Read: April 5, 2011

Summary: All the good stories!

_

This new addition to the field of video game histories is a whirlwind tour of the medium from the 70s blips and blobs to the Facebook games of today, with everything in the middle included. Given the herculean task of covering 45+ years of gaming history in a completely serial fashion would probably result in about 4,000 pages, Goldberg has wisely chosen to snapshot pivotal stories. He seizes on some of the most important games, and even more importantly, the zany cast of creatives who made them.

My personal favorite is Chapter 8, “The Playstation’s Crash” featuring none other than that lovable Bandicoot, myself, Jason, Mark Cerny and various other friends. This chapter covers loosely the same subject matter that Jason and I detail in our lengthy series of Crash blogs (found here). It’s even 98% accurate! :-) If you enjoyed our Crash posts, I highly recommend you check out this book, as it includes not only some extra insights there, but 18 other chapters about other vitally important games or moments in gaming history.

These include old Atari, the great 80s crash, Mario, Tetris, EA, Adventure Games, Sierra Online, EverQuest, WOW, Bioshock, Rockstar, Bejeweled, and more. All are very entertaining, and focus heavily on the personalities behind the scenes — and boy, are there personalities in this business! In many ways this reminds me of Hackers, which is dated, but was one of my favorite books on the 80s computer revolution.

So click, buy, and enjoy!

For my series on Making Crash Bandicoot, CLICK HERE.

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

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.

 

Subscribe to the blog (on the right), or follow me at:

Andy:  or blog

Also, peek at my novel in progress: The Darkening Dream

or more posts on

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

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

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 E3. 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 tiles 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. You also never know when we might add more, so 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.

Detailed and Colorful - but most important fun

Certainly varied

Sorry for the lousy screen shots!

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 6

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.

Also, 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.

The Limited Edition Launch Poster