# Trinity, Part 3: Game MechanicsTrinity, Part 3: Game Mechanics

In this article, I elaborate more on what I mean by "Game Mechanic" -- a term I used quite loosely in article #2.

Mike Stout, Blogger

June 22, 2015

# Intro

This is one part in a series of articles that will attempt to explain how I think when I design. The purpose of these articles is not as much to provide a hands-on practical approach – just to explain how I do stuff. Once I finish this series, I’ll focus on some more practical applications of this stuff.

## Important points from the last article

The Big Principle: A game is fundamentally a conversation between the designer and the player.

Principle #1: As a game designer, your job is to ask your players questions. The players’ job is to answer those questions using the tools you give them.

Choice Field: A collection of spectrums all of which describe a single game mechanic.

Spectrum: Any two opposing concepts which are the same in nature, but differ in degree.

Binary choice: Any two opposing concepts that differ in nature, but are the same in degree.

Dimension: An individual spectrum or binary choice within a choice field.

## Game Mechanics

The focus of this article is going to be game mechanics, which I was pretty vague about last time. “Game mechanic” is a term I use a lot differently than some other people who write about game design. I tried to make up a new word, but it made reading and writing this impossible – so I’m going to stick with game mechanic. I’m not trying to say my way of using it is better or anything, just when you hear me say it – this is what I mean.

First off, a definition:

Game mechanic: A game mechanic is the meeting point of two design ideas: a Question the designer asks the player, and the Tools the player has for answering that question. Each game mechanic contains at least two choice fields – one for the Question and one for the Player Tool that answers it.

Another way of saying it is that the Question and the answering Player Tool are two sides of a coin, and the coin’s metal is made out of “game mechanic.”

For example, let’s examine one of the game mechanics from the combat system in games like Skylanders: Spyro’s Adventure and Skylanders: Giants or Ratchet and Clank. There are several overlapping mechanics that all affect combat in these systems, but for this article I’m going to focus on just one so you can see how a mechanic’s two choice fields are related to each other

## Mechanic: Enemy Placement VS Weapons

The game mechanic I’m describing here focuses mainly on the interaction between A) where enemies are placed in the game world in relation to other obstacles (Question) and B) the player’s weapons (Tools).

Hopefully from this example you can see how both of these are two sides of the same coin – and how both inform each other.

### Question: Enemy Placement

This question asks the player “how do you want to attack me.” By placing the enemy across, on, or behind obstacles – enemies gain an advantage that the player can overcome with good weapon choice. The choice field attached to this game mechanic looks like this:

Spectrum #1: Horizontal (near/far)            Spectrum #2: Vertical (low/high)

Each dot in the diagram above represents a type of terrain variance that is an example of the extremes we’ve built into this choice field.

1. Flat Terrain (low/close) – Control case. Everything is effective on a flat plane, given no other wrinkles.

2. Horizontal Gap (low/far) – Blocks movement but not projectiles. Ranged enemies placed across gaps have an advantage the player will need tools to overcome.

3. Vertical Ledge(high/close) – Enemies up on a ledge are hard to hit unless the player can get up on the ledge, or has tools to overcome that advantage.

4. Line-of-fire-blocking Cover (high/far) – Blocks some projectiles and affects movement. Enemies placed behind cover are immune to horizontal attacks unless the player moves around it, or has a tool.

Each of these represents a question the designer is asking – which requires that the designer give the player tools to handle it.

### Tools: Weapons

In this example, I’m ignoring a number of spectra that exist in this combat system and focusing mainly on two: Range and Directness. Range is how far away the enemy can be from a player before a weapon gets useless. Directness is whether the shot travels directly at the target or takes another indirect route.

The choice field attached to this game mechanic looks like this:

Spectrum #1: Range (near/far)         Spectrum #2:: Directness (direct/indirect)

Each dot in the diagram is a category of weapon we used in the design of Skylander characters. We chose the categories because they offered players a tool to solve the extremes of enemy placement questions.

Note: If you’ve seen my Skylanders GDC talk (link), this might start to sound familiar. EXAMPLES:

1. Close (Short/Direct) – Weapons that do damage very near to the player, like a knife or sword. These are good on a flat plane, or when close to an enemy behind cover.

2. Weird (Short/Indirect) - These attacks usually affect large parts of the combat area with damage coming from nowhere in particular – like flaming skulls raining from the sky.

• Because this is obviously very powerful, we usually limit it with extra rules: e.g “You have to stand still to use it” would make it worse against close-range enemies. I’ll get into how that works, later in this article series, hopefully.

3. Straight-ahead (Long/Direct) – Weapons that fire projectiles at range. The projectiles fly straight in the direction they’re fired until they hit a wall or a target. These fly over gaps, but are usually bad at hitting guys on ledges or behind cover.

4. Lob (Long/Indirect) – Weapons that fire projectiles in an arc, or otherwise along a non-direct path. These are good for getting up on ledges or behind cover, but may arc over closer enemies.

## Principle #2: Put Them Both Together

Together, these two choice fields make up a single mechanic from a combat system like those in Skylanders, Ratchet, or God of War. There are far more mechanics, which I hope to get into next time, but for now what I want you to see is how the two halves of a mechanic relate to each other.

This leads us to Principle #2: When the designer creates a challenge to ask the player a Question, the designer must also create Tools for the player to answer it. The task of designing the one IS the task of designing the other.

The player’s abilities and the challenges you create to test those abilities are two sides of the same coin. “Game Mechanic” is the term I’m using to show how the two combine to become basically the same thing.

It is possible to design each half of the coin separately (at different times), and I hope to explain how to split things up like that later in the series, but for now I just want to say that it’s pretty difficult if you aren’t careful.

## Next Time

This is a complex subject, and I think it’ll take a few more articles to finish explaining, so next week is going to be more on game mechanics. I’ll elaborate more on the combat system I’ve been building up above – as it’s still missing a lot of information (enemies, movement, damage, etc).

I also still need to talk about how different choice fields and game mechanics interrelate -- which I've been vague about because these diagrams I've been using aren’t all that useful for conveying that kind of information. I’ll get into that when I talk about Chen Diagrams in a later post in the series. These diagrams are mainly useful for conveying the range of options available within a given choice field.

Note: This series is made possible by my supporters on Patreon. Thank you all so much for making this happen.