[What can you learn about game design from working on mobile titles? Cellphone game design veteran Ventrice (Guitar Hero Mobile), now working with iPhone developer Smule (Ocarina/Leaf Trombone) on music games, discusses the key conceptual layers of game building that are common to all titles.]

A salesperson might understand the importance of a compelling brand but have no concept of game mechanics. An engineer might understand a compelling game mechanic but not understand the methods of teaching it to the user.

Creating a successful game requires critical cross-discipline coordination, yet all too often team members only understand the facets of the design that face their own specializations.

It is the responsibility of the game designer to bring these specialized perspectives together in a comprehensive design. If the designer fails, different groups in the team will waste time and effort working towards unrelated goals.

But bringing together aspects as disparate as the marketing face of a game and its user interface may seem to be an undertaking in the abstract. What is needed is a framework for understanding the interconnectedness of a design; a way to visualize the trickle-down (or up) impact of design decisions made at any level.

Mobile Insight

Mobile phone games may not be as immersive or as intense as their console and PC counterparts, but their simplicity provides an ideal starting point to an inquiry into the structure of game design. The mobile platform is unique for two reasons: reduced depth and increased breadth.

Reduced Depth. You've probably heard that a design is perfect once everything that can be removed has been. The mobile platform puts this adage to the test. Even today, in the dawning age of the iPhone, mobile developers still have to deal with phones that allow as little as 128k of space; that's 128k for art, code, game data, sound and anything else.

These limitations nearly prevent any kind of gameplay from existing at all, but games do survive; very simple games. In these stripped down games, the underlying design structure is highly refined and clearly visible.

Increased Breadth. Over the course of a relatively compacted span of time, a mobile designer works on dozens of titles, spanning nearly every conceivable genre.

Designing three or four different games at a time, you have two options: learn to understand all games by a common set of terms, or go crazy trying to keep track of everything individually.

What follows is a summary of lessons learned in the field of mobile design.

The Layers

Every game design can be understood through four distinct perspectives. These perspectives stack nicely, so it is convenient to label them as the four layers of a design:

As an example, let's take a quick look at the perennial mobile favorite, Tetris, in Figure 1:

Paradigms may seem abstract at first, but they are an essential perspective to understand.

Every game can be defined by these four layers. Let's take a more detailed look at each individually.

Concept

For many people, game design begins and ends with a concept. "Hey, I have a great idea for a game," it usually begins; what follows is a concept.

The concept on its own offers very little real insight into how or why the game will be fun. Often, the person pitching the concept is imagining a few other games with similar concepts and assuming all of the ancillary details of the gameplay are implied.

If you're a designer, you know this is not the case, but that's not to say a designer should be dismissive of concepts. After all, the concept is the highest level of the game design; a game won't sell without a concept that tells a compelling story all by itself.

Some of the greatest games ever designed were commercial failures because the concept didn't resonate with the consumer. Sequels and movie-licenses are successful largely because the concept is already defined in the consumer's consciousness.

In a mobile game, there is no box art or demo video: the concept has to come across in the game's name. When I was working on a game using the 24 TV show license, the greatest obstacle the team faced was naming the game.

We were already on the sequel and we knew the first game had underperformed, probably because of the name, so "24 Part 2" just wasn't going to work. Something like "24: Jack Bauer's Back" was contractually not an option. Ultimately, the game was named 24: Agent Down and very likely suffered because of it.

In our case, the concept was already set; anyone who had seen the show knew 24 was about espionage and intrigue, hacking computers and after-hours shootouts, but communicating it to the consumer in one short line of characters was almost impossible, making the concept as good as lost.

A game that worked was ER Rush. ER Rush was an original IP, hospital-themed "plate-spinning" game, similar to the successful Diner Dash. We diverged with many of the mechanics, but the basic concept was the same. The users got what they expected (a game where you rush around servicing patients in a hospital environment) and the game sold well.

The best thing to do with a new concept is to encourage it; pick out the aspects that seem most compelling and expand on them. Tell a story. Let others tell a story. This won't necessarily describe the final game, but it helps define the next step: paradigm.

Paradigm

Paradigm is perhaps the most difficult to name of the four basic layers of a game design and the most easy to overlook. It sounds pretentious and abstract, but the meaning is actually very specific and necessary; the paradigm is the perspective with which the user interacts with the game.

Every user that picks up your game will be approaching it with a certain set of preconceptions; assumptions that are inherent to the user himself, his society and humanity in general. Games are reflections of human life so it is only natural that most games tend to fall into the same range of popular experiences such as, hunting, hiding, collecting, building, etc. It is these experiences that define paradigms.

A paradigm encompasses a set of expected rules. The user intuitively knows the objectives and hazards inherent to a paradigm, such as managing resources, without needing to be told. If a game incorporates many different experiences, each with its own micro-goals, then it can be said to incorporate many different paradigms.

Paradigm is similar to genre, but where genre relies on past games to build archetypes, paradigm refers directly to the fundamental building blocks of human experience.

An example genre; first-person shooter, describes the visual perspective and objective, but fails to define the specific paradigms. A FPS might feature slow-pacing (methodical/planning ahead), heavy use of cover (hide and seek), strategic weapon-upgrading (resource management) and situational toggling of weapons (tool management).

Each of these aspects of gameplay is actually its own little paradigm (marked in parenthesis) and each carries with it a familiar experience that the user can be assumed to understand immediately. A user doesn't need to be explained the premise of hide and seek; it is inherent to the human psyche.

It can often be difficult to differentiate paradigms from concepts; many concepts will immediately suggest an obvious paradigm (for example, a deer-hunting game begs for hide-and-seek gameplay), but that doesn't mean other paradigms can't be used.

It is also easy to confuse paradigm with game mechanics. Often, the first game to succeed in a paradigm sets a precedent for mechanics that is rigidly copied by generations of successors. For example; does a trick-based boarding game have to be built around a four-button combinational input scheme? For many years, it did.

Mechanics & Features

Paradigms imply the rules of a game but the mechanics define them. In a way, mechanics are the toy within the game. Momentum is a mechanic, so is matching three blocks to remove a set, reloading a gun, building a barracks out of wood and iron, or anything else you can do in a game. If the user can change or affect something, it is a mechanic.

Mechanics are specific and technical and the details generally constitute 'too much information' for anyone other than programmers and designers. For everyone else there are features which are just lumped-together groups of mechanics that gloss over the specifics.

An experienced designer is thinking about mechanics from the moment the game concept comes crashing onto the scene. If someone says, "Hey, let's make a game where you're God!" and everyone agrees that's a great concept, the designers had sure better be working to define manageable mechanics before everyone shakes hands and starts work.

A common, unspoken, belief in mobile game development goes like this: The more features and mechanics in your game, the better it will be; this is because, the more things there are for the player to do, the greater the value of the game.

The above statement would be completely true if making games was not a process limited by time, money and user attention. The most important thing a designer can do is decide which features add up to a compelling whole and which features are expendable.

Being a designer is like being a director because, at the end of the day; ideas are cheap, artistic vision is not. Programmers can view the design as pure mechanics, producers as pure features, but the designer must see more.

Beyond the functionality and the features, it is the designer's job to use experience and vision to pare down the proposed design into something which is aesthetically pleasing, poses meaningful user decisions, adheres to an intuitive interface, and creates a cohesive, balanced experience of tension and release.

Interface

The final layer of game design is interface. Interface is the physical means, and audio-visual cues, through which the player interacts with the game mechanics.

Traditionally, interface is about buttons, but it might also include an analog stick or two, mouse, microphone, accelerometer, plastic guitar, or futuristic motion-sensing glove.

At its simplest, interface design is just matching inputs to the mechanics, but the task quickly becomes a balancing act: don't overwhelm the user with too many new inputs, avoid difficult input combinations or prohibitively precise timing, and stick to a consistent, easy-to-remember theme.

With mobile phones, interface is a significant challenge; phones aren't built as gaming devices. While designing Guitar Hero World Tour for mobile, I quickly confirmed that adding just one more button for a kick-drum created gameplay significantly more difficult than the three buttons the player experienced on guitar. Players often had to change their entire method of holding the phone to accommodate the added input.

To simplify the addition, we allowed the entire bottom row of number buttons (7,8,9) to be valid kick-drum inputs and then went further and filtered the note-data so that no multi-note chords would occur on drum tracks.

In the end, this additional simplification actually helped create unique gameplay between the guitar and drums modes: the challenge of guitar was in managing increasingly complex chord transitions and the challenge of drums was in the fast succession of single notes over a wider range of inputs.

As much as we may wish it wasn't true, interface exerts an upward influence on the mechanics; a design only works if the user intuitively understands how to interact with it, so accommodations must be made for the sake of the interface. Entire books have been written on interface design and usually the conclusion is the same: the goal of the interface is to make the interface as transparent as possible.

Conclusion

At this point you may feel that many more questions have arisen than have been laid to rest. How should you balance the benefits of fresh concepts and familiar concepts?

How granular should the definition of paradigms be? What is the best way to organize features so that they are defined by both by upward-facing behavior and underlying mechanics? How should interface requirements be prioritized?

The benefit of defining a game by the four layers is that it opens up understanding of the design and allows visibility to the deeper questions that need to be asked.

Each of the four layers is surprisingly deep in its own way:

On a small mobile project, all of the above are most likely the responsibility of one person -the designer- but this can be an advantage.

When all of the layers of a game design are understood by a single person, that person is in the position to make the most informed and effective decisions. If an entire team can be brought to understand the game as a whole, the entire team can make informed decisions.

The purpose of this article wasn't to explain how to design a game as much as how to approach designing a game. Once the four layers have been addressed, the design is only just begun, but at least you're pointed in the right direction and you understand where you're going.

For Further information

The Rules of Play -- Zimmerman and Salen
Universal Principles of Design -- Lidwell, Holden and Butler

Related articles:

Lopes and Kuhnen's take on understanding design in terms of Top Down and Bottom Up approaches:

http://www.gamasutra.com/view/feature/2129/game_design_cognition_the_.php

Ernest Adams' rail against bottom-up design:

http://www.gamasutra.com/features/20041018/adams_01.shtml

John Rose's argument for parsimony with Mechanics:

http://www.gamasutra.com/view/feature/3621/fewer_mechanics_better_game.php

Phil Goetz' argument for parsimony with Interface:

http://www.gamasutra.com/view/feature/1839/too_many_clicks_unitbased_.php

Berbank Green's investigation of the fundamentals of interface and mechanics:

http://www.gamasutra.com/view/feature/2316/one_button_games.php

Brett Johnson's discussion of user expectations, or as I've called it, paradigm:

http://www.gamasutra.com/view/feature/3052/great_expectations_building_a_.php

Specific examples of managing features, mechanics and interface, in Black and White 2:

http://www.gamasutra.com/view/feature/2399/postcard_from_gdc_europe_2005_.php

---

Title photos by P.A. Hudson, Nicolas Nova, Richard Hagen, and Kerri 2009, used under Creative Commons license.