Podcast Transcript: BioWare On 'Creating A Monster RPG'

Gamasutra is now providing transcripts of selected Gamasutra podcasts, this time featuring a full transcript of BioWare producer/project director Casey Hudson's 2004 GDC speech "Creating a Monster RPG: The Light and the Dark Side of Development on Star Wars: Knights of the Old Republic," discussing the development of the critically acclaimed console/PC RPG. As the official lecture abstract explained: "BioWare's Star Wars: Knights of the Old Republic started development as an ambitious role-playing game set in the Star Wars Universe. In the end, it achieved almost all of its original design goals and went on to set sales records, becoming one of the most critically acclaimed RPGs of all-time. This talk will cover the entire development process at BioWare, from concept to completion, of this large and complex project. With a length of 40-60 hours, a complex rules system, 20,000 audio assets (including 14,000 lines of spoken dialog) and a 90+ man-year schedule, the physical size of the game alone presented a significant challenge to the developers. Further challenges faced by the development team at BioWare involved complex testing efforts, licensing and approvals processes, the support of large-scale Marketing initiatives, managing co-development of two SKUs (Xbox and PC) and management of the BioWare online community. BioWare's Producer/Project Director of Star Wars: Knights of the Old Republic will discuss the challenges faced in development as well as the methods used to achieve the original design goals on this ambitious game while still keeping marketing, PR, and licensing responsibilities in balance." An full transcript of the session, which is also available in MP3 form on the GDC Radio website, follows: Casey Hudson: So hello everyone. Good afternoon. Thank you for coming to this presentation. I think it's going to be a lot of fun. For myself, and the team at BioWare, developing Star Wars: Knights of the Old Republic was really a tremendous experience. It was full of lots of challenges and setbacks, and some really exciting victories, too, so I hope I can share some of that with you today. My name is Casey Hudson, and I was the producer and project director on Star Wars: Knights of the Old Republic. I actually have a degree in mechanical engineering, which is, believe it or not, actually pretty appropriate for this kind of work. It's pretty applicable. I was also a technical artist and 3D modeler on Neverwinter Nights, and I was a level artist on MDK2, so anyone who threw their controller in frustration trying to do this level - now you know who to blame. That was my fault. Lots of anger over that one. [laughter] So I know there's a lot of experience and talent in this room, so I don't want to give a lecture as a kind of lesson, and show you how I think you should do things. Games are all very different, and it's also a very big subject, so what I'd like to do is give you a really good overall picture, a kind of high-level view of how we develop this kind of role-playing game, and then you can apply it in your own way on your respective projects. And so I'll try and hit as many things as possible, but we'll have time at the end for questions if there's anything you want to know about. But first, the name. Obviously, Star Wars: Knights of the Old Republic is a very long name, so to save us all a lot of time, today I'll be calling it "KotOR." [laughter] KotOR. It always reminds me of some kind of B-movie sea creature or something, but that's kind of the theme of this talk - it is a monster RPG to develop, and it was very frightening to look at, frightening to work on. We think Star Wars: Knights of the Old Republic is kind of an interesting case study. It is a physically enormous game; it had 90 levels, a very complex simulation of the D20 rule set, and it had 40 to 60 hours of story-based game play. And it also had 15,000 lines of voice acting, so it was just a huge game, like all the stats on it are - you can see we had a lot of work to do. It was also a very high-stakes enterprise for BioWare, because it was the first console RPG that we had worked on, and it was also the very first-ever Star Wars RPG. And I think the fact that it was pretty successful kind of makes it also an interesting case study to look at. It won over 40 Game of the Year awards, and it's selling really well, too - it actually set sales records on XBox; it sold 1,500,000 plus copies worldwide, and it's on its way to basically a 2,000,000 lifetime seller. So it's been fairly successful for us, so hopefully there's applicable lessons for people working on other projects. So just quickly, a little bit about BioWare - we're a development studio based out of Edmonton, Canada, and we're currently at about 175 employees, but actually, since the time that I wrote this, we're at 180 now, so we're still growing strong. And we were founded in 1995 by two medical doctors, Greg Zeschuk and Ray Muzyka. Our first released game was a mech combat game called Shattered Steel, in 1996; we also released our first role-playing game, which is really the passion of the company, in 1998: Baldur's Gate. We've also worked on a console game, MDK2, which was developed on the Dreamcast and released in 2000; we also made PlayStation 2 and PC versions, so we got a little bit of experience there doing multi-platform development and working with a few different consoles as well. But really, our focus at BioWare is developing really big, exciting, high-quality role-playing games, so through the development of Baldur's Gate and Neverwinter Nights, and ultimately, KotOR. The other thing we like to really focus on - you'll see the value of this in the talk - is developing our own game engines, and it's a huge undertaking to do, and now, certainly, more than ever. But we always like to - we find that there's a very specific kind of game that we want to make, and fortunately, there are other people who want to make very similar kinds of games as well, so it's been licensed to use - to develop games such as Planescape: Torment and Icewind Dale. So the opportunity to do KotOR really kind of came out of the blue. We were working on Neverwinter and MDK2, and we got an email from then-Director of Development, Simon Jeffery, at LucasArts, and they wanted us to do the first-ever Star Wars role-playing game. They were working with quality developers on the Star Wars property, and so they were interested in doing a role-playing game, and they contacted us. So it was very exciting for us; we're huge Star Wars fans. And we also, at the time, had the opportunity to either set it in the existing Star Wars time period or set it in something that was kind of really new and risky, which was the Old Republic Era, about 4,000 years before the time period of the movies. But looking at the existing period that you see in the movies, with Luke and Han Solo and Darth Vader - we wanted to make the biggest story in the galaxy. We wanted to make the biggest villain and the best heroes and so on. So we set it in a previous time period, so that we could have all that kind of fun and tell the stories that we want to tell. And, being a multi-project company, we usually have basically three big projects going on at once. We were actually able to slot this project in pretty quick, because the MDK2 team was just about complete. Now, a little bit about our team structure at BioWare. There are basically five different types of team members on a development team at BioWare: There are artists - so that's basically concept artists, modelers, texture artists, and level artists. A lot of the artists on KotOR actually worked in a number of those areas, if not all of those areas, because we like to keep people moving around, but also to kind of play to their strengths. So it kind of keeps things interesting. We also have designers, and a designer at BioWare is really responsible for creating the gameplay content: Basically, writing the story, writing the dialogue - a lot of scripting, as well, the very complicated scripting that goes on between a player's actions and the game world. And programmers obviously do the coding of the game system and the tools. We have a number of animators, as well, for the cutscenes, and a lot of the actions were actually hand-animated in KotOR, so there's a lot of work there. And then we also have our own in-house QA department, which is, I think, extremely valuable for a developer, because it really allows you to get a handle on the quality of your game without having to rely on an external source, so that you know that when your QA department says that it's at a certain state, then you know that it's coming from someone that has the same understanding of quality that you do. Now, the team at BioWare on the KotOR project got as high as 75 people, so pretty big project - not the biggest project that's ever been put together, but certainly a really big project, a challenge in terms of managing. So the management mainly fell under five leads: The Lead Programmer, the Lead Designer, the Art Director, the Lead Animator, and the QA Lead. And we also had other leads; these additional leads were basically focused on expertise in their area, and a little bit of management as well. So, for example, the tools programmer would be the expert in the tools we were building for the game, but at the same time, he would have maybe a couple people that he was responsible for managing. We've got system producers, line producers... We also have a Lead Technical Designer, which is a really important position to fill, I think, in a role-playing game. And what we do with a lead technical designer is, he's responsible for every bit of the rule set, all the interactions that take place under the hood, so when we need someone who can really understand the rule set and figure out how it's going to be implemented, work with the programmers on that and also to kind of catch all the things that would otherwise fall through the cracks in developing a complicated role-playing game. And the team is led by a producer and project director, so in this case that was myself. And it's kind of dual role, so kind of like a producer-director in a movie where on the producer side you're responsible for scheduling and figuring out how you're actually going to get all this work done, and then on the director side holding the central vision for what it is everyone's working towards and trying to communicate that to the team and then reintegrate their ideas into that vision. So to make sure you have a context for how all this stuff fits together, I'm going to go through these actual stages of development, starting with pre-production. We had some unique challenges in the pre-production stage on KotOR. We've worked with licensed properties before, such as Dungeons and Dragons. So working with Star Wars and its very established license, it really answered a lot of the questions we had early on in the pre-production stage that normally you'd have to try and spend a lot of time figuring out, such as: Why do people love it? What's going to be great about it? What's going to be great about the way it looks or the way it sounds? So a lot of people love Star Wars, and so a lot of that is not a question. But at the same time, we were taking on a really new and different time-period. How does the world 4000 years before the time of the movies look, and what's going to be cool about it? How is it going to be different and yet still really appeal to Star Wars fans? And really that was the goal. We wanted to make sure that Star Wars fans would really be able to love this game. And so we looked at the Star Wars timeline and we were able to actually kind of use it to our advantage, because looking at the time of the movies, space-travel had been around for 30,000 years, so we thought obviously that doesn't mean that there's always huge technological advancements. Maybe it advances and it can recede and kind of hit a plateau. And so we used that idea to give us a reason why we can capture a similar look and feel and still have all the starships and light-sabers and all the good stuff, but really create our own art and our own story that would kind of capture that feel. So also in pre-production, one thing that we did was we kind of had three things that we would bounce back and forth between. We developed basically a two-page storyline, and we kept it at two pages until we were happy with the way it was structured. We also would brainstorm the classic Star Wars moments. Think about what would you really want to do if you were Luke Skywalker or Han Solo or Darth Vader, what are your fantasy moments in Star Wars? And then at the same time, even though we didn't really have a good idea of what the story was going to be, or who the main characters were going to be, we would make concepts. Not of anything specific, but something that you would possibly see in the game, and something that kind of demonstrates the look of what we were building. And these three things, they start out rough, but by iterating between each other, you kind of get a nice emergence of what you want. The art gives the writers ideas and vice-versa. So all of this really resulted after the four months in a really good vision document. It's not a design document, but it was a vision document that basically reads the way you'd want a review to read: What's great about the game, why did you love it? And what this ultimately resulted in was we had an announcement in the fall of 2000, and that means we had roughly three years of PR, and that's a long time. So obviously there's benefits to that, it builds a huge amount of anticipation over that time. But people get frustrated as well, waiting for something that they don't have yet. That means you have constantly supply a stream of content so that there's always fresh stuff, you don't want it to get stale. And that can be really exhausting over a long period, but it's also kind of worthwhile. So the next stage I think was prototyping and architecting. We knew what we wanted to make. We knew why we thought it was great. So we started thinking about the details, planning the actual game systems and thinking about not just what's supposed to happen on a planet, but exactly who do you talk to, where do you go, and specific art concepts. And obviously we would spend more time on some concepts than others. And being a Star Wars game, the villain was extremely important to develop. So this is an example of what Darth Malak looked like before. He was even called Darth Malak. We knew that we would need a villain and he would be a Jedi and that it was set in a strange, older time period. So before we even knew what we wanted from him, this is kind of what he looked like. And beyond that, we knew that we wanted him to be a big guy, so he would be kind of a fun Jedi to fight and he had to be human because of the way he worked into the story. So after a while we kind of developed him into something more. We started looking at ideas that maybe he had lost his jaw in an injury, that might be one of the kind of hooks to his overall appearance, but it was kind of gruesome, so we thought maybe we'd cover it with a mask. And as well, we started looking at ideas that would make him more graphical in terms of his color. So, overall very red but with maybe a pale face, so you would see him on any poster, you would see him on the background of a screen-shot. You'd always be able to recognize him. And so we started to close in on something more realistic. And we did tons and tons of concepts and I actually didn't include the one that had giant horns on it, but we covered everything. And these things help you answer what you don't want as well. And ultimately, this painting here, by the art director, kind of represented what we wanted Darth Malak to become. So after some touches by the modelers and the texture artists and so on, we had our villain. And I think he was successful in terms of being something that is iconic, and you can recognize him anywhere, and he's kind of a cool guy to build up throughout the game, and then ultimately, get to kill. So the other thing that we didn't have in the prototyping stage was programmers. Being a multi-project company, we are able to move personnel from one project to the other. And so at this point, it was really valuable to start bringing programmers on and actually dive into the code and figure out how we were going to put together the Odyssey Engine that was going to power Star Wars. And being that we develop our own engines, we were able to look at in-house, kind of modular components that we can use to put together the larger structure. The other thing that we did with our older engines was we use them to prototype our ideas. So we had the Omen Engine from MDK2 and the Aurora Engine from Neverwinter Nights. So, it's kind of hard to imagine right now, but it was actually really hard for us to imagine what it would like to play a game that was in 3rd person perspective and cinematic, but still kind of a top-down Bio-Ware, party-based, rules-based game. We had no idea what that would look like. And so we had a lot of questions, so we did a lot of prototyping. Prototypes in the Aurora Engine from Neverwinter on how you would explore as a party of three. Prototypes in the Omen Engine to think about camera issues. So in this case for example, "How tight can we make the Ebon Hawk interior?" You know, we would just put these things together really quick; not to look good or anything, but to help us visualize what it would look like. And prototypes of just walking around in the world, and how tall buildings could be and still fit within your view. So all of this really resulted in a very clear vision for the game, and we had plans for the Odyssey Engine, how we were going to build it, detailed design documents. And what this really resulted in was the E3 2001 demo. We thought we'd go to E3 and kind of give a sneak-peak for the press as really our first reveal of what the game is going to be like. And it actually did really well, because it was a demo that looked like something that was pretty finished. And it also kind of led to a private demo for Microsoft that led to us being able to do the Xbox version as the lead SKU, which really gave us a lot of backing as a prominent title on that system. So this is a clip from the actual E3 demo, just a video clip. So even though my machine's going to kind of choke on this video, it gives you an idea that we had a pretty good vision for what the game would actually look like, and this was two years before we even shipped. So being able to actually have your team look at something that is basically the final product, two years before you even finish building it, is extremely valuable, and it really galvanizes your team towards something that they can work towards. So we came back from E3 really energized and ready to get to work. And so we started working on the game content, but I think this phase really - even though we were hoping that we were in production, we really weren't. It was mostly a shakedown stage, because the issue was that a lot of the systems and the tools were still in progress. And the problem with that, of course, is that you want to be prepared for a shakedown stage where you're going to play with the tools and make sure that everything works - as long as you're not expecting that that's going to be production. And we knew that things were still being developed, so it wasn't too much of a problem, but there were some specific big changes that we had to make. So, for example, in the level art, we originally were thinking that we would have to have a more distant camera, similar to Neverwinter Nights, where you can see your entire party and you're kind of far back from your characters. And, as you can see by the guy standing in the doorway, we had to really create a huge scale for the world, so that there wouldn't be camera issues with the camera being that far out. And so, after building a few levels like this, we realized that it was actually just a lot better-looking and more interesting if we brought the camera in quite a bit, and scaled the world down. So we went to all the artists and said, "You've got to scale your worlds down to 70%." And it was actually a tough decision to make at the time; we'd built a lot of stuff, and we were used to it, and it looked good to us. We just couldn't figure out how we were going to populate it and make it look busy and everything, being that it was huge. But it looked good, and we were used to it. But, in the end, you can see - same doorway, same area - obviously, the original scale that's on the right would have been way too big. We couldn't have populated it. We couldn't have made it look interesting. And, even in the final game, the areas were still a little bit larger, still a little bit too expansive... but this is the kind of large-scale change that you have to make if you do any production before you have final tools shaken down. So we spent just a little over a year in full production - about sixteen months. And the team peaked at about 75, so a pretty big team. And we had a workable pipeline. It wasn't ideal - part of the reason is because, in this kind of role-playing game, the systems really are a form of the content, so we couldn't just build the basic game play, and then make sure that it worked, and then go through and build all the rest of the levels. Really, a lot of what you're building for those three years of development is the rule set, and all the interactions, all the different things you can do, the interface, everything. So this makes it really challenging to build the art and write the story without all this stuff in place yet. You kind of have to design to what you're hoping the guy next to you is going to build over the next year. So it's a very challenging phase in a role-playing game, and it's certainly very hard on the team. And then, right in the middle of full production, came E3 2002. And so we thought we would go and demo a full section of game play, because we were basically ready to do that at that point. And the problem was that a lot of the systems wouldn't be in their final form. We wouldn't be able to get a lot of combat in there; we wouldn't have the RPG components that the role-playing game players are going to be looking for - the stats and the character creation and all that fun stuff. We also wouldn't have the final-quality art or anything. But it would be a demo, and actually, the demo we put together was really good. It was awesome. It was the kind of demo that, if it was an internal demo, would have knocked everyone's socks off, and it would have been really exciting. However, it's not necessarily the kind of demo that you want the public to play. But there we were, going to E3, on the show floor, with a whole bunch of demo stations. And the demo was actually rock solid back at home, when we developed it, but once we got to E3, it started crashing. And it wasn't crashing a lot, but we did have eight systems, so we started to worry about it. And I blame it on the ventilation and the little cases that they were packaged in, but who's to say... the cases, though, had a little hole in the front that you could stick something into and reset the machine if it crashed, so just in case, we went out for sushi that night and brought back a whole bunch of chopsticks. And the next day, we had our eight demo stations running, and let me tell you, those chopsticks were in big demand. It was like a minefield, running that thing and the public coming up and playing it. And it was pretty rough on the guys, and I think a lot of them still have flashbacks about it. So we came back from E3 2002 with a lot of lessons learned - specifically, let's never do that again. [laughter] E3 is really valuable, and if you can put a demo on the show floor, if you have the opportunity to do that, that's awesome. And we did get some really good PR from it, so we basically achieved our goals. But the thing that we learned is, I think, there's really two demos you can afford to do: Either the kind of early sneak-peek demo that looks like an awesome final game, or a playable demo that plays like an awesome final game. And anything that doesn't seem like it's finished, or anything that seems like maybe it's going to be great, but you still have work to do - no one will perceive that. And so you really have to make sure that it's basically the final thing, ready to go, if you're going to demo it. Or at least that it seems that way. The other thing that we learned was that the combat system in our initial implementation, for what little was there, was actually... it was very counterintuitive, and people - because it looked like a third-person action game - people would come up to it and expect to be able to play it like a game like Obi-Wan, where each button has an immediate action, you can twirl your light saber with the analog sticks, and so on. But that's exactly what would break our game, because our game was turn-based, and if you started moving, then your round would be cancelled, and so on. And it was extremely painful for people to play the first time. So we came back from E3, and the first thing we started to do was to plan improvements to our combat system. And we actually finished our first implementation of the interface based on those ideas. And at the same time, throughout the remainder of the year, we continued with production, and made sure that the rest of the game was built. So, just to give you an idea of how many people were working on different things on this game - that was basically the height of production, and we had 14 artists, mainly working on levels, but also building characters and things like that as well. We had 14 animators; we had a huge number of cut scenes, and they were all hand-animated, and all the character actions were hand-animated, so hundreds of character actions. So a lot of work there too. We had ten designers writing dialogue and scripting the story together. We also had 14 programmers, so a huge amount of programming going on, even at that stage of development. So that was less than a year to go. And eight QA testers, which, at that time, were basically shaking down the engine and making sure that all the systems were working. And one of the really neat things that we did was, we made sure we had a full play through for Christmas 2002. So we organized the team around one singular goal for the end of the year - that let's close out the year with a version of the game that you can play from the very beginning to the end, and you can create your character, and you can get all the items and weapons, and play the story, and play all the way through and defeat the villain. We actually were able to do that, and it was a really exciting thing, and it was very valuable, because playing the game over the holidays - people aren't playing because of work; they're not trying to focus on getting stuck on a walk mesh or things like that. They truly want it to be fun, you know? And so, at that point, we're getting really high-level bugs, like "It's just... I don't think it's fun when this happens," or "I wish there was this." And those kinds of things really fold back into the game and make it so much better. So I guess if there's an environment that you can let people play it just purely for fun, then you can get a different kind of bug. And then came the dark times. We had a rough stage after Christmas because it was, by far, our busiest time. But we also had kind of a problem which was that we had an enjoyable story. It was actually really fun to play and people were giving us great comments about it, but there were huge problems and that was that the comment system was still really awkward and it had a big, clumsy interface. It just didn't feel right. So we completed the story and the art and the programming and kind of wrapped up all the loose ends in that kind of completion stage, but at the same time we started a process of interface revisions. So we get together in a big meeting of all the leads and we make a list of everything that sucks, everything that just wasn't working about the engine or about the interface, and we would make sure that all the problems were listed. We wouldn't try to solve them, but we would list them, and then we would go away. And I wanted everyone to think about what their particular solution would be, kind of think about the whole solution in your head. Because at the beginning it's going to improve in quantum stages, so you don't want partial solutions. If someone can have a whole idea for what you can do to change the whole thing, then that's really helpful. Then we would meet again to discuss the potential solutions and decide on what the action items would be and then we'd implement it, and by my count we did this seven full times. And by that stage we're basically down to the level of just entering the remainder of the changes through the bugs. But we did seven pretty big iterations to the interface; part of that was because this was something that we had never seen before. I don't think it was -- has been done before like this, and that's going to cost a lot of time in your interface. So just to give you kind of background, we came back from E3 2002, and thiswas kind of the first concept mocked up in PhotoShop for how we were going to solve some of the problems that we had, and then this is it actually implemented, and so very similar. But even though I had kind of a cool, slow-down effect while you popped up a menu and chose your action, it was contact sensitive, so it was kind of cool. But it was also a huge menu, and the game just felt like you were always playing a menu instead of playing the game. So we started coming up with ideas that we would hope would be more elegant based on maybe icons at the bottom of the screen that you would choose from categories and maybe select your actions that way. And after a few more iterations we came out with something like this that really was so much more elegant than what we had before. And you kind of realize the things that are redundant or not necessary on your interface, so we were able to -- for example, from this version there was a pop-up menu of scrollable icons on the left there you can see, and we actually realized that's not necessary, because you can also just rotate the icon in place from the bottom of the menu. So we would go through these stages, and ultimately we came up with the final version of the interface, which we were very happy with how it was able to achieve our goals of being cinematic and exciting looking, but also tactical combat and being able to pause and play and rules-based is a very difficult challenge. But in the end, because of this interface revision, we were able to achieve that. The other really tough part of this stage, in the kind of completion stage, was we had a huge marketing in PR push. So in addition to the stuff that you're doing all the time anyways, screen shots and interviews and things like that, we were doing B roll for the TV ads and cinema campaign that was in Canada. We were doing downloadable videos and desktops and character bios. So it's a good idea to plan this stuff in advance. I mean you know you're going to have to do it, so it's a really good idea to think about these things. And part of mitigating that is having a PR and marketing department, something that we didn't have a few years ago, but now that we do it really helps us offload a lot of this kind of asset creation so that the team, especially in this stage, can really continue to focus on their work. And then came the final QA and submission process. We spent about three months in the submission, or doing the last bugs and getting a final candidate ready to go. And so this is probably pretty common in the industry, but what we like to do is once the bugs get kind of manageable, you can look at the whole list, so like below a thousand, for example, for us on this kind of game. All new bugs will go through one person, so in this case, myself. Because as a producer it's really important, if you're going to be part of making the decision as to whether the game's ready to go or not, you have to know where the game is at in terms of the bugs and the overall quality, and this is really the only way that I could feel confident that I had a handle on that. The other thing that we did that was extremely valuable is we had a daily bug triage meeting. And so we would get all the stakeholders into the room at the same time and actually go through every single bug in the database. And it's time-consuming, but every day we would catch a few things that would have fallen through the cracks, so it was extremely useful. We would find things that were on -- were a bug that was assigned to someone to fix that maybe had gone away for that day or maybe the bug wasn't getting the correct priority that needed. And these things, even a day at that point is really valuable. So if you can cut down on that by this kind of meeting, we found it extremely important. And then after a lot of really long days and a couple all-nighters, we were finished, and we were tired, we were very tired. So we -- well, you're never really finished. You have to post-shift support. So one thing that we like to do is look at our community boards and make sure that things are going well. We have a very large community that's also very vocal on our board so if there's a problem we'll know about it, and that's actually extremely useful, both before the game ships and after. You can get a really good handle on whether people are enjoying it or if there's lots of problems, so it's very valuable to be able to use your community that way. And then we would track the bugs through there and investigate them. Even if they were kind of anecdotal, if they were -- if there were people having a similar problem, we would look into it and try and fix it at that time, and then, as well, looking at the LucasArts support line to kind of get a more statistical look at how the game is, what the overall quality is. And then we would implement these fixes as we developed the localized versions, because we had ongoing SKUs, the localized versions, and ultimately the PC version that we wanted all these fixes to be in. So I'll briefly touch on the PC version. This is mainly a talk that covers the Xbox SKU. And I think the reason that I'm able to just briefly discuss the PC version is because it actually went pretty smoothly. We maintained a PC version of the game throughout development. And actually, it was pretty straightforward. The developers would all work pretty much strictly on their PCs in the beginning, and then halfway through we would have dev kits for everyone and they would occasionally check their work on the dev kit. But because they were truly in parallel, it really sped up that process so you could make something, run the game on your PC, and quickly check it. But towards the end, of course, everyone was working strictly on the Xbox to make sure that -- because really, that's the only thing that matters when you're doing that platform. So it was actually pretty smooth. We had similar resources, similar work flow. But we actually did come across a problem, and it was a big problem. We were planning to ship the game for Christmas of 2003, the PC version, but we analyzed the schedule early on in the year as we were still finishing the Xbox version. And we realized that -- based on the new things that we had learned about how long it takes things to do in this particular game, we realized that there was no way that we could hit Christmas. Not only could we not hit Christmas, but it was going to blow way out into 2004, into the summertime. And we actually came up with a solution, and the solution actually worked. What we did was we printed the entire schedule out and we went through every single feature, and we minimized the schedule, but in real and meaningful ways. So specifically, we looked at the feature set and thought about the kind of features that were necessary for us to put into the PC version, given that the Xbox version was going to meet our expectations. What do we have to do to the PC version in terms of the tools as well to make sure it met our standards of quality? We were very specific about what that standard was. So it helped us analyze the schedule, and we were able to cut out some significant features that were significant to the schedule, but really you wouldn't notice whether they were there in the game or not and would still hit our level of quality. The other thing that we did that was extremely valuable, was we assembled a crack team of programmers from BioWare that we called the advance team. And the advance team was led by a senior programmer in BioWare and the rest of the guys were put together of people who had worked with other engines in BioWare, so they were experienced working this pipeline. And this was all based on the premise that we would put together this group that would work on the PC version, but they would work completely independent from the Xbox team and they would start immediately. And that meant that we were able to get development done on the remainder of the Xbox version and the PC version as well, and without actually having any additional management overhead, which can be a problem as you add other teams in parallel. So overall, the PC version for us was a huge success in terms of development, because we were able to perceive and avert a major scheduling crisis. And we actually hit the target date exactly, to the day, so that was kind of fun and unprecedented for us. And we also met our expectations of quality, which really supports the decisions that we made when we were actually scaling down the feature set because we had an idea for exactly what the game needed to be and we were able to hit that. So I think that the fact that the game has done well, critically as well kind of reinforces that process for us. Now I couldn't do a PowerPoint presentation without having at least one pie chart in there, and so I give you the KotOR work breakdown. It's basically showing that we spent 90 man-years developing KotOR. It's also kind of interesting to look at the way the breakdown was. We spent a lot of time on the art. We spent 28 man-years doing the art. So a huge amount of art-content went into KotOR, and a tremendous amount of programming too. And this was even given that we are leveraging the technology that we've developed previously. And even though the game was very story-based and is really about the story, we spent less time on the design part, 14 man-years versus 16 on the animation side. Because we had 76 cut-scenes, and hundreds and hundreds of character actions for the choreographed combat, and it was all hand-animated. So a huge amount of work went into that. And then we also spent seven years on our QA side and again that's really important for us to have QA in-house, so a lot of work went into that. And the audio part is a little deceptive because obviously a lot of work went into the audio in KotOR, but we also used a lot of external contractors. So internally we mainly implement the sounds, make sure that they're...we can kind of fix things, or create sounds that weren't done in the original sound-sets or whatever. But that's kind of how it broke down. So a lot of work throughout the game, but a lot in the art and programming. So to make sure that you come away with this with some good take-aways I think it's useful to look at specifically what went right and what went wrong in the project. There were definitely a few things that went wrong that we could do better in the future, and I think one of the first things is really ambitious scheduling. Another way to look at that is "really ambitious overall vision for the project." I think its...you have to want to make something great. That is obviously integral to making something that does become really popular. But there's creating something great, and there's throwing in everything but the kitchen sink, and I think that's kind of a little bit of what happened on KotOR. It had a huge number of features, and not all of them were really necessary to make it what it was. So in the future, one thing we like to do is we now have a template of exactly how long it takes, historically for us to do works. And we're not calculating, we're estimating how long we think it will take. We can actually look historically and say "Oh wow, really? It takes that long?" And without questioning it in terms of whether it seems to long or something, we can actually use that and maybe multiply it by an initial factor, so we can have schedules that are based on previous templates that are now very high confidence. And also just the process that we use in the PC version to make sure our feature set is really going to match what we need it to be. Another major issue I think is pipeline issues. Part of that has to do with the fact that we had a really ambitious schedule, making sure that we get the game done in three years, which is still fairly long in terms of development. It required us to develop all this stuff in parallel and really, that's part of what caused the pipeline issues. We couldn't get content in the game as fast as we like. We would build stuff and then realize that we had to do some process on it to make it work in a newer version of the engine and things like that. So I think in the future, one of the things we'd like to do to solve this is first of all, in a broad sense, put a stronger emphasis on the pipeline, just to make sure that our tools are well-developed before we go into production. And that's...it's not an impossible goal because you can really frontload a lot of your work onto the tools. Because, looking at our schedule, we really only spent a little over a year in full production. And even in that time--and that's out of three years. So in other words, if we had loaded more of the tool stuff later on, then we'd probably still have had a year or maybe even less to develop the art and the content that we did. So putting a performance budget into the project, that's something we should have done early on. But what I mean by that is that is a way for artists and designers to know exactly how close to the limit of the machine in terms of how much memory they have to use, and how many polygons they can render, so that you can see an immediate indication of whether the game's going to run. And we had a budget, but what we didn't do was, we didn't have any kind of hard limit. So we actually, on average, we nailed the budget exactly. But what that means is, half the levels and areas would be within memory, and the other half were over, and it was a very painful process trying to take the stuff that was over and get it within. So in the future what we want to do is make sure that we have actual meters and the tools that give an artist and a designer the indication of how close they are to their budget, so they can continue to build. And you know, you can make anything great within just about any limitation. You just have to know what your limitation is. The tough part is building something you think is great and then having to scale it down because there is a new limitation. Sequencing of resources. We're a multi-project company and so we move people around where they're most needed. And one thing that we wanted to do early on to kind of mitigate the issues on the schedule was to actually build the story early on with designers and actually kind of prototype what the story would be like before have the tools ready. So that would have helped us with this parallelism. But again, you have to put people where they're most needed, and I think getting people on much earlier than they're really, absolutely necessary is a tough thing to argue for. So, in the future there's a way to solve this as well, which is we have a cross-project, long-term human resources plan. And really all that is is just a way to have all the producers make sure that their personnel needs don't overlap for the next project or two so we can make sure we get people when they want them, even if that means hiring. And finally, the interface iteration. It was a great way to solve the problems that we had. But I think the only problem there was that, and the lesson that it would have been valuable to know ahead of time (and I think this is pretty standard), is that the first time you implement your combat system, that's really the beginning of the real design process. Because that's when you know what the real questions are, what the real problems are that you are going to have to solve. So, planning for this ahead of time, or figuring out a way to do prototyping of your interface, so you can actually get a controller in your hand and do things with the controller that interface with the way the game will actually work in the end. That will help you figure out what the issues are before you actually build the game. So, I think we must have done a few things right as well. I think first of all, we paid loving attention to the license. Yes, that's right, I said loving, because you have to love what you're making. Because the IP, the property that you're licensing, really isn't just about the setting or the name. It's about the spirit, the thing that people love about that property when they see the movie or they play the card game, or whatever it might be. There's something that people love about it already, and it's that spirit that you have to capture. The other thing that I think was really valuable was we focused on the mainstream. We knew that it was going to be a D20-based game, and that's partly a decision that was made because of the way that we like to make games and the way that we had experience in the past doing this kind of game. But to make sure that it was the kind of game that any Star Wars fan could pick up and play, or any Xbox player could pick up and play, we really wanted to focus on the mainstream. That meant that we were going to make it a game that was easy to play, but also would have a deeper level for people who knew where to look. So, basically two tiers of complexity. And, as well, intuitive ways of letting people like casual gamers interact with the D20 rules set, both in the way the interface worked, but also in our interpretation of the rules. Because a rules system can be great on paper, but then that's one medium, and the console machine is actually a different medium, and you have to think about what things are going to work and what won't. So, we actually interpreted the rules a little bit differently, so that they would be more fun. The fact that it seems to have captured a wide audience, I mean like the review on CNN where they said that you can basically twirl the sticks and press buttons and you can just have fun with it. That's an incredible thing, given that it's got a hugely complex rules system under the hood that can normally be pretty intimidating to the casual gamer. I think another thing that was really important to us was that we had relevant experience. We'd never really done anything like this before, nothing exactly like this before, anyway. But we did have experience doing all of the tasks that were components of it. So we had done a tool set for a role-playing game. We had done large-scale resource handling, and localization of games that had half-a-million, or a million, or more words. Localization of all that resource into many different languages. As well as RPG design methodologies. Being that it wasn't our first role-playing game, we had stuff to build on, and ideas, and ways of thinking in the company. And we also had console experience. So I guess the bottom line is if you're taking on something that is ambitious and that you've never done before, that's great. I think a meter for how likely you are going to be to be able to handle that kind of challenge is whether you can get pretty good coverage based on your previous experience. So maybe that involves making sure that there are people on your team that can help you get that coverage. For us, I think we had a pretty good coverage of all the challenges we were about to take on. And, as well, using feedback to tune the game. We had people from the entire company playing the game, especially throughout the last six months. Everyone was playing the game, and the fact that at some point people will want to play it, just because it's fun and it is a new game, that really helps because you can get really high-level bugs, things that help you make it a lot more fun, all the way up to the CEOs, to in our case enter up to 10 percent of the bugs in the database. And we had 40,000 bugs in our database. As well, web boards. That's a form of feedback, and you have to take that with a grain of salt because people are very vocal and they are very specific about what they want. But that's also the value of it because you're developing a game, and they're telling you what they want that game to be. So it's a really useful thing to listen to. And as well, Microsoft usability testing was really valuable to us, because it was really great to get comments back from actual gamers, but also in a format that didn't take us forever to read. We could just look through what they thought about this issue, or what did they think about the way that Darth Malek looked, or the way this part of the game played. So that kind of stuff is really useful, as well as tracking QA tester feedback in terms of the difficulty and the fun factor even per area, or like the way they liked the art. We would even do ratings per planet and collate everyone's opinions about all the different planets. We would find that they would collate pretty well, and we would take the planets that weren't actually fun, and we redid the entire stories of major parts of the game to make sure there was actually fun and really interesting equal to the other areas. So that kind of helps create a consistency. But I think, obviously, the most important thing that goes into anything that can go right on a game is to really have a great team, and we were fortunate to have great people on our team. I think there's nothing more important than a group of talented and motivated people who are really dedicated to their craft. And especially if you, as managers, can create an atmosphere of humility and professionalism, because that's really a culture of success, where people feel confident that they can be creative, and that they can grow. Ultimately, in this business, I think our primary resource is people. So if you can get great people onto your team, can keep them challenged and involved and motivated, there's nothing they cannot overcome in making your project a success. And that is all. Are there any questions? Questioner 1: I'm curious why you felt the need to make a game as big as this game, like just by the prices? Did Lucas ask for that? Did they offer you so much money per part? Casey: So, the question is, why would we make a game as big as this, and who's idea was that? Well, I think part of the thing was we were coming down from a huge high. Baldur's Gate was a huge game, and Baldur's Gate 2 was even bigger. There's a few different ideas of how long it is, and we're saying 200 hours and so on. So this, for us, was actually a smaller game. We were saying 40 to 60 hours. And at one point it was actually up to 80 hours, the original estimate. It's also hard to plan how big a game's going to be. We thought 40 to 60 being smaller, to try and make it a little tighter. But part of that is figuring out how fat the game is going to be as well, and it was a very fat game because you had the good and evil side, and all the different sides in between. I think, ultimately, it just comes down to we saw this as a really exciting opportunity, and we wanted to create the very best game that we could think of. And so part of that is making sure that its really rich in terms of story, but like I say, I think there were things that weren't absolutely necessary that we would probably tighten up in the future. Yeah, go ahead, in the black. Questioner 2: Yeah, I was actually one of the club members in 2000. And one of the questions early on was whether combat was going to be twitch or stat-based, and I was wondering if you guys ever consider a system with mix or use stats and twitch maybe similar to like Jedi Knight II with put stats and others on top, and just another question. When did you guys decide it was just going to be purely stats with pseudo-action? Casey: Oh, thank you. So the question was, why did we decide that we would go with kind of a pseudo-round based system instead of a more twitch-based game like Jedi Knight, and I think we decided that early on, based on the idea that we wanted combat to look really exciting, we wanted combat to look like the Obi-Wan versus Darth Maul fight in the movies, very spectacular. Part of that meant that we would have choreographed combat. So that was one of the exciting issues that we thought early on would make it a different kind of game to play, and as well, I think a lot of it, a lot of that decision came from wanting to make sure that people who had played BioWare games on the PC would be able to come over to the Xbox and have a similar experience, and not have to suddenly do twitch combat. I think that something to be very careful of when developing a role-playing game is what does your audience, especially if you've created games previously, what are they going to be expecting this one to be and what do they like about that kind of combat? So our previous games were very rules-based and point-and-click kind of combat. We wanted to make sure those people would be able to play Star Wars: Knights of the Old Republic without having to get really good at twitch combat. Yeah, go ahead, in the black. Questioner 3: In the game, the central discovery is one of the major aspects for the fun of the game. What are your thoughts on keeping the discovery from the QA team when they are testing the game and they get to the point where they know it and they are kind of tired of playing? Casey: OK, so you are asking, as the QA team is testing it a lot, do they get bored of that, and how do we kind of keep that fresh, is that it? So, I think it is a really tough job. We actually just finished the last work on KotOR literally just a few days ago, we did the live content, we did a Polish version and so there was a guy who was still testing and playing the game many times a day, even up until just recently, and that is a really tough job. So I think being able to stay fresh is the issue, but they did a really good job in giving us good feedback. Part of it is, we give them, we try to mix up the tasks that they do. So we'll have someone work on rushing through the game, the critical path, and then we'll have other people where we specifically say, "Just play this for story" and in some cases, like you say, what you really want is what's the fresh opinion, what do people think the first time they play it, because that is a major factor. So for that kind of response on the story, we would have, we would look to other things like focus testers, the Microsoft usability tests. Really, anyone that we could get, people in the company and you know, friends and family members. That kind of stuff is actually, it's almost kind of anecdotal, and it's not necessarily a solid statistic, but it kind of helps you get a feel. You start to see a correlation between all the different people giving similar feedback and this is something we did with a twist, for example. There's a major twist, I won't give it away if anyone hasn't played it, but that's something that has to be done very delicately, and so we would get people who had never seen the game before come in and play through it and give us their feedback. Yeah, go ahead. Questioner 4: Can you talk about how you maintained design documentation throughout, like, dialogue lines and the process of iteration between maybe temp dialogue to back to re-writing it back to recording it? Casey: OK, so the question was, kind of how did we handle the documentation of dialogue and what was temp dialogue. Questioner 4: The dialog and documentation. Casey: Well, with regard to the actual dialogue, we actually would write, we didn't do the VO until very late in the game. And like I say, we would actually rewrite an entire planet if it wasn't very good. So I guess all the dialogue in the game was assumed to be final until it was rewritten, so part of that is managed by our tool-set. Everything gets written into the tool-set, and that actual database is the real data. And that can get changed and goes into source control so we can roll it back if we wanted to recover the older version of the planet and things like that. So that's kind of how we did that. And then once, basically I would occasionally ask the lead designer, "Are you 90% confident in the dialogue?" And so once he was basically confident that we had at least 10% and maybe as little as 5% that we would have to rewrite after that point, then that's when we went to do the VO. And in terms of the other documentation, we basically did source control on it. And we had a large number of documents, but basically, it was restricted to the technical design document that was mainly for programmers and the way the game architecture was working. And we had a rules document that really is the repository for all rule stuff. And that was maintained by the lead designer and the lead technical designer. And then we also had story related documents, but those were the main documents that we would have and they were constantly updated through source control. Yeah, go ahead in the front. Questioner 5: Can you talk a little bit more in detail about the profile of the design team and whether specifically if some of them are more oriented towards game play structure and some more towards storytelling and dialogue? And how you train them. Where do they come from? Casey: OK, so I guess the question is kind of, what was the breakdown of the team in terms of their interests, whether it's game play versus maybe the technical stuff and where do we find these people? I think part of the way our team worked anyway, was we had quite a variety of different types of people, also people who like different kinds of games. Like there are people who really don't play RPGs, and they want something that is just faster or easier to get into and things like that. And I think that really works well. As long as you're listening to your team, it's great to have this kind of different feedback because you fold it back into your game and then it helps kind of make sure your game is covering a lot of these different kinds of people that have different interests. So we do have quite a range of people from people whoare very interested in writing. We have people who are involved in writing for local theater, and they write plays and so on. And then we've got programmers. Some of the programmers are very interested in even like recreational programming and going home and learning stuff, and others are very much about management and making sure the team has what it wants. And so I think we had quite a variety, and I think it's a good thing to look for, it certainly helped us in this case. Questioner 6: Actually this is a two-part question. One is, how are you going to interface with LucasArts and two is, are you guys planning do more RPGs? Do you want to stay with it? Casey: The question is, how do we interface with LucasArts, and how that relationship worked, and the other part of it was, are we going to work it with RPGs in the future? The first part of the question, how we worked with LucasArts. It was actually really good for us because first and foremost we really value most being able to tell the story we want to tell and create new stuff. And being huge Star Wars fans, we wouldn't create something that really stood out, or wouldn't be appropriate in Star Wars. I think that worked really well with the Star Wars, or the Lucas Arts approval process. We would do concepts and story ideas and so on, and then everything would actually get sent up by our LucasArts producer to Skywalker Ranch, where they would have people who look at all the licensed properties and make sure they fit in with Star Wars. They also have content coordinators that are really helpful for us. There's a huge extended universe in Star Wars, so a lot of the back story has been written, and things about characters. Sometimes you can step on someone's toes by creating something new that maybe contradicts what's been done before. But we have content coordinators who are experts in all that stuff. They would be able to help us in that way, and make sure that a creature variation that we had can have certain eye colors but not others. But the times we had to change something I could literally number on one hand. For example, we had done a concept for our sand person. They had kind of short leggings. One of the big things about sand people is that they have to have really long robes that go down to the ground. That's a minor thing to make, and the success of the game wasn't really hinging on that. And there was maybe one or two other minor things, and that's out of a huge pile of probably over a thousand concepts that we sent them. So it was pretty good. And then, the second part, whether we are going to work on RPGs in the future. I think most people at Bioware believe that some form of RPG is the ultimate evolution of the game. Because really all that means is it's about story and developing your character into something new and better. It's really based on feeling immersed in a world, which I think all games are moving towards, anyways. So, we love RPGs, and we're certainly going to continue making them. Go ahead. Questioner 7: I have a question about a problem that happened early on, when your artists were really appreciating that in hard performance budget numbers, and your cool programmers don't know the answers to these questions. Casey: That was the reason that we didn't do it early on. I think it can be solved in the future. It's something you can overcome, partly by choosing a limit and being conservative with it. It's a lot easier to go up from a conservative estimate, and add more particles and add more texture, resolution and so on, than it is to have to come down from any number. Just having a number, usually your programmers and technical people will have an idea. And if they pick the conservative end of the spectrum, then it will probably be pretty solid. But a lot of the time they don't want to give a specific number because that number might turn out to not be true. As long as it's conservative, I think you can work within that, and make something that's really great. Then, in the end, if you have some more room, then you can scale up. Or at the very least, all your levels will be at the same stage, so if you do have to come down, then maybe there's one specific thing you will have to do. If you were over by a certain small amount, we could have said, OK, we have to take one head variation out of every level. But as it was, it was much more complicated, because some were a little bit over and some were a lot over. And we actually had to go through and figure out every single level, what we would have to do to get it in memory. Any other questions? At the back, there? Questioner 8: How early was it in your development that you did the dialog in game system with the cameras? Casey: The question was, how early did we do the in game dialog system with the cameras. That was one of the first things that we did. Very important, because it's part of the critical path for the designer's development. They need to be able to write the story, and then see the characters talking in dialog. We got the basic system working probably within the first year, but it took us at least another year to develop it into what is in the end, where the cameras were set up the way we wanted them to be so they wouldn't poke through walls and things like that. We also had animation stuff that we implemented later on, like the lip syncing and things like that. But that's not really critical early on, mainly you need to be able to see and visualize h