     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Postmortem: The Collective's What Went Right 1. A solid license and an enthusiastic team. My previous work on a licensed title was a PC game based on a movie that was still in development. That was truly untested ground; we didn't know how the public would react to the movie, and that would largely affect the success of our game. In fact, since the game was in development while the movie was being shot, we had very little idea what we were attempting to make. The Emperor's Tomb was a completely different situation. Indiana Jones is one of the most beloved characters in movie history. Almost every member of our generation has seen the movies and has fond memories of them. This gave us a tremendous reserve of goodwill and enthusiasm from which to work. It also set high expectations for us to meet.
Just about everyone on the team really wanted to be working on this title. We were all tremendously excited because we saw it as a great challenge. As we developed the prototype and began shopping around the company for team members, people started to go Indy crazy. Pictures of Harrison Ford in Indy costume began appearing on various cubicle walls. Numerous level designers and artists came to us to express their desire to be a part of the team, and one of the level designers even bought an entire Indiana Jones outfit including the trademark jacket, whip, and fedora. We tried to put this enthusiasm to good use. To come up with ideas, the team watched the movies numerous times and then brainstormed about which of the set pieces and concepts would be fun in a game. We wanted to create a very brawling-intensive game, but in a different way than Buffy. Buffy's focus was on kung-fu-style fighting. But of course Dr. Jones doesn't fight like that. He swings haymakers, throws chairs, and in a pinch he just shoots people. In the movies he also uses a lot of environmental objects, which was a challenge to accommodate. We decided to make everything that wasn't bolted down a usable weapon. So Indy had to be able to smash chairs, tables, and boxes. He also had to be aware of his environment at all times: when near a wall, he should ram his opponent's head into it, and when fighting near a ledge, enemies should be able to topple over them and fall. Obviously the ability to clamber around and explore the environment was crucial, as was the integration of perilous and lethal traps.
The story behind The Emperor's Tomb came entirely from our
Lead Designer, but all the members of the team contributed set pieces
or other additions. The most challenging level - the Von Beck tank
chase - was the result of a late-night inspiration from our Lead
Artist. My desire to work with dynamic physics and some of the constraints
we had to impose upon the whip led to the heavy integration of ropes,
chains, and vines as navigational objects. What I consider to be
the funniest gag in the game - a bit with a Nazi rehearsing his
tough-guy lines - was contributed by one of the level designers
loaned to us by LucasArts. The development team had a cabal-like
atmosphere, which helped keep the excitement level high. Specifically, we encouraged our team members to come up with their own designs for parts of levels and for new technology systems. We also tried to make sure that nobody worked on too many things they found boring or uninteresting. Most importantly, we did our best to listen to grievances and to address burnout by not insisting upon crazy hours for long stretches of time. We had an open-door policy and always welcomed our team members to come and talk with us about anything. When much of your team is coming from a project that has been in crunch mode for over a year, it can be difficult to motivate them. We tried to combat this problem by not asking anything of our teams that we wouldn't do ourselves. We also organized get-togethers and team events such as meeting to look over new additions to the game, re-watching the movies as a team, or just getting together for the standard cheesy faux-jousting at the local Medieval Times. 3. Existing tools and technology. One of the biggest benefits of joining The Collective while it was developing Buffy was the fact that there was substantial existing technology to work with. We had the working Buffy engine as a base and spent most of our time customizing and extending it to suit The Emperor's Tomb. Having the existing technology to work with was immeasurably better than trying to write everything from scratch. One of the ways this helped was having an engine and editor which both worked on our development platform. While I was working on porting the engine to the Xbox the team was able to start development with the PC version. This allowed us to easily prototype and test behaviors, environments, and character designs. We were even able to borrow some basic elements from Buffy, such as their weights and measures setups and basic character control, to get our prototype on-line. But the best benefit of having an existing tech base was the ability to start with a moderately stable tool chain. Even though we had a number of problems with the tools, the fact that we had a relatively solid foundation on which to build gave us a boost. From the first day we were able to create and use assets, which helped tremendously in planning the development path for the game. In addition to the existing software with which we were provided, we also owe a great debt to the core technology group, and the Buffy team, for their willingness to pitch in and help when it was most needed. Regardless of how full their schedules were they always did their best to act as a source of information and to help us get major features into the engine. For this they have my gratitude. 4. Pre-plan, plan, and re-plan. This was the first title I worked on that had a prototype phase. The Collective decided on this experimental approach to the project based on their experiences while developing Buffy. The idea was to figure out what the major risks would be during full-scale development, and to get the basic look and feel of the game hammered out. This was an immensely valuable part of the development process. It did not completely prevent us from making mistakes, and even after six months of implementing gameplay we had a lot of questions without answers. But we also had the framework upon which the entire game would be built and a working demo to show our publisher. This demo would be later polished and refined and became the first full level of our game. The experience also gave us an idea of how we would work together as a team. All of this information was used to build the schedules for our project. These schedules were the glue that held the project together and the light in the darkness that kept everything moving forward. Even during the roughest moments of development we always had an idea what was being worked on, what was in the game, and what was coming up next. A lot of this can be attributed to our producer, who did a great job of keeping the schedules organized and up-to-date. He also helped the individual leads quite a bit by taking some of the schedule-minding off of our shoulders, leaving us to fill in production gaps.
5. A willingness to scale back game features. When we project leads began to realize that the game could not possibly hit its ship date with the schedule and design in hand, we knew we had to re-evaluate our design and look for features to cut. We knew our team's limits when we began our full-production phase. We had all spent six months crunching on a prototype as a small team, and the few people coming on board from Buffy were also coming directly from a long crunch period. Asking people to work more hours just wasn't the solution, nor was yelling and screaming when people missed schedules. It came down to simple math. We counted up the man-hours we needed and the resources we had to dedicate, and it didn't match up. So we had to scale back the design. We ended up cutting a large chunk of the original design plan, and to the credit of the design team, these cuts did not significantly affect the game. The aggressive documentation and scheduling greatly helped us to make the decision of what to cut and what to keep. By having all of our game spelled out and scheduled, deciding what to cut became a much more simple process. We simply looked at our list of C and low B features and structured a new game without them. This isn't meant to imply that making the cuts was easy. Some of the features we were truly sorry to see go; some of them were cut and then re-added in a more simple form. For example, the game was originally designed with a number of chase scenes, each of which took place in a completely different dynamic environment. One happened in a rickshaw; one happened in a car; one was a foot chase across boats which were supposed to bob up and down in the water. We cut these scenes since we had no vehicle technology and a very limited spline system. Later we re-added a trimmed-down version of the system to add to make the gameplay more diverse. These cuts initially put us at loggerheads with the owners of the company, who were extremely reticent to allow us to cut features. In their defense, I can understand that they had to report our decisions directly to the publisher and deal with the flak. Having promised LucasArts so many features, it was undoubtedly a difficult prospect to offer a smaller game for the same amount of money. But ultimately we were able to convince the publisher that this was better in the long run. Better to have a tight, focused game that ships than a sprawling experience that is in development forever. The sad fact is many people who played The Emperor's Tomb never finished it. Even with the cuts, it is still a very long game.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Features
|
|
|