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

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

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

_

The Crash Bandicoot Trilogy: A Practical Example

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

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

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

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

Development: September 1994 – September 1996

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Development: October 1996 – November 1997

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Optimization risk: can we put more on screen?

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

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

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

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

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

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

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

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

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

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

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

Development: January 1998 – November 1998

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

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

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

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

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

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

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

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

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

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

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

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

Technical risk: more more more!

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

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

Conclusions

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

_

Yet more Crash Bandicoot posts can be found here.

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.

117 comments on “Crash Bandicoot – Teaching an Old Dog New Bits – part 3

  1. aimee says:

    Do you know if Activision have a development team for Crash bandicoot?

    Have you asked Mark Cerny again for his article? 🙂

    • agavin says:

      Yep. Game development doesn’t leave a lot of extra time for blogging etc! In 1997 I didn’t go into a store for 9 months! No stores. Not even a grocery store. I ate takeout in the office. I ordered new underwear online instead of doing laundry. Driving home (in the light) at 6am I used to notice people going into Starbucks and the like and get a nostalgic feeling.

    • agavin says:

      I don’t know about Crash, but I havnt heard anything. And the yep was for asking mark.

      • aimee says:

        Thanks for asking, it would be sooooooooooo interesting to hear from his perspective as he was involved with Crash as well as president of Universal

  2. aimee says:

    if crash was still in your hands at the time of ps2 era what would you have done differently?

    if you carried with the series would have done Crash bash?

    • agavin says:

      I have no idea. But Bash is a good game, just very different. I doubt we would have programmed/made it ourselves, but we might have outsourced it in some alternate reality.

  3. Friedslick6 says:

    Wow. Everytime I hear about exactly what Naughty Dog did, it blow my mind. And it’s a shame that development like this is hard to come by now. Thanks again for posting.

    • agavin says:

      Naughty Dog (and other great teams) are working just as hard and smart now as then. It’s just on Uncharted instead of Crash, and they have over 100 people instead of 8!

      • DjGDA86 says:

        Yeah it’s about expanding, going big. 🙂
        I am new here on these pages so let me thank you on your posts about Crash development etc. I already have read for 3 hours or so now it’s really interesting, like a reading a book. 😀
        Keep up the great work 🙂

  4. Great work Andy. I’ve been loving the articles, but is this the last one or will there be more as these are such great reads?

    P.S My site The-Kennel (A Naughty Dog fansite) Featured these posts 😀

  5. its_not_a_me_mario says:

    Amazing , thanks for posting all this 😀

  6. robotnik says:

    Hey Andy, do You know a site where I can get the original soundtrack from the Crash Bandicoot games that were developed by Naughty Dog?

    • its_not_a_me_mario says:

      They’re all on youtube 😉

      • robotnik says:

        Yeah, the ones that were ingame are all on Youtube but what I mean is this:

        Apparently there seems to be a version of all tracks in unique sound quality “how they were originally intended to be”,those are the ones I mean. 😀
        Can you help?

    • agavin says:

      In Japan they sold the soundtrack, I’m not sure they did here.

      • robotnik says:

        Thanks for the info, maybe I will find it some day. At least now I know where to start searching. 😀

  7. Bandicoot X says:

    Thanks for all the great Crash games, I spent countless hours playing them when I was younger. Even today I rather play Crash Bandicoot than some of the new platform games. Hopefully Naughty Dog will buy the franchise back one day.

  8. aimee says:

    any updates of mark cernys article?

  9. Joe Labbe II says:

    I think Warped and CTR were the most intense, yet fun, of the Crash series to make!
    We really pulled together as a family and team… and when you play them, it shows!
    I wouldn’t trade that experience for the world!|
    Good write, Andy!

  10. aimee says:

    when are do doing crash bandicoot 2? its been so long since the first one?

  11. aimee says:

    andy have you seen the new fan made crash bandicoot crysis mod game? if so what do you think?

    • agavin says:

      The graphics don’t look half bad. The spin perhaps a little weird (needs more transparency :- ))

      • aimee says:

        I agree andy with you on the the spin attack and also crash,s face looks kinda scary, someone should suggest this to Activi$ion, surely they cant be that stupid, to not do anything with the crash franchise as its a IP goldmine. You`d think Evil Acivi$ion would know this.

  12. Gabriele Fiasconaro says:

    Mister Gavin, if you can do another Crash Bandicoot game, how it would look like? I mean: The Story, the gameplay, playable characters and Bosses, ecc…

    P.S.:Thank you for the original 4 games 😀

  13. Leo says:

    I remember playing Crash in my friend’s house when I was six years old or so. We would make up lyrics to every song in the game lol!
    You did a great job back then and these articles inspired me greatly into finishing some gaming projects I have pending. Thank you!

  14. aimme says:

    Andy did konami publish and market the first five crash bandicoot games in japan or was it another publisher?

    • agavin says:

      Sony sold them directly.

      • aimme says:

        so all of crash`s the japanese marketing was not done by konami during 1996 to 2000, but by sony?

        How did that work?

      • agavin says:

        Konami never did ANYTHING with Crash Bandicoot as far as I know. For sure all the 1996-2000 Crash marketing was done by Sony in all territories. Of course they had subcontractors like Ad Agencies and deals like the big Pizza Hut co-marketing deal, but it was still theirs.

  15. aimme says:

    sony were good weren`t they, do you think its fair that evil Activision have 5 development teams for the call of duty franchise and not even one for crash bandicoot?

  16. aimme says:

    Andy
    Did mark cerny ever work on Crash Team racing?

    If not why not?

    P.S it looks like Activision are not releasing any Crash bandicoot games anytime soon 😦

    The only thing to look forward to Crash bandicoot wise is the rest of your Crash articles on the other games

  17. aimme says:

    Hi andy it looks like activision are not releasing any crash bandicoot games in the near future 😦

    Iam so dissapointed in Activision they proved they are sooo evil, by not caring about crash, yet they have got so many dev teams for call of crappy duty

    you live in santa monica where activision is located cant you go and meet someone in charge and tell them we want some crash games, its been tooooo long , cant you do anything?

    • agavin says:

      I know lots of folks over at Activision, and they’re really good guys. But development planning (and politics) at big companies is “complex” and not always rational to outsiders.

  18. ricardo fernandes de souza says:

    Why sony sold crsh’s rights?

  19. ricardo fernandes de souza says:

    Andy
    I can make a fan game of the crash without being illegal?

    • agavin says:

      It’s not illegal to make it. It’s illegal to SELL it, or perhaps even to give it away (probably any kind of distribution). Activision owns the copyrights and trademarks on the character, so you can not distribute something that infringes on that. Otherwise everyone would make Crash or Mario or put out Spiderman movies or whatnot.

  20. ricardo fernandes de souza says:

    in one of my school work, I had to do a quiz of the Portuguese language (I’m Brazilian) and I chose as the protagonist crash bandicoot
    So this is not illegal?

    • agavin says:

      I’m not an intellectual property lawyer, but that isn’t a commercial use, and certainly they would never sue you.

      • ricardo fernandes de souza says:

        thanks Andy…
        congratulations of the amazing games…
        even today i still playng your games…

  21. ricardo fernandes de souza says:

    do you have plans to make more games to video games?

  22. ricardo fernandes de souza says:

    todos os jogos que voce fez tornaram lendas epicas…

  23. ricardo fernandes de souza says:

    sorry…i send to you in portuguese

  24. ricardo fernandes de souza says:

    Let’s go back to the time when CTR was finished, and Jak & Daxter was on its way. Supposing you had gained the rights to Crash back then, would you have considered continuing the series in the future? If so, any quick thoughts on what you would have kept and changed?

    • agavin says:

      If we could have had the rights at that time WITHOUT Universal’s involvement, we would have done more games. But that wasn’t possible, so we didn’t.

      • Gabriele says:

        What types of games would be?
        We had a Crash Bash by Naughty Dog, or you would have preferred to continue the classic series?

      • agavin says:

        You guys ask VERY hypothetical questions. Presumably, we would have considered doing a PS2 reboot of the game. But we never thought that way. There isn’t a lot of time during game dev to speculate extensively on projects you AREN’T making — the ones you ARE consume everything.

  25. Gabriele says:

    I’m sorry but this kind of questions are my favourite XD.
    Well,I’m sure no one will continue the series as you would have done, however, the project Crash 2010 was not so bad.
    Here is the link to the video that shows Crash and Dingodile and the concept arts for the game http://www.youtube.com/watch?v=8dx-o5kkEPI
    What do you think about that?

    • agavin says:

      That’s kinda cute actually

      • Gabriele says:

        Unfortunately this game was planned for 2010 but the team that was working on it got fired so it’s a cancelled game. And now there is nothing new about a Crash Bandicoot Game.

      • aimme says:

        I personally think its awful and so glad it got cancelled, Crash looks too Japanese and dingodile looks just as awful, Radical were soooo bad at developing crash games, they didn`t have a clue, hence why Activision fired them. Activision is no better though they have completely abandoned the series and are not planning any further releases

  26. aimme says:

    Hey andy
    Any update on mark cernys article, maybe he could contribute to the Crash bandicoot 2 article, When is that anyway?

    soon i hope as there is nothing to look forward to crash bandicoot wise.

  27. Gabriele says:

    Now I understand. Same thing for the scrapped hippopotamus character of which I found a concept art I guess.
    Well Thank you for your answers Mr. Gavin.

    • agavin says:

      You can only do so much. Originally for Crash 1, we had intended like 50% more levels and like 8-10 bosses. We worked for two years and barely finished what we did — but it’s not like it isn’t a full game worth. The stuff that didn’t make it into Crash 1 that seemed good made it into Crash 2 or Crash 3.

      • Gabriele says:

        Crash 1 + Crash 2 + Crash 3 = The perfect game!
        I hope that in the future we will see another Crash Bandicoot game made by you and Jason Rubin.

  28. aimme says:

    when are you doing your Crash 2 article?

  29. aimme says:

    you said you know guys from Activision, do you know bobby kotick or eric hillbirg or what ever he`s called.

    Are the people you know developers or higher in the chain at Activi$ion?

    • agavin says:

      Both. Jason Rubin and I both are friendly with lots of people at Activision. The games biz is pretty small.

      I know people would love to see a new (and great) Crash game — and so would we — but it isn’t really our place to comment on their business. Which is complex.

  30. aimme says:

    If Sony wanted to get invovlved with Crash again, would they be able to?

    Could they publish with Activision like they did with Universal?

    • agavin says:

      It’s not that likely in that form, as Sony is it’s own publisher. Universal didn’t publish the Crash games, Sony did. Universal fronted the original money to develop them (we did that part) and provided production assistance.

      • aimme says:

        so it would be impossible if sony wanted to get involved with Crash?

      • agavin says:

        Nothing’s impossible. It’s just that certain business moves are less likely than others. First parties (like Sony, Microsoft, Nintendo) generally don’t co-publish with Third Parties (like EA or Activision). First parties try to keep neutral about the Third’s, as all Third’s are customer/licensees of theirs.

  31. aimme says:

    how was it possible with Universal weren`t they third party as well?

    • agavin says:

      Yeah. But much smaller (then — Universal only had 3-4 games), and the times were different. But as I said, nothing is impossible.

      • aimme says:

        From what I have heard Universal were useless and hands off, as Mark cerny was the president, did he not control that aspect, surely he must have
        had the most power at Universal being the President

  32. aimme says:

    Have you ever thought of making your own Crash game like that `Crash bandicoot returns` mod?

    Not to sell obviously (Activision would have a field day), just to see how the game would look or be

    • agavin says:

      Mark was the good part of Universal. But in the Crash 1 days he had a “boss” named Rob Biniaz that we (Naughty Dog) didn’t get along with (mild way of saying it).

  33. aimme says:

    Hey andy have heard that Activision have renewed the crash bandicoot trademark in april? (all information is on crash mania)

    whats the pointin renewing a trademark if your gonna do nothing with it

    is it possible for activision to renew that trademark and keep the IP, even though they are not doing anything with it?

    • agavin says:

      They do not need to do anything with the IP to keep it — they own it.

      • Gabriele says:

        I hope that a new game will be more similar to the original ones, I personally don’t want another Crash Twinsanity or another Crash Mind Over Mutant/Crash Of the Titans.
        Maybe your friends at Activision will work on a new title for the series…

  34. its_not_a_me_mario says:

    I’m checking daily the blog with a hope to read more “behind the scene” related stuff but looks like its going to take a while 😦

    • agavin says:

      I will eventually do a bunch more (I have dozens of articles and all the rest of the games to do), but I have to spread them out — and I’ve been busy with my new book. You can also subscribe to the blog on the right sidebar.

  35. aimme says:

    Andy

    Sony owns the rights to the original 5 crash bandicoot games so would they be able they make them into HD remakes without Activisions Knowledge or consent?

  36. aimme says:

    OMG what does LOL mean are they in the works?

  37. aimme says:

    andy
    Have you ever thought of making your own Crash game like that `Crash bandicoot returns` mod?

    Not to sell obviously (Activision would have a field day), just to see how the game would look or be

    • agavin says:

      There is no “just for fun” anymore in game making. Even a prototype would take several guys several months and cost at least a couple hundred thousand dollars — and that would be doing it cheap. Maybe one could do a quick mod, but it would be throwaway stuff.

  38. aimme says:

    Andy are you attending E3?

  39. aimme says:

    here`s to hoping to hear some crash bandicoot related news at E3, but I highly doubt it knowing Activi$ion

  40. aimme says:

    So andy what did you think of this years E3 , what impressed you the most?

  41. aimee says:

    Andy
    I think you should do the Crash Bandicoot 2 article along with mark cernys article on crash`s 15th birthday, which is around september 2011 i think, Is that true? if so what do you think?

  42. Daniel says:

    Does Naughty Dog still work with Insomniac Games?

    • agavin says:

      NDI never worked in an official fashion with Insomniac. However, both companies were and are great friends and besides being adjacent for some years in the 90s did share various technologies and strategies over the years. Parts of the Jak & Daxter engine were used in Rachet & Clank.

  43. Gabriele says:

    I know that Sony already owns the first 5 Crash games, From Crash Bandicoot to Crash Bash. I don’ t jnow how this thinks work so I ask to you: What Sony can do with this titles?

  44. bluepasj says:

    You at the Naughty Dog are geniuses. I think almost everyone else in the world would get crazy if they were to make something so heavy on patience and hard work as programming. God, this is completely incredible! How did you manage to not get crazy with all this on your mind and, worst, having to rewrite! You must REALLY love the work you do, you must really love to write codes!!! And that’s admirably, ’cause there are no much people in this market that are so fearless of the work as you are.

    And I love the way u do games, the way we fans come to know in your posts. It’s this way all the game makers should work, but this not seems to be the case. That’s why you are among the bests.

    And can you say something about the secrets that are in these Crash games (like the UFO plate in that we can crash to go to anothr level, for example)?

  45. xan1242 says:

    I have one question.Why do Crash Bandicoot games have Spyro demos in them and vice versa? (those are Crash Bandicoot 3:Warped,Crash Team Racing and Crash Bash)

    Do those games share some of the elements (that is,graphics,sound,etc.) or code?

    And Eurocom was lazy;they left the whole beta in their demo.You can just type the cheat menu code and you have the beta version of Crash Bash.

  46. Amec says:

    What was the purpose of getting crystals/gems/relics/powers after garnering a rather lengthy combo in Crash 2 and 3? This is usually done by jumping on an arrow crate for a few mins, then killing an enemy. Was it put there as a joke or something? 😀

    Example:

  47. […] perspective 9. The programming 10. Tools for the game 11. Teaching an old dog, new bits 12. A practical example 13. Russian fan interview 14. Old 20 questions 15. […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s