The prototype methodology we've used for the naval of Assassin's creed 4

Gameplay prototyping library

My name is Sebastien Lambottin, I was the principal designer of the naval gameplay for Assassin’s creed 4 black flag and with this article I would like to share with the developer community my prototyping methodology: building a gameplay prototyping library.

I know doing prototypes is nothing new for a game development team. What I consider special about the way I’m doing prototypes is that by using the same external engine repeatedly, I’ve build a library of features that I can reuse from one project to another.
 

Here’re some examples of the features we’ve managed to prototype on AC4 with this methodology:
 

- For every ship AI archetype, a prototype of a first basic version of the AI (the brig, the frigate, the man of war…. )

- A prototype for our ballistic shooting mechanic, especially to evaluate how hard and difficult we could make it.

- A prototype for basic AI navigation for the ships. To define the challenge a group of ship would create to the player.

A part of the result of those prototypes was the architecture of the player's weapon ship:

(For those who have read my article about the pillar of combat design -http://www.gamasutra.com/view/feature/175950/the_fundamental_pillars_of_a_.php - this schematic above will remind you what I was explaining about designing very different and complementary weapons for the player)

The main points of the method

Now that you’ve seen some examples and some result of our prototypes, I’d like to go in detail about my methodology:

Overall I’d say the goal I’m aiming for with those prototypes is to increase the iteration speed of the design and also, as a game designer, to give me the ability to be more creative within an “AAA” dev-team.

In a certain way what inspired me about trying to build a gameplay prototyping library is the way concept artists work.

They generally use the same tool from one production to another: Adobe Photoshop. This tool is an external tool, and there’s a big community using it.

As they keep using the same tool, they’ve built a library of brushes and textures which they keep from one production to another.

A- Choose an external engine to work with and stick to it

Just as the artists which are using Photoshop, I’ve chosen an external engine which is different from the in house engine the team use to develop your game.

There’re 3 main reasons for this:

B- Build a library of features

Building your library of features is the most important concept of the methodology.

When you have developed a base set of features, you will be able to re-use and combine these features to create new prototypes rapidly.

Here’re some concrete examples which demonstrate the benefits I’ve obtained from building and maintaining my library of features.

I- Mini-map example

For the need of a shooter prototype I’ve coded a mini map to be able to spot the player’s allies around him.

Then when I had to code the prototype of naval combat for AC4 I just had to import my code and assets I had coded few years ago for my shooter prototype.

II- Multiplayer example

Having the base of a multiplayer working in a game engine is quite tricky, and it takes a bit of time to code it.

I spent a few months 2-3 years ago to learn this complex exercise of coding a basic multiplayer.

For fun, I’ve implemented the multiplayer in the prototype I did for the naval combat. It took me just 2 days to add the multiplayer in this prototype. This is one of my best examples to showcase how my library starts to become very efficient to code new prototypes.

III- Ship and sword fight example

I’ve coded many combat prototypes so I have a lot of clean code and assets in my library. In parallel, we did a prototype of naval combat. Then just to test a few ideas I’ve implemented a sword fight system inside the naval gameplay prototype. This took me little more than a day to implement. Once again it shows how quickly I can combine different features I’ve developed for different prototypes.

It’s been 4 years that I’ve really started to code those prototypes. So the library of features starts to be quite big. Also by building this feature’s library, little by little, I’ve learned and improved myself a lot about game programming.

C - Code it myself

As a game designer having the ability to code by myself and showcase my idea in a playable way has turned to make me more creative and more precise in my design.

A good tool for pre-production:

By being more and more efficient at coding prototypes you'll be able to playtest a lot of feature with them. Indeed those prototypes are super helpful to de-risk and playtest the most complicated feature and get ready for production.

The most ambitious exercise with my methodology would be to prototypes all the game this way, only focusing on gameplay.

To make a parallel with another entertainment industry, the movie industry uses a super-efficient tool to give them an overview about what their movie is going to look like in early development stage: the story board:

I’ve always felt that we were missing some steps to validate our ideas before developing a game, and reaching the level of completion of a story board would be the next step I’d try to go with my methodology.

Conclusion:

I hope this article will inspire other designers. Overall I wanted to express that as game designer it’s always good to push our abilities to be as autonomous as possible, and be more efficient within the team.

As a reminder, the key takeaway from my methodology would be this simple schematic:

Code it yourself + keep using the same tool + build your gameplay prototyping library

1: Expand your creativity, explore new feature by yourself: new camera view, new type of vehicle, new AI behavior...

2: Be more efficient; increase your iteration speed, your communication. Accelerate accessibility to playable feature and rely on it to take decision