Multiplayer Design Patterns

Teodric Abstract: This document describes constructs used in multiplayer games. The document is loosely related to the Haven project but should be applicable outside that project with no modifications.

Availability: Public

Contents

Background - Format - Patterns - Links - Bibliography and Sources - Copyright

Quick Index to Patterns

Narrative Receipt - Requirement Progress Milestone - Experience Diversity Sum is Greater than Parts Cooperation Coalition Conflict Faction Communication and Information Information Filter Representation Avatar

Background

This document is not about describing design patterns as a tool or motivating the use of design patterns in creating multiplayer games. For that type of sources, consult the bibliography . The reader is assumed to know what design patterns are and how to apply them.
Instead, this document is a collection of patterns commonly used in multiplayer games. It is not about patterns specific to multiplayer games but the way the patterns are approached and described is focused on multiplayer designs. In its nature, design patterns are a collaboration effort, and the patterns described draw heavily on other pattern collections.

Format

The patterns follow a basic format. Different sources use very different format to describe design patterns, but their essence is the same and adaptation should be fairly simple.

Pattern Template
This is a descriptive name for the pattern
Problem:
Solution:
Consequence:
Examples:
Discussion: Optional. May contain background and develop some aspect of the problem and solution.
Comment: Some patterns contain a comment. Among other notes, this is where relation to other patterns are mentioned. References to pattern descriptions in other sources are here as well.
Other Names: Sometimes it is necessary to clarify what is and what is not a use of the pattern.



Patterns

The patterns are sorted in a number of rough categories. This is only for convenience.

Narrative Patterns

Receipt
Problem: To allow players to make progress in a storyline
Solution: Introduce some sort of milestone or landmark action representing the essence of the achievement.
Consequence: In the eyes of the player, the receipt will represent progress.
Examples: If a game has progress, it is either a continuous scale or discrete events. Sometimes discreet events are visible to the player, such as a response in a MUD or MMORPG NPC dialog.

Consider the following MMORPG dialogue between player ("Neo") and NPC ("Child"):
Child says,
 Instead, only try to realize the [truth].
Neo says,
 what truth
Child says,
There is [no spoon].
Neo says,
 no spon
Neo says,
 what no spoon
Child says,
 There is only your self.
In this dialogue, the action that the player needs to perform to advance is clearly marked with square brackets. In some games you may see these called triggers, since they trigger an event in the game world.
The Receipt usage in this dialogue is the response to the character's repetition of the key phrases ("truth", "no spoon") - these responses are examples of visible receipts. They let the player know that he is making progress. Upon hearing the word "truth", the NPC responds by revealing new keywords.
Comment: This is a special case of the Milestone Pattern. See also the Requirement Pattern to which this is the companion pattern. The Receipt Pattern is not specific to multiplayer scenarios.


Requirement
Problem: A task put before the player is described as a collection of requirements the player needs to fulfill to achieve his objectives.
Solution:
Consequence:
Examples:
Comment: This is the companion pattern to the Receipt Pattern. A Requirement fulfilled usually results in a Receipt. The Requirement Pattern is not specific to multiplayer scenarios.
Other Names:

Progress Patterns


Milestone
Problem:
Solution:
Consequence:
Examples:
Comment: The Milestone Pattern is not specific to multiplayer scenarios.

Experience
Problem:
Solution:
Consequence:
Examples:
Comment: This is a special case of the Milestone pattern. The Experience Pattern is not specific to multiplayer scenarios.

Diversity Patterns


Sum is Greater Than Parts
Problem: To encourage diversity in player choice
Solution: In a set of available (and approximately equally beneficial) paths, encourage diversity by making different-choice groups more capable of solving tasks than single-choice groups.
Consequence:
Examples:
Discussion: The sum of players may be greater than the parts even in single-choice groups. In a time-regulated situation (group capability governed by the pace at which the group members regain power needed for progress), a group of two will overcome the obstacle in half the time - during that time the drain on the regulated resource may be less than half, meaning the group can accomplish more than 2 x the progress single players could. However, the pattern may still be valid if a multi-choice group has even greater potential than a single-choice group.
Comment: The Sum is Greater Than Parts Pattern is not specific to multiplayer scenarios - other situations where it might occur are strategy games where diversifying one's forces may be more advantageous than having fewer types of units, or RPG party composition.

Cooperation Patterns


Coalition
Problem:
Solution:
Consequence:
Examples:

Conflict Patterns


Faction
Problem:
Solution:
Consequence:
Examples:

Communication and Information Patterns


Information Filter
Problem:
Solution:
Consequence:
Examples:
Comment: The Information Filter is not specific to multiplayer scenarios.

Representation Patterns


Avatar
Problem:
Solution:
Consequence:
Examples:


Links

Bibliography and Sources

The first version of this source list is a copy of the bibliography in Kreimeier's article A Case for Game Design Patterns , with some additions. The format of this document is raw html, which made numbering a bad choice for references.

Copyright

This text was written by Olof Ekström. For more information about the author of this page, see Olof Ekström's personal information in the Project Profiles document.

Copyright © 2002 Olof Ekström/Extro System. All rights reserved.

Bälinge/Uppsala, Sweden, March 2002