How I work

My take on game design in three quotes:

“No battle plan survives contact with the enemy.” (von Moltke)

“Simple rules lead to complex behaviour. Complex rules lead to stupid behaviour.” (George Lemnaru)

“A build tells more than a thousand words.”

In the olden days game designers would sit down for weeks or even months to write hundreds of pages of game design documentation, which they then would hand over to the developers. The devs would then create a first-playable prototype. Half a year later the team would find out the game was actually no fun at all.

This is, of course, an exaggeration but it illustrates how I do not work. Instead I adopted a much more agile approach to game design and production, not only regarding agile project management but also agile game design. The process in a nut shell:

  1. Depending on the briefing I start with an extensive research phase.
  2. Then I write a brief first concept or create some slides which describe the core game loop. This brief concept provides enough food for a first round of feedback.
  3. I check the gameplay against its targeted audience and run a motivator check against its core features and mechanics to analyse and assess the still theoretical gameplay.
  4. Instead of writing long documents I start with creating flowcharts, wireframes and mock-ups. My weapons of choice are collaborative whiteboards. The mixture of high level flowchart and wireframe visualises the game loop screen by screen. Publishers, developers, project managers, designers find the wireframes much more helpful than written documentation at this stage.
  5. Low-fi prototyping: Paper prototypes, LEGO bricks, click dummies … anything interactive is better than static information on paper.
  6. I extend the wireframes based on feedback. They can now be used as a basis to break down the feature set and further documentation.
  7. Now an iterative specification phase follows. There is no one-fits-all-template at this stage since every game project is different and demands different deliverables at different stages during the development process.
  8. Ongoing documentation. You can find more information in this post.

Leave a Reply