Introduction

In this article I'll discuss a game creation method through iteration for small, unique projects, and will describe how the failures and success of the process of designing our studio Mobile Pie's upcoming iPhone and iPod touch title B-Boy Brawl: Breakin' Fingers shaped that methodology.

I will discuss our initial design approach, based in the traditions of linear video game design, and how that evolved, through the failures we saw and the confusion we felt, to produce a core gameplay mechanic that is fun and functional and how the process can be refined and applied elsewhere successfully.

I will consider video game design according to Ian Bogost's theory of Unit Operations; this suggests video games are constructed from discreet unit operations which function to create a system which delivers a desired meaning. We can hypothesize that our approach to building a complete system, or video game, must be based on a sound understanding of how these unit operations function with each other to achieve a desirable outcome.

Existing systems can be deconstructed and recreated verbatim or slightly deviated, with reasonable ease and security. However, if we wish to construct a new system, relatively unique from those that already exist, then we must choose the correct unit operations (or design elements, perhaps) which interact to create our desired outcome, however their selection is tricky and cannot always be deduced by pure logic.

Instead I suggest one must create, test and refine a unique system through an iterative developmental process; observing the feedback of the system, isolating the elements that pervert the intended meaning, replacing them with those deemed more suitable and repeating the process until a satisfactory result is observed.

The proposed process may seem self-evident to many seasoned video game design practitioners, especially those with experience of Agile methodologies, however, best practice at each stage and considerations for different projects are discussed throughout, with conclusions drawn from our own successes and failures.

The Context for Iterative Development

Digital content delivery has long been the prophesied savior for an industry creatively bound by huge overheads and a physical retail stranglehold. While concept approval and overzealous development hardware restrictions may hinder certain console outlets, the PC and Apple's App Store both allow small development teams the freedom to test the water with commercial yet ambitious and unique games, providing for interesting experiences such as Zen Bound and World of Goo, as well as thousands of miserable, ugly failures.

As video game production costs grow and return becomes increasingly spread, ever more financial risk is put on all new development. In order to normalize the market, publishers, as well as studios, greenlight fewer products with unproven design elements; focus has shifted from design innovation to proven success and careful market positioning, slowly homogenizing the video game experience and potentially eroding consumer confidence.

The huge budgets and slimmer margins have also brought with it a culture of tight micro-management: both in terms of scheduling and over-reliance on meticulously pre-planned design, which incorporates the marketing will of licensing and small risk-free design deviations; both of these blights are linked creatively as well as commercially.

Although this may well be an understandable and, perhaps, forgivable norm for the large publicly held companies, small indie developers are gaining worldwide notoriety by releasing attention-grabbing games which deviate massively from the slew of cookie cutter commercial titles. However, for every Darwina or Alien Hominid there are a thousand nice ideas poorly realized that ultimately sink and disappear without even a ripple.

These failures could in part be blamed on development methodology; placing too much faith in the big studio ideology of immovable production paths. In taking a great idea and committing, what might seems sensibly, to the design very early on small teams can, from my experience here at Mobile Pie, put themselves in a perilous position where predetermined schedule is chased at the cost of quality.