The
Design Guidelines
One
thing we definitely didn't want to do with Baldur's
Gate II was make some of the same design mistakes
that we had followed with the original game. Since
some our team members were brand new, and since
many of our (the authors') memories seemed rather
porous, we decided to make up a set of 'guidelines'.
While each department had its own set of guidelines,
the level design guideline was by far the largest,
as it was the area with the most room for improvement
in Baldur's Gate II. Below is a truncated
version of the guideline used by the game designers:
Basic
Design Rules:
-
The
player must always feel as if it is HIS actions
that are making him succeed. He should feel
that through his smart decisions and actions
that he has solved a puzzle or battle.
-
The
player must feel as if he is having an effect
on the environment. His actions are making a
VERY visible difference with how things are
running in the game world. His actions have
consequences.
-
When
designing, a good and evil path must be considered.
Several plots should be marked as changing according
to the player's alignment.
Story
Design:
-
The
story should always make the player the focus.
The player is integral to the plot, and all
events should revolve around him.
-
It
is important that the player is kept informed
about the progress of the villain. This can
be done through cutscenes during chapter transitions,
or through integrating him/her into the main
plot from time to time.
-
It
is important that there be a twist in the story
(or even more than one). This is where a revelation
is made to the player that makes him reevaluate
what's going on with the story. All of the twists
should involve the main player. Twists that
the player figures out on his own are also better.
-
It
is good to keep the ending of the story open
ended, especially if a sequel or expansion packs
are being planned.
Environment
Design:
- The
game world should be divided into chapters. Each chapter
should be of equal size and exploration potential. Each
of these chapters should have a rather obvious goal, but
one that the player can achieve in any fashion that he wants.
- Certain
areas should be marked as core areas. These areas are usually
towns or similar places that the player will be returning
to often. Core areas should change as the environment changes.
As the player performs actions in other areas, there should
be changes to reflect this in the core areas.
- The
player must always feel that he or she is exploring interesting
areas. This means that areas always need to have a unique
feel to the art.
- It
is not a good idea to have the player moving between areas
often. This becomes annoying. Plots should be kept within
the confines of a single area.
5. It's good to show things to the player that he cannot
use or places that he cannot go. Later on, these objects
or places will become enabled.
Game
Systems Design:
-
A
well thought out reward system must be created.
The player should be rewarded OFTEN during the
course of the game. These rewards can come in
the form of XP, items, story rewards, new spells,
new monsters, new art, romances, etc.
-
It
is important that the player is able to personalize
his character. This means that he should feel
that the character he is playing is his own.
-
It
is important that the world reflect the ways
in which the player has personalized his character.
Writing Guidelines:
-
No
modern day profanity. This excludes lesser profanity,
i.e. damn, hell, bitch, bastard.
-
Each
of the dialogue nodes (dialogue piece) spoken
by an NPC should be limited to two lines. Only
in VERY RARE circumstances are more than two
used.
-
All
character responses should be one line when
they appear in the game. There should be no
reason for them to be longer than this.
-
Try
not to use accents in dialogue. For certain
characters (Elminster, sailor types) it is all
right, but for the most part it should be avoided.
-
When
using player choices, try to keep the visible
number to about three. Two or four are all right,
but only when really necessary.
-
When
an NPC talks directly to the main player, this
should be noted for scripting purposes. Other
dialogue should be included for when someone
other than the main player talks to this character.
-
Random
dialogue should be avoided, or at least used
sparingly. Commoners should have only a few
random dialogue lines, but there should be several
different commoners to talk with.
There
are a few important points to be made regarding
these guidelines. First, they were a work in progress,
and the version you see here is not the version
that we used at the beginning of the development
process. Second, we considered them as a set of
guidelines, not the absolute law. If a situation
dictated the guidelines not be followed, and it
made sense to do so, the designers were given
the latitude needed to follow their creative goals.
Sometimes this worked and at other times it didn't.
In
retrospect, it would have been very helpful to
have this finished set of guidelines at the start
of the project, rather than at the end. A number
of decisions that were made very early in the
development of Baldur's Gate II did not
follow the guidelines and could not be undone.
Most noteworthy was Chapter 2 of the game - it
included a story segment that was similar to those
in other chapters, but in Chapter 2 the player
could also access all of the class-specific subquests.
This led to Chapter 2 potentially dwarfing all
other chapters in length because the players could
spend 60 hours doing subquests. We needed to put
the subquests at a point where all players could
access them equally, but end result was that it
bloated an early section of the game. In the end
there was nothing we could do to fix the chapter
disparity so we simply worked around it.
Another
major problem area related to the programming
constraints that had been established early on
in the project not being followed in all cases
by the other departments (design and art). For
example, we had audio file maximum sizes established,
and maximum sizes (both in area and number of
frames of animation) set for spell effects, as
well as a maximum area size of six by six 640x480
areas and a maximum number of characters per area.
In some cases these guidelines were not followed
which lead to framerate slowdowns at some points
in the game. This lead to some frantic optimization
efforts needed to get the game playing faster
near the end of the development cycle when little
time was available neither to identify the problem
areas nor to fix them.
The
lesson we learned here was to establish development
guidelines, follow them, but also continually
work on refining the guidelines based on the progress
of the game.
Improve
the Pipeline
One
of the most important elements of any game development
process is the art and content pipeline. The pipeline
is the means by which artists and designers put
their content into the game. Essentially the pipeline
for Baldur's Gate II remained the same
as it was in the original Baldur's Gate.
In BG1 the pipeline started off looking
rather nebulous, but had solidified into a concrete
operation by game's end. With Tales of the Sword
Coast (the BG expansion) we had another
4 months to refine the entire content creation
process.
There
are four basic divisions in the Baldur's Gate
pipeline: programming features, movies, in game
animations and game levels. The largest and most
complex of these is the game level pipeline. Going
into BG2 we had an 8-stage process that
we followed when creating levels for the game.
The process for creating a game level was:
-
Designers
map out an area and write up a description.
-
Concept
artist draws an isometric concept of the level.
-
Models
are created for the level.
-
Models
are placed within the level and then textured.
-
The
level is dressed with smaller objects (barrels
and chairs). Lighting is done for the level,
and then any final tweaks are completed.
-
The
art piece is given to the designers so that
the clipping, luminosity, height and search
map can all be done.
-
Creatures,
items, traps and triggers are all added to the
level.
-
The
scripting for the level is completed.
By
the end of the project we had found several weaknesses
in the overall procedure. We found that we needed
a better way to document the changes that were
made to a game level during development. We had
tried to keep our word documents as up to date
as possible, but with the amount of people involved,
and the enormity of the game, it was nearly impossible
to keep these documents completely accurate. Some
elements of the large team worked independently
from each other - designers sometimes didn't interface
adequately with artists resulting in missing elements
in the game areas and different naming conventions
between art and design, potentially a huge problem
when you consider that BG2 had hundreds
of areas and thousands of creatures and pieces
of individual art. Improvement of the integration
between different disciplines (programming, art,
design, quality assurance, audio, etc.) is a now
goal for all of our projects. For example in Neverwinter
Nights we have a database (called the Event
editor) where we keep track of all changes to
a game level so that developers from various areas
can all simultaneously be aware of the specific
status of game content.
Another
oversight in the Baldur's Gate II level
design process included the lack of a specific
early testing stage (effectively the ninth stage
of area development). Early testing of a game
level would have allowed us to make changes and
tweaks while the level was being developed, when
it was still relatively easy to modify, rather
than doing it in the final QA pass. This would
have streamlined the final testing process. Instead
we didn't start testing until large sections of
the game were fully content complete. While Baldur's
Gate II was in development we added an in
house QA department and to BioWare in order do
more early testing. We can now run game levels
through this department as soon as we have a working
version of the level and fine tune it earlier,
rather than later. Much QA support also was provided
by our publisher Black Isle/Interplay, in that
some QA testers visited BioWare for the last few
months of the project and additional QA testing
occurred down at Black Isle/Interplay.
Interestingly,
we did such an excellent job at automating the
level development process that there was little
time to review a game level as it went through
the stages. A designer might submit a level description
and receive it, art complete, a month later ready
for scripting, but missing some key features (almost
always a door). We would then have to determine
whether the omission was important enough to have
the art piece redone, or whether we could simply
tweak the design of the level to fit the finished
art. Again, this relates back to the issue of
integration of the disciplines, something we will
perpetually work on with our large scale RPG projects.
During
the development of Baldur's Gate II we
added Line Producers to assist the three Producers
in maintaining team communication and task tracking.
By its end, Baldur's Gate II had a Line
Producer/Designer assigned to making builds of
the game and managing BG2's gigantic resources
and another Line Producer responsible for the
thousands of bugs on the bug list. We added a
third Line Producer near the very end of the project
to work on compatibility issues and to help with
answering technical questions on the [email protected]
support email.
We
learned to make sure all elements of the team
are talking to each other and working as a group,
rather than as a bunch of individuals!
Manage
the Mid-Project
During
the development of any game, no matter how cool,
there comes a time where people have been working
on it for a long time and they start to tire of
it. This mid-project doldrums period has to be
managed very carefully, with attention paid to
the individuals involved. In the case of BG2,
our situation was complicated by the fact we had
a shiny new project in the form of Neverwinter
Nights (also with Black Isle/Interplay as
publisher) in production just across the hall,
and another cool new project in the form of our
Star Wars RPG (with LucasArts as the publisher)
also recently underway.
At
BioWare we like to have monthly events for the
entire company - like going to a movie or having
a barbecue to give people a break by taking them
out of the office. It's our way of pointing out
we're still in this business for the joy of it
- we're making games, and we should be having
fun!
For
the Baldur's Gate II team specifically
we spent a lot of time talking to people throughout
the project, especially at the mid-project low-point,
in order to make sure we were providing enough
support for the people who were slaving away on
the game. We also shifted some people around -
one of the major benefits of being a larger developer
is that we have multiple projects arranged in
a matrix organization, and at any given time there
are likely a few people that wouldn't mind switching
games. Also certain people are "starters"
while others are "finishers" - it's
important to understand each individual and tailor
their tasks to their working style.
The
lesson we learned was to beware the mid-project;
morale can take a precipitous drop before it again
climbs when people see the light at the end of
the tunnel.