Click "Sleep" for a dark background.
Click "sleep" again if text isn't dark.

 

Saturday
Jun272009

for the Feel of Design Space pt.2

The long time game designer Damion Schubert wrote an article called Understanding Design Space: Making Room For Your Game To Grow. In it Schubert talks about what design space is and why it's important.

"Design space is best described as the canvas that the designer can paint on. How far can an idea go? Does it have legs? Where can it grow? What are the boundaries? Where can mechanics be expanded upon at higher levels of play?"

get it?

Definition

Schubert defines a game's design space as being a product of its settings and mechanics. For our purposes, we have to be more specific and exapnd the definition. I define design space as a combination of a game's primary function, mechanic(s), core dynamic(s), and fiction. For now, let's take fiction out of the equation. Why? Well, when a designer prioritizes gameplay over graphics/story/fiction, gameplay tends to shape everything else. Basically, staying inside of a fictional design space can be as simple as not putting magical fantasy spell graphics in your realistic sci-fi action game. We're more interested in how game elements function.

 

The primary function is the main interactive action/idea at the player's control. It's simply the one concept that sums up what the player does the majority of the time. Mario is all about that legendary JUMP. Advance Wars is all about making strategic moves with units. And Boxlife is all about cutting and rolling boxes. The primary function sets the limits of the range of a game's design space. After all, if you have a bunch of mechanics and elements that have nothing to do with what you do in the game, then what's the point?

The mechanics are the specific actions the player can do. Because the player primarily interacts with the game world via mechanics, all the dynamics and intricacies of the mechanics help shape/define the design space. For example, if you're making a typical realistic FPS, the limits of the design space encompass a wide range of weapons. But the actual design space is much smaller than that based on how many and what kind of weapons are actually in the game. Looking at how elements of a game take up design space isn't just about mechanics though. You can look at the design space of any type or group of game elements like weapons, attacks, enemies, etc.

Finally, mapping everything around the core dynamic of a game helps focus our attention to considering whether or not an element/mechanic actually plays along with what's interesting about the gameplay in the first place. In a game like Super Mario Brothers with a core dynamic of gravity, how an element (level/enemy/player) influences the player to engage with gravity is the most important part to consider. It really wouldn't matter too much if you designed a new Goomba that makes a new sound effect as it walks or reacts differently if Mario is wearing his fire flower suit. Those ideas have nothing to do with gravity and/or platforming, and therefore don't contribute significantly to the design space of Super Mario Brothers that's bound by JUMPing (platforming) and defined by the few, simple player mechanics.

The whole idea of the circular design space graph is to visualize how different elements influence the player, how different they are, and how well they fit together. Now we must take a look at how to consider the differences of game elements.

 

Degrees of Difference

Even when designing elements that do work with the core dynamics of a game, there are still many ways you can significantly change things up. Back in the Mario Melodies series, I introduced the concepts of minimum degree of difference and quantification. To recap, it's important before you being any thought or discussion on a game's variation to be aware of the scale by which you measure change. Determining this scale is harder for some games than others. Luckily, for the easy games, the game worlds and sometimes even the player mechanics are designed to work in discrete, quantified ways. Whether space is composed of a grid or players move in turns, some games make it easy to measure.

 

Either/Or Variables of Change

Being able to measure changes in a series of levels/challenges by how much they differ according to the minimum degree of difference is a great way to analyze level progression. However, design space has much more to do with a game's core design/gameplay than its levels or specific challenges. In other words, design space is all about gameplay and the potential interactivity of game elements. So before we consider how unique any given element is or what kind of design space it takes up, we have to understand how many variables we need to consider.

Let's start by looking at the design space of a familiar and relatively simple game; Super Mario Brothers. The land enemies in SMB can be organized by the following properties:

  1. affected by gravity or not (core dynamic)
  2. can be jumped on or not (primary mechanic/function)
  3. impervious to fireballs or not (secondary mechanic)
  4. multiple hits (transform) or not (cause and effect counter)
  5. moves in a straight line/constant/predictable fashion or not
  6. can fall off of platforms or not (core dynamic)
  7. chases after Mario or not
  8. launches a projectile or not

Notice how many of these properties deal with the core dynamic or player mechanics specifically. Designing enemies around these properties ensures that the game will be fleshed out in a way that's pertinent to the core gameplay in Super Mario Brothers.

 

It's better to show the design space of the SMB enemies like this.

As you can see, each enemy in the game represents a unique combination of these properties. This means that no two enemies are exactly alike or functionally interchangeable. Because the properties are either/or (one way or the other) the unique space each enemy takes up is quite obvious. Just thinking back on the game, you know that a Goomba can be squashed, a Koopa can be burned with fire balls, yet a Buzzy Beetle (the black ones) are like Koopa that cannot be burned. 

When you think about the core dynamic of Super Mario Brothers (gravity) and the limited amount of mechanics (MOVE, RUN, DUCK, JUMP, SHOOT FIREBALL), it's easier to see how well the enemy design space in SMB was developed. Because of gravity, most of the action in Super Mario Brothers is concentrated at the bottom of the screen. It only makes sense to design most of the enemies to move through that most traveled through space to have a high chance of engaging the player. Most enemies (10/12) you can JUMP on to kill/disable. There are only 2/12 enemies that are impervious to fire balls which makes the long range attack very useful in most situations. Designing a new enemy for SMB that would be unique from the original enemies yet stay true to the platforming core of the game would be very difficult.

 

Analog Variables of Change

Things get a little more complicated when the properties of game elements/mechanics can't be simplified into an either/or case. With a fighting game like Super Smash Brothers Brawl, each move has a much wider set of variables and properties that define it within the design space. Some of these properties are either or, while many are highly variable down to specifics like frames of animations.

Smash Brothers Brawl:

Primary function = FIGHTING: Smashing = knocking opponents around an area.

Primary Mechanics = attacks, grabs, shields, jumps

Core dynamic = 2D spacing with gravity

*Bolded entries = either/or properties*

  1. start up time (the time it takes a move to activate a hit box after the button input is entered)
  2. duration (how long the attack hit box(es) stay active)
  3. recovery lag time (how long it takes for you character to recover after an attack ends)
  4. length/range
  5. element (fire/electricity/wind/magic)
  6. priority of the move
  7. is the move a projectile or not
  8. how sharply a move decays due to stale move negation
  9. if the move has different effects depending on the point of contact
  10. is the move multi hitting
  11. can the move be used in the air or on the ground
  12. how long it takes an air move to "cancel" on the ground
  13. how much damage the move gives
  14. how much knock back the move gives
  15. what base trajectory the opponent with fly in
  16. how much stun the move gives
  17. the actual animation of the move (character and attack)
  18. if the move can hurt the player character that used it
  19. can the move be charged/stored
  20. what chance the move will trip the opponent
  21. can the move match blows against other moves
  22. any other special properties (stun/super armor/healing/etc)

 

When designing different moves in a game like Smash Brothers, for a single variable, figuring out just how little you can change a move so that it's distinct and unique from other moves is probably something that's best determined by feel. After all, what's the difference between a forward smash that lasts for 15 frames versus 16 frames? (If you answered 1 frame then you're missing the point!)  When designing over 20 moves per character and over 35 characters, I imagine that Sakurai didn't worry about all the minute details initially.

On the other hand, when designing a game with far fewer elements, one way to ensure that you're filling out as much of the potential design space as possible is to design moves/enemies/elements/and dynamics that are as different as possible from each other.


Branches of Design Space

Take Neo*RPG, a game I made a few years ago, for example. The three enemies in Neo*RPG have 3 very distinct behaviors. One is very aggressive and seeks to do nothing but ram into you. The next enemy moves in close and hovers just off to the side. Whenever you make move, this enemy rushes in for an attack. The last enemy is a long range enemy that throws rocks and runs away when you approach it. These 3 behavior types (aggressive, defensive, indirect) are so different from each other that they layer or fit together like a puzzle piece when all 3 types are present in a level. Instead of influencing the player in the same ways, each enemy type influences the player in a different way that stack up in the counterpoint of contrary motion.

After coming up with the behavior design, I tweaked the analog properties for the enemies by feel. As you can see from data in the image to the right (click to enlarge), no two enemies move, recover, or attack at the same speed. This means, even if you attack two different types of enemies at the same time (or they attack you at the same time) the resulting actions will inevitably desync in rhythm creating a very syncopated, jazzy feel to the combat.

As I mentioned in The Depth of Interplay pt. 3, Jonathan Blow only needed 3 types of enemies to take up 3 unique spaces in Braid. Like with Neo*RPG's enemies, the Attack-Block-Grab interplay triangles of fighting games, shoot-melee-grenade (FPS), or shoot-EX-boost (Bangai-O Spirits) designing game elements/mechanics to be well rounded are the most efficient way to flesh out design space. The farther away each element is to each other functionally within the design space, the more well rounded the game. In this way, fleshing out a game idea is not about filling in the design space with lots of mechanics/elements that are slightly different from each other. Understanding game design and design spaces is about getting the most out of the few elements you do create.

Because mechanics, their dynamics, and their functions are such a key part in considering a game's design space, we have to be careful about the potential mechanics have in actual gameplay. Whether designing multiplayer games or not, if two elements don't take up unique enough design spaces one will overshadow the other. Like Fire 1, Fire 2, and Fire 3 in the classic Final Fantasy RPGs, there's little functional reason to use the weaker spells once you have the more powerful spells. In this way, it's clearly possible to add elements that take away from a game's functional or practical design space rather than add to it. If a gun is too powerful and too plentiful in a multiplayer shooter, players will naturally only use that gun. It's the same with counters. Though this is an issue that mostly falls under balance, I wanted to introduce the idea here. If one move/option counters a wide range of moves (even a whole branch of design space), if you're not careful, you could ruin all the hard work you put into those other moves/options. This is why it's important to think of your interplay systems when designing counters. More on this later.


Why Bother?

Why worry carving out unique design spaces for any or all of the elements in your game? What's the harm of some overlap? What's the harm of a lot of overlap? You may not be able to answer these questions at first, but I'm sure that you've felt the effects. I think of it like this:

Games are all about interactivity. Through interaction profound and long lasting meaning/ideas are communicated to the player. The relationship/function between game elements and the concepts they represent create meaning. Sometimes, when you fail to create elements within their own distinct design space, the meaning that's derived contradicts other ideas in the game. Games, like stories, are an artifice. And when you put anything in your game (or story) that distracts from the core messages/ideas being communicated, you ultimately bring attention to the fact that you, the designer, didn't think things through as clearly as you could/should have. This then pulls one's attention away from the merits of your ideas and to the quality of the construction/craft/artifice. Think of it like watching a magic show where you can see all the secret strings, switches, and hidden doors. It just wouldn't be the same.

 

Chekout these Wii guns

When striving for greatness and a clarity of meaning ito a video game, you can't afford to add any clutter. You can't afford to waste your time and money on anything unnecessary. Chekhov's gun is a literary technique that is the equivalent to foreshadowing. The author has explained the phrase to also mean "do not include any unnecessary elements in a story." In other words, if you're going to put a gun on the stage in a play, you better have that gun go off at some point. When designing video games, I think the phrase Chekhov's Arsenal would be more appropriate. It's not that you have to worry about any individual element in a video game. You have to worry about the whole store of elements in how they differ from each other and what they do (function). Hence the arsenal.

The more well rounded a game, the fewer elements it needs to create a rich variety of scenarios and gameplay challenges that inturn enrich the game fiction/world through interactive examples. The farther away each element is to overshadowing or encroaching on another element's functional space, the more that element will be able to layer with the other elements in the game (assuming the elements are designed around the core dynamic of course). In other words, the potential for counterpoint increases. This naturally reduces the amount of clutter in a game creating very pure gameplay experiences. After all, the more interesting gameplay you get from fewer rules and interactions you have to learn/memorize, the quicker you can move on to playing the game and experiencing the meaning through the function.

When playing a game, you can definitely get a feel for its design space. And when it's less than spectacular, you can definitely feel the difference.

« for the Steps of Development pt.3 | Main | for the Love of Variation pt.1 »

Reader Comments (2)

Your call to explore the design space and make enemies different reminds me of Harvey Smith's talk on Orthogonal Unit Differentiation.

July 25, 2009 | Unregistered CommenterLucas

I note an amusing similitude between those smash mechanics and the Attack-Sustain-Decay-Release enveloppes used by early synthetisers (esp. the SID and adlib chips ;)

August 25, 2010 | Unregistered Commentersylvainulg

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>