Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 24, 2014
arrowPress Releases
October 24, 2014
PR Newswire
View All

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

 Assassin's Creed 2 's Plourde On Why 'Fail Early, Fail Often' Is The Wrong Approach
Assassin's Creed 2's Plourde On Why 'Fail Early, Fail Often' Is The Wrong Approach
November 16, 2009 | By Chris Remo

November 16, 2009 | By Chris Remo
More: Console/PC

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."

Related Jobs

Digital Extremes
Digital Extremes — LONDON, Ontario, Canada

Digital Extremes
Digital Extremes — London, Ontario, Canada

Generalist Programmers
Petroglyph Games
Petroglyph Games — Las Vegas, Nevada, United States

Unity Engineer
University of Central Florida, School of Visual Arts and Design
University of Central Florida, School of Visual Arts and Design — Orlando, Florida, United States

Assistant Professor in Digital Media (Game Design)


ken sato
profile image
This is a critical point.

A lot of developers, including some new to the market, miss this point and attempt to maintain this process which takes a lot of 'polish' on the title. Instead what you get is some sort of disjointed gameplay which 'reminds' you of other successful titles rather than the one you're playing.

Also maintaining this process throughout the development cycle increases the uncertainty of the over all project, keeping risk and tasks fluctuating rather than stabilizing to define the critical path. (If you find several 'critical' paths, something is DEFINITELY wrong.)

Finally "velocity" is only one variable to completion. This goes beyond FPS / gun models but also to project development tasks. You can complete a lot of small independent tasks quickly but if it doesn't produce the result of stability to finished work, then what's the point? The impact is some sizable piece of work that can be flagged as "done" with some clean up work at the periphery towards the march towards FC. Otherwise you're just progressively increasing the risk as the project progresses.

(The image of juggling multiple hand grenades. If you're not reducing the number of grenades being juggled to zero, someone always goes and pulls one or all the pins.)

Kai Steinmann
profile image
Whether I agree or not, I do enjoy a good "I'm not drinking the cool-aid" argument. Always question convention. Thanks!

Craig Henderson
profile image
This article fails.

" 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." "

That's kinda the whole point of the 'fail early, fail often' mantra. The point isn't to fail early in your CODING, it's to fail early in your PROJECT. No wonder Ubisoft is doing poorly this quarter.

Mohammad Musa
profile image
This 'Fail Early, Fail Often' approach might not fit well with a sequel type game (like Assassin's Creed II). However, if you are creating a new game from scratch and you are not 100% clear on the game mechanics, you need to iterate on many ideas and experiment to figure out what works.

Its mentioned above that the team added a number of new features to AC2, but I bet many of them were based on the critical reception of AC1.

Luis Guimaraes
profile image
There's a reason of why there's a game designer (or planner, as in Japan) at all. Vision and foreseeing ARE a must for big scope projects.

Jason Bakker
profile image
I think the "fail early, fail often" mantra is around to create the situation that Ubisoft are currently in for Assassin's Creed II, where they have already made a game and know their failures and their successes.

When you're not in a situation where you're basing your game off a sequel, a lot of your ideas are untested, and while it may be more cost-effective to limit yourself to what you know will work in an original game, that does mean that the game's originality is constrained.

Yannick Boucher
profile image
I think the headline here is actually totally misleading. The "fail often, fail early" idea is obviously to be applied at the conception phase, which Plourde admits: "It costs less to fail during documentation than production." Well, yeah, that's exactly the point. He's not saying it's wrong at all.....

Federico Fasce
profile image
Well, they have done at least one iteration: the first Assassin's Creed, which counts clearly as a prototype tested by willing (and paying) players.

Yannick Boucher
profile image
@Frederico: Strong words. Next time you make a prototype that matches AC1, mind to share? ;)

brandon brown
profile image
I'm actually really curious as to why they use excell over word. As far as i'm aware just about everything you can do in excell, you can also do in word. With the added benefit of making a much more attractive looking document that can be so much more eaiser to read and understand.

Glenn Storm
profile image
As mentioned in comments, the title misled me as well until I got to the part where pre-production, the documentation, is described as the place of iteration. I see what he's saying and agree; there's no place in a tight schedule for noodling the design in the middle of development, and there's no place for 400-page docs that no one reads. I want to highlight then, the brief mention that working off a lighter GDD means a lot of work. This makes a lot of sense to me; if you've written down only the 10 Commandments of your production/product, then you've probably got a lot of sermons to deliver to maintain the spirit of the design.

Barry Meade
profile image
I have to say the gist of Plourdes argument reads as if trying to justify the mountains of paperwork he is so obviously forced to do by working at a mega-office, and I can relate. But I think he's rather missing the point of iterative testing in software if he imagines, as he seems to be saying, he can hothouse ideas/gameplay on paper. Unless I've completely got the wrong end of the stick (which is both likely and regular :P) I think the wires are crossed on this one.

The whole point of blasting ideas into software is to *avoid* mountains of tedious paperwork. Claiming he manages to gain the same benefits of iterative software testing by over-producing paperwork doesn't make sense. It's rather like claiming that extra human muscle on a production line can bring all the benefits of robotics - it's irrelavent as the robots are designed to replace human muscle, not compete with it. Paper design is necessary to set paradigms for the team so everyone knows what they are supposed to be doing. As far as it being the medium to proove or test out gameplay or in-game design ideas, that's what software is for and if you aren't building and iterating your game (and those big paper ideas...) in software, on screen and through the control system, then you're kidding yourself. If ACII turns out to be a series of big ideas strung together by over-wrought cutscenes, ponderous traversing of the levels and very little love in the second-to-second gameplay, I'll remember this article. It already makes clearer to me how AC 1 ended up as it did.

I might also add, just to be fair, that whilst I thought the gameplay in AC1 was, well, what everyone else thought :P, I genuinely loved AC1 as an experience and thought that in the areas where it excelled, it was point zenith for what can be achieved in this medium of ours and I've been drooling for the next one for quite a while now. I'm glad Mr. Plourde and the rest of Ubi are in the industry making us all pull up our socks :P

Thomas Langston
profile image

I'd venture the guess that is about what Excel can't do that makes it so attractive. You can't make pretty little novels of design philosophy readable in Excel. You are constrained into making small percise statements about design features. Although I'd further assume that the SUM function on the 'completed' column is probably also gratifying.

Curt Perry
profile image
"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."

The problem with this statement is that gameplay mechanics that sound great on paper often turn out not to be fun when actually put in the game - and I've seen this happen more often than not. Your customers aren't going to care how much fun the design document sounds, what matters is the actual game. Asserting that you aren't going to iterate the code sounds like you aren't going to fix design problems that did not become apparent until they were implemented.

Luis Guimaraes
profile image
That's the problem, mechanics aren't supposed to sound fun, they're supposed do be fun, you can't iterate words. Plourde is right.

Arun Prasand
profile image
'Fail Early, Fail Often' Is The Best Approach --- if it is a new idea.

'Fail Early, Fail Often' Is The Wrong Approach --- if it is a sequel, where all the failing would have happened in the earlier version's prototype itself.

[User Banned]
profile image
This user violated Gamasutra’s Comment Guidelines and has been banned.

Barry Meade
profile image
"That's the problem, mechanics aren't supposed to sound fun, they're supposed do be fun, you can't iterate words. Plourde is right. "

Not sure what you mean here Luis - Plourde is the one advocating iterating words.