|
|
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
What
Went Wrong
1. Unfocused design. The single most damaging problem during SoF's early development was that the original game lacked a truly focused design. We knew what the fundamentals of the game would be, but we did not have the specifics that we needed to create a solid, cohesive product. The game's overall story changed five times before it was finalized - at one point we had even changed the basic game concept to a team-based tactical shooter, similar to Rainbow Six. One reason for this indecisiveness was that, at the time, our original marketing team was wondering what the "hook" would be for the game. This was a major roadblock in creating the game because we knew that if marketing wasn't behind the idea, SoF wouldn't get the marketing money that it deserved. On top of that, without the backing of the marketing division, the senior management at Activision wouldn't get behind the title, either. We had to constantly sell and resell the idea that a high-octane, action-movie-like, real-world combat game would be enough of a hook. At times, it went so far that we were making design decisions not for the fun or betterment of the game, but to find the hook that we felt we were missing. The last straw came when we found ourselves working on a tactical team-based shooter, a complete 180-degree shift from our original design. We then decided to return to the game's roots and started banging out a new story.
Eventually, a new marketing team came on board that recognized exactly what we had been saying all along. SoF had more than enough to stand on its own, and they worked with us to find the right angle for marketing the product. This new team fit right in with the development team and things started to roll. On top of that, since we urgently needed to nail a story down in a short amount of time, they recommended that we meet with a hot-selling writer (Gonzalo Lira, author of the spy novel Counterparts) and John Mullins. Although the full story that Gonzalo Lira wrote for us was never used, some elements of it were, and the process made us realize exactly what we wanted from this game and how to get it. John Mullins contributed an element of realism to the game that we were missing at that time. In short, working on everything at once was not the way to go. For the projects that we currently have lined up we are designing the entire game from start to finish before we begin physically developing it. The SoF team learned the hard way that a day of preplanning saves a week of rework. Also, getting a green light for everything before starting development saves having to back-pedal later on. Both of these lessons will be applied to our future projects. 2. Technology. creation took longer than expected to visualize gameplay. A sure way to sell your product is to have a working prototype at an early stage in its development. Since we had decided to give the Quake 2 engine an entire overhaul, we realized that we would really have to come together and work as a team to make sure things were completed on time. One of the major enhancements for SoF was the Ghoul modeling system, which replaced the entire Quake 2 modeling system, and turned out to be quite the undertaking. Throughout the entire life of the project, tweaks and changes were made to Ghoul to make it more flexible and powerful. Unfortunately, this also meant that for a substantial part of the early development, we had no game to look at - only individual components. It's one thing to be able to look at a model in a model viewer, or at a level with nothing in it, but it's essential to be able to see the model in the world and interact with it.
Another problem was the huge number of animations planned for SoF. Since we had so many animations (more than 600 sequences) we had to limit which animations would appear on a specific level due to memory constraints. Limiting the animations on a per-level basis was a nightmare in itself, not only for the animators but also for the AI programmer (who had to make the AI work within the animation constraints) and the designers, who had to create scripted and cinematic sequences using only the animations available for each level. As the game drew nearer and nearer to completion it became increasingly difficult to bring new animations into the game without ruining someone else's work by removing an animation that was already in use. The final problematic technology was the AI. Developed throughout the entire course of the project, the AI went through many different incarnations. We decided early on that the pace of the game should be fast and furious with a large number of enemies attacking at once. Enemies were to be reactive, but not too intelligent. There were three major areas that caused AI problems: developing the models, developing the intelligence, and working with the scripting language. The main enemy model for the game was very complex. Incorporating all of the animation sequences and consisting of nearly 4,000 polygons, the model contained every piece for various body builds, coats, and other items that differentiated the enemies. Because of this complexity, we were forced to preprocess enemy sets for each level. These individual enemy sets looked at what enemy pieces and animation frames were needed for the level because we did not have a skeletal system in place. This directly impacted the AI because not every move was now available on every level. In turn, the AI could only call animations that were generic across the levels. The second area that caused AI problems was the addition of multiple skin pages, bolt-on accessories, gore, and death animations. Although not directly seen by most people as AI, all of these were important features for SoF. One of our main goals from the beginning of the project was to have lots of unique-looking enemies. This meant that our model was composed of many different skin pages into which we could swap different faces or outfits. We also implemented what we termed "bolt-ons": any item or feature that was not originally part of the model. These included Mohawks, canteens, briefcases, and side arms, which helped distinguish different characters. Implementing the gore was also very time consuming. We implemented gore zones that required skin page overlays, bolt-on models of viscera, the ability to remove limbs, and all of the blood pools and spatters that litter the game. Finally, implementing the various death sequences also hampered the AI. In addition to all of the gore that we created, we also had to play one of several animations when an enemy died. Animations had to be called based on certain circumstances, such as where on the body the enemy was shot and what he was shot with. On top of all of that, adding the violence-lock system that would allow players to lock out the game violence meant that all of the gore and animations had to be able to be shut off if the player wanted. The third area that caused problems for the AI was its actual development. Along with the problems created by the per-level animation system, the AI also had to work with the game's scripting language. If the AI was tweaked in certain ways, it caused the scripting to break. Many times in the game, enemies had to be "frozen" in place while their script waited to be activated. If a player happened to see one of these suspended enemies before they were triggered, it obviously made the AI appear less intelligent. We had to come up with ways around these problems, and expended considerable time and energy to fix them. To make matters worse, the AI had a slight unpredictability built into it that caused scripted events to occur differently each time. Although unpredictability is good for gameplay, it had to be removed from the scripting element. Finally, a large amount of time was spent with the designers to build in hints for the areas (such as reactions of the enemies) and to specify which areas the enemies could traverse. At the beginning of the development we had "duck," "hide," "flee," and other commands that eventually were removed and taken over totally by the AI. The AI was in development until nearly the end of the project. 3. Too many OEMs and demos. Something that seemed like a great idea at the time but turned out to hurt us in the end was the decision to make specific OEM releases before the game was truly finished. The main reason for this was that we looked at the revenue that would help the bottom line instead of considering how much it would set back the game. Because there were both regular and low-violence versions of the game, we needed to make several different builds for the different violence levels and test each build accordingly. In the end, we had roughly 75 QA submissions. While each OEM and demo iteration helped bring more of the game together, it also diverted our attention from the final product. As we were tweaking and fixing the OEM versions, full production would come to a standstill as we focused on getting the smaller versions out the door. 4. No fixed deadlines. Originally, SoF was scheduled to ship in July 1999. Activision wanted to avoid releasing SoF in the "blast zone" of competing FPS titles that were shipping that year, so they extended the deadlines on the game. As our competitors' titles were pushed back, so was SoF. Although within these deadlines we had schedules set up and planned out, this caused a never-ending uncertainty of how much time we had left in the project and how much technology we could add or change within that time.
In March 1999, we realized that with our complex models and the amount of animation we wanted, we needed to address memory concerns. Because we thought that we only had three or four months left of core development at that stage, we concluded that switching to a skeletal system would be too risky for the project. Instead, we created a vertex compression system that mimicked the benefits of skeletal compression in a few ways. Unfortunately, this meant that we were not able to provide all of the animations at once, as we would still be over memory budgets. If we had known that our deadlines would be pushed back another six months, we would have added the skeletal system, saving everyone a large amount of headaches and work. 5. Miscommunication about some technologies. Confusion over project scheduling aside, additional technologies were developed during the course of the project that were never truly planned out appropriately, such as the terrain engine, the in-game effects editor, and the scripting system that we used. All of these technologies served to improve the game substantially, yet they could have worked better if they had been properly discussed between the team members. The terrain engine, while flexible enough to do various types of visual effects, was never properly coded into the gaming logic. The basic premise of the terrain engine was that the designers would create architecture that represented the portions of the world that the player could interact with. For example, on the train level, the train was created by the designers. The terrain engine would then be responsible for the scrolling polygons, in this case the train tracks and surrounding landscape. When we put this level in, we soon realized that we needed a bunch of special code to handle the various effects, such as when a person falls off a train. We wanted to add more unique kinds of levels like this but we didn't have time to develop a generic physics system for handling other types of terrain, such as water where bodies might float or sink.
The effects editor was created by one of the programmers to help him create visuals for the weapons. The interface, while functional, was crude. Other people wanted to create visuals, including designers, but were hampered by the editor's interface design since it was never intended to go beyond the programmer who created it. Although the in-game editor allowed someone who knew the tool to create a special effect quickly and efficiently, it had a long learning curve for those not familiar with it. This reduced the amount of control that the artists had over the effects. SoF shared the same scripting language that Heretic 2 had used. It was originally developed to give designers more control over their levels, but we soon learned that we would need to add more and more power to the scripting system. SoF's complex scripting soon overwhelmed the scripting language and too much time was spent trying to tweak out sequences. With the addition of in-game cinematics (an unplanned feature not included in the design document), we realized that the way we were using the powerful scripting language was wrong. If we had planned better from the beginning, the scripting would have gone much easier. Unfortunately, since the story was planned so late, we didn't know at the time what would be needed. ________________________________________________________ |
|
|
Features
