Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Micro Forte' s Fallout Tactics
View All     RSS
June 12, 2021
arrowPress Releases
June 12, 2021
Games Press
View All     RSS







If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

Postmortem: Micro Forte' s Fallout Tactics


April 20, 2001 Article Start Previous Page 3 of 4 Next
 

What Went Wrong

It might seem that given the scope of the game and the fact that we got it all done in 15 months that nothing could have gone wrong. Actually, plenty of things went wrong. We more or less completely redesigned the entire mission set in the last four months of the game's development. These are what I think were key blunders.

1. Incomplete design documentation and unrealistic design goals. Although our design specification gave a clear outline description of the game, it did not go into enough detail. This became very apparent in the final stages of the game when the level builders and programmers needed to know exactly what had to be done. There were problems with NPCs and PCs not being designed in sufficient detail, experience progression not being mapped out, not knowing how the quartermaster would behave, no information on how equipment should be released into the game, and other missing details. There were many areas that just were not designed at all. This meant that a lot of design had to be done on the fly by the people doing the implementation. I believe a flexible design is essential, but key design issues need to be nailed down before the programmers or scripters have to implement them. In our case, people outside of the design team ended up making the design decisions in a rather ad hoc manner. In any event, it went pretty well. I do not think there would have been any point in trying to design these things far in advance, but they should have been ready to go well before they needed to be implemented.

Character Stat GUI. We wanted to keep as faithful as possible to the original Fallout look so we copied the character stat GUI right down to the Pip boy illustrations for each stat. The fact that we had a very complete library of UI functions in the game engine made creating this GUI much easier although we really needed to have put some effort into GUI design software.

 

The game's design goals were another, more serious problem. When I joined the project I had the distinct impression that the game was going to be a turn-based RPG. As the game progressed, it became clear that this was not the case, and we started to move farther into the world of tactical combat and ultimately to real-time gameplay. The situation finally became intolerable in August 2000, when we attempted to produce our first single-player demo. The game absolutely stunk! It was obvious to all who played the game that this just was not working and at this point Brian Christian phoned my CEO and told him that the game did not play.

Our CEO stepped in and worked with us to help define what the game was actually about: tactics. He worked with our lead designer in defining key tactical elements that a level designer could pick and chose from in order to help design interesting tactical situations. We realized that the RPG element had to be peripheral to the game, and we concentrated instead on setting up carefully designed tactical situations for the player to solve. We started with just the opening section from the second demo mission and worked on that until it was fun to play. We gradually expanded this to the whole level. Over a period of a few weeks, we were able to turn the demo into a fun experience. By the end of August we had a finished level that was great fun and challenging to play. But the cost was further delays in the release date. The big problem was that by this time we had already started building game levels based on assumptions about how the game would be played, so most of this work was wasted. Combining this with the fact that the text had to be ready for localization and recording of voice-overs meant that we were unable to make all the changes we wanted. Eventually, we had to completely rewrite a large percentage of the missions with a substantial cost in terms of time.

2. Poor asset management. We used CVS for the source code, and this worked well, but we never came up with a good system for the art assets. Artists worked locally on their machines and then uploaded the finished renders onto the server. Level designers worked directly from the server, and at times this could be very slow. We had an ad hoc series of temporary and final directories where people kept work. Sometimes stuff got overwritten; normally it didn't. The other side of this was that we ended up taking a huge amount of server space up with multiple copies of redundant data. We ended up very short on file space, but we managed.

For future projects we will have to come up with a better system. It's a topic that is being discussed in many different places, so I guess a lot of other people in the industry are having similar problems.

3. FTP. Being located in Australia did not seem to be a major problem at the beginning of the project. We were able to talk to Interplay on the phone in the mornings, and if we had a substantial amount of stuff to send we could courier it over and it would take a few nights. It was not until we were due to deliver the first demo that we began to realize just how serious the problem of getting updates to Interplay was.

The fastest I could courier a disc to America was about four days. Using FTP was the only alternative, and FTPs from our location only managed speeds of about 5KB/sec. This meant it would take about two days to upload the complete game to Interplay, and that made it impractical to send the whole thing every time we produced another version. We had to send incremental updates and hope that the version that Interplay was testing had kept pace exactly with the version we had at Micro Forte. Up until a few weeks before we shipped I was still not sure how this would work. In the end, we had to lock our sprite and tile data down early and send that in the early version. Again we managed, but it was a constant source of concern for me, and we still had problems in the game that I am sure were caused by the versions getting out of sync. One of the main reasons I chose to spend the last week of the project at Interplay was to ensure that if things went badly I would be available to make sure that the version they had was sound. I made changes to voice-overs and sound effects at Interplay in parallel with those made by the development team at Micro Forte. We could have used a third-party patch program, but such programs can be very slow to execute, and towards the end of the project we were sending versions once or twice a day.

I think Australia is a great place to develop games and the FTP problems we had are actually not significantly worse than the problems any developer has when dealing with a publisher. The use of in-house QA really made a big difference here. Still, I think a faster FTP link is in order for our next game.

4. Unrealistic deadlines. Originally, we had 12 months from starting the design to delivering the gold master. If you take off a month for initial design and a month for QA, that only leaves 10 months for the development of the game. We made our first deadline, E3, but after that we were constantly slipping.

Our original art estimates were based on Interlay providing the model data for most of the in-game graphics, such as all the characters and creatures that had been created in the original Fallout 1 and 2. Once the project was started, Interplay informed us that it was not possible to retrieve the art from the tape backups they had. This meant that our original art schedule was blown away and we needed many more artists. We negotiated for more time and cash, but only received more money and no additional time. Fortunately, through our relationship with the Academy, we were able to hire six more artists quickly who were able to come right up to speed. Thanks to our illustrator Tariq, we were able to re-create from scratch all the creatures from the original series and the overall Fallout look.

Explosions. More death this time with explosions thrown in. We pre-rendered all our explosions. This scene shows a player accidentally detonating the explosives which raiders have placed on the generators. The object of the excersise should have been to save the lives of the civilians who are currently being cooked.

 

We tried to stick to the original schedule, but it became obvious that we could not possibly deliver in October. Interplay agreed to extended our deadline to February 2001. Micro Forte had made considerable financial investment in the game itself, on top of what was negotiated with Interplay. At this point, we had already invested in extra artists to try to meet the original deadline, so not only was our burn rate higher than we had planned, but it went on for longer. At the beginning of the project, the QA team and many of the 3D artists recruited for the project had been advised that there was no guarantee of ongoing employment after the game shipped. We tried to keep everyone employed, but ultimately we were left with a situation where we had no choice but to let half the art team and the QA team go upon completion of the game. We finally delivered the game in the first quarter of 2001, but even with the extra four months, it was a close thing. The game did come together incredibly fast in the last few weeks, but it was very tense for everyone concerned.

When I first joined the project I produced a Microsoft Project document for the game. The Gantt chart still hangs on the wall downstairs as a testament to the hopelessness of our original goals. Two weeks for pathfinding and six weeks for AI seem hopelessly unrealistic now, but at the time we had no choice if we were to meet our original deadline.

Another major headache for us was that Interplay wanted to ship localized versions simultaneously. From a technical point of view this was not a problem, and it actually helped us to design the game from the start so that we could plug in the voice-over and text without code changes. The problem was that in order to get everything ready in time to ship, Interplay had to start recording and translating dialogue months before the game was due to ship. With our tight deadline we still had a lot of unknowns in terms of what would and would not work right up until the game went into QA. Unfortunately, by the time we were able to focus-test and find flaws in the game, the voice-overs had already been recorded and we were effectively prevented from fixing some basic flaws in some of the missions. This was a shame, because we were very aware of how important it was to give the player plenty of guidance in the missions, and dialogue was the obvious way to do that. We also wanted all of the core dialogue to have voice-overs attached, so that made it very difficult for us to add new elements late in the development.

5. Too big a game and too much stuff. The unrealistic time limit problem was further exacerbated by the size of the game we created. Originally, 20 single-player levels and 10 multiplayer levels seemed a reasonable size for the final game. However, when we started to get flak from the Fallout fans about the game not being true to the original, we decided to link the missions together with a world map rather than a linear mission structure. This in turn led to the inclusion of random encounters and unique encounters to add extra interest while traveling between the core missions. We produced special levels for bunkers where you could reequip and change your squad. This works very well in the game but increased our workload substantially. We also hopelessly overestimated how big our maps needed to be. We ended up with some truly huge playing areas and the associated problem of having to populate them with interesting encounters. Rather than reduce the size of the maps or lose maps altogether, we decided to press on and fill them with interesting objectives. We estimate that to complete all the core and secondary objectives and see all of the multiple endings takes about 40 hours of playtime -- even for someone who knows the missions well.

We should have been far more brutal in what we were going to drop from the original Fallout. We inherited a lot of nifty ideas, but many of them simply did not work in the context of a tactical game. For example, we have something like 150 different weapons. This sounds good, but the time spent rendering them and making sure that each one had its stats set up correctly was time that would have been better spent play-testing missions. This led to another problem: we had so many objects that it was difficult to differentiate clearly between them. In fact, all of our pistols are almost completely useless in the game, as they do not do enough damage and offer no clear advantage over an SMG. The character stats were also overly complex for a tactical game. We have 18 different skills, some of which are very poorly differentiated, such as the difference between doctor and first aid (we had to change the original doctor skill completely to make it useful). In our defense, Fallout also implemented these things badly, but I think we should have played the original Fallout games in a much more critical manner, noting things that just did not work in the original and stripping them out. The golden motto should have been "If it doesn't do something useful or if there is another thing in the game which does nearly the same thing -- take it out!" We stripped out some stuff, such as the speech skill, but added far more than we removed. The huge selection of stuff on offer is one of the game's selling points, but it has affected the quality of the finished product. In the end, I don't think we have really kept the original Fallout fans happy, and we compromised the game design at the same time.

The size of the game also made QA very difficult. The problem is, of course, that every time the game changes the only safe way to test it is to start right back at the beginning. Because of the size of the game, that would have necessitated another 40 hours of testing after the final candidate was burned before it could ship. Time restrictions made this impossible, so the only way to test it was with the cheats enabled. Most of the obvious bugs were easy to spot in cheat mode, but the more subtle balancing issues only became apparent when the finished game was played through properly after it had shipped. The result is that some of the gameplay is rather obscure, and bugs have slipped in which can make it impossible to complete certain missions under specific circumstances. There are some missions where the whole map depends on finding one key in an obscure place, which is a shame because we had a very clear plan early on not do that kind of thing. There are missions which are almost painfully difficult to complete, resources such as medical kits and ammunition are also in rather short supply. Mind you, at least we don't have any jumping puzzles.


Article Start Previous Page 3 of 4 Next

Related Jobs

California College of the Arts
California College of the Arts — San Francisco, California, United States
[06.11.21]

Unranked, Adjunct Faculty, Animation Program
Insomniac Games
Insomniac Games — Burbank, California, United States
[06.11.21]

Technical Artist - Pipeline
Insomniac Games
Insomniac Games — Burbank, California, United States
[06.11.21]

Technical Artist - Pipeline
Insomniac Games
Insomniac Games — Burbank, California, United States
[06.11.21]

Technical Artist





Loading Comments

loader image