     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Postmortem: What Went Wrong 1. Over-Documentation. The game design document for Big Mutha Truckers was excessively large. It had to cover all areas of the game, such as the gameplay mechanics of the driving sections, the trading and background economic model of the world, win/lose scenarios, special mission scenarios, character profiles, and in-depth descriptions of all of the game's locations. Due to the sheer volume of descriptive text required, the design was written much more like a screenplay or "game bible," and concentrated more on characters, the environments and the various scenarios within the game. The design was also written as an in-house marketing tool, to help sell the concepts. As a result, instead of concentrating on the "hows" and "whys" of the game's production, it was instead focused on the "whos" and the "wheres." This, combined with the fact that the information relevant to a particular section of game was not always contained in one area, but often spread out over the entire document, meant that staff not only had to "extract" the tasks from the document, but also that, because of its size, they found it difficult to take the time to fully read the document.
We have since reorganized the way we produce designs, with each team given specific documentation relative to their area of production. A "standard" game design document is produced to detail the story, the visuals of the characters, and the locations and other content-related elements. That document is then broken down further to detail the specifics of each area for each team. The technical design document is also produced as a separate document, covering not only the technical side of the game (such as detailing how each element will function). but also a risk assessment of each element. We
also have created a collaborative intranet web site (a Wiki - see
Jamie Fristrom's
recent column for more information about Wikis) to aid sharing
information. This is proving to be an invaluable way to keep important
documents in one place and track changes within them. Any changes
are automatically flagged on the home page, so everyone can easily
see when a relevant document has changed. While this is invaluable
for internal development, the game design document is still essential
and is available to all staff as part of our shared resource library.
2. Resources Focused on "Obscure" Content. One of the main problems with Big Mutha Truckers was the fact that our content -- and allocation of staff to its development -- wasn't as efficiently distributed as it could have been. There are many spectacular, one-time events within the game which took a lot of resources to implement, but they're not obvious and often difficult to find, so players don't often see them. Our design intention was to include a lot of replay value, so we deliberately had some elements of gameplay that required the player to do a little more work to find them or replay the game and take a different "route" to uncover them. For example, at one point players are given the opportunity to accept a mission that involves destroying a large suspension bridge. However, to qualify, they must be in a certain location on a certain date, having completed a certain number of missions prior to this. In other words, the criteria required to qualify to take part in this mission - and see the outcome - were far too complex. As a result, there are a number of events that most players will never encounter. Not only is this bad from a gameplay point of view, but it also means that in-house resources were misspent on infrequent game events or content, when they could have been more focused and used on the "everyday" content. Rather than concentrate 50 percent of our output on content 10 percent of players might see, we should, instead, have catered to the majority of players. An example once more of Pareto in action. We have since re-evaluated our approach to content within our games and our designs/game flow layouts work on the principal of allowing the player to encounter the special one-time events more readily and on using repeatable code, rather than squandering our efforts on elements players won't see. 3. Gameplay Balance. Throughout the game's development we discussed the primary focus of the game -- was it about trading or driving? How much of a challenge should there be in getting from city to city? Was finding the best price for your load the challenge, or did it come from on-road attacks? Were we aiming at driving gamers or strategy gamers? Our intention was always to make the game's primary challenge come from the trading side of the game, with the on-road action being secondary. The idea was that players would be rewarded for making astute purchasing decisions and finding the best place to make a profit, as we felt this added an additional element of depth to the game and differentiated it from other driving games. Because the economy was dynamic, we felt this made the game more interesting and offered much greater replay value, as no two games would be identical, especially when compared to an arcade game where players can learn the "patterns" of the enemies. However, when we demonstrated the game to people, they often would forget what they had just bought before leaving town and why getting $100 per unit more on their truckload of cattle was such a good thing. There were more interested in outrunning the police en route to their destination. Unfortunately, we planned a lot of on-road events (such as UFO abductions, redneck feuds and more) but didn't implement them, as we felt the trading to be the differentiating factor in Big Mutha Truckers and didn't want to dilute that. It seems that we were wrong and the game would probably have benefited from the occasional alien abduction. With
hindsight, more re-useable on-road activity would have made the
game more immediately rewarding to players and accessible to a larger
audience. This was addressed to some extent in the NTSC and later
European releases, with the player being able to pick up cash bonuses
by orchestrating crash combinations, but the initial European release
received some criticism for the lack of hazards en route.
Additionally we were working with a very small team of animators who were developing a lot of character models. A team of initially three people had to model, texture and animate over 30 characters in a short space of time. This meant the quality of the animations differed from character to character, with some being stronger than others. As there was a steep learning curve involved, some of the earlier characters weren't as well animated as the later ones, but we simply didn't have time to go back and modify them. We also had problems with the way data is exported from 3ds max, which forced our technology team to constantly re-write our exporter. In max, characters would move perfectly and look great, but when they were exported, much of the data would be lost or mangled, so when the characters appeared in game, their movements looked unnatural. Vital development time was spent trying to fix this, and as a result, we were rushed toward the end of the project. Seeing this problem, we assigned additional staff to our character team as the focus of the game shifted to a more character-driven title, and although the extra staff helped ease the workload and produce better results, we were still battling the deadline. Thankfully this situation has now been addressed by hiring animators and improving the abilities of our original staff, who were still "learning on the job" during the game's development. Additionally, members of the technology teams have been assigned to work specifically with the character team - in other words, we've improved the lines of communication between departments - and the two interact on a daily basis to solve problems and test new systems and routines before going into production. This pre-production period has helped "iron out" critical path tasks, where previously this time -- particularly for animation technology -- was not available due to key programmers being tied up for the majority of the project developing game engine and rendering technologies. 5. Managing "Greenhorn" Staff. At Eutechnyx we often hire graduates straight from university. Although they rarely have any commercial programming experience, we do this because not only are they highly qualified academically, they also don't bring baggage with them from previous development studios and haven't picked up any bad habits. Although this means we can shape a new programmer to fit our needs and work patterns, it also means that they require more help and supervision during the early stages of their tenure at Eutechnyx. The start of the development of Big Mutha Truckers coincided with the start of the current generation of consoles and was also a time of company expansion, so Eutechnyx had just hired a number of people who were new to the industry. Unfortunately, at the start of the project the experienced programmers were working on the technology that would be required to power Big Mutha Truckers - as it was our first PS2/Xbox title - and the less-experienced programmers were assigned the task of implementing this technology and adding content - in other words, coding the game content itself. As mentioned previously, the economy was developed independently of the main game and this was an ideal mini-project to give to our new programmers, who did an excellent job. However, after the integration of the economy with the main game, we should have reorganized the teams. In this instance the teams remained unchanged, with the majority of the game code being developed by new programmers and the technology by the veterans. Although each team size was relatively small, I believe if one programmer had been exchanged between the teams (each team consisted of about five programmers) the benefits would have been huge in terms of information exchange and accelerated learning. There big benefit to integrating technologists with the game programmers is the transfer of knowledge. Interestingly, we found that this transfer is bi-directional: a technologist may be so bogged down with VU code that he becomes unaware of high-level utility functionality that is obvious to the game programmer. Following this experience, Eutechnyx re-structured its teams and now has a technology department in addition to game teams. Many of the members of the technology department are now dedicated to a particular project, and our game programmers also perform technology tasks that benefit all projects. This crossover is working extremely well. When the next incarnation of game consoles arrive, I believe we will be much better prepared as a company to ensure that all our programmers will be busy producing useful code, while at the same time learning from each other. It's A Good Sign When The "Wrongs" Are Hard To Find… Overall, we were pleased with Big Mutha Truckers. Not to sound egotistical, but we actually had trouble coming up with five "What Went Wrong" items. We found it much easier to list the "What Went Rights." But perhaps that's because the game has a special place in our collective hearts as our first next-gen game. It also appears that the game has struck a chord with gamers looking for something a little different. In a market dominated with licensed franchises and sequels, it's reassuring and pleasing to see that there's also a place for a quirky, original title like Big Mutha Truckers.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Features
|
|
|