Difference between revisions of "Player-Location Proximity"

From gdp3
Jump to: navigation, search
Line 23: Line 23:
 
Gameplay depending on [[Player-Location Proximity]] is likely to create [[Traverse]] goals, and [[Races]] if [[Time Limits]] exist or other players may block effects by arriving to the place first. Since moving to physical locations require [[Physical Navigation]], the pattern may also make [[Player Physical Prowess]] and [[Real World Knowledge Advantages]] part of the gameplay. If the locations are not well-known to the players, [[Player-Location Proximity]] dependent gameplay can also give rise to [[Game World Exploration]] and [[Gameplay Changes Perception of Real World Phenomena]]. The locations that players' positions are compared are [[Strategic Locations]] unless very many of them exist.
 
Gameplay depending on [[Player-Location Proximity]] is likely to create [[Traverse]] goals, and [[Races]] if [[Time Limits]] exist or other players may block effects by arriving to the place first. Since moving to physical locations require [[Physical Navigation]], the pattern may also make [[Player Physical Prowess]] and [[Real World Knowledge Advantages]] part of the gameplay. If the locations are not well-known to the players, [[Player-Location Proximity]] dependent gameplay can also give rise to [[Game World Exploration]] and [[Gameplay Changes Perception of Real World Phenomena]]. The locations that players' positions are compared are [[Strategic Locations]] unless very many of them exist.
  
While [[Player-Location Proximity]] always creates [[Real World Gameplay Spaces]], it can also create [[Pervasive Gameplay]] and [[Activity Blending]] if the gameplay area is not explicitly stated and separated from other activities. When the gameplay area in the latter case becomes large enough, as is the case for example with [[Geocaching]], [[Insectopia]], and [[SCVNGR]], the pattern also promotes [[Encouraged Return Visits]].
+
While [[Player-Location Proximity]] always creates [[Real World Gameplay Spaces]], it can also create [[Pervasive Gameplay]] if the gameplay area is not explicitly stated and separated from other activities. When the gameplay area in the latter case becomes large enough, as is the case for example with [[Geocaching]], [[Insectopia]], and [[SCVNGR]], the pattern also promotes [[Encouraged Return Visits]].
  
 
When used in [[:Category:Pervasive Games|Pervasive Games]] and [[:Category:Live Action Roleplaying Games|LARPs]], [[Player-Location Proxmity]] gives [[Game Masters]] information about players' locations and thereby let them instantiate gameplay events based upon where the players are.
 
When used in [[:Category:Pervasive Games|Pervasive Games]] and [[:Category:Live Action Roleplaying Games|LARPs]], [[Player-Location Proxmity]] gives [[Game Masters]] information about players' locations and thereby let them instantiate gameplay events based upon where the players are.
Line 29: Line 29:
 
== Relations ==
 
== Relations ==
 
=== Can Instantiate ===
 
=== Can Instantiate ===
[[Activity Blending]], [[Encouraged Return Visits]], [[Gameplay Changes Perception of Real World Phenomena]], [[Pervasive Gameplay]], [[Physical Navigation]], [[Player Physical Prowess]], [[Races]], [[Real World Knowledge Advantages]], [[Strategic Locations]], [[Traverse]]
+
[[Encouraged Return Visits]], [[Gameplay Changes Perception of Real World Phenomena]], [[Pervasive Gameplay]], [[Physical Navigation]], [[Player Physical Prowess]], [[Races]], [[Real World Knowledge Advantages]], [[Strategic Locations]], [[Traverse]]
  
 
=== Can Modulate ===
 
=== Can Modulate ===

Revision as of 19:14, 14 August 2012

Game rules that depend on players being physically close to places.

While many games make the position of players' tokens and characters in the game worlds into important part of the gameplay, few make the actual position of the players themselves part of the game. The main exception to this is traditional sports. Those that make physical location has specific gameplay meaning when players approach or enter them make use of a Player-Location Proximity relation.

Examples

While many Sports inherently make use of Player-Location Proximity, Orienteering explicitly sets goals for players to position themselves at specific locations.

Human PacMan, Geocaching, Pirates!, and SCVNGR rely on player movement and use technology to let people report in their locations to the game systems. Backseat Gaming also uses technology to locate players but is designed to work for the passengers of a car. Uncle Roy All Around You also depends on players' location in the physical world, but let the players report their locations freely regardless of where they actually are.

Using the pattern

Implementation of Player-Location Proximity is rather straightforward - one simply designs location-dependent gameplay (e.g. regarding Check Points, Exploration, or Traverse) as usually but for players instead of Avatars, Characters, or Tokens. Specific details that need to be addressed (and which may be more difficult due to real world measuring) include what distance should trigger gameplay events, and if Extended Actions are need for the triggering to take place or the triggered events to continue. Besides this, considerations need to be made are due to the possible consequences of player movement such as Player Physical Prowess and Real World Knowledge Advantages, since these can imbalance gameplay.

A specific alternative for games with Player-Location Proximity, first reported for Uncle Roy All Around You, is to let players do Self-Reported Positioning rather than rely on technology or Dedicated Game Facilitators to do this. While this can remove problems with the reliability of the technology to locate players, it can also let players have a more play-like approach to the games.

Delivery goals typically requires that players' Focus Loci carry or move a specific game element to a specific location. This makes games using Artifact-Location Proximity likely to force the players themselves to go to the locations, and thereby the combination of Delivery and Artifact-Location Proximity can be used to create Player-Location Proximity.

Consequences

Gameplay depending on Player-Location Proximity is likely to create Traverse goals, and Races if Time Limits exist or other players may block effects by arriving to the place first. Since moving to physical locations require Physical Navigation, the pattern may also make Player Physical Prowess and Real World Knowledge Advantages part of the gameplay. If the locations are not well-known to the players, Player-Location Proximity dependent gameplay can also give rise to Game World Exploration and Gameplay Changes Perception of Real World Phenomena. The locations that players' positions are compared are Strategic Locations unless very many of them exist.

While Player-Location Proximity always creates Real World Gameplay Spaces, it can also create Pervasive Gameplay if the gameplay area is not explicitly stated and separated from other activities. When the gameplay area in the latter case becomes large enough, as is the case for example with Geocaching, Insectopia, and SCVNGR, the pattern also promotes Encouraged Return Visits.

When used in Pervasive Games and LARPs, Player-Location Proxmity gives Game Masters information about players' locations and thereby let them instantiate gameplay events based upon where the players are.

Relations

Can Instantiate

Encouraged Return Visits, Gameplay Changes Perception of Real World Phenomena, Pervasive Gameplay, Physical Navigation, Player Physical Prowess, Races, Real World Knowledge Advantages, Strategic Locations, Traverse

Can Modulate

Game Masters, Real World Gameplay Spaces

Can Be Instantiated By

Player-Artifact Proximity together with Delivery

Can Be Modulated By

Extended Actions, Self-Reported Positioning

Possible Closure Effects

-

Potentially Conflicting With

-

History

Updated version of the pattern Player-Location Proximity first described in the report Game Design Patterns for Mobile Games[1].

References

  1. Davidsson, O., Peitz, J. & Björk, S. (2004). Game Design Patterns for Mobile Games. Project report to Nokia Research Center, Finland.

Acknowledgements

Johan Peitz