Gamasutra - Features - "Baldur's Gate II: The Anatomy of a Sequel" [05.02.01]

Baldur's Gate II: The Anatomy of a Sequel

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.



	*Concept sketch for a temple in Baldur's Gate II.*

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.



	We had audio file maximum sizes established, and maximum sizes (both in area and number of frames of animation) set for spell effects.

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.



	*Concept art for Baldur's Gate II.*

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.



	Baldur's Gate II inventory screen.

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 bginfo@bioware.com 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.


				\|\|\|\|

________________________________________________________