Production: Entering Prototyping

29 Sep Production: Entering Prototyping

Tameem Antoniades

We are currently entering the prototyping phase of Hellblade and I thought this would be a good time to do a production blog for you.  Broadly speaking we are breaking up our development into the following phases:

Concept Phase – The idea behind the game with supporting art.

Prototype Phase – Experimenting with game mechanics, art styles, processes, anything that is unknown and risky.

Vertical Slice – A small section or two of the game that looks, feels and plays like the finished article, built under production constraints.  It is here we discover the heart of the experience, and how we go about building it.

Consolidation – Assuming we know what the experience is and how long it takes to build a small section, we take a month out to simply plan the approach, scope and detail for the rest of the game. It is also a phase where we ready our production pipelines to make the next phase as smooth as possible.

Production Phase– This is where we put our heads down and make the bulk of the game. By the end of this, the whole game is playable from start to finish.

Polish – This is where we nail down the story, VO, cutscenes, as well as playtesting the hell out of the game to give the best possible experience.

Mastering – Bug-fixing, optimization, platform compliance.

Concept Phase

The concept phase is where we develop an idea into a game concept with a small design and art team.  This generally concludes with a few materials:

  • Design Treatment – A 10-20 page document which describes the main thrust of the game designed to be read by anyone.
  • A Trailer – This can be in the form of a ripomatic, i.e. an edited video using other movies as reference, to give a feel for the style of the game before committing assets. In Hellblade’s case we went straight into doing an in-engine trailer which is the one that was used to announce the game at gamescom.
  • Concept Art – Designed to give a feel for the art direction of the game.
  • A Character Brief – An idea for the hero, who she is and what her story is.

We are currently leaving behind the concept phase.  That’s not to say there will no longer be concept art, story development or such going on, but the free-form brainstorming of wild concepts that defines the concept phase, will be more directed from here on end.  We have some goals to hit, we know the direction but perhaps not the destination or how we get there.

Prototype Phase

We have just entered our prototype phase.  So much of what we want to build in a game like Hellblade is unknown and risky.  It is in the prototype phase where we encourage risk-taking and try out ideas that may or may not work.  We do this phase for every game as there is always risky new stuff in design, art or production to try out before betting the farm on it.  We always want to push for new experiences, you have to when you are making games, otherwise, you are simply making clones.

In Hellblade more than most projects we do, there is a lot of unknowns and risk.  Just to illustrate the scale of the problem: if we were to make Hellblade in the same way we did DmC or Enslaved, but with the tiny team we have, we would end up with a one hour game (if that).  So not only do we have to offer a new gameplay experience, but also an entirely new way of making the game.  There are hundreds if not thousands of questions, doubts, unknowns that we are facing in every area of production so where do you start?

Stating your Objectives

I divided the game into several key areas:

  • The World
  • Senua Character
  • Enemy Characters
  • Movement & Interaction
  • Combat
  • Storytelling & Performance Capture
  • Soundscape
  • The game experience, structure & progression


I set up an area of confluence for each of these and created a statements to describe the objectives.  So this is what it looks like for the “The World”:

The World

So in the case of the world, the statements and objectives are made for us internally to help shape our thinking and approach rather than marketing statements designed to excite players.  To be clear, we have no intention to make a game where all you do is wander around for hours without combat.  However, when you are faced with a statement that says that it should In Theory be possible, then it gives those responsible for building the world freedom and power to create something that isn’t dependent on gameplay designers.

Killing Dependencies

The issue of dependencies is such an important point that I wanted to call this out with its own heading.  Game development is a massive tangle of dependencies: most things cannot be done without something else by someone else being done first.  In an ideal world everything would be done in the right order with minimal wastage.  This seems so logical and sensible and much of the science of production is about minimizing any potential for rework.   Unfortunately, it is utterly unrealistic.  Lay all the dependencies out in a line and it will balloon your project timeline by an order of magnitude and, what’s worse, it disallows for iteration and experimentation.  Unless you are making a direct clone of something else, it is a doomed strategy.

A big part, probably the biggest part, of my job as Creative Director is to break dependencies as much as I can and direct a kind of messy flow of experimentation followed by intense focus to get to our destination.  In this instance so much of world building is dependent on player metrics and combat gameplay, that we would just not be able to build much of anything until those two facets where locked down.  However that would takes us months into development and we wouldn’t have time to build much of a world at all.  So I chose to break those two dependencies.

There will be rework later, but let’s face it, there always will be rework.  Rework is required to achieve anything worthwhile so we’ll start work right away and embrace change and iteration when it inevitably comes.  Iteration is not waste, it’s the pursuit of excellence, and dependencies kill iteration.

Setting an Approach

Further on from the objectives, I like to talk to the team about a general approach to the problem.  Sort of like the Camera blog post, it’s good to consider various options, even if some feel wrong from the outset, then pick one to pursue.  So here is an example of that for The World:


Ask the Questions

So far we’ve narrowed the question “How do we make Hellblade?” to “How do we make the world in Hellblade?” to “How do we make the Hellblade world interesting to run around in without worrying about gameplay, story, and code?”

One way to find answers is to ask the right questions.  So the whole team was asked to come up with as many questions as possible for every area of the game.  Here is an example page:


Answer the Low-Hanging Fruit

So then we get into a room with a few key people go through the questions.  We try and answer as many as possible then and there. Probably 80% can be answered definitively or near-enough, based on previous experience.  We do this for every area of the game.

Set your Proof of Concepts (POCs)

For the ones we cannot answer, we set proof of concepts (POCs) like so:


These POC’s are printed and put up on the wall, alongside the objectives and become the basis of the prototype phase of the project.  A team member or POD of team members is assigned to tackle the POC and it is their responsibility to tackle it in whichever way they feel fit. They create and track their tasks with post-it notes.  Here is one of our walls:


We’ve set ourselves 3 months to answer the remaining questions.  At the end of that period, we will move onto building a section of the game with what we’ve learnt.  If questions are not answered by then, then we proceed on the basis that we will not ever get an answer and design the game assuming so.  So it’s up to the team to get to the heart of the answers any which way they can in any manner they think will work.

The Prototyping Trap: “Killing Two Birds with One Stone”

Prototyping is a time for risk-taking, experimentation and creative problem-solving.  It’s about answering fundamental unknowns.  Once answered, building the game becomes a lot more straightforward.  Many teams and team-members try and create work that is usable in the final game during this phase as it will “kill two birds with one stone”.  This is a trap.  It shifts the focus away from being mercenary about testing and prototyping solutions, and focuses them instead on creating shippable content.  This slows down prototyping, creates assets that will most likely be redone anyway, and will ultimately leave many more questions unanswered, making the rest of game development harder.  That’s not to say that there isn’t potential for re-use, but don’t go into prototyping with this as a goal. If you hear that phrase being used, be afraid.  In my experience, when you try and kill two birds with one stone, the stone will miss its mark and the two birds will come back to peck your eyes out in bloody revenge.


Hopefully, you’ll see that the process is straightforward in its approach, very visible to all team members, and puts the responsibility into team members’ hands.  The execution and problem-solving is the hard part that requires extraordinary talent, motivation and experience.  That is what I try and do as creative director: set objectives, make things clear and simple and give people room to do what they are good at.  I don’t pretend to know all the answers, I don’t know where we’ll end up in a few months time.   It is scary, exciting and more so as we are sharing this with you, my friends.  But, in my team I trust!

In the near future, we will take you through the actual prototyping process and the results we achieve. Until next time!

  • Daniel Prem
    Posted at 16:04h, 29 September Reply

    Very interesting post. I beginn to understand how hard making a game really is. Keep going !

  • Ivan Motta
    Posted at 16:19h, 29 September Reply

    This is priceless information… I can imagine how you boost groups interation with time defined goals, and visible and open progress tracking. As a one man team, I thank you so much for these posts, they are working as my personal brainstorm and coaching! Thank you guys, and happy prototiping!

  • John
    Posted at 17:49h, 29 September Reply

    Wow, as always really interesting. I’m looking forward to the next blog!

  • Michael Shade
    Posted at 18:45h, 29 September Reply

    Fantastic Post!

  • Pablo Amaral
    Posted at 03:19h, 30 September Reply

    Really try to kill two birds with one stone in the prototype phase is a problem, since it makes you forget what the main reason you are prototyping and say this because I’ve fallen into this trap as well.

    Keep with this great posts, thanks!

  • Jeff Miller
    Posted at 14:43h, 15 October Reply

    Absolutely loving the transparency of the development process, and am already eagerly awaiting more info.

Post A Comment