In this in-depth article, designers Lopes and Kuhnen look at two major approaches to video game design - from the bottom (in-game actions) up, and from the top (story) down - and discuss the pluses and minuses of creating a game with both methods.
It is often said that there is one single word that ties both ends of the process of designing a game, being its cause and consequence. That word is "fun". But just how is it possible to create fun? What drives the creative force inside game designers and developers to define, specify and ultimately implement concepts that are entertaining by nature?
Such a process is called Game Design Cognition, and it is absolutely necessary to understand and improve it if we want to evolve as an industry that creates fun out of thin air. However, the subject of meta-design applied to games is barely mentioned in the reference material about game design that we see today. Thus, this article introduces a proposed breakdown of the cognitive process behind game design, enabling the discussion of different methods that are intuitively used, but seldom understood, by game designers.
For example, take the award-winning action game God of War. The process of designing such a game probably involved, in some order, the definition of its main concept (an epic, gripping third-person action game centered on a brutal anti-hero), context and environment (conflict among the gods in ancient Greece, in which the protagonist gets personally involved), features and content (combos, weapons, levels), mechanics and verbs (the divine powers system, the power-ups, the player's actions such as jump, light attack and heavy attack).
However, the process of putting this whole picture together is never as streamlined as our quick analysis would assume. Rather, designing a game in practice often involves multiple traversals up and down those layers, in a much more organic fashion. Therefore, this article comprises the study of each layer and its relationships with the others, presenting them as a hierarchical structure for an easier understanding of the top-down and bottom-up approaches to game design cognition.
Gilliard: Look! Can you see the marvels of game design cognition being applied in this case? Do you realize how the basic verbs and mechanics have translated into an amazing game concept?
Rafael: Yeah... I see “kick butts” translating into “awesome boss fight”!
The cognitive process of designing a game begins with an idea. Sometimes it is a concept that we want to translate into play; sometimes it is gameplay that we want to turn into concept. The process of turning such ideas into palpable material, which then becomes a game, is composed of several journeys of thought and specification back and forth between these two extremes. Filling the space in between with concepts that break down the design of a game into working parts is the core of this article, as seen in the next section.
Examining complex processes is never an easy task; thus, approaches that try to divide such complexity into smaller parts that can be more easily understood are necessary. This is called analysis. Analyzing the game design cognition process is a critical part of developing a deeper understanding about how such process works.
Therefore, we propose the following layered view as a breakdown of the game design cognitive process, where each layer corresponds to a generalization or abstraction of the layers below it, and a specialization or concretization of the layers above it.
Each layer is described in detail in the following sections.
Concept is a pretty broad term meaning “the abstract description of an idea”. In games, the concept is composed of a couple of phrases that describe the game's style, general setting, and sometimes the main plot motivation, as well as the types of characters and interactions involved. Game concepts are generally short, but they serve as the ultimate definition of the game, something that the developers should keep in mind at all times to make sure that they are really making the game they were supposed to.
Therefore, the game concept is the topmost layer of our proposed architecture, tying all the other layers together into cohesive game design. A proper definition of the game's concept is crucial for establishing the game's vision and focus, inspiring the whole design and development processes. The concept is also the general starting point of the top-down approach, as discussed later in this article.
As an example of a game with a strong concept behind it, let's take a look at Blizzard's blockbuster Diablo. The game could be described as “a fantasy role-playing game with a strong focus on hack-and-slash action, item collection and dungeon exploration”. The whole game has been constructed around this concept, such that items with increasing power both allow and drive the player to explore the dungeon deeper and deeper, killing more and more monsters to get another, even more powerful item, and so on.
Gilliard: Now, that is a good example of game concept turning into verbs, is it not?
Rafael: Yeah... Lots of verbs, like “click”, “click”, and... ummm... “click”?
As the starting point of our discussion, the concept layer represents the most abstract view of the game. The next sections describe the remaining layers with increasing granularity, representing an incremental process of specification of the game idea, turning it into the detailed description of the game.
The context of a game, as far as the proposed architecture is concerned, comprises the story, circumstances and motivation presented to the player. Why must the player do what he is doing? Does he have to save the princess from the castle or must he save the world from an alien invasion? The context does not have to be story-driven, but it must define a more concrete view of the game that the players can easily refer to.
Whenever a player has to make a choice in order to progress further in the game, his options are based on, and related to, the concept at hand. Such decisions could be choosing between types of weapons in a shooter, dialogue options in an adventure game or RPG, or even whether he will dodge or strike in a fighting game. It is expected that every choice the player makes in a game is a meaningful one, even if its purpose is merely aesthetic (say, to answer a question made by a character that has no other purpose besides telling you how mean he is).
The context should be the guide to these choices, enriching the game environment with events related to the situation proposed by the game. It is important that every non-aesthetic choice has a clear purpose and outcome in the game; if not, the game should rather “choose” for the player, and keep the things going. For example, in 2K Boston/2K Australia's masterpiece BioShock, you are not supposed to use your weapons in certain areas, so the game “chooses” no weapons for you, instead of letting you choose any weapon -- that you will not be able to use anyway.
It is important to note that it is not always necessary for the context to be related to the storyline, but one important purpose of context, being it through aesthetic or game-changing choices, is to bind the player to the game universe.
Take for example Square's highly-praised RPG Chrono Trigger for the Super NES. This game puts the player in the role of Chrono and his friends, inhabitants of the interesting and conflicting kingdom of Guardia. The game's context comprises the journey among the Guardia region in different eras in time, and the story itself is full of opportunities for the manipulation of future events through actions taken in the past.
Gilliard: Beware! Wonderfully crafted world and story, amazing context... The greatest game of all time!
Rafael: When did we start talking about Ocarina of Time?
Gilliard: (Sigh) We never did... This is Chrono Trigger...
On the other hand, let's look at Wii Sports; there is no story there to guide the player through, but the game's context comprises several activities that everyone is familiar with.
Gilliard: See? You don't need to tell a story in order to play with Mii and my Wii... hehehe...
Rafael: Dude... that joke was already old six months ago...
Although the context defines a more material view of the game's concept, it still lacks any game-specific components. For example, the concept and context of a game could also be implemented as a movie or a book, with only minor adjustments. It is in the next layer down the line that such game-related functionality becomes clear.
Contents of a game are basically what players see and most often can touch inside the game space. The player's avatar itself is game content, together with any other characters, weapons, items, scenario objects, etc., that are there for the player to interact with, using the game system. We can think of content as the concretization of the game from the perspective of the player.
Features, on the other hand, are the mid-level description of gameplay, often represented as use cases (“squad control”, ”vehicle riding”) and broad system descriptions (“price fluctuation”, “real-time cloth physics”), which comprise the different ways in which the player can touch the game or be touched by it. They also define the nature of the player's interaction, in terms of the feedback perceived by the player from his actions in the game world (“destructible environments”, “believable emotional NPCs”).
While concept and context are the layers responsible for the player's first impression and general understanding of the game, it is the content and features that will make him want to play more and more. Content and features are the bread and butter of a game. Together, they define how the concept and context are realised as an interactive experience. Features are the blueprint onto which content is constructed, thus instantiating gameplay.
Content and features, therefore, play a major, central role in the player's experience with the game, and so we decided, for our layered approach, to bind these two components in a single layer called Core.
The most important distinction between the top-down and bottom-up cognition processes, as discussed later in this article, is exemplified in the relation between content and features with regard to the other layers. If we work down from the top, we can see features as an abstraction of content in order to create the desired game mechanics; on the other hand, if we go up from the bottom, we can see content as an abstraction of features to create the desired game context. Therefore, it is impossible to tell which of these two layers is more abstract than the other. That is the main reason why we choose to consider these two layers as an unified component of the architecture.
The relation between features and content can also be observed through a different perspective: the conflict between “open-ended” and “scripted” gameplay. Open-ended games such as Zelda or GTA rely on features to provide the desired gameplay experience, in the form of emergent behavior of the objects and characters that populate the game environment. In this case, features are more abstract and fundamental than content, because it is the behavior of things, rather than their actual colors and flavors, that generate a living game environment for the players to explore.
On the other hand, scripted games such as Half-Life or Metal Gear Solid rely on content to guarantee that the gameplay experience is exactly what the game designers have planned. In this case, content is more abstract than features, because it is the actual layout of things that will provide the desired experience; the behavior of things has to be only as complex as needed by the desired content.
Gilliard: Now this is an open-ended game! I can do things the game designer has not planned...
Rafael: And all you can think about is carrying a chicken around?
The mechanics of a game are the “brain” of a game's design. Whenever the player wishes to perform an action, he must invoke one of the available verbs in the given game state (more on this in the next section). Then his input is processed internally by a set or rules and an output is given (hopefully being what the player had intended to do). Game mechanics must be designed to be the gears that spin under the hood; all the player must do is step on the gas and feel the car moving. He does not need to understand how the engine works to be able to drive.
The game designer, however, must have a clear and detailed definition of such mechanics, in order to provide the other developers with an accurate picture of the desired outcome in the game. The most important component of the mechanics layer is the definition of the process in which verbs (the layer downwards) are manipulated by the system and provide feedback, both to the player and to the game world, of the actions performed, thus bringing the desired game features and content (the layer upwards) to life.
To illustrate game mechanics, let's take a quick look at Sony's masterpiece, Shadow of the Colossus. Most of the player's actions are focused in the small circle on the corner of the screen. That circle measures the power that the player has available to execute actions such as strike a colossus with the sword or the bow.
The maximum power available can be reduced if the player keeps hanging on things or executing other tiring actions -- thus, consuming power slowly -- and with every consecutive blow struck upon the giant. Pressing the button once willl start filling up the circle with power; pressing it a second time will unleash a blow as powerful as the current power level in the circle. The player then has to wait a short while in order to recover this power. As the player sees it, the character just gets tired of those extreme actions; he cannot use his full power to strike all the time, and needs to stop to rest for a little bit.
Gilliard: And now how am I supposed to take down this giant beast?
Rafael: Well, that bow in your hands should be useful for something...
Gilliard: Yeah... That makes him MUCH smaller...
This layer consists of the actions that will be performed by the player during the game. These actions mean the desire of the player being enforced upon the game as low-level micro-decisions that will use the mechanics layer to run the player through his game experience. Some of these verbs might be “shoot”, “jump”, “brake”, or even “change camera perspective”, “craft an item” and “move units”.
Verbs are related to specific game states, that define which verbs are available to the player at any given moment. For example, if “in car” is a game state for Grand Theft Auto, “accelerate” and “brake” might be some of the available game verbs, as “shoot” and “reload” would be verbs for the “weapon drawn” game state. A picture showing a simple example of game states and their corresponding verbs in the Grand Theft Auto universe is provided below:
Game states and their respective verbs are related to a cognitive process representing an important aspect of games: learning. While specifying game verbs, the designer has to make sure that their use and relations with any game state thereafter is coherent throughout the entire game. Designers must take what the players learn very seriously and must not expect them to act against it. For example, if in a given game state the player is not allowed to shoot while inside a car, and suddenly, in another state, he is allowed to do that (or worse, he is required to do so to get through a given obstacle), the transition between such states must be made clear through the appropriate feedback.
Gilliard: There are so many verbs I can use in this game! I can walk, jump, drive, buy things...
Rafael: OK, here's some verbs for you: stop talking and shoot!
Once our proposed layered architecture is defined and explained, we can start talking about the proper process of game design cognition, which involves traversing the layers as the game's design is constructed. Such process has distinct approaches if we are moving from a more abstract view to a more concrete one (in top-down fashion) or the other way around (from the bottom up). Studying these approaches is a useful meta-design exercise that will allows us to understand deeply how the layers relate to and depend on each other.
Since we have already discussed the layers in the top-down order, let's start by studying the process in which the game design process is driven from a conceptual perception of the game towards more specific and concrete views: the top-down approach.
When working down from the top, the game designer usually exercises his analytical skills, i.e. his capacity of breaking a broader concept into smaller parts that are representative of the whole. For example, when trying to transform a game concept into its context, a designer must further unfold the concept to answer questions like “where and when does the game take place?” and “which characters or entities are involved, and in which circumstances?”. Finding out which are the right questions is often trickier than finding the right answers to them.
As said before, concept and context do not necessarily involve interaction or entertainment, which are major features of any game. Thus, one of the main challenges of the top-down approach is that this process often requires that the game designer introduces fun elements into concepts that are not necessarily entertaining by themselves, or at least not as much as a game should be. For example, a game concept derived from a very serious book must still turn out to be a fun experience.
Famous game designer and BioShock mastermind Ken Levine has something to say about fun: “Game designers have a weird job. At root, it is their responsibility to ensure that a game is fun to play. The problem with being a game designer is 'fun' is an extremely relative term.”
Typical situations in which top-down game design cognition is applied are games based on existing IPs from other media, such as books and movies. In these cases, it is common that the game's concept and general context have already been defined by the source material, and so the game designer must work downwards in order to turn such material into a truly interactive and entertaining experience. A spin-off of an existing game series, where the contextual elements are maintained but the gameplay is changed, is another example of a situation where a mostly top-down approach is used.
Before we start talking about the bottom-up approach, let us clarify some differences between our definition and the one presented in the excellent article “The Designer's Notebook: The Perils of Bottom-up Game Design” by industry expert Ernest Adams.
In Adams' view, bottom-up game design occurs when an existing mechanism, not related to gaming at all, is used as the baseline for the construction of a game. Adams points out that such an approach can lead to overly and unnecessarily complex game mechanics. The whole difference is that, in our case, we are talking about bottom-up cognition, rather than bottom-up design; our mechanisms are always game-driven by nature, since our process starts with verbs, which are already components of a game. Any non-game mechanics must be processed and turned into a game system through the top-down cognition process.
Bottom-up game design cognition can be seen, in some sense, as the process of finding excuses to successfully apply a particularly fun gameplay verb or mechanic, complementing it with the appropriate setting, content and story. And if we look at some of the most well-known game developers in the industry, we will find out that such process is used more often than not. Take, for instance, id Software's highly-praised series Doom and Quake. As David Kushner's excellent testimony in “Masters of Doom” tells us, these games were built barely as excuses for the brutal, over-the-top shooting gameplay that Carmack and Romero had devised.
Let us say, for example, that our next first-person shooter will feature a unique weapon that can split a target into smaller and weaker parts that can then be shot upon again. What kind of weapon is that? What objects (or characters) are we shooting at, and how do they split? Why are we shooting them, in the first place? Answering questions such as these is the core of the bottom-up cognitive process.
Designing an expansion of an established game is a typical situation in which mostly the bottom-up approach is applied. Expansions generally imply that the major gameplay elements from the original game are maintained; this way, most of the verbs, mechanics and even features layers are already defined from the start, and the designer has to define content and context that fit well with the rest, still providing the player with a fresh experience in a familiar gameplay setting.
Rafael: Take that, you stupid alien!
Gilliard: Dude, aren't they... like... demons?
Rafael: Umm... Er... Whatever... Can I just keep shooting at them?
There is no such thing as a recipe for game design cognition (or any cognitive process for that matter). In the end, the main outcome of this article is that the practical game design process involves a mixed approach between top-down and bottom-up cognition.
Bringing together those little pieces of gameplay inspiration into something fun can be quite a challenge that involves several iterations of top-down and bottom-up thinking. But it is a challenge that we hope to have made easier and more approachable by studying the different layers of game design and their relationships during the cognitive process.
We also hope to have inspired you to think of meta-design more frequently and profoundly, as we truly believe it is a very important path for us, as designers, to evolve in our craft towards even richer and more entertaining games.
Read more about:
FeaturesYou May Also Like
