Thursday, March 17, 2011

Visual vs Action Oriented Design [Game Design]

Visual vs Action Oriented Design [Game Design]:

Eye hand

(with thanks to Ian Carroll)

Generally speaking, there are two ways to start designing a game. The first is to start with visuals. You create a world, a series of possible dynamics that might come out of that world, and you have a sense of back story. You tend to describe the world in terms of place, character or storysense, and paint a picture of an experience to inspire your team.

The second is to start with actions. You start with what the player will do, how he will do it, how the game will control and what the camera will do. You tend to think in terms of rules, efficiency and flow and treat the aesthetic components as something that will come along later.

The games industry often uses visually oriented design to sell its ideas, but action oriented design is usually superior for making great games. So why does the visual persist?

 

Visually Oriented Design

Visually oriented design is a top-down way of creating a game. It focuses on the whole game as a series of experiences and desired outcomes. The visual designer tends to think in terms of emotions, moments and the marketing story first, then backtracks to consider how the game intends to achieve those goals. Starting top-down is also a useful way of elevator-pitching a game to investors and the public because it captures the experience in neat sentences.

However, visually oriented design also has a critical weakness: While a visual approach might sell the idea of the game to the team, or to management, each group comes away with different understandings about what the idea implies. Starting top-down creates an impression rather than a specific template for a game, and so everyone who comes in contact with the design interprets it on their own terms. Visually oriented design is prone to a lack of clarity, and that can lead to very serious problems later on.

Visually oriented design’s second weakness is that it assumes that the game part will be filled in later. This often means that the programming team becomes the de facto design team and so the game that results diverges wildly from the intended design. Most programming teams hate being put in this position because it lays all the responsibility for project failure at their door, and yet they have no clear idea of what’s required of them. Programmers are the most literal people on any team and they thrive best when they understand requirements clearly. Visually oriented design is not their friend.

Third, visually oriented design forgets basic considerations. Fairly vital questions tend to go unanswered for long periods of time, such as:

What will the player do?

Will he have enough of it to do?

What will the steps to the epic win consist of?

What’s the game dynamic?

These are important questions that frame the rest of the game, yet they are often left until much later in the process and then require significant rethinks to be incorporated. What often happens in a visually oriented design is that the team will work for a long time to satisfy the initial emotional vision of the game, only to realise that it doesn’t seem to hang together. So they end up having to pick the whole thing apart in order to figure out what’s wrong.

Finally, visually oriented design tends to lead to no-brainers. The creator tries to find a genre or hook that her pitching audience will understand and she defaults to referencing other games. Saying that a game is like a mesh of Halo and Starcraft is a pitch that most people can immediately visualise, for example, and might get the game sold. This is the very essence of nuts-and-gum thinking, however, and like all no brainers there’s usually a very good reason not to make it.

Visually oriented design works best as a method if the designer does not have to explain the rules of the genre. If you want to make a Modern Warfare style of shooter, you can simply point the team at Modern Warfare as a case study. If you want to make a city simulation game on Facebook with a unique twist, you can point people at an existing game and say ‘It’s a bit like this, but with dolphins instead of cows.

If, on the other hand, you intend to create something brand new then visually oriented design is horribly unproductive. What you need instead is action oriented design.

 

Action Oriented Design

Action oriented design dumps all ‘elevator pitch’ concerns and starts from the bottom up. It asks what can the player actually do on screen, why are they challenged, and how can they then get to do more. Action oriented design sees the player as a doll, enemies as blocks and thinks only about rules and consequences and nothing else. It is only focused on what the player can see, hear and do, and everything else such as story and setting are regarded as secondary [...]

No comments:

Post a Comment