Designed by: Collin Oguro
By: Dr. Ray Muzyka and Dr. Greg Zeschuk, joint CEOs of BioWare and co-executive producers of Baldur's Gate II; James Ohlen, director of writing and design at BioWare and co-lead designer of Baldur's Gate II; with assistance from Brad Grier, BioWare communications manager
Designers must have enough time to allow the game to reach its full potential. Make a feature list, ranking features in order of importance and noting as well which features could be cut if needed.
Do not reverse decisions lightly--a development decision should be reversed only if it is absolutely essential to do so, and then only after being carefully thought out.
Establish development guidelines and follow them, but also continually work on refining the guidelines based on the progress of the game.
Ensure all elements of the team are talking to each other and working as a group, rather than as a bunch of individuals! Click for full size image 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.
Constantly look at the target date and adjust content development accordingly. In many ways, quality is more important than quantity. Even though Baldur's Gate II was bigger than Baldur's Gate, the content in BGII was still of a much higher quality--we just didn't realize how much more we had made in the sequel until it was too late!
Test early! Test often! You don't have the time at the end to test adequately.
Save some energy during the final crunch because you need it at the very end of the project.
Post-project support. Ensure development staff is designated to provide very quick (same day or as close to it as possible) technical support to fans--their goal is to make sure people who purchase our games can play them.
Support the fans who buy the games. This means shipping a bug-free product and being completely available to help people who are having trouble with our games--on message boards, via contact e-mails, and anywhere else you can think of. Next: How we learned it--the long version
In the beginning...
Click for full size image BioWare was a Canadian game developer with only a single game, Shattered Steel, to its credit. The first demo of Baldur's Gate was created at BioWare during the last stage of development of Shattered Steel, in January 1996. Titled Battleground Infinity, it bore little resemblance to [the final] Baldur's Gate, the game that some say revitalized the role-playing genre on the personal computer. 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 includes the venerable Bard's Tale and the highly respected Fallout, both developed by Black Isle/Interplay. Released in December 1998, Baldur's Gate beat the odds and was a critical and commercial success (Baldur's Gate collected nearly all the industry's PC RPG of the year awards and also more than a few game of year awards, and BG and its derivatives--the Tales of the Sword Coast expansion and Baldur's Gate II: Shadows of Amn--have since sold more than 3.5 million total copies worldwide).
After the resounding success of Baldur's Gate, BioWare began the development of Baldur's Gate II and set out thinking that not only could the magic of Baldur's Gate be repeated, but also that a great game could be made even better.
It was the best of times...
Click for full size image The BioWare development teams were flush with energy, enthusiasm, and excitement. Baldur's Gate and Tales of the Sword Coast were bona fide hits worldwide, and everyone was looking forward to the challenge of doing our best work yet.
But building an excellent sequel is not nearly as easy as it may sound. In making BGII, we knew everyone would be looking very carefully at the result. We faced competition and comparisons with great games, some of which were developed using our own BioWare Infinity Engine. Icewind Dale and Planescape: Torment, both developed by Black Isle/Interplay (which licensed the BioWare Infinity Engine from us for this purpose), are also very good games in their own right.
In developing a sequel, you must start with the right philosophy--the goal must be to make the game better, not just 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 conduct a thorough post-project review 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 found that we just didn't have enough time to reach our design goals, as we were simultaneously developing the BioWare Infinity Engine and creating the game content. This resulted in extreme pressure to have simple areas and game design. With Baldur's Gate II, we decided that the designers had to have enough time to allow the game to reach its full potential.
Next: Choices and lists abound
Click for full size image Any game design is, at one point or another, a collection of lists--lists of questions, lists of problems, and lists of features. In our case, the Baldur's Gate stories unfold in the Forgotten Realms, an extremely popular and well-documented setting in the Dungeons & Dragons universe. Thanks to the rich collection of existing D&D material, we faced the daunting task of choosing from thousands of possible features. Our challenge was to determine which features would let us create a game that met our high expectations.
We solved this problem in two ways: 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. The second was to ask the fans what they wanted to see in the game. A number of fans in related newsgroups had already helped point [us in the right] direction through a compiled list of desired features for BGII. This list gave us a sense of what our hard-core fans were expecting.
Click for full size image After combining and editing the two lists, we came up with the major feature list that looked like this:
1. Higher resolution support (800x600 and up).
2. 3D support for 3D graphics cards.
3. Non-pausing dialogue in multiplayer.
4. Drop-off panels in the interface.
5. Multiple new character kits (subclasses) for all classes.
6. Faster character movement.
7. The ability to wield two weapons at once.
8. Improved character animation (more detail, more frames).
9. Inclusion of all of the "famous" D&D monsters, including the most famous of all, the dragon.
10. Spells up to the ninth level for mages.
11. Streamlined journal, annotatable map GUIs.
12. Deathmatch mode.
13. Character interaction and romances on par with those of Final Fantasy VII and other great PC and console RPGs.
14. Definite evil and good paths to allow for alignment-based role-playing.
Click for full size image Additionally, we added several features as the game went on, including a new race (the half orc), three new classes (sorcerer, monk, and barbarian), and a myriad character kits.
One thing we did not do well was rank the game features into simple classes such as essential, important, and less important. When it came to making feature choices, we opted to keep as many as we could, but we didn't have an agreed-upon list or mechanism to make the decisions. Fortunately, we were using a mature engine that we had developed, so adding most features was relatively easy. Very few features were cut or implemented in a fashion that didn't work as well as we hoped they would. 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 would have been a very cool feature, and we wanted to keep it in the game. Once it became obvious that the ship date would have to be moved back in order to accommodate deathmatch--the multiplayer code was some of the most fragile in the engine at that time--and the deathmatch implementation wasn't very well received by our dedicated quality assurance (QA) staff, we reluctantly decided to cut it.
Next: Final design guidelines
Non-pausing dialogue was the most problematic feature. Early in the project it was cut due to time constraints. Then in early 2000 we decided to resurrect the feature, as the amount of dialogue-pausing/key-press-to-continue in the game was making multiplayer 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 and you pressed a key to continue. We had to create a hybrid system where plot-critical dialogue would still pause, but noncritical dialogue did not. These changes to the multiplayer code also created several instabilities that led to some very late nights for the programmers near the end of the project.
Click for full size image The lessons we learned included the need to make a feature list, ranking features in order of importance, and noting which features could be cut if needed. We also learned not to reverse decisions lightly--a development decision should be reversed only if it is absolutely essential to do so, and then only after being carefully considered.
Those who do not learn from history are doomed to repeat it.
The choices we made, and some of the resulting problems, proved to be a great teacher in the school of game development. In Baldur's Gate II: Shadows of Amn, we definitely didn't want to repeat the same design mistakes that we made in the original game. This time, a few of our team members were brand new, and since many of our (the authors', not the team's) memories seemed rather porous, we decided to make up a set of "guidelines"--lessons learned from the last game. Each department had its own set of guidelines, and the list of level-design guidelines was by far the largest. It was also the area with the most room for improvement in Baldur's Gate II. Below is a truncated version of the final guidelines, as they evolved through the game development process, as used by the game designers:
Click for full size image Basic Design Rules:
1. The player must always feel as though it is his or her actions that are making him or her succeed. Players should feel that it is through smart decisions and actions that they have solved a puzzle or won a battle.
2. The player must feel as if he or she is having an effect on the environment. His or her actions are making a very visible difference in how things are running in the gameworld. Actions have consequences.
3. When designing, you must consider good and evil paths. Several plots should be marked as changing according to the player's alignment.
Story Design:
1. The story should always make the player the focus. The player is integral to the plot, and all events should revolve around him or her.
2. 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 or her into the main plot from time to time.
3. 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 or her reevaluate what's going on with the story. All the twists should involve the main player. Twists that the player figures out on his or her own are also better.
4. It is good to keep the ending of the story open, especially if a sequel or expansion packs are being planned.
Next: Environment, game systems, and writing all need design guidelines
Click for full size image Environment Design:
1. The gameworld 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 or she wants.
2. 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.
3. 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.
4. 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 or she cannot use or places that he or she cannot go. Later on, these objects or places will become enabled.
Click for full size image Game Systems Design:
1. 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 experience, items, story rewards, new spells, new monsters, new art, romances, and so on.
2. It is important that the player is able to personalize his or her character. This means that they should feel that the characters they are playing as are their own.
3. It is important that the world reflect the ways in which the player has personalized his or her character.
Writing Guidelines:
1. No modern-day profanity. (This excludes lesser profanity, like "damn," "hell," "bitch," and "bastard.")
2. Each of the dialogue nodes (dialogue pieces) spoken by a non-player character should be limited to two lines. Only in very rare circumstances are more than two used.
3. 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.
4. 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.
5. When using player choices, try to keep the visible number to about three. Two or four are all right, but only when really necessary.
6. When a non-player character 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.
7. 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 guiding principles, not the absolute law. If a situation dictated they not be followed, and it made sense, the designers were given the latitude needed to follow their creative goals. Sometimes this worked and at other times it didn't.
Next: The pipeline is revealed
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 players could spend 60-100 hours doing just subquests. We needed to put the subquests at a point where all players could access them equally, but the 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.
Click for full size image Another major problem related to the programming constraints established early on in the project, which were not being followed occasionally by the other departments, concerned design and art. For example, we had established audio file maximum sizes, maximum sizes (both in area and number of frames of animation) for spell effects, 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 led to frame rate slowdowns at some points in the game. This led 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 and follow them, but also continually work on refining the guidelines based on the progress of the game.
Click for full size image 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 BGII, we had an eight-stage process that we followed when creating levels for the game. The process for creating a game level was:
1. Designers map out an area and write up a description.
2. Concept artist draws an isometric concept of the level.
3. Models are created for the level.
4. Models are placed within the level and then textured.
5. The level is dressed with smaller objects (barrels and chairs). Lighting is done for the level, and then any final tweaks are completed.
6. The art piece is given to the designers so that the clipping, luminosity, height, and search map can all be done.
7. Creatures, items, traps, and triggers are all added to the level.
8. The scripting for the level is completed.
Next: Quality assurance and early testing
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 of each other. Designers sometimes didn't interface adequately with artists, which resulted in missing elements in the game areas and different naming conventions between art and design--potentially a huge problem when you consider that BGII had hundreds of areas, and thousands of creatures and pieces of individual art. Improvement of the integration of different disciplines (programming, art, design, quality assurance, audio, and so on) 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.
Click for full size image Another oversight in the Baldur's Gate II level design process was 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 to BioWare in order to do earlier 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. A great deal of QA support was also provided by 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 of 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.
Click for full size image 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 BGII'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 answer technical questions from the [email protected] support e-mail address.
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!
Next: The midlife crises
Click for full size image During the development of any game, no matter how cool, there comes a time when people have been working on it for such a long time that they start to tire of it. This mid-project doldrum period has to be managed very carefully, with attention paid to the individuals involved.
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, we specifically spent a lot of time talking to people throughout the project, especially at the mid-project low point to make sure we were providing enough support to 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 who wouldn't mind switching games. Also, certain people are "starters," while others are "finishers"--it's important to understand each individual and tailor his or her tasks to his or her working style.
The lesson we learned was to be aware of the mid-project; morale can take a precipitous drop before it again climbs when people see the light at the end of the tunnel.
The beginning of the end...
Click for full size image In a project as content-rich as Baldur's Gate II, we didn't really have to worry about cutting content. While we shipped with nearly all the features we originally planned, we did start cutting quests and characters well before the final testing phase. We still ended up with more than 200-250 hundred hours of gameplay.
In retrospect, we should have started this process many months earlier. One of the dangers of development is that game developers have a tendency to always add content if they are given time. They don't naturally spend time limiting and polishing content--instead, more time means more stuff. It's wise to use that prioritized feature list to hone the work (of course ours was informal, which made it a little difficult).
We learned to look at our target date and adjust our content development accordingly. In many ways, quality is more important than quantity. Even though Baldur's Gate II was bigger than Baldur's Gate, the content in BGII was still of a much higher quality--we just didn't realize how much more we had made in the sequel until it was too late!
Next: Testing, the nightmare
Click for full size image Because of its immense size, Baldur's Gate II was a tester's nightmare. This was compounded by the fact that we didn't do enough testing as areas were being developed. Baldur's Gate II contains roughly 290 distinct quests, some of which are very small (20 minutes long), while others are quite large (several hours in length). Each quest needed to be tested in both the single-player and multiplayer modes.
During testing, we adopted a very sound task and bug tracking method taught to us by Feargus Urquhart, the director of Black Isle Studios. We put a number of white boards in the halls of the testing and design area and listed all of the quests on the boards. We then put an X next to each quest. We broke the designers and QA teams into paired subgroups; each pair (one tester and one designer) had the responsibility of thoroughly checking and fixing a quest. After they were certain the quest was bulletproof, its X was removed. It took about two weeks to clear the board (on the first pass).
Click for full size image In addition to the subquest testing, we had another BioWare QA team (consisting not only of a couple people from QA, but also of some junior programmers and some designers) work through the game in multiplayer mode. This was in addition to an Interplay multiplayer QA team working onsite at BioWare and the nearly 30 QA people working down at Interplay. The experience with Baldur's Gate II reinforced the point that role-playing games really need significant QA commitment to be successful.
In the end, we found and crushed over 15,000 bugs in Baldur's Gate II. Thanks to the hard work of everyone involved in QA of Baldur's Gate II, we were able to ship a giant game with no significant bugs.
The lesson: Test early! You often don't have the time at the end to test adequately.
Next: The final crunch
Click for full size image In the final days of working on BGII, there was a strangely serene feeling in the office. We didn't experience the headlong panic that is sometimes prevalent while finishing a game, but we certainly did experience considerable stress as we built 21 final candidates in three days. After a few long nights with the whole team playing the game over and over again, we reached a point where we built a good final candidate. Then it was sent to duplication!
We learned to save some energy during the final crunch because you need it at the very end.
It's not over, when it's over...
The final area to mention regarding Baldur's Gate II is the topic of postgame support. We've recently come to the realization that we believe in personally providing support to purchasers of our games. Though we have always provided this support, it was only after the completion of BGII that we formalized it as one of the goals of BioWare. A group of line producers, managed by their producers, have recently been given the formal duty of providing very quick (same day or as close to it as possible) technical support to fans--their goal is to make sure people who purchase our games can play them.
We could rely on standard routes of customer support (and we do have this as well, of course, in the form of CS from Black Isle/Interplay and LucasArts), but we also want to make the time to directly interface with the purchasers of our games. After all, who better to work through technical issues than the people who made the game? For the first weekend after release, we forgot to assign someone the duty of watching the message boards and support ([email protected]) e-mail, so the joint CEOs of BioWare did it themselves. It was very entertaining when people disputed whether it was actually us on the boards or answering their e-mails--they couldn't believe that we would bother to answer them in person (we did).
However, one of the most important things we've learned in our years in the industry is how important it is to support the fans who buy our games. This means shipping a bug-free product and being completely available to help people who are having trouble with our games--on message boards, via contact e-mails, and anywhere else we can think of. What's the point of making games if you can't make sure people can play them?
Conclusion
Click for full size image In conclusion, we'd like to thank all the people who worked on Baldur's Gate II, both on the development team at BioWare and at our publisher Black Isle Studios/Interplay. Like any big game, BGII had its ups and downs, but in the end, we are all very proud of the game we made. We hope this retrospective provides you with some insight into our development methods and gives you some tangible ideas that you can apply to your own productions. In the end, it's all about the game--if you've put forth an honest effort, you will always be satisfied with the result.
//news/index.htmlBack to GameSpot features
zpostcode 
Recruit 
weather 
mreligion 
Yellowpages 
sport 
constellation 
shopping 
name 
game 
directory 
literature 
Word 
tour 
furnish 
Lottery 
tftnews 
lyrics 
News 
digital 
car 
dir 
Edu 
Finance 
