Designing Assassin's Creed II

You might think that assassination itself would be one of those core gameplay pillars, but it isn't. It's simply the culmination of using the fighting system, the navigation and the social stealth in concert. It's the payoff for all your hard work.

"Assassination for us on ACII is the end result of the player using the core gameplay within the confines of the fantasy," clarifies Plourde.

"So basically I have a target to kill. I'm going to be challenged on the core gameplay which is navigation, fighting and social stealth to reach a target and once I've reached it, I press X, he dies. And so basically the design direction was to have no challenge in executing them and really the call is that life is cheap in Assassin's Creed."

The process of assassination in the game was also changed, tweaked and refined from the first outing due to frustration from some of the audience.

"That's something we received back in feedback from AC1, that sometimes it's hard to perform an assassination," Plourde reveals. "You're supposed to be the master assassin, it's not supposed to be hard. Assassination is now perceived as a reward for the player."

Assassin's Creed II was a truly mammoth production, featuring over 300 staff that worked across several continents: Ubisoft Montreal handled the core game, the Singapore studio took care of the linear missions while Ubisoft Annecy in France implemented the villa.

This presented something of a unique logistical challenge. As lead designer, Patrick Plourde admits that he can't remember half the names of the people who contributed to the game, and as many of these people would be working in other countries, he couldn't visit their desks to communicate his ideas.

"You, as a designer, you have to be sure of what you're making. You have to have the courage of saying 'this is the game we're making', understanding it and basing those decisions around that," Plourde says. "How can you communicate that efficiently to your team? With a strong document process."

Plourde points to three major advantages of strong documentation. Firstly, by having ideas committed to paper, you're forced to think them through and it makes the process of identifying flaws that much easier. Secondly, the mere act of documenting everything means that you'll never forget an idea. And finally, it reduces the scope for unnecessary questions from other sections of the team.

"By saying it limits questions I'm not saying that I don't want to have comments or feedback from anybody in the team. Everybody is invited to my desk and come up with suggestions, I'll listen to any comments, I don't think there's a bad idea," Plourde adds.

"What I want to say is that I don't want a programmer to spend half an hour, 15 minutes, five seconds on a question that could be answered by yes or no. The programmer is there asking 'does the designer want this blue or red?' I want them to have some kind of spec, knowing how to make that decision on the fly, and focus his work on what he's good at - which is writing code. That's what he likes, that's how you can maximise everyone's effort on your team."

But the final element of the documentation process is the most crucial in a project where every feature you produce has to be right on the first pass.

"It costs less to fail in documentation than in production. When we have to review game design documents, it's better to do that than to revise three or four weeks of work by a games programmer," says Plourde.

He isn't into game design bibles either, and feels that documenting an explanation of concepts or gameplay ideas doesn't help the programmer in his day-to-day life writing code. In putting together his design documents, Plourde talked to the team to see what they wanted from them, what would be the most use.

"We made the design documents with the help of programmers, we asked them what they needed for us to give them," he says.

"We separated every feature: what happens in the gameplay loop, what happens in spawn/despawn, what's the control, AI reaction, sound etc, and in every one of those cells we would write lines and every line needs to have an answer to a question - does it work? Yes or no."

Many of the game's variables are highlighted in the document with brackets. These contain suggested values for a huge array of aspects of the gameplay - for example, how long it takes to loot a corpse.

"Everything in brackets is a value we want to have available in data, so those figures are not hard-coded.

"Those variables are available to game designers at their desks so they can tweak their values and play with them in gameplay. It's really useful late in production where you want your programmers to debug the game and you want your designer to polish. So when I said we had no time for revision, we had time to polish our mechanics using variable data, and also it removes needless debates."

In a team passionate about their work, discussions and arguments over about minutiae can cut heavily into production time. The variables system allows the team to playtest rather than debate.

"The fun isn't in the document, it's created in the game, so when you use brackets, you're trying a value in the game," Plourde says. "It also helps communicate to the programmer what's important for you as a designer in the feature."

The ACII team was fastidious in its work with the design documents, keeping them scrupulously maintained right up until the final days of production.

"Right now you can go into the database of documents for ACII and it's what we shipped with. It's really important because if people start mistrusting your document, they're useless," Plourde states definitively.

"The programmer's going to ask himself a question: 'Is that really what the designer wants? Did he change his mind recently?' We don't want people to ask these questions about what they're supposed to do. We just want them to do their stuff the best they can."