Here is the content of the article I have published in Develop Magazine, issue #116 that you can read and download on the following links:

Read online:

PDF Download: Look for the issue #116 in May 2011 page 47.

The version in the Develop Magazine is obviously nicer to read with diagrams. The magazine is definitely worth reading as a whole!


“Dealing with a Serial Killer”


We all know that “requirements” quality is a major factor in developing a hit title. The subject has been covered at conferences for years and books have been written on how to model and improve them. But to my mind, the deeper and root cause of many trans-project bottlenecks is often intrinsic and completely missed – namely the subject of “ambiguity”.

The first challenge faced by games designers is to accurately convert your “world of ideas” into a “world of words”, i.e. into a games design document (GDD). This exercise is essential for scope, but will also create issues for the following reasons: (1) Some ideas are not conscious enough to be converted into words so about 30% are lost; (2) A further 20% of the ideas that can be converted are partly “damaged” on the way; and (3) When the written document is received by others for implementation, ambiguities remain that require interpretation and some of these interpretations will be wrong, resulting in 20% being badly implemented.

To formularise: For every 100 ideas or features desired only 44.8% (100×0.70×0.80×0.80) are implemented accurately in the natural world of software. Yes, less than half and a major cause of change requests.

Why? Because written language is treacherous! It was originally invented to calculate how many cows or slaves we bought and sold at market. More typical communication is conducted face-to-face and major studies show that 80% of a message is not conveyed by words, but rather by human interaction such as touch, body language, facial expression, inflections of speech, etc. Beyond that, even hoping for precision in a written document is pure fantasy. The best example is that after 1,000s of years of writing laws, we are still totally unable to write an important one that is clear enough to not demand a first “interpretation” by a solicitor or judge. That’s how lawyers make their living.

I have seen some astonishing statements in GDDs I have worked on. For example:

  • “…the amount of time this takes depends on the weapon and the length of time the player has been firing for.”
  • “If the target is far away, the crosshair remains…”
  • “Accidents need to be spectacular. (Without being gruesome!)”

None of these descriptions are testable. They appear to be sufficient, but will lead to interpretive troubles later. And that’s when your change requests will begin. They contain no clarity.

For example, if I told you that, “I’ve had a tough day.” you would simply nod in affirmation. But then if I ask you what I meant, you may begin to see problem. My day may not seem so tough to the receiver of the message – it’s based on their experience. This phenomenon is common in GDD’s and, all too often, around a dozen ambiguities are common per page. All are excellent dream makers but publishers put fortunes on such statements. I call that a big gamble. In fact, the biggest culprit is not the hard-working human behind his/her keyboard but the written and natural language; excellent for writing a novel or poetry, but so weak at precision. Would a mathematician ever express a differential equation in plain English?

So, what can we do to improve things? Below is a process we often use with clients (in my writing and therefore partly flawedJ), but the act of conducting the exercise eradicates the vast majority of ambiguities affecting your internal team or publisher.

  1. Scan the GDD and any other requirement documents to look actively for ambiguities
  2. Have a number of your core team carry out the same exercise
  3. Write down each one ambiguity
  4. For each one found go through the following cycle:
    1. Identify the type of ambiguity (you need to define a typology of the ambiguities you encounter for your kind of project – it is likely to be different for an FPS, a RTS or a simulation game);
    2. Grade the severity, i.e. the consequences it may have if misinterpreted;
    3. Identify a possible mitigation solution;
    4. Assign the removal of the ambiguity to someone;
    5. Measure your level of confidence in the possible solution;
    6. Measure the level of testability once cleared;
    7. Measure the overall risk value of the ambiguity on the project.


For the ambiguities you cannot clarify (there will be some, but less than you think), flag them and make sure that both studio and publisher agree that the ambiguity (and its possible consequences) are acceptable and better left as is, rather than resolved.
It is important to understand that removing an ambiguity is not necessarily done by adding words to the document. Often, the more you write the more ambiguities you are likely to add. It’s the very nature of the trap.

This strategy will present you with a completely different understanding of the risk on your project. You make the project testable. You drastically increase the quality of the expectation of the different parties before each delivery. The level of trust amongst the project’s stakeholders is built tenfold. Ultimately, your project will gain a greater ability to complete on time, within budget and to all parties’ expectations.