TGS: Epic's Mike Capps On Developing Epic-Style

Hoping to inspire the Japanese game development community that so inspired the creative minds at his studio with titles like Resident Evil 4, a visibly excited Mike Capps delivered a speech about Epic Games' creative process to a packed hall at Tokyo Game Show, in which he examined the processes behind studio's Gears of War and Unreal Tournament franchises in detail. Anything But Pastries One big issue at Epic is what Capps describes as "The insufficient Pop-Tarts problem." People at the company are prone to complain about the flavor selection of breakfast pastries: "I worry why they're complaining about Pop-Tarts and not the quality of our games," says Capps. It's representative of larger potential problems with company culture. "Our philosophy is that people are volunteers," and as such, says Capps, keeping them satisfied is important. And there's an important practical consideration: "They could work anywhere. I have to treat them that they could leave any time if they're not happy," says Capps, in reference to the fact that Unreal Engine is now so prevalent across game development that Epic's own staff are in demand. So what are Capps' goals for company culture? "You want people to work hard, and to work harder than they would if you did not have a good culture and they were not working well." It's important to get them to work hard as a team -- not just as individuals -- and also over a consistent period of time. Says Capps, "What's hard to do is hard work for six months, or two years." While noting that developers are "willing to sacrifice for that goal" of making a great game, working them hard for too long doesn't produce results. "You don't get good work out of people that way." The solution, instead of running people into the ground, is to "sacrifice enjoyable inefficiencies." Examples include for-fun web browsing during the work day, and research projects -- says Capps, it's important to cut projects staff "think are important for shipping a game, that will actually not help at all." Territoriality and unwillingness to fail can also cripple the game development process, says Capps. If people are unwilling to give up control and truly collaborate, the game can be paralyzed. And not penalizing for experimentation is essential, says Capps. "Failure is so important for making good games... intolerance [of that] is the sort of thing you can't deal with." Inspiring Results Capps believes that you get the best results from talented people when you team them up and give them a task that is "not an impossible mission, but an almost impossible mission." Capps tasked a team with improving the performance of Unreal Tournament III on low-spec machines. "Any of these folks individually could not have done this task," says Capps. "Having them rely on each other and giving them a really hard goal" was the key. By the end, they had gotten UT3 running on a nine year old PC despite being tasked with getting it running on one that was four years old. "If you take creative people who are very smart and give them an almost impossible mission, you'll be surprised every time." Capps launched then into tips on how to design efficiently and play to the strengths of game designers: they want to play games. When hiring, says Capps, "we want intelligent people who are really impatient and want to see their game features immediately."
 Design, Epic Style Capps does not believe in heavy documentation. If docs are too detailed, nobody reads them; if they're too short, they can be too ambiguous to be useful; and if they are hard to understand, people will argue against them, creating tension and confusion. They also add extra work when, says Capps, "one of the major problems is just finding time to get everything done." Epic uses the Kismet scripting tool to have its designers prototype all ideas before any code or art resources are put towards them. A good idea is translated into a visual proof of concept, which is playtested and improved. The results are "really rough... it's not pretty, and it's easy to break it," says Capps, but that's okay. When an idea reaches a point where a designer is more confident in it, it's presented at a meeting and the stakeholders will "decide if this goes into the schedule or not," says Capps. The visual prototype is given to the code team who are told to "please build it just like that." With the visual prototype, says Capps, "now our programmers know exactly what they're supposed to do, and it's very predictable... easy to estimate and schedule." The concept of perching a character on a tall wall and allowing them to fire downwards was considered for Gears of War 2, but a quick prototype revealed that it destroyed multiplayer balance, says Capps. The good news? "We never had to schedule this or estimate it or anything else... This was a terrible idea and we found that out quickly."
 On the other hand, pushing over furniture to use as cover was a good idea that made it into the game, and, says Capps, "the programmers never even ended up writing this." The original designer scripting was used. Outlining "New, Better, More" The immense commercial and critical success of Gears of War lead the team to devise a process known as "new, better, more" for the features in the sequel. Journalists, gamers, and the team all expected the sequel to vastly outpace the original, and this approach was designed to stimulate that. Management canvassed the whole team for ideas, and then broke them into 16 categories, such as weapons or creatures. They then met with people to hear their ideas and choose "what were the coolest new ideas."
 The important thing in choosing ideas, says Capps, was that "once we had all of these different ideas we tested this against the core pillars for our franchise." His instructions: "never go against it." The five core pillars of Gears of War are: destroyed beauty, humanity's last stand, nightmarish horror, never fight alone, and Marcus is the lead. Ideas like the new crowd system and destructible environments were a "perfect fit", says Capps. Despite a shorter development cycle than the original game, these techniques resulted in a game that is "maybe 50 percent larger than GOW1 in terms of gameplay length. Multiplayer is also 50 percent larger. And we did it in half the time. It's because we found fun stuff quickly and gave the team time to polish," says Capps. Small Features, Big Problem Capps also described what he calls "shaking the Jell-o" -- a process by which changes that can seem small, towards the end of a project, can upset the entire game: "We think is that we want one tiny change here, and the whole game is a mess for weeks. It's very important not to add new features or make changes unless it's critical." The bars for changes are continuously raised until, at the very end, only the most necessary can be made; management's job here is to make the necessary calls. This also applies to getting rid of content, says Capps: "Cut when you need to cut. That's the job of the management team at Epic." Capps also said that crunch is necessary toward the end of the project; however, it's not allowed at the beginning -- and everyone must leave the office by 2 AM. He describes development as a marathon that "becomes a sprint" at the end. The Next Generation of Unreal During the Q&A session, Capps discussed the next version of Unreal Engine, which Capps sees as critically designed to work with massively parallel processing, with a move from a handful of cores in the current gen to in the neighborhood of 64. "We've been working seven years now to get ready for the next generation. We're very worried that the next generation will be massively parallel. We're writing from scratch to make it easy for programmers to work on those systems." However, Capps sees the industry as four to five years away from next generation.