Difference between revisions of "Asynchronous Gameplay"
| Line 19: | Line 19: | ||
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. | 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. | + | 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]]. | 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]]. | ||
| Line 25: | Line 25: | ||
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. | 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. | + | [[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 == | ||
Revision as of 19:33, 2 July 2015
Gameplay that does not require - or demands - that not all players are playing at the same time.
This pattern is a still a stub.
Contents
Examples
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.
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, 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
- ↑ Björk, S. & Holopainen, J. (2004) Patterns in Game Design. Charles River Media. ISBN1-58450-354-8.
Acknowledgements
-
