Postmortem: Micro Forte' s Fallout Tactics

What Went Right

It always annoys me when I read a game Postmortem and the author sings the praises of the team and game. I think we made a lot of mistakes, but we had an incredibly difficult job to do and we got it done -- eventually! We must have done a lot of things right; the following are just a few of the things we did well.

1. Game-creation tools. Right at the start, we recognized the importance of developing decent in-house tools and invested a substantial amount of time very early in the project to producing them. By January 2000 we had a level editor in place, and the artists could start placing tiles. This became the cornerstone of our level-production process. Over a period of a few months we produced a suite of tools, including a level editor, tile editor, and sprite editor, that we continued to develop right up until the end of the project. Because we did this early, the artists were able to start producing content for use in the game right from the start.

	Level Editor. This was the main development tool used for creating the game. Tiles could selected using the file browser on the left of the screen and dragged into a scene before being positioned in 3D space.

 

An unexpected benefit of this was that towards the end of the project, when the artists had finished creating the tiles for the game, they were also experienced in using the tools for placing them into the levels. At that point we needed to generate a substantial amount of content very quickly and achieved this relatively easily because we had good tools and a large team of people, all of whom could help with creating levels. The situation was further improved because it was easy to cut and paste within maps and between maps. We could have put more effort into our entity-editing tools, but on the whole I was very pleased with the tools we created compared to tools I've seen and used at other companies.

2. Working closely with the publisher. I spent a lot of time dealing with Brian Christian at Interplay. If he was happy, I was happy -- if he was pissed off, I did not sleep. I visited Interplay about once every three months for a one-week design and planning session. My reception at the first meeting was very cold, and I got the distinct impression they were not happy with the way the project was going. I went through the progress we had made and spent a lot of time reassuring them that we were addressing all of their concerns. Eventually, we agreed to have regular meetings either over the phone or with me traveling from Australia to L.A. During this time we were able to recap on what had gone right and wrong. Near the very end of the project, I went to Interplay and worked there for the last week. This way, I was able to see first-hand the problems their QA department were having and interpret them. I was able to fix minor problems with the dialogue and insert new data into the game on-site to save a lot of time. I think our relationship with Interplay was excellent, and I enjoyed working with them very much.

3. In-house QA. I was initially skeptical about the benefits of having a formal in-house QA process, but by the time the project was completed I was converted. The programmers were able to release versions to our QA first, and they in turn would identify key issues and request fixes before Interplay got hold of the versions. Because our QA was in the same office, there was a very healthy dialogue between QA and the programmers and mission scripters.

Toward the end of the project, the in-house QA really saved the project. The time difference between Micro Forte in Australia and Interplay in L.A. meant that the turnaround between Interplay's QA reporting bugs and receiving new versions was too long. Because our team was checking the bugs in-house and talking to the team directly, we saved literally days of QA time. We were lucky to have an experienced QA manager in the form of Jason Sampson with us for nearly the entire project, and he established most of the procedures which we would later rely on to get the product out.

4. Excellent team structure and discipline. Initially the studio lacked a strong structure. I came in as a lead programmer and Parrish was the lead artist. John De Margheriti felt that I should be promoted to producer. Karl was promoted to the position of lead programmer, and Ed was the lead game designer from the beginning. Paul McInnes, lead designer from our other studio in Sydney, made some very strong contributions to the overall level designs near the end of the project. The leads took complete control for what happened within their teams, and I only dealt with the team indirectly through the leads. This worked extremely well once we had got over a few initial teething pains.

	A group of Brotherhood of Steel members.

We had a large art team. This could have caused problems, but Parrish was excellent at maintaining the schedule. By the time we finished, the team had grown to 13 artists. We were very lucky in that Micro Forte is allied with the Academy of Interactive Arts, a training facility in Canberra that specializes in training 3D artists. From there we were able to recruit some of the most talented artists I've ever worked with.

The programming team, led by Karl, did a fine job under difficult circumstances. We had the good fortune of having a well-designed code base. A decision was made before I joined the company to largely rewrite the existing Chimera engine, and ultimately it paid off. The programmers were able to spend time putting a solid C++ architecture in place on which they were able to comfortably build new features. I was not involved in the design of the engine, which is one of the major reasons why I was never conformable in the role of lead programmer, but I know from the very small number of crash bugs reported by QA that the strategy adopted by the programming team worked. By writing from scratch they were able to get everything in place pretty much how they wanted it. I'm not a great fan of rewriting stuff for the sake of rewriting it but, I have to admit it worked in this case.

Game design was our only real weakness, but I think a lot of our problems came from muddled design goals that may have originated largely from outside the studio. There were no major personality clashes during the project, and everybody remained very motivated right to the end. I did ban Counter-Strike in the last three months of the project, but by that point we all knew what had to be done to get finished.

For the final few months there were a lot of long hours involved, but for the bulk of the project we managed to keep the weekends free and only had to stay late when a milestone was due to be released. Compared to other projects I've worked on, our working hours were very reasonable. I think the fact that we were still able to deliver in 15 months is living proof that working ridiculously long hours for a sustained period is not the way to get projects out on time.

5. Well-defined milestones and demos. Having a short development cycle and clearly defined milestones certainly helped us to focus, to say the least. E3 was our first deadline, and we were due to demonstrate a working multiplayer version of the game. This was a major achievement for us. It also provided a great boost to everyone's morale. After E3, though, we had a couple of rather weak milestones. During this time we did drift a bit until we were due to deliver our first single-player demo. It was obvious at this point that, in a space of about three months, things had gone wrong, and we concluded that we would not be able to get the game finished by October.

	Campaign Editor -- World Map. The last tool to be developed was the campaign editor. This allowed us to link all the missions together by placing them into the world map. The tool allowed us to set up the frequency of random encounters.

After this we reassessed the project and remapped our milestones. Once we had established attainable milestones, we were able to refocus. Our most important milestones became the single-player demo which shipped just before Christmas 2000 and the multiplayer demo which shipped at the end of January 2001. Both these demos could have been very disruptive with regards to completing the final game, but we used them instead to get game critical stuff finished. The single-player demo was the first time we used a focus group to test the whole combat system, and the results were very encouraging. The multiplayer demo gave us the chance to test the Game Spy support and get all the synchronization issues nailed down. Both demos were very successful in raising the public awareness of the game.