Trinity: A Game Design Methodology

Part 1

Intro:

This is the first of a series of blog posts which will try to convey my overall design methodology, which I’ve nicknamed Trinity for now. It’s a big task, and I’m not sure how many posts it will take to get there – we’ll have to see as we go.

There are two ways I could write this: I could start big and zoom in, or start small and zoom out. If I start big, I start in the realm of abstract principles and, over the course of the series, drill down to show how those principles are applied in practice. The other way (which is the way I’m going to write it) is to start with specifics and, by the time the series is finished, show how all the specifics are just applications of a few generic principles.

I like the second way best because I don’t like having arguments, and generic principles are argument magnets. Arguments are hard to avoid without a huge amount of preamble – and so I will start with the preamble and move on over time to the “amble”.

The kinds of games I’m discussing:

There is one overarching principle, though, that I have to state at the beginning. These posts will all grow out of the idea that “a game is fundamentally a conversation between a game’s designer and the game’s players.” I state this not because I believe that is the One True Definition™ of games, or because I think that is the only way a game can be made – but because I am limiting the scope of this series to games which are that way.

I’m sure someone can come along and make a great game that doesn’t meet these criteria – and that’s cool. What I’m going to talk about in these articles might even apply to that game, but I have no idea if it will. All the games I’ve ever made or played fit this definition, as far as I’m concerned, so just know all that going into this and take everything with a grain of salt.

I hope to demonstrate how it is true at some point, but until then just keep this in your mind as you read the rest of this series and try to see how it applies: A game is fundamentally a conversation between designers and players.

Principle #1: Games ask questions, Players answer them

Trinity all begins with what I’m calling Principle #1 (not because it’s most important or anything, but because I happened to write it first).

As a game designer, your job (in a very practical sense) is asking the players questions. The players’ job is to answer those questions using the tools you give them.

I think this is what Sid Meier meant when he said that games were a series of interesting choices, only I want you to see it from a slightly different angle: Instead of focusing on the choices, I want to focus on the questions the game asks that cause players to make the choices. It may seem like a small difference, but focusing on choices has a number of knock-on effects.

Focusing on Choices

Before I talk about questions, let me give you a couple examples of what I mean by “focusing on choices.” Hopefully this will give you an idea of the knock-on effects I’m trying to avoid by phrasing Principle #1 (designers ask questions and give players tools to answer them) this way.

Normally when I see designers approach mechanic design by designing a series of interesting choices, I see something like this:

“Do you want to go left, or go right?”

The designer here wants players to make choices about their path through a level – ideally choices that result in varied gameplay. Imagine a linear level that forks off two ways, and you have to choose one. Or you’re given dialogue choices between good and evil, etc. There’s nothing really wrong with doing it this way, but I find the results end up being expensive to make, and the player only sees half of the game this way.

Even worse, I’ll sometimes see things like this:

“Do you want to do it the right way or the wrong way?”

Imagine an enemy that can be damaged by two different attacks. Attack A does more damage to the enemy than Attack B. Sure, the player can “choose” between them, but only one is correct – so it’s not really a choice, it’s just rope to hang the player with.

There are many other pitfalls I see all the time because a designer focuses more on the choice than on the reason the choice is there in the first place.

Focusing on Questions & Answers (AKA Game Mechanics)

Think of it this way: The game presents a problem, the player uses a countermeasure. Our job is to design both the problem (question) and the countermeasure (answer) that solves it. You can start with either, but eventually you’ll need to design both.

Before I close this first post, I want to walk you through what it’s like to design this way. It’ll become more obvious as the series goes on, but this should give you enough context to make it through to the next post.

Let’s take the same problem of the multi-vulnerable enemy I mentioned above. We want the players to have choices in dealing with this enemy, so the enemy needs to ask a question that prompts each answer.

The easiest, most used form of this is the enemy with vulnerability states (e.g. When the enemy turns red, Attack A is most effective. When the enemy turns blue, Attack B is most effective). This is very common, but there are other answers too.

For example, the enemy could ask a single question, but the best attack to use against it at any given time is based on the context the enemy exists in. Let’s say you have a 1 HP 1 Damage enemy called “Bob” which stands still and shoots at the player. The player has three attacks: One shoots bullets straight ahead (Magic Missile), one does damage over time to everything in a short cone (Cold Spray), and one lobs a projectile into the air that explodes on landing (Fireball). The attacks may have other differences, but for now let’s just consider the range.

If the player encounters Bob on a flat plane, any of the three attacks are a good answer. If Bob is behind cover, though, Magic Missile and Cold Spray are useless unless you run around and get a new angle. Fireball, though, could arc over the cover so it’s the best option. If Bob is up on a ledge, the player could aim and shoot with Magic Missile, or try to jump and lob a fireball. If there are two Bobs close together, Cold Spray and Fireball will hit both of them, but Magic Missile will only hit one.

The enemy is still asking one question “what’s the best way to attack me” but now we’ve added a meta-question: “Given the terrain, what’s the best way to attack me?”

You keep stacking questions and meta-questions on top of each other until your game feels like the player has enough choices in every circumstance.

A few things to notice:

Up Next:

Right now, the next thing I want to talk more about is choice fields, how many “dimensions” a choice field should have (and what “dimensions” mean), and if I can get to it in one post, I’d like to show how I visualize choice fields to make it clearer which questions and answers I want to provide the player with.

Just so you know, though, I intend to write that now. As I write it, though, it may change. FYI.

(Link to next article)

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