Designer pal Carl Klutzke linked to an intriguing project the other day:  a wiki of Gameplay Design Patterns curated by the Swedish ICT Interactive Institute. They’re developing a game design pattern language, modeled after Christopher Alexander’s seminal works in the field of architecture and since adopted by software engineers:

How can we understand the possibilities of game design? Having a language to talk about existing or potential features of gameplay is a fundamental requirement for this.

Each gameplay feature is described as a design pattern, a way of describing repeatable design solutions in an accessible way.

It’s an intriguing idea that has been discussed in my game design circles for a decade (Justin Love‘s early work on one gets a mention on an episode of Design Time With James and Kory), and here, this academic group has been building one the whole time!

This is an invaluable resource for game designers.

To begin, what do they mean by “gameplay design patterns”? It’ll help to define the concept of a pattern language as coined by Alexander. Wikipedia is useful here:

A pattern language is a method of describing good design practices within a field of expertise.

Like all languages, a pattern language has vocabulary, syntax, and grammar—but a pattern language applies to some complex activity other than communication.

Now, take a look at the entry in the Gameplay Design Pattern wiki for Token Placement (their more useful term for Worker Placement). It begins by defining the pattern “Token Placement” and how it fits within the Gameplay Design vocabulary:

Many games give players several different actions to choose from. Those using Token Placement let players compete with each other in picking actions to be played by placing tokens. By having limited number of tokens that can be played and needing to compete with other players for the actions, Token Placement can require players to make trade-offs between with [sic] actions to do and iteratively design their plans before performing them.

The entry gives a list of published game examples that use the Token Placement pattern, then goes on to describe common usages of Token Placement and situations in which it is more and less likely to be a good design choice (the syntax).

Token Placement systems require deciding what actions players can pick by placing Bookkeeping Tokens and how many such tokens players should have. Since one of the reasons for using it is that players need to compete for being able to perform actions, the pattern is primarily one for Multiplayer Games…

Regarding the actions, this not only means designing a Limited Set of Actions players can choose from but also considering if there should be one or several slots for each type of action. The actual amount of Tokens give[n] to each player each round is often designed to occupy a certain percentage of the total number of actions – this means that the number is often changed depending on how many players participate but at the same time the number of actions are typically set so that players at least get to place two or three Tokens (the pattern Role Selection basically supersedes Token Placement if one can only place one token)…

Additionally, it provides a list of consequences or gameplay effects resulting from this design choice (the grammar) and ways in which Token Placement can interact with other gameplay patterns (a cross reference of the syntax and grammar).

The use of Token Placement in games provide Planning Phases in which players have a Freedom of Choice to place Tokens (Bookkeeping ones even if they are referred to as workers in many games) to select future actions from a Limited Set of Actions. Since players have only a few Tokens to place, these are Limited Resources, and since these are used to decide future actions the pattern can be seen as a form of Budgeted Action Points (the places to place the Tokens may also be Limited Resources and when this is true the pattern modulates Limited Resources as well)…

Being a wiki, each pattern term is linked to its own page and cross referenced. Hours of link diving await the curious designer. Incredibly useful stuff!

I plan to dive into this rabbit hole and see what wonder awaits.

Gameplay Design Patterns