Page 5 of 6
Areas for Improvement Some of the contingencies in our risk analysis ended up being used, and probably spending additional time up front with the technical risks and contingencies could have saved us some valuable time later. It wasn't that we didn't have a nice technical design document with detailed risk analysis, but at 20 pages, it probably could have used an additional, more detailed pass. I think we were hoping to benefit more from the Arcanum engine than we did. I am not sure the ratio is quite one to one, but it seems like for every good reason you find to use an existing engine, there is another to rip out the old code and rewrite new stuff from scratch.
Probably the single biggest thing that did not work out perfectly and had far-reaching consequences was our desire to stick to the original ToEE module very strictly. The first and most obvious thing affected here is the story, which didn't provide us much to work with. Tim did a great job finding one-sentence descriptions of characters and building whole quests around those, but this didn't address some of the obvious questions like why the party is there in the first place, and why they should be the ones to go and investigate this old Temple. We tried to patch some of that in through the opening vignettes, but as it was not part of the original design, I don't think enough time went into building ongoing story lines for each of the alignments. Although I think we missed opportunities to give some of additional background about the Temple and the surrounding areas from some of the early NPC encounters in the game, there really just wasn't much in the original module.
The other big problem caused from sticking with the original module was that the dungeon maps just don't translate well to an isometric computer game. Making lots of 10 by 10 rooms to fill in every space on your piece of graph paper might be cool for your pencil and paper experience, but you can't even see the ground in the computer game. Needless to say, we had to scramble a LOT near the end to widen hallways, combine rooms and knock down walls (I kept thinking of the quote from Johnny Dangerously, "this place is too small, we need to knock down that wall, knock down that wall, and knock down THAT fargin' wall.") Combining rooms often meant combining monsters and changing encounters a bit too. Had we re-designed the levels up front with our isometric view in mind, this time could have been spent much better on scripting some of the cooler special encounters such as unconcealing more monsters (like in the minotaur "statue" room), making Thrommel appear to be a vampire at first, having a falling grate in the pillared hall with the harpies, and other memorable encounters from the module.
Finally, I won't go into further detail about my problems with voice over, but that certainly is one area I look forward to doing in the next project with much enthusiasm. There are many things I will be doing differently.
Lessons Learned Here are a few obvious scheduling things that come to mind, but as evident as they sound, you need to make them a reality and not something you wish had gotten done when it's all over:
1. The more complex a game is, the more time you need to put into the schedule for testing. There need to be several milestones when a game is this complex that read "TESTING ONLY" as their milestone requirement. Our game went alpha one month, beta the next and final the next. Even though we got some testing before alpha, most of the testing didn't kick in until we hit alpha, which meant only two months for full testing. Outside beta testing might even have been a good idea to pick up some of the more complained-about features such as NPC looting and full magic item descriptions.
12:00 am PST November 25, 2003