Making Neverwinter Nights: A Classic BioWare Postmortem
-
Category: News ArchiveHits: 5961
Although Baldur's Gate was intended to have multiplayer support from the beginning, we did not actually start programming the multiplayer systems until relatively late in that project. As a result, some of the multiplayer aspects in Baldur's Gate such as forcing all players to see all dialogue were less than optimal.
In Neverwinter Nights, the multiplayer systems were integrated directly into the original design. Even in singleplayer, the game acts like a multiplayer game with a single client attached. Although this deep integration increased the time to develop each system (compared to a single-player-only system), it did result in an overall reduction in the time required to integrate multiplayer and ensured that all the systems were optimized for multiplayer play.
One useful lesson from both the Baldur's Gate series and Neverwinter Nights was how much time QA testing of a multiplayer game takes compared with testing just the single-player game. We have found that three to five times as much testing is needed for multiplayer role-playing games compared with singleplayer. Thus we require 30 to 50 testers (including both on-site and external testers) on our multiplayer projects for three- to six-month periods not a small undertaking.
...
A large RPG such as Baldur's Gate or Neverwinter Nights requires a similarly large amount of art, design, and programming resources. One of the problems that we encountered was what to do while the new game engine technology was being developed. Due to our schedule, we needed to start working on art and design assets right from the beginning of the project. The problem was that it took the programming team three and a half years to complete the game systems. Thus the art and design teams had to make assets based on technical specifications derived from early prototypes. As the game progressed, many of these specifications changed, requiring some assets to be rebuilt, or else workarounds had to be adapted in the game code to allow for old and newer assets to work together.
In an ideal world, the length of the project would have been longer, with the programming done at the beginning with only a skeleton team of artists and designers to provide prototypes. Full production would have then gotten underway once the engine was complete. Unfortunately, this was not feasible due to schedule limitations and interproject scheduling pressures. We have found that when we are reusing or building on an existing engine framework, art and design can be completed with little risk of having to rework resources problems like we encountered on NWN seem to occur mainly when we are creating a new engine from scratch (we encountered similar issues during the creation of Baldur's Gate, for example, but not during the various BG derivatives), and we are keeping this in mind as we schedule new projects in the future.
...
To ship a game that takes five years to develop takes a fair amount of intestinal fortitude. You really can't second-guess your decisions or you'll have no chance of ever completing the project, so the leads of the project agonized over some late feature additions to Neverwinter Nights. Given that the game was in development for such a long period, we were all concerned it might look dated by release. To combat this issue we laid out a plan to add a number of high-impact but relatively easy-to-implement features late in the development cycle to improve the game's visual quality. These additions resulted in constant concern among the artists who had to generate the new art required to support the late-added technologies. In the end it all worked out because of large personal efforts by many team members.
From the start there was a strong desire to make NWN a unique game distinct from the Baldur's Gate experience. While this did lead to the development of new systems that were better than those of Baldur's Gate, it also led to an excessive amount of time spent on design and prototyping of features that ultimately could not be implemented. We'd often sink a considerable amount of research into creating an innovative system, only to fall back on a similar system that worked better in the earlier Infinity engine.
Too often we were determined to start at square one, instead of expanding on what had worked with our previous games. We learned that it is important to choose our battles. In the future, when designing a game set in a genre that we have experience with, we will look more closely at what has worked well previously and aim to innovate only in the areas of our past games that our fans and critics perceived as weak.
