The article “Combat System Development on BioWare’s Star Wars: Knights of the Old Republic” initially appeared in the December 2003 issue of Game Developer magazine.
CASEY HUDSON | Casey was producer and project director on Star Wars: Knights of the Old Republic.
RAY MUZYKA | Ray was joint-CEO of BioWare Corp. and was executive producer of Star Wars: Knights of the Old Republic.
JAMES OHLEN | James was the lead designer of Star Wars: Knights of the Old Republic.
GREG ZESCHUK | Greg was joint-CEO of BioWare Corp. and was executive producer of Star Wars: Knights of the Old Republic
Many of the design decisions made, and project management methodologies used at BioWare during the development of Star Wars: Knights of the Old Republic (KOTOR) were built on the experience of our exceptional staff from our past projects such as Baldur’s Gate 1 and 2, Neverwinter Nights, and MDK2. We set our high goals for the combat system: first, we wanted our system to leverage the fun of BioWare’s past RPGs and the experience we gained from them. In addition, the combat system needed to look as exciting as the battles in the Star Wars movies. Finally, the combat system and the game in general had to feature an interface that was very accessible; we wanted any player who likes Star Wars, likes playing Xbox or PC games, or likes console or PC RPGs, to have fun with the combat techniques in KOTOR.
Building a new and unique game system is difficult at the best of times, but the most valuable asset a team can have is people that have tried similar things in the past. Fortunately, many of the senior members of the KOTOR team cut their teeth on the original Baldur’s Gate, where we first developed the processes allowing us to make enormous games with new methods of depicting RPG combat. After developing Baldur’s Gate 1 and 2, Neverwinter Nights, and expansions to both series, we had trained — and retained — a very strong group skilled in the development of far-reaching game systems, and we had prototyped many different combat models over the years. Add to that experience a few forays into console development (MDK2 for the Dreamcast and PS2), and we had a team with all the experience required to navigate the pitfalls and rewards for a large, mainstream console RPG.
We leveraged the experience of our team by making use of the personal round-based system (one action per three-second round per character) used in our previous titles. In addition, we had experience in using Dungeons & Dragons’ D20 system to create a satisfying type of party-based combat, something we wanted to replicate in KOTOR. By basing the system on the personal roundbased system of the Star Wars D20 rules, we weren’t trying to reinvent the wheel. Instead, we built upon what had succeeded in the past, adjusting it for the new goals for this particular game.
We did add highly choreographed combat actions to provide a more action-oriented experience for players. Success in this area would have been much more difficult had we not worked on a similar system for Neverwinter Nights. It’s also worth noting that a number of new, inexperienced people worked on Star Wars: Knights of the Old Republic; BioWare’s matrix structure mixes new and experienced team members to build an efficient group dynamic.
One of our most important goals was to create a combat system that would be easy to use for a broad cross-section of players. Knowing that LucasArts’ revered Star Wars brand would give the game widespread attention, we wanted to make sure that all types of players — not just experienced console RPG fans — could jump in and have fun.
To this end, we started with an over-the-shoulder view of the action, giving a cinematic view of the surroundings, rather than the top-down view of more traditional PC RPGs we had created in the past. We also needed the combat to look as action-packed as other mainstream games but be controllable through a simple interface. These goals prevented the system and interface from becoming overly complex and added weight to any feedback from QA or focus tests that certain parts of the combat system should be easier to use. Usability testing with fresh perspectives played a large part in the development of the combat system.
We also adjusted our implementation of the Star Wars D20 rules, simplifying the player’s interaction with the rules in a videogame setting. Fortunately our publisher, LucasArts, supported us in this endeavor, and we were able to balance our attention to the D20 rules with playability considerations for mainstream fans.
In the end, we were surprised at how well the combat system turned out. Even though combat seemed complex at first glance, most people mastered the system before completing the game. Much of the positive feedback we received about the game was from people who have never played role-playing games before.
While the combat system featured personal rounds for each character, we didn’t want it to look like the combatants were taking turns via a strict alternating system (we at BioWare affectionately call this “caveman combat,” where each combatant politely takes turns bonking the other on the head with a large club). To capture the excitement of a Star Wars blaster or lightsaber battle, the action had to look as fluid as possible.
To achieve this kind of realism, we used a “choreographed animation” system for playing our combat animations. Each character would “lock” with one enemy, attacking for part of the round and defending for the other part of the round. Animations were therefore made in 1.5-second choreographed sequences, where one character did an attacking motion and the defender performed the appropriate countermoves. Essentially, combat actions were predetermined and synchronized between interacting combatants.
This meant that characters could do virtually any combat move that you see in the movies, and each attack would be choreographed with the defender’s animations, enabling characters to do spins, backflips, and rapid lightsaber flurries while appearing to interact physically with other characters. Making multiple animations for each combination of weapon types limited excessive repetition.
Choreographed animation was also efficient for the development process. Since both characters were animated in tandem in 3DS Max, animators were able to see exactly how the animations would look in the game, streamlining development of the system and the adjustment of animations. However, it was still essential to review all combat actions within the context of the game engine, to discover any subtle differences in playback within the engine, on both Xbox and PC.
In the early design stages of Star Wars: Knights of the Old Republic we put a lot of thought into the main interface and how the game would be controlled. Since we were taking a new approach in creating a strategic, party-based console RPG, we couldn’t be absolutely confident in the interface design until we experienced it under true game conditions. As we had learned on many of our past projects, our first attempt at an interface simply initiated a process of repeated iteration (including usually two to three major revisions and multiple smaller iterations of each major revision) that lasted right up until the project was complete.
The first version of the interface was crude, lacking the elegance and simplicity that we later realized was needed. A set of combat actions was attached to each button, which would generate a menu of context-specific combat choices. The complexity was confusing to casual players.
After watching the uninitiated struggle with the first interface at E3 2002, the team leads, QA, and other senior members of the company spent time that fall to record all known concerns about the main interface, which prompted a fundamental change in how we let the player interact with the world during combat.
As a result of this feedback, we decided to create more rigid frameworks for player control. Players could interact with enemies only by entering a combat mode. In combat mode, the camera would focus on the hostile target, and non-hostiles were non-selectable. In addition, we felt it was important to depict the range of possible combat actions to players in the form of an always-visible combat action menu (we extended this to noncombat as well to keep it consistent, and called this the “horizontal action menu”). These two factors made the combat much less confusing, and with the addition of action icons instead of drop-down menus, we finally had an interface that was becoming easy and fun to use.
Between spring 2002 and summer 2003 (when the Xbox version of the game was released; the PC version followed later in 2003), we did around 10 smaller iterations to arrive at the final interface. After the most coarse, time-consuming, radical changes (such as the ones just described), we eventually tunneled down to dozens of smaller changes that took only a few hours to make. We incorporated extensive feedback from QA teams at BioWare and LucasArts, plus valuable feedback from usability and focus testers at Microsoft, internal usability tests at BioWare, and multiple rounds of comments from the press, compiled during various press tours and demos. This iterative process gave us confidence that players would be able to control the game easily, but more importantly, we were starting to have fun playing it ourselves.
One of the main problems with many RPGs is game balance: it is easy to make a game that is perceived as either too difficult or too easy, but balance is elusive. Thus, we sought more effective methods of getting fun-factor feedback from our QA department during the course of development. While we’d used feedback from QA to improve balance and fun factor in previous games, we explored new ways of doing it this time.
We devised a system to document combat feedback that was used extensively by our testers during the last few months of development. These documents listed every combat encounter in the game, and each tester in the QA department filled it out during their playthrough. The document included fields that detailed the general difficulty of each encounter, the amount of credits and experience points they received, and the tactics and Force powers they used to defeat the encounter.
Most of the testers could finish the game in a weeklong session, so at the end of each week we would review all of the data from the QA departments at BioWare and LucasArts . We identified levels that were too easy or too difficult. We looked at the overall treasure allotment and decided whether it needed to be increased or reduced. We also reviewed level progression and then tweaked the experience point system throughout the game. This was an ongoing, repetitive process that lasted through the last few months of development; only through our quality assurance teams’ painstaking effort, where they repeatedly documented combat difficulty, were we able to hone the gameplay experience for both casual and hardcore players.
Balance testing was also aided by BioWare’s and LucasArts’ QA teams’ game-playing skills. Because QA was always trying to plow through the game as quickly as possible, they would discover which Force powers and combat tactics gave them the best playing advantage. Once we identified these overpowered culprits, we’d “nerf” them, forcing the testers to use a broader variety of tactics and powers. By the end of the testing cycle we discovered that people used a very large range of tactics, and no one method proved superior.
Demonstrating the first playable version of the game at E3 2002 uncovered one of our biggest hurdles in the combat system’s development: the graphics and camera angle made the game look so much like an action title that people didn’t intuitively play it in a turnbased manner. Novice players wanted to mash buttons and twirl the thumbsticks during battle, breaking the combat system and making the game look extremely awkward. The interface’s discrete character control enabled players to disrupt their current attack by moving or accidentally selecting a container while attempting to engage the enemy.
We battled this problem to the end of the development cycle, and it required a lot of concerted planning and work to overcome. Carefully controlling the player’s access to gameplay functions in and out of combat produced a more intuitive system, but consumer trade shows are not the place to discover such problems in the first place, and we had to recover from some of the poor press at the show.
The fundamental lesson learned, albeit in retrospect, is that the scale of player actions allowed by a combat system must match the scale of actions on which the system operates; if a combat system is based on doing discrete combat actions at any time (like throwing a single punch or firing a single magic spell, as occurs in our upcoming Xbox RPG Jade Empire), you should allow equivalent “peraction,” low-level player control. Games like Star Wars: Knights of the Old Republic with higher-level strategic systems should actually restrict players to only controlling higher-level strategic actions.
Though we were able to find a good balance between strategic control and ease of use, the final combat system still required considerable player adjustment, because at the time no similar system had been implemented. This uniqueness led us to attempt to train the player in all of the basic control and combat systems in the first few areas of the game. Many players found the complexity of the resulting tutorial areas detracted from their initial immersion in the story.
The tutorial condensed too much information into the first hour of the game, when it would probably have been better for us to spread the tutorial elements throughout three or four hours of gameplay. Not only would this have been better for the flow of the story, but also for the player’s retention of the information. However, a benefit of condensing the tutorial to a small number of areas was that iteration of the tutorial itself (such as rewriting the tutorial text as interface changes occurred) could occur more frequently and be tested separately, with less risk to the overall project.
Another option would have been to include a separate, stand-alone tutorial. We considered this in the initial design meetings for the game but decided against it, fearing too many players would skip the tutorial. To improve the game’s accessibility, we felt console players unfamiliar with PC RPG conventions needed training before getting into the bulk of the game.
Through an iterative process of implementation, testing, feedback, and redesign, we arrived at a main interface that exceeded our original design goals. That process, however, was extremely lengthy — over one full year — and required a huge amount of manpower, which drove up our development costs. The key missing element from our early paper sketches and graphical mockups was interactivity.
After several iterations of the interface, it became clear that we were simply waiting to see how certain actions would “feel” with the Xbox controller or PC keyboard and mouse, and see how the game would respond. If we had an interactive method for quickly prototyping our ideas, we could have drastically shortened the iteration period. Though we had actually experienced similar issues in all of our past RPGs, KOTOR proved once and for all that more complex RPGs require early hands-on design to develop powerful, transparent, easy-to-use interfaces.
On future RPGs like Jade Empire, we hope to test our interface ideas interactively much earlier in development, so we can work out the “feel” issues well in advance of implementing the interface in the actual game.
One of the challenges in working in a multi-project company like BioWare is that sequencing of resources is a constant learning experience. Over the years we have developed a number of techniques to optimize the use of our matrix personnel system (see Ray Muzyka and Greg Zeschuk’s “Managing Multiple Projects,” GD Magazine March 2003), but there is always room for improvement.
Since the combat system in Star Wars: Knights of the Old Republic was different from anything we had encountered in the past, we planned to mitigate risk with lots of early preproduction and prototyping. We initially planned on putting designers on the project early to prototype gameplay into placeholder areas of the game, but things didn’t pan out as expected. Instead, we ended up doing a fair amount of retroactive design while balancing the requirements for story and event scripting.
To solve this problem on future projects, we now pay closer attention to the planning of personnel scheduling based on what we learned in our past projects’ schedules, with the aim of maintaining adequate staffing throughout each project. In some cases this involves outsourcing or hiring additional staff much earlier than we have in the past, anticipating their need later on in the project and allowing sufficient ramp-up time. Hiring the right staff early enough can actually reduce the overall development time and cost of a project.
Our use of feedback was both a strength and a weakness in the development of KOTOR. While we extensively used team and QA feedback to fine-tune the interface and balance the combat system, there were several areas where we could have made much better use of feedback.
First, our measurement of the game balance was more of an art than a science. We didn’t have adequate metrics in place early enough (or in some cases, ever) to determine whether the game was doing what we wanted it to as players fought enemies, gained experience, and moved up in level. QA testers didn’t have a formalized way to report combatbalancing statistics until the later stages of testing. We also didn’t build enough automated testing systems into the game engine to track statistics on character experience, abilities, and combat encounters.
We also underestimated the importance of the feedback system in the game. Intended only as a means of letting the player know exactly what happened in a tough battle, the message screen that formed the heart of the feedback system wasn’t given much priority. However, during testing, bugs in the feedback system made it extremely difficult for testers to determine whether the game was performing properly (appearances are often deceiving). It required a large amount of work very close to the end of development to make the feedback system work well enough to be used as a testing tool, presenting a significant risk to the schedule. Planning for a clear and robust ingame feedback system much earlier in the project is now something we now consider essential in our RPGs.
Despite the challenges encountered during development, Star Wars: Knights of the Old Republic ended up being a big success. Microsoft touts the Xbox version of the game as the fastest-selling Xbox title ever released, and the game is also one of the highest-rated RPGs of all time according to Gamerankings. Based on this success, we have high hopes for the PC version, which expands on what we learned in the development of the Xbox version.
In addition, we are actively applying the lessons on what worked well and what didn’t work as well to the three new intellectual properties in development at BioWare, one of which, our recently announced Xbox-exclusive title Jade Empire, will be published by Microsoft.
Credit must be given where it is due: Star Wars: Knights of the Old Republic’s success is entirely due to the hard work of the team at BioWare and also that of our publisher, LucasArts, who fully supported our development efforts and who shares the high quality standards toward which we were all aiming. The team who worked on the game, like the other teams at BioWare, are all hard-working, smart, creative, passionate individuals, and it is an honor for the authors to work with all of them. Our goal at BioWare is to try to exceed the quality of our past games with each new game we make; we felt we accomplished that with Star Wars: Knights of the Old Republic, and we will continue to strive toward this goal in the future.
