Introduction
Just over two years ago Baldur’s Gate was released. It was the culmination of nearly 90 man-years of work by a number of inexperienced, but very talented and creative individuals at BioWare. BioWare was a Canadian game developer, with only a single title (Shattered Steel) to its credit prior to Baldur’s Gate. Published by Black Isle Studios (the internal RPG division of Interplay Productions), Baldur’s Gate was the next in a line of famed RPGs that included the venerable Bard’s Tale and the highly respected Fallout, both developed by Black Isle. Baldur’s Gate beat the odds and was both a critical and a commercial success (it collected nearly all of the industry’s PC RPG of the year awards and a few “Game of Year” awards, and it has since sold about 1.5 million copies worldwide).
After the resounding success of Baldur’s Gate, BioWare began the development of Baldur’s Gate IIand set out to prove the magic of Baldur’s Gate could not only be repeated, but that a great game could be made even better.
The Challenge
Building an excellent sequel is not nearly as easy as it may sound. In making BG2 we knew everyone would be looking very carefully at the result. Facing comparisons with multiple great games using our BioWare Infinity Engine like Baldur’s Gate, Icewind Dale and Planescape: Torment (the two latter games both developed by our publisher’s Black Isle Studios after they licensed the BioWare Infinity Engine for this purpose), our work was cut out for us.
In developing a sequel, you must start with the right philosophy: the goal must be to make the game better, and not just to make the same game over again. You also need a mechanism to quantify your previous mistakes and learn from them. If you don’t make a point of figuring out what you did wrong last time, you’re not likely to fix it the second time around.
At BioWare we have learned to do thorough post-project reviews to analyze both the strong and weak development areas of our projects. The best way to start a sequel is to review and improve upon the processes used in the original. In the case of the original Baldur’s Gate, we felt we didn’t have adequate time to reach our design goals; we were simultaneously developing the BioWare Infinity Engine while creating the content in Baldur’s Gate. This lead to extreme pressure to have simple areas and game design. With Baldur’s Gate II, we resolved to allow the designers adequate time to allow the game to reach its full potential. We had learned to review our previous projects, learn from our mistakes, and apply these solutions to all new and ongoing projects.
The success of the original Baldur’s Gate set the bar for the sequel quite high.
Make a Feature List
Part of any design phase should be creating a feature list. Thanks to the AD&D license attached to Baldur’s Gate II, there were thousands of possible features we could add to the game. This being the case, our challenge was to determine which features to add. We used two routes – the first was to make an internal list (generated by BioWare and our publisher Black Isle/Interplay) of what was feasible and reasonable considering the engine, and the second was to ask the fans what they wanted to see. Fortunately in the case of BG2, a number of fans on the newsgroups already had done much of the work for us, and compiled a list of what they wanted to see in BG2. This list gave us a sense of what our hard core fans were expecting, and helped point us in the proper direction. The major feature list that we eventually came up with looked like this.
- Higher resolution (800×600 and up).
- 3D support for 3D graphics cards.
- Non-pausing dialogue in multiplayer.
- Drop off panels in the interface.
- Multiple new character kits (subclasses) for all classes.
- Faster character movement.
- Dual wielding of weapons.
- Improved (more detailed and more frames) character animation.
- Inclusion of all of the ‘famous’ AD&D monsters, including the most famous of all, the dragon.
- Spells up to 9th level.
- Streamlined Journal, annotatable Map.
- Deathmatch mode.
- Character interaction on par with Final Fantasy.
- Character romances.
- Definite evil and good paths to allow for alignment-based roleplaying.
We added several features as the game went on, including a new race (the half-orc) and three new classes (sorcerer, monk and barbarian) plus a myriad of character kits. Very few features had to be cut or weren’t implemented in a fashion that worked as well as we hoped they would.
The half-orc was one of several new features added as the game went on.
One thing we did not do was to rank the game features into simple classes such as essential, important, less important, etc. When it came to making feature decisions we opted to keep as many as we could but we didn’t have an agreed upon list or mechanism to resolve the decisions. Fortunately we were using a mature engine that we had developed so adding most features was relatively easy. However we certainly can’t claim that all of our decisions were enlightened.
Deathmatch was a feature that should have been cut early on, but persisted until close to the end of the project. It then became obvious that the ship date would have to moved back in order to accommodate deathmatch. Considering that multi-player code was some of the most fragile in the engine, and deathmatch wasn’t being very well received by QA, we reluctantly decided to cut it.
Non-pausing dialogue was the most problematic feature. Early in the project it was cut due to time constraints. In early 2000 we decided to add the feature back in, as the amount of dialogue in the game was making multi-player very frustrating. Looking back, this was probably the wrong decision. Most of the dialogue had already been written under the assumption that the game paused in dialogue mode. We had to create a hybrid system where plot critical dialogue would still pause. Our changes to the multi-player code also created several instabilities that led to some very late nights for the programmers.
The lessons we learned included the need to make a feature list, ranking features in order of importance and as well noting which features could be cut if needed. We also learned to not reverse decisions lightly – reversing a development decision should be considered only if it is absolutely essential and then only after being carefully considered.
