Confidence Rubrics for Patterns and Pattern Relationships
By: Chris Barney
Tags: Pattern Language, Game Design, Pattern Library, Game Development, Videogames

PATTERN LANGUAGE FOR GAME DESIGN

Confidence Rubrics for Patterns and Pattern Relationships

This article is in reference to the website patternlanguageforgamedesign.com and the book Pattern Language for Game Design.

Pattern Confidence

It is essential to acknowledge that all Patterns equally valid. Different exercises create more or less reliable Patterns, and you should carefully consider your confidence in any generated pattern before you use it in your designs. I recommend using this rubric for assessing your confidence in a new pattern, and for updating that confidence as you use the pattern over time. All patterns start with a confidence rating of 0 and add 1 for each item below that applies.

Some of the items below are related and ‘stack.’ For example, a ‘Common Pattern’ (+1) would also have to meet the requirements for being a ‘Limited Pattern’ (+1) and a ‘Singular Pattern’ (+1) for a total of 3. You should apply all the applicable labels. So if you had used this hypothetical pattern and another developer had independently described the same pattern, you would also apply ‘Demonstrated Pattern’ (+1) and Independent Sources’ (+1) for a total confidence score of 5.

Pattern Confidence Rubric

(+0) Theoretical Pattern: The Theoretical Patterns exercise generates this type of pattern. You might also create a ‘theoretical pattern’ by adapting a pattern from an existing repository that does not cite example games. This pattern may be valid, but you do not generate it from observation. Instead, you create it by imagining how a theory about game design would fit the pattern format.

(+1) Single Example Pattern: This level of confidence comes from a pattern that was generated based on one example. It is entirely possible to look at a single game and derive a valid pattern from it. However, it can be challenging to determine whether what you see is an actual pattern or just the results of a design technique or element that would yield a different pattern if you looked at its use across many games.

(+1) Limited Pattern: If you have observed the pattern in fewer than ten games, it is a ‘limited pattern.’ If you have a hard time providing the ten examples in an exercise, this level of confidence may result.

(+1) Common Pattern: The pattern is visible in at least ten games, probably many more. You have found a ‘common pattern’ when you stop recording examples at ten but could go on, and it’s a good sign that you have done an excellent job formulating a pattern based on your observations.

(+1) Demonstrated Pattern: A pattern is a ‘demonstrated pattern’ if you, or another developer, have used it in development, and the effect was as intended.

(+1) Validated Pattern: This pattern that is in common use among a variety of game developers and has been proven through widespread use to be effective is a ‘validated pattern.’ At the time of the printing of this book, it is probably not possible to find a pattern validated through use. As you work with Patterns throughout your career, it may become more common. A pattern might also be a ‘validated pattern’ if you conducted empirical user research to show that the pattern was effective.

(+1) Independent Sources: If more than one developer derives a pattern, it has ‘independent sources.’ In teaching, it is common to discover this kind of pattern as more than one group of students arrives at the same pattern from different starting points. As the community of developers using the exercises in this book increases and shares patterns, this will become more common.