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).
the resounding success of Baldur's Gate, BioWare began
the development of Baldur's Gate II and 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.
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.
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.
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.
a Feature List
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.
resolution (800x600 and up).
support for 3D graphics cards.
dialogue in multiplayer.
off panels in the interface.
new character kits (subclasses) for all classes.
wielding of weapons.
(more detailed and more frames) character animation.
of all of the 'famous' AD&D monsters, including
the most famous of all, the dragon.
up to 9th level.
Journal, annotatable Map.
interaction on par with Final Fantasy.
evil and good paths to allow for alignment-based roleplaying.
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.
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.
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.
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.
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.