     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Postmortem: Big Huge Games' Rise of Nations What Went Wrong 1. Not listening to all the other Postmortems ever printed in Game Developer. The Postmortems are the most widely read feature in Game Developer around Big Huge, and yet somehow we still managed to make many of the mistakes developers are cautioned against in these pages. We underestimated the amount of coding time necessary, which resulted in an extremely overworked programming staff. We misjudged the amount of revision time that we'd want for various systems. We overloaded our lead programmer such that he became the bottleneck on a number of critical systems, including multiplayer and matchmaking. Most of this could be traced back to simply not hiring enough programmers early in the project, and was compounded by lack of scheduling and technical oversight. We also never knew what was "enough" - since this was our first project in the RTS world, we were desperate to cram everything in that we could think of. For the next project, we will certainly hire more programmers and not schedule our lead programmer for anything other than management and support, with the expectation that he will have some flexibility to jump in and help out wherever it's needed. We also expect that we'll have a much more straightforward perspective on scheduling to meet our goals.
Another classic blunder (comparable to getting involved in a land war in Asia) was in undervaluing single-player tool creation. We always assigned our most recent programmer hire at any time to be the "scenario tools" guy, meaning we not only always had our least-experienced team member doing that work, we also had no continuity since we'd pass the torch each time we hired someone new. The editor also suffered grievously from several revamps of the game's terrain system and other parts of the engine. Hence, we had a great deal of difficulty creating single-player scenarios, and we were very fortunate to have the Conquer the World campaign turn out as well as it did. In the last few weeks of development, programmers Ike Ellis and Scott Lewis finally whipped the editor into shape with some intense hours and smart coding, but for the next game we will have someone working on this module early and throughout the project. This task will also be easier because we'll be working from a more mature engine. 2. No clear idea of the kind of game we were making. In the first year, both we and the publisher waffled back and forth on whether we should be doing a "classic" RTS game, a completely new kind of strategy game with some real-time elements, or something in-between. The prototype would swing back and forth between those two poles. Eventually, external events (such as the release of Empire Earth and Microsoft's purchase of Ensemble Studios) made it clear that a straight-down-the-line "classic" RTS was not the right game to be working on, but not before several months of work on art and game design were wasted going back and forth. For the next game, we have a much better sense of what our style of game should encompass - epic scope, strategic depth, and large armies clashing - and hopefully we won't have to be so concerned about standing in the shadows of the other giants of the genre. We've also got a much stronger sense about what works and what doesn't in an RTS game.
3. Hard time finding the look from the art perspective. Partly because of the preceding problem, we took longer than usual to nail down an art look for the game. Among other issues, it took us some time to decide whether we'd be fully 3D. The rest of the market was going full 3D, but we really loved the detail and crispness that 2D offered for things such as building graphics. The only engine feature we would give up to go 2D was the ability to rotate the camera, which we'd never found to be very useful in RTS games anyway. However, there was also a lot of hand-wringing about whether we'd be considered behind the curve graphically. We did numerous tests with 3D and discussed the issue with marketing, but in the end we went with a 3D engine that utilized 2D for buildings. We've been happy with how the game looks and think the high detail on the buildings adds a lot to the world. Next time, we'll do a lot more prototype art and concept work before going into full production, and we'll be more confident diving into a fully 3D world off the bat. Having an experienced, full staff will also help with this issue - at the beginning of Rise of Nations we made do with just a couple of artists. We were also faced with the classic dilemma of doing a history game - it's hard to differentiate yourself from earlier products when you are drawing from common source material. A pikeman looks like a pikeman, no matter how radical an approach you try to take. For the most part, we attacked this issue on the marketing end. We focused on creating screenshots from the later eras of the game and highlighted the diversity in cultural art sets from nations that hadn't been covered as much in other products. Art leads Bill Podurgiel and Ted Terranova worked hard to create units and buildings that were both realistic and varied, ultimately helping to help differentiate the look from that of other products. 4. Solo scenario meltdown. When we started work on Rise of Nations, we assumed that the single-player game would feature classic RTS-style linked scenarios that followed a nation's history over time. However, we started work on those scenarios and found that they just weren't particularly appropriate for our subject matter - it's not a lot of fun to take a game about all of history and then constrain players to a smaller canvas and scope. This approach also did not play to our strengths as developers; we are more interested in creating open-ended and infinitely replayable experiences than in making a scripted, linear campaign. Our prototype design process ended up helping the situation. Starting from scratch, programmer Ike Ellis coded up the skeleton of the module that would become Conquer the World, which aimed to bring context and meaning to linked scenarios that change depending on choices the player makes throughout the game. This campaign mode went from a prototype experiment to a central selling point for the game in less than nine months, and we are planning a new version of Conquer the World for the next game.
5. Refusal to acknowledge the true state of the game in the final months. Our insistence that we could power through our bug counts at a faster-than-light clip meant that we worked our team much harder than we should have going into the final months of the project. There were a couple of modules that were going to cause us to slip by the month that we did, and recognizing reality sooner would have saved much of the team a death march that was extremely difficult for all involved. On the next project, we'll retain our faith in our programming team while making more effort to be up-front with ourselves about the status of the project at any given time. Specifically, we need to pay more attention to our bug counts as reflective of the state of the project. We will also be more careful about not calling something "done" until it is truly "done-done-done," and adjust our schedules and expectations accordingly.
It Takes More Than Effort We're
extremely happy with how Rise of Nations has turned out.
We started the company with a vision of how games should be created
and how teams function best. In the end, the only tangible validation
to our approach is the quality of our games. We said many times
during the project that the gaming public only rewards success,
not effort; we hope that Rise of Nations demonstrates our
commitment to both.
[back to] Introduction |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Features
|
|
|