Opinion: Visual Vs. Action Oriented Design

[In this opinion piece originally found on Tadhg Kelly's What Games Are blog, and reprinted in full with his permission, UK-based game designer Kelly looks at the differences between visual and action oriented design, spelling out the pros and cons of each approach.] 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. Action oriented design should start with the game’s interface (joypad, mouse and keyboard, etc) and establish rudimentary things like controls and camera perspective very early. What is the player’s doll going to do? How is the doll going to do that? How quickly can we prototype that action to see if it is actually fun or not? As a method, it has many strengths. It breaks the game down into objects that programmers can understand, and so they know what they are trying to code toward. This means that the game engine will perform better, and having better engineering yields many of its own benefits in the long term. As a corollary effect it also doesn’t make the programmers feel like they have been handed the bag. Secondly, action oriented design focuses on the main risk area of a game (is it fun?) earlier rather than later, saving a lot of misdirected effort. This means that the team can work out how to develop a fun set of actions and then extend them, and so figure out what the game will be. That in turn means that required assets, production costs and so forth can be reasonably assessed as the project develops. Thirdly, action oriented design teaches game designers to think efficiently. When you are obliged to describe game controls first it makes you consider whether the controls are causing button overload, whether the camera perspective will work, and other physical factors. Subsequently you realise that game rules are better expressed in simple rather than complex terms, and you realise that special case objects and behaviours are generally inferior to class based ones that are widely applicable across the whole game. In short, action oriented design is really good for finding the fun earlier rather than later and then producing a game which is elegant. It is also less prone to opacity because it results in early working software that can be played and understood. Games built from an actions-first perspective therefore tend to be substantial rather than flaky experiences, and more likely to produce 100 hours of gameplay. However action oriented design has its shortcomings too. The biggest is that outsiders do not understand it. An action oriented game design often looks ugly for a long time, has no sense of story or place, and so it’s very hard for management, artists and other people working on the periphery of the game to know what the game is supposed to be. These are the sorts of people who need to be sold on the emotive qualities (because they think visually) and just blankly stare or become uncomfortable with a design method that seems intellectual. Secondly, action oriented design runs the risk of creating an abstract game. An abstract game is one which technically is correct, and is fun to play, but which players have a hard time caring about. Many indie games feature the adventures of a spring navigating a series of clever object platforms, but it’s hard for players to get why that is supposed to be fun. There’s no humanity to it, and so the marketing story behind such a game tends to be dead on arrival. Thirdly, action oriented designs can end up using a control method that the team thinks is natural, but in the real world turns out to be confusing. This happens when the team is simply too close to the game and become used to how it works and its shortcomings. They do not realise that they are designing from the point of view of experts rather than novices and so they assume that what they find easy is easy for everyone. Mirror’s Edge is an example of this kind of game. It relies on using a first person perspective for acrobatics, which just doesn’t work well, and so forms a barrier for enjoying the game. All the other actions flow from this initial design decision, so if the player is able to overcome the initial barrier then the game is quite good fun. Most do not, however. The upshot of these problems is that action oriented game design tends to need a company culture around it that is happy to take risks. Big budget videogame production struggles with this mentality because there are too many stakeholders to be appeased. And lately Facebook game development seems to be struggling to innovate on actions because it is seen as cheaper (although it’s not really) to simply copy something else already understood. So action oriented design tends to be used mostly by indies and smart companies like Popcap and Nintendo. In the long run it’s a smarter way to design, but the reality of many companies is that their culture is simply too panicky to work that way. Which Path to Take? So should you start with visuals and then actions, or actions and then visuals? I think most people would say the former. Start with a high concept to sell the idea, then go into prototyping actions as soon as possible to reconcile any conflicts earlier rather than later. That might mean starting with a short document (2-4 pages) that pitches the game using an executive summary, a little story, some art and some indication of the game features. And in fact this is how most studios pitch most projects. Actually I think the latter is the better method. The problem with leading with visuals first, no matter how sparse they may be, is that they immediately start to set expectations in the viewer’s mind. Before any key decisions are made about how the game will work (such as what camera position is sensible) there are already assumptions coming through from the visual that will lead to confusion down the line. By leading with actions first, the idea is to try and nail down that what you have might actually be fun before you set about trying to sell it. This means that the core of the idea will have substance, and the playable version of it will start to identify problems earlier. Of course the problem with that is that it asks the management, investors or other interested stakeholders to have blind faith. Lacking a frame of reference or the confidence to simply trust in the outcome, most stakeholders need visuals to hand-hold them through the process. That’s why visually oriented design is by far the more dominant method for creating games, even though it is generally less successful in the long term. (with thanks to Ian Carroll)