Assassin's Creed 2's Plourde On Why 'Fail Early, Fail Often' Is The Wrong Approach

Patrick Plourde, the lead designer on Assassin's Creed 2 at Ubisoft Montreal, isn't a big fan of that whole "fail early, fail often" thing, ubiquitous as it may be among game design talks. "Oftentimes I visit sites like Gamasutra or go to talks like GDC, and one thing they always say, this recent trend -- it's interesting but it doesn't relate to me," Plourde said during a session at the Montreal International Game Summit today, referring to the "fail early, fail often" principle of design. "There's a stage in the game design process where you need to experiment and not be fearful of failure," he acknowledged, "but at the same time, it leads to a lot of fail." "We couldn't afford to go that way," Plourde said of his Ubisoft Montreal group. Tasked with developing a sequel to 2007's Assassin's Creed in just 18 months, the team of more than 300 developers had to stay on track in order to make a game that would not only beat the success of the first game's impressive sales of 8 million units, but also address its mixed critical reception. "Some people adored it; other people despised it," admitted Plourde. The development team decided to increase the scope of the sequel in September 2008, adding a multitude of new features to its spec when it was roughly a year out from ship. In its final form, the game sported over 230 defined features. So, how does Ubisoft Montreal put its games into production while remaining confident they don't need to resort to an iterative development process? The answers are clearly identified in the game's core focus -- and practical documentation, Plourde revealed. "It's important you first identify the core of your game, and then create a hierarchy," he said. "First, that guarantees at least your game will be fun, and secondly it helps you realize where you can cut corners and still maintain quality." That goal can be greatly facilitated by clear design documents. "A lot of people don't necessarily believe in documentation, even game designers," Plourde said. "[They say,] 'Documentation is useless, nobody reads it. It's just to validate your job.' I don't believe that. It forces you to think about your future. You start writing it, and then questions are raised. You will face those questions early. You're supposed to be a specialist at addressing those questions." Getting the "failing early" out of the way when a game is still in the design documentation process is critical, he added: "It costs less to fail during documentation than production. When I said we had no time for iteration, that's not entirely true. We had time to iterate design, but no time to iterate the code." As a result, documentation and feature approval takes a huge percentage of designers' time at Ubisoft Montreal -- at least two to three hours a day, every day for six months, according to Plourde. "Every director from the game -- creative director, game director, producer, lead programmers, and the lead from the team responsible for the deliverable -- once everyone in that group would approve on a game design, that design was frozen and would go into production," he explained of the feature sign-off process. At that point, "not even the creative director could say, 'Oh, I have this new amazing idea.' No, that feature is done." But that reliance on documentation should not be confused with overly verbose documentation, he warned. "I believe in game design bibles. I'm not saying 400 pages of stuff where I explain my view of life, or why we're doing this. Those are the documents that people don't read. Nobody has time to search through 400 pages of documentation." Instead, keep it straightforward: The people who use documentation are using with that kind of stuff every day. Programmers like to do lists. If you make a list, programmers will be happy, and they'll want to use it." As such, the team doesn't make their feature sign-off documents in Word; they use Excel, and the documents are practical, categorized, subdivided lists of features and specifications, covering as many use cases and gameplay timings as possible. "It's not the easiest road. It's really, really, really time-consuming," Lourde admitted of the document-driven process. The documents are kept up to date until the very end of the project, being used by the QA team to ensure they aren't marking designed features as bugs. Still, he reiterated, they are necessary to the kind of tight development the studio prizes, particularly with such large teams needing to know what's going on at any point. "When making big-budget games, mistakes can prove extremely costly," he concluded. "People don't like to work for nothing, and my job is to make sure people on the team trust me enough that the game we're going to make is not going to fail."