Back in 2003, the game industry was determined to suss out how we might be able to standardize game design. This wasn’t so that we could make cookie-cutter experiences. It was to ensure that we had a common language and that we defined certain core principles of good (i.e. effective) design.

It’s important to remember that in 2003 there were no true textbooks on practical game design. Most of the articles and books written up to that point were theoretical. The content focused more on feelings and impressions from past games, rather than identifying any underlying principles that could be leveraged in future games.

Game design as a discipline was hard to pin down. Some designers tended to feel as though this gave the discipline an air of mystique. In reality, it made it difficult for other team members to understand why design-as-a-discipline was necessary. Additionally, whenever a designer did happen to discover a useful principle, it wasn’t uncommon for designers to hide their notes. After all, hoarding knowledge meant job security, right?

That ain’t necessarily so. In fact, as people in this industry slowly discovered, knowledge, once shared, tends to multiply. But that’s a hard lesson for an individual to learn; harder still, for an industry.

This lack of definition and cohesion led to confusion within the discipline.

Around 2000, some industry veterans, like Doug Church, Chris Crawford, Noah Falstein, and Hal Barwood, started the herculean task of attempting to structure and codify the practical design of games and game mechanics. By 2003, Noah Falstein and Hal Barwood had started to define some game design patterns, following the Alexandrian pattern form that originated in architecture. These patterns were summarized by statements like “Privileged Move” and “Paper-Rock-Scissors.” In fact, the strongest patterns were easiest to visualize from their statements alone.

Here’s a quoted section of a Gamasutra article discussing the case for design patterns, defining in detail one of these patterns:

Privileged Move
Problem: Sometimes a given game entity cannot be permitted to interfere with others, or other entities cannot be permitted to interfere with it.
Solution: Introducing exclusive moves and locations separates and protects game entities. These exclusive moves and locations cannot be entered or left without being able to perform the respected privileged move. By introducing different, separate spaces or media, the game environment is broken down into distinct areas, which can serve as safe zones or safe passages.
Consequence: Depending on the implementation, this can be a very heavy-handed way to ensure protection. Unless protection is implemented in a way that is at the player’s disposal (a door that only she can open and close), the player might perceive the constraint as annoyance and disappointment. If the restriction is meant to be temporary, the mechanism to allow it to be lifted has to be communicated to the player, and initiated by her.

So much of this seems obvious to anyone that’s worked in the industry for a while. Heck, because of the increasingly standardized language of interaction across games, so much of this should seem obvious to most players. At the time, though, the industry considered this line of thinking revolutionary.

I started working at High Voltage Software on February 3, 2003. We had weekly design department meetings, which were useful. By May of that year, it was decided by our director that we had to come up with a bunch of design patterns. I think part of the reason behind this was to help us articulate what we had learned over the course of our careers. I also think part of the reason behind this was to demonstrate to the organization that designers were not simply technical writers or “idea people.” I’m certain that part of the rationale was to help us build a knowledge bank of principles that would help us to generate interesting pitch ideas and design solutions quickly. As a third-party independent developer, we were always searching for a way to increase our velocity.

Our ability to come up with real, usable patterns varied wildly. I don’t think we were, as a department, on the same page, regarding the task. Some of the ideas were really interesting, though, and I’ve continued to keep them in mind throughout my career.

For example, Tom Dowd shared the idea of “7 Times to Own.” His idea was based in the pedagogical theory that the average person needs 7 times with an experience in order to truly internalize and own that experience. If we, then, exposed players to functionality and mechanics with that in mind, we could minimize — or eliminate — on-rail tutorials. We could also spring variations of our mechanics on players in a way that would minimize their frustration if we helped them master the core mechanics first.

Another designer, Matt Entin, shared the idea of “One Item, Many Uses.” He looked at classic games, like Loom, and — expanding “item” to include “interactions” — proposed that we consider how we could expand the functionality of each interaction in the game. So much of game design is in figuring out how to turn common tropes on their head. I really liked this answer, because he took the idea of a design answer — “Here is an item the player needs to accomplish this task” — and turned that on its head.

Many of the ideas offered weren’t patterns per se, but they did work well as general principles for understanding development and the player experience.

Ed Kuehnel, for example, suggested we consider that — even in a game with time travel — the player’s experience only ever moves forward. The experience should never lead the player backward through the narrative or the gameplay without somehow pushing forward the greater experience.

Dave Rodriguez proposed, “Same, but Different,” as a general design principle. With that, he taught us to embrace known tropes. People don’t mind the same structure for a narrative or an experience, so long as the experience itself has something interesting to say. Generally, people tend to be resistant to new interaction structures. A new structure tends to make them feel lost and dumb. Players who are willing to embrace the learning process might spend so much time mastering the new environment that they miss the greater point you’re trying to make with your design. Creating something familiar that says something different — change in small doses — makes it possible to leverage a common design language, giving designers more time to spend on the actual game. In fact, by iterating upon a structure, you can imply and introduce new structures into the greater vocabulary.

For those curious, I had proposed the user-defined narrative. I like games with story. Heck, Zork convinced me that I wanted to make games. It’s hard to get story to work in an interactive experience, though. If you constantly lead players by the nose, forcing them to live an experience that you’ve defined for them, they tend to get disinterested or frustrated.

I learned this when I worked on Descent: FreeSpace. My first mission (which — for a very irritating reason — didn’t make it into the final game) was a huge success. Players were given a set of mission objectives (escort an allied space cruiser, keep the peace) that seemed fairly mundane. They warped in to find the space cruiser under attack by a new type of alien. The ship blew up in front of the players’ eyes during the first 3 seconds in the level. The objectives changed to “shoot all the enemies” and “get out alive.”

The team loved it. They felt like it had a lot of narrative power. They talked about the mission as though it opened up this world for them. Confident in my abilities, I created another mission that was meant to have a slow burn, building in intensity until a final surprise attack. I spent a week setting up triggers and narrative choke points, carefully testing out the experience.

And… when it was finally tested… it flopped. It was a space sim, and every fighter had the ability to boost the speed of their ship in short bursts, which was really helpful when trying to cover long distances. Players blew through all of my triggers, setting off the narrative elements in their wake. I had tried to create an on-rails experience that had a lot of narrative importance, and I made something horribly broken and dull.

I was frustrated, but I listened to the criticism. More importantly, I started asking questions. By the time I got to this meeting at High Voltage, what I had learned developed into the idea of the user-generated narrative. In my notes from 2003, I outlined the process like this:

1. Players want, ultimately, to play a game. To do so, they need agency.
2. Games are conflict situations where the agent (player) determines a course of action aimed at creating a favorable outcome.
3. When players engage and resolve, they create an internal narrative of their experience. (Example: “I ran into 3 monsters in that room, but I was able to defeat them with my mega-punch.”) This extends to games without story. (Example: “The AI in Pong is clearly trying to cheat me. I’ll show it who’s boss!”)
4. This internal narrative is, itself, story.
5. Players are the hero of this story.
6. Games provide the context and direction for that narrative.
7. Controlling that context and direction creates a more powerful, more profound interactive experience.
8. This context and direction extends to the game rules.
9. Breaking the rules for the sake of narrative (i.e. inserting an on-rails element) has a high probability of destroying the player agency and suspension of disbelief necessary to develop and maintain the user-generated narrative.
10. If the game doesn’t support the user-generated narrative, the game will fail.

As I said before, so much of it seems obvious now. Still, every insight ever had is new to the person who discovers it. Also, design as a discipline was — even in 2003 — still fairly new, and we were still learning. Even if we didn’t come up with “industry changing” patterns, the exercise itself was useful. I can’t recommend it enough.

In fact, you can apply the general process of pattern creation to anything you enjoy doing. The process is simple.

Problem: Come up with a central problem statement. What is a common problem that you encounter? Do other people encounter this problem?

Solution: How do you tend to solve this problem? How have others solved this problem? Is there any overlap between your solution and their solutions?

Consequence: What happens after you’ve solved the problem? Is there anything you have to consider after applying the solution? Do you often say, “Oh dang, I forgot to think of X. Now I have to rework Y in order to make X work”? Consider the ramifications of your solution and how it affects future decisions.

Before long, you’ll have your own guidebook!