The Deeper Game Part 2: Mechanisms vs Mechanics

What happens in a game? Why do player actions in one game flow and feel like part of the world and part of the story, while in others, they feel like, well, the moves in a videogame?

Small note here on terminology. I don’t want to create jargon or put forward my words as special. I really don’t… but I do want to make a meaningful distinction between two sets of concepts, “space and place”, in the previous article and “mechanisms and mechanics” in this one. Now, those concepts are 100% not captured in the dictionary definitions of those words. I am going to define what I mean by each term in these articles. I’m only doing that for the sake of this discussion and not inferring that it is what these words ‘should’ or ‘do’ mean outside of this context. If you would like to suggest more understandable words in the comments, feel free to do so, and I may take you up on your suggestions. If you need to tell me that my usage is ‘wrong,’ you don’t have to. I already know that and am very sorry for your suffering at the linguistic torture I am subjecting you to :)

Here, I define ‘mechanism’ as the discrete functional component (of a game) that creates a particular in-game action of effect. I define the ‘mechanics’ as the effects that are created.

Note my careful use of plurals there. As the dictionary stands, it is incorrect to refer to one of a set of mechanics as a ‘mechanic’ because a mechanic is defined only as a person who works on machines. As someone who wants to communicate clearly this vexes me. It has been suggested that we should use the word mechanism to refer to one of a set of mechanics individually. But here I am using the term mechanism to mean something different than one of a set of mechanics. So, I am going to say mechanic when needed here. In this article, I never mean a person or persons who work on machines when I say mechanic or mechanics.

Now, on to the meat of this article.

Previously, I looked at how space and place differ and offered five questions that a developer can answer to ensure that the scenes and levels that they create have a sense of place that elevates them. Below I am going to try to do the same for the mechanics of games.

The mechanics of games define them as games. Without mechanics, there is no interactivity. And if there is no interactivity, what is left is a movie, a book, a play, or a painting. It is no less art, but it’s no longer a game.

A game does not require many mechanics or complex mechanics to be great, though. Yes, a game like Baulders Gate III has many intensely complex mechanics, but that doesn’t make it a ‘better’ game than Journey. And even simple puzzle games like Tetris, Bejeweled, or Go are seen as elegant, not as simplistic or limited.

In many games, especially more mechanically complex ones, actions can become confusing in a variety of ways. Players ask questions like:

• What does this button do?
• When should I block, vs. dodge or parry?
• What do these items do?
• Why is there a gathering and cooking mini-game in my Pokemon?

Okay, maybe it’s just me asking that last one, but the question remains: Why do we have these questions in some games and not in others? I never wondered why I should cook things in Breath of the Wild.

The answer, of course, is Unified Design. (I will be writing another article on that as I can’t find anything comprehensive to link to, but it is essentially what it sounds like.) On some level that can be all the guidance an experienced designer needs, but it’s very abstract and not actionable without answering these five questions:

• What is this mechanism? (diegetically/non-diegetically)
• What does this do? (diegetically/non-diegetically)
• Why does it do that? (diegetically/non-diegetically)
• Why would we want to make it do that? (diegetically/non-diegetically)
• How do we (player/character) know all of that?

An Example

Let’s take character statistics (stats) in an RPG as an example. In this hypothetical game, characters’ abilities are based on a set of underlying statistics. We will examine the Strength stat. This number is a mechanism. In isolation, without answering these questions it is close to meaningless.

What is this mechanism?

Diageticaly it represents the character’s strength. Nondiageticaly it is an integer with a range of 1 to 100. This number is set at the beginning of the game and may change due to various in-game events. (Leveling, items, etc.)

What does this do?

Many aspects of gameplay rely on this number:

1. Damage is modified by player strength.

2. Situational actions are enabled or restricted based on thresholds. (Forcing doors, pushing boulders, etc.)

3. Item use is limited based on thresholds. (Wearing heavy armor, wielding heavy weapons, etc.)

Why does it do that?

For 1 above, a calculation is in place to modify damage. Perhaps 1% of weapon damage is added for each strength point above 50, and 1% of damage is subtracted for each point below 50. This could be any calculation, but different ways of calculating this effect will impact the importance of the strength stat.

For 2 and 3 non-diegetically, there is a simple check of an action against the character's current strength. If their strength is below the threshold, they can not perform the action or use the item; if it is above the threshold, they can.

These answers may be obvious, but they define a whole set of rules of operation and effect around the discrete mechanism.

Why would we want to make it do that?

Allowing characters in a game to have varying strengths creates the opportunity for gameplay diversity. (A low-strength character fosters different gameplay styles than a high-strength one.)

Allowing strength to change over time creates the opportunity for character progression.

Gating areas with strength based checks allows exploration progression.

Gating character abilities and item use with strength checks created opportunities for character progression.

Diageticaly the weak character has less autonomy in the world, and as they progress through the world and grow in strength, they are more able to take on its challenges.

How do we (player/character) know all of that?

Non-diageticaly we may show the character’s strength in a character statistics screen. This screen may show the range of the strength stat and even list the effects of the current value.

In the game’s visuals, we may diegetically represent a low-strength character’s failures to pass strength checks. For example, the character might grunt in frustration when failing to push a boulder or open a door. This suggests to the player that these actions are possible in the game but that they are not capable of them yet.

For items and abilities, we might non-diegetically grey them out in the User Interface (UI) and show a message stating the required strength stat.

There are likely other diegetic and non-diegetic affordances that we can use to communicate these effects. It is critical that we look at all of the mechanism's effects and ensure that they are communicated to the player, directly or indirectly.

This above example seems more like a system than a mechanism, and that’s the point. The mechanic of strength in the game is more than the representation of the character’s strength as a number; it is the complex effects of that mechanism within the context of the game and its other mechanics.

Another Simpler Example

Let's look at Jumping in a sidescrolling game like Super Mario Bros.

What is this mechanism?

Jumping is the vertical movement of the character away from collideable objects such as the ground, platforms, and perhaps even enemies. The player presses a jump button to trigger the jump.

What does this do?

When activated a jump moves the player vertically away from the surface at a defined rate, negatively modified by a gravity constant. When the movement reaches 0 or the jump button is released the player then falls back toward the ground through a positive velocity modification of the effect of gravity. There are a variety of different ways that a jump could be implemented, but defining EXACTLY how it functions in a particular game is required to answer this question.

Why does it do that? (diegetically/non-diegetically)

Different jump implementations will have different reasoning applied here, understanding the effect of the above implementation is the point of this question.

In this case, the variable jump height creates fine gradation in the character’s movement. The interaction of the ability with the gravity mechanism of the game helps create this effect, as does the variable input from the player.

Why would we want to make it do that?

Diagetically, the above implementation creates a jumping model that fits with a ‘realistic’ model of movement within the game world.

From a design perspective, we want to give the player fine control over the character’s movement and create a player skill curve. We want to have jumping in the game to increase player autonomy, to allow more interesting traversal of the world, and to create dramatic gameplay situations. We want to create situations that challenge the player and allow them to succeed as they improve their skills.

We also likely want to combine the ability to jump with player progression systems to allow for more and more complex gameplay.

How do we (player/character) know all of that?

The player is likely presented with a non-diegetic prompt at the beginning of the game, or at least with a mapping of the game’s controls. The details of the function of the mechanism are likely conveyed through observation. That is probably sufficient for a simple implementation like the one described. If the implementation included less obvious features like ‘jump queuing’ or ‘coyote-time,’ then we might want to add digetic affordances like a character crouch if they land with a jump queue or their feet spinning a bit if they trigger coyote-time.

As you can see from these examples there is a significant difference between a bare mechanism in a game and a fleshed out description of the mechanic that exists around it.