GDC Austin: Star Wars: The Old Republic And The Challenges Of Big Teams

BioWare Austin technical director Bill Dalton delivered a look at how interdependencies can lead to problems in development on games -- with the studio's Star Wars: The Old Republic MMO as a perfectly complex test case. When it comes to game development, says Dalton, "For any game these days, we have very large teams. For MMOs, in particular, we have a lot of stuff going on. Everything everybody does is challenging. Producing the art, source code... So what do we do? I think it helps to understand what the different customers you have, as a technical worker on the game, are."
 Different disciplines do not perceive the game in remotely the same way, says Dalton, and it's important to think about how they do. "The writer looks at the game as a setting. The game is essentially a story vehicle; the writers are writing the story. The first people involved with hatching our game are the writers and the concept artists. The point is -- they don't really care if the server's up or down." Varying Views Says Dalton, "Animators look at the world as a cast of bodies. They don't really care which planet this thing is on or anything else -- what they care about is that the physics of this thing flipping around on the screen looks good," while "world builders need something that allows them to experiment, explore, and test what they have, and iterate very rapidly. Environmental artists see half-baked clay. The environmental artists say 'How can I make this beautiful?'" Different programmers view the game in different ways, too: "The engine programmer sees what we do as endless challenges. In the end, they have very difficult numbers to meet," while "the gameplay programmer sees puzzles. They're listening to what the designers want." "It pays to sit back and think about these things," says Dalton. "Later on as you start to grow your teams and you form the groups to handle these things that you need to think about pipelines and how to serve them best." It's tempting to try and jump up and respond to problems immediately, but it is not the best solution, says Dalton. "You have to look at the dependencies. When you have a crisis on the team, you have to measure your response to it." "As soon as you hear someone on your team saying 'I can't do my job,' it's scary. But sometimes the answer is 'I'm really sorry -- we'll get to that as quickly as we can.' While think it's valuable to always prioritize stability in your game, the individual pipelines have to be given individual thought when you're responding to a crisis or feature request." Problems and Communication When it comes informing the team about problems, says Dalton, "There is nothing you can do to communicate too much. In a situation where things are in crisis and something is broken, and you've told individual people as they come up, it's not a bad idea to overcommunicate and tell the whole team what's going on. The worst thing is that someone who's going fine just deletes the email. I do this form of communication very frequently. I always get feedback from people I don't expect, just saying 'thank you.'" Other forms of communication, such as team surveys, one-on-one meetings (as, says Dalton, "a lot of people aren't comfortable talking in large groups and will tell you things they wouldn't otherwise say") are vital. "Don't let people float through the [SCRUM] stand up saying 'no, I'm good, I'm good.' Find out where they are and what's blocking them." Since teams are made of people, Dalton believes effective management is absolutely crucial. "You can't tolerate petty politics. When you have bad behavior on your teams, you need to call it out and you need to stop it. One of the ways that you can foster a professional and open environment is to be transparent." Process changes as projects change, says Dalton. "Things that are important early on in the project may not be important later on."
 A Case Study From The Old Republic "It's great in the early days to run wild and free. You need to avoid getting panic-stricken over the fact that you're not generating game content," he says. However, "At some point, you really do need to say 'This is it, this is how the game's going to get delivered and we can't be messing around with that stuff anymore'." 
 Dalton showed some case studies from the development of The Old Republic to explain his problem-solving methodology. The game is being developed using the Hero Engine, an MMO engine which allows for real-time simultaneous editing by all disciplines -- great for visualizing changes, but put under strain by the size of the team working on TOR. Dalton was careful to note that his team stopped taking code drops from the engine providers some time ago and that the engine's capabilities may be profoundly different today. At BioWare, writing is the foundation for their games. Problem: the communal editing server didn't work at first, and the writers had to be peeled off and given stand-alone tools -- creating unexpected complexities. The server ground to a halt again later due to a problem with the sound design section. Instead of a complicated solution, "We asked what it would take to limit the size of the sound banks," says Dalton. The response? "'50 megs? Okay!'" It was a painless solution -- or as Dalton put it, "They don't all have to be mountain-movers." The game also implements Morpheme for animation. Says Dalton, "The problem here is that they're changing the animations live, and if they break things, it triggers a lot of fallout. So you'll have scripts that are now starting to fail, and you'll have NPCs that won't appear in the world. This was a nasty one because people weren't even aware why it was breaking." The engineers briefly considered making the animators work on a different shift when others weren't using the editor. The solution reached, however, was simply changing process: the animators have to email the entire team when they're about to make changes. "It was causing so much havoc across the team but with these steps it's a non-event now," says Dalton. At about 80 people editing simultaneously, the engine's editing environment started to show serious strain. "None of [the problems] are huge but they're all sand in the gears, slowing everybody down," says Dalton. This change was major: the team had to branch the engine for different disciplines. "This was a massive undertaking, a huge change. What it enabled the team to do was spread out a little bit. We got pushed into a do-or-die situation with this one." When Times Are Tough When asked if the communal editing environment was worth the complexity it brought to the development process, Dalton found it hard to answer. "I think that there's no single answer for that. I think it's not worth it at the team size we have now. I think it was absolutely worth it when we licensed the product and started work, because that's what you wanted in the early days." When it comes to project management, Dalton says forthrightness is the key. For content produced, "The numbers don't lie. Everybody is tracking what their teams are up to. The project manager's role is to roll that up and hit us in the face with it early and often. That is the place where the leads have to step up and say 'this is why we're failing.' People assume that they know why things are breaking. I think that's a director role -- you have to make the calls on those things and say 'What are we going to do about it?'"