During a talk at the Montreal International Game Summit, Assassin’s Creed 2 lead designer Patrick Plourde told how the schedule for the blockbuster sequel was so tight that they didn’t have the option of making wrong decisions.
The project, which was in development for 18 months and launches in the US and Canada at midnight tonight, had a clear target: to create a game that would be received critically and commercially better than the original Assassin’s Creed.
To do that, they examined all of the feedback from the first game and set about creating a hierarchy of game features to identify those ‘core pillars’ of the experience: fighting, navigation and social stealth, as well as those that they categorised as ‘supporting features’ and ‘exotic features’.
They soon came to realise that the missions in the first game were unpopular because they didn’t incorporate these key features. "They were almost like mini-games, in a way," said Plourde. "They were all quite different from the main experience and required a lot of coding to get to work."
With Assassin’s Creed 2, however, the team decided to revamp the missions by making them take advantage of the pillars. "So, for example, we have Prince of Persia style missions where the aim is to get from point A to point B in these interior spaces, and the gameplay there is working out how to use the environment to do that," said Plourde.
"Immediately, once we focus tested these missions, people were really enjoying them, because they exemplified our game’s strengths. And we didn’t have to write a single line of extra code."
Plourde also shared how he managed to, as lead designer, communicate his vision clearly to the 300+ people working on the game in three different geographical locations (Montreal, Annecy and Singapore): through being exhaustive with documentation, but not by creating exhaustive documents.
Rather than create a giant game bible – which Plourde said he "didn’t believe in" – he instead managed over 200 ‘final sign-off’ documents; each one an Excel document with clearly defined and hierarchically-presented information so that everything could be easily understood without paragraphs of text.
"A lot of people don’t believe in documentation – they think that no-one actually bothers to read it, or that designers just do it to justify their jobs. But that’s not the case – when you have to write a feature out, all sorts of questions will come to you, and you can answer them then rather than have to field questions all the time.
"It was also the only chance for us to iterate, by all working on these documents – we couldn’t iterate in code once things had been implemented; but we could iterate at this document stage."