Difference between revisions of "Asynchronous Gameplay"

From gdp3
Jump to: navigation, search
 
(27 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
[[Category:Patterns]]
 
[[Category:Patterns]]
[[Category:Needs work]]
+
[[Category:Dynamic Patterns]]
 
[[Category:Needs revision]]
 
[[Category:Needs revision]]
[[Category:Needs examples]]
 
 
[[Category:Needs references]]
 
[[Category:Needs references]]
[[Category:Stub]]
 
 
[[Category:To be Published]]
 
[[Category:To be Published]]
[[Category:Staffan's current workpage]]
+
''Gameplay that does not require - or demands - that not all players are playing at the same time.''
''The one-sentence "definition" that should be in italics.''
+
  
This pattern is a still a stub.
+
While many games are played by players that are co-presence with each other, not all games do. Those with [[Asynchronous Gameplay]] can be played with some or no other players present while not causing gameplay problems.
  
 
=== Examples ===
 
=== Examples ===
[[Left 4 Dead series]]
+
Turn-based games such as [[Chess]] and [[Go]] support [[Asynchronous Gameplay]] since players alternate between performing actions in the game and each action can be simply described in messages. This allows players to record their action as messages for other players, who performs these actions when the messages are received and after this begins considering their own next move.
  
==== Anti-Examples ====
+
The [[Left 4 Dead series]] allows players to come and go by simply replacing them with AI players when someone leave and having those AI players yield their places when someone wants to join a game.
optional
+
 
 +
Game masters of [[:Category:Tabletop Roleplaying Games|Tabletop Roleplaying Games]] can handle cases where not all players are present by either taking on the roles of those players' characters themselves or by providing narrative explanations why those characters are not active in the same way others are.
  
 
== Using the pattern ==
 
== Using the pattern ==
  
ref to [[Unsynchronized Game Sessions]]
+
One of the needs of [[Asynchronous Gameplay]] is maintaining the game state, often without any player present. This means that [[Dedicated Game Facilitators]] are often needed for [[Asynchronous Gameplay]]. One simple aspect of the game state which games with [[Asynchronous Gameplay]]  often need to support is simply making it clear to active players which the other players are; [[Handles]] is a simple solution to this.
  
=== Diegetic Aspects ===
+
Another aspect of [[Asynchronous Gameplay]] is how players should be able to interact with the game and other players. [[Turn-Based Games]] ensure that players have chances of interacting with the game in equal amounts but can lead to [[Downtime]]. [[Tick-Based Games]] in practice makes players have simultaneous and synchronized turns but unless the ticks are long players the presence of [[The Show Must Go On]] can work directly against [[Asynchronous Gameplay]]. The same goes for [[Real-Time Games]]. Games with [[No Direct Player Influence]] avoid this through making players make all decisions before gameplay begins. [[Ghosts]] offer a similar solution by having recordings of players offer competition. [[Free Gift Inventories]] on the other hand provide players with possibilities of supporting other players without them being present. While not possible for all types of games due to technical issues, [[AI Players]] can in a brute force way support [[Asynchronous Gameplay]] by simply replacing human players with [[AI Players]].
  
=== Interface Aspects ===
+
While not strictly necessary for [[Asynchronous Gameplay]], it is often easier to allow players to also not be in physical proximity through the use of [[Communication Channels]] and [[Mediated Gameplay]]. Most cases of [[Persistent Game Worlds]] support this as well as having [[Dedicated Game Facilitators]], so they make good starting points for supporting [[Asynchronous Gameplay]]. Similarly, games that support [[Drop-In/Drop-Out]] gameplay have typically met the requirements for supporting [[Asynchronous Gameplay]].
  
=== Narration Aspects ===
+
While [[Asynchronous Gameplay]] can require all players to be present at the beginning of a game instance, one could argue that a fuller form of the pattern supports [[Late Arriving Players]]. In contrast, players may not be need to be present at the end of a game instance due to [[Player Elimination]] or support for [[Early Leaving Players]] but games can also simply end at players can be informed about the final state later. As these patterns show, support for [[Unsynchronized Game Sessions]] often overlap with support for [[Asynchronous Gameplay]] so it often makes sense to consider both when considering one.
 +
 
 +
[[Public Information]] can be difficult to combine with [[Asynchronous Gameplay]] since players can potentially gain advantages by access information about the other players. Likewise, [[Common Experiences]] can be problematic to support in games with [[Asynchronous Gameplay]] since players may not ever actually directly interact with each other (this is especially the case when [[AI Players]] are used to replace players that leave gameplay).
  
 
== Consequences ==
 
== Consequences ==
 +
[[Asynchronous Gameplay]] can cause quite difference consequences depending on how what other characteristics a game has. If it allows players flexibility when to play, it supports [[Interruptibility]] or a [[Freedom of Choice]] of when to play and when taken further in this direction it also supports [[Ubiquitous Gameplay]]. On the other hand, if players need to wait for other players to finish their game sessions so they jointly can start new ones, [[Asynchronous Gameplay]] instead causes [[Downtime]] with the silver lining that this can be used for [[Stimulated Planning]].
 +
 +
In games with [[Private Game Spaces]], [[Asynchronous Gameplay]] can turn [[Multiplayer Games]] into [[Massively Single-Player Online Games]]. As another example of different consequences due to the presence of other characteristics or patterns, [[Asynchronous Collaborative Actions]] can emerge when [[Asynchronous Gameplay]] co-exists with [[Altruistic Actions]] or [[Cooperation]].
  
 
== Relations ==
 
== Relations ==
[[Real-Time Games]]
+
=== Can Instantiate ===
[[Cooperation]]
+
[[Downtime]],
[[Massively Single-Player Online Games]]
+
[[Freedom of Choice]],
[[Dedicated Game Facilitators]]
+
[[Interruptibility]],
[[Turn-Based Games]]
+
[[Stimulated Planning]],
[[Private Game Spaces]]
+
[[Stimulated Planning]]
+
[[No Direct Player Influence]]
+
[[Extra Chances]]
+
[[Late Arriving Players]]
+
[[Persistent Game Worlds]]
+
[[Free Gift Inventories]]
+
[[Altruistic Actions]]
+
[[Handles]]
+
 
[[Ubiquitous Gameplay]]
 
[[Ubiquitous Gameplay]]
[[Ghosts]]
+
 
[[Interruptibility]]
+
==== with [[Altruistic Actions]] or [[Cooperation]] ====
[[Mediated Gameplay]]
+
[[Communication Channels]]
+
 
[[Asynchronous Collaborative Actions]]
 
[[Asynchronous Collaborative Actions]]
  
=== Can Instantiate ===
+
==== with [[Private Game Spaces]] ====
-
+
[[Massively Single-Player Online Games]]
 
+
==== with ... ====
+
  
 
=== Can Modulate ===
 
=== Can Modulate ===
Line 60: Line 50:
  
 
=== Can Be Instantiated By ===
 
=== Can Be Instantiated By ===
-
+
[[AI Players]],
 +
[[Dedicated Game Facilitators]],
 +
[[Drop-In/Drop-Out]],
 +
[[Ghosts]],
 +
[[No Direct Player Influence]],
 +
[[Persistent Game Worlds]]
  
 
=== Can Be Modulated By ===
 
=== Can Be Modulated By ===
-
+
[[Communication Channels]],
 +
[[Free Gift Inventories]],
 +
[[Handles]],
 +
[[Late Arriving Players]],
 +
[[Mediated Gameplay]],
 +
[[Real-Time Games]],
 +
[[Tick-Based Games]],
 +
[[Turn-Based Games]]
  
 
=== Possible Closure Effects ===
 
=== Possible Closure Effects ===
Line 69: Line 71:
  
 
=== Potentially Conflicting With ===
 
=== Potentially Conflicting With ===
-
+
[[Common Experiences]],
 +
[[Public Information]],
 +
[[The Show Must Go On]]
  
 
== History ==
 
== History ==
An updated version of the pattern ''Asynchronous Gameplay'' that was part of the original collection in the book ''Patterns in Game Design''<ref name="Bjork & Holopainen 2004"/>.
+
An updated version of the pattern ''Asynchronous Games'' that was part of the original collection in the book ''Patterns in Game Design''<ref name="Bjork & Holopainen 2004"/>.
  
 
== References ==
 
== References ==

Latest revision as of 19:44, 2 July 2015

Gameplay that does not require - or demands - that not all players are playing at the same time.

While many games are played by players that are co-presence with each other, not all games do. Those with Asynchronous Gameplay can be played with some or no other players present while not causing gameplay problems.

Examples

Turn-based games such as Chess and Go support Asynchronous Gameplay since players alternate between performing actions in the game and each action can be simply described in messages. This allows players to record their action as messages for other players, who performs these actions when the messages are received and after this begins considering their own next move.

The Left 4 Dead series allows players to come and go by simply replacing them with AI players when someone leave and having those AI players yield their places when someone wants to join a game.

Game masters of Tabletop Roleplaying Games can handle cases where not all players are present by either taking on the roles of those players' characters themselves or by providing narrative explanations why those characters are not active in the same way others are.

Using the pattern

One of the needs of Asynchronous Gameplay is maintaining the game state, often without any player present. This means that Dedicated Game Facilitators are often needed for Asynchronous Gameplay. One simple aspect of the game state which games with Asynchronous Gameplay often need to support is simply making it clear to active players which the other players are; Handles is a simple solution to this.

Another aspect of Asynchronous Gameplay is how players should be able to interact with the game and other players. Turn-Based Games ensure that players have chances of interacting with the game in equal amounts but can lead to Downtime. Tick-Based Games in practice makes players have simultaneous and synchronized turns but unless the ticks are long players the presence of The Show Must Go On can work directly against Asynchronous Gameplay. The same goes for Real-Time Games. Games with No Direct Player Influence avoid this through making players make all decisions before gameplay begins. Ghosts offer a similar solution by having recordings of players offer competition. Free Gift Inventories on the other hand provide players with possibilities of supporting other players without them being present. While not possible for all types of games due to technical issues, AI Players can in a brute force way support Asynchronous Gameplay by simply replacing human players with AI Players.

While not strictly necessary for Asynchronous Gameplay, it is often easier to allow players to also not be in physical proximity through the use of Communication Channels and Mediated Gameplay. Most cases of Persistent Game Worlds support this as well as having Dedicated Game Facilitators, so they make good starting points for supporting Asynchronous Gameplay. Similarly, games that support Drop-In/Drop-Out gameplay have typically met the requirements for supporting Asynchronous Gameplay.

While Asynchronous Gameplay can require all players to be present at the beginning of a game instance, one could argue that a fuller form of the pattern supports Late Arriving Players. In contrast, players may not be need to be present at the end of a game instance due to Player Elimination or support for Early Leaving Players but games can also simply end at players can be informed about the final state later. As these patterns show, support for Unsynchronized Game Sessions often overlap with support for Asynchronous Gameplay so it often makes sense to consider both when considering one.

Public Information can be difficult to combine with Asynchronous Gameplay since players can potentially gain advantages by access information about the other players. Likewise, Common Experiences can be problematic to support in games with Asynchronous Gameplay since players may not ever actually directly interact with each other (this is especially the case when AI Players are used to replace players that leave gameplay).

Consequences

Asynchronous Gameplay can cause quite difference consequences depending on how what other characteristics a game has. If it allows players flexibility when to play, it supports Interruptibility or a Freedom of Choice of when to play and when taken further in this direction it also supports Ubiquitous Gameplay. On the other hand, if players need to wait for other players to finish their game sessions so they jointly can start new ones, Asynchronous Gameplay instead causes Downtime with the silver lining that this can be used for Stimulated Planning.

In games with Private Game Spaces, Asynchronous Gameplay can turn Multiplayer Games into Massively Single-Player Online Games. As another example of different consequences due to the presence of other characteristics or patterns, Asynchronous Collaborative Actions can emerge when Asynchronous Gameplay co-exists with Altruistic Actions or Cooperation.

Relations

Can Instantiate

Downtime, Freedom of Choice, Interruptibility, Stimulated Planning, Ubiquitous Gameplay

with Altruistic Actions or Cooperation

Asynchronous Collaborative Actions

with Private Game Spaces

Massively Single-Player Online Games

Can Modulate

-

Can Be Instantiated By

AI Players, Dedicated Game Facilitators, Drop-In/Drop-Out, Ghosts, No Direct Player Influence, Persistent Game Worlds

Can Be Modulated By

Communication Channels, Free Gift Inventories, Handles, Late Arriving Players, Mediated Gameplay, Real-Time Games, Tick-Based Games, Turn-Based Games

Possible Closure Effects

-

Potentially Conflicting With

Common Experiences, Public Information, The Show Must Go On

History

An updated version of the pattern Asynchronous Games that was part of the original collection in the book Patterns in Game Design[1].

References

  1. Björk, S. & Holopainen, J. (2004) Patterns in Game Design. Charles River Media. ISBN1-58450-354-8.

Acknowledgements

-