Player-Artifact Proximity

From gdp3
Revision as of 09:43, 23 October 2012 by Staffan Björk (Talk | contribs) (Consequences)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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

Players' physical position in relation to gameplay artifacts is typically assumed not to be part of gameplay since either the artifacts are virtual ones or all players are co-located and can easily reach all artifacts. However, some games do this by measuring the position of both players and gameplay artifacts or otherwise ensuring that they are close to each other in order for players to interact with the artifacts or for gameplay events to be initiated. Games that do this make use of Player-Artifact Proximity. Note that artifacts can be either physical ones or virtual ones that are somehow given a location in the physical space.

Examples

Sports that make use of balls or pucks are trivial cases of Player-Artifact Proximity since it is rather obvious that players need to be close to them to be able to influence them. Ice Hockey and Soccer are two examples of this. Baseball is a somewhat more interesting example since pitchers need to throw balls within the strike zone of the batters, in effect requiring that a Player-Artifact Proximity is achieved.

Geocaching is based on players trying to find small caches hidden by other players. While the general locations of these are given with GPS coordinates, players need to locate the actual caches to be able to report their contents. Insectopia makes use of nearby Bluetooth devices to generate gameplay content and given the range of Bluetooth communication, this becomes a form of Player-Artifact Proximity.

Using the pattern

Design choices linked to Player-Artifact Proximity relate to what events are triggered by coming within the proximity and leaving it, and the distance for the proximity threshold. This can be modulated by having several different proximity thresholds for different events, making the triggering require Extended Actions, and making the events continuously trigger as long as players perform the Extended Actions of being in the proximity. While sensors or Dedicated Game Facilitators can measure distances between players and artifacts to determine if they are in proximity, and alternative exists in creating Gain Information goals that are completed by physically examining the artifacts. This option is used in Geocaching where technology helps players get close enough to the caches to start looking for them based upon clues received and then verify that they have been found by reporting on what it contained.

Beyond this, the artifacts used can be gameplay Tokens or Game Items such as Tools, so when using Player-Artifact Proximity one should take the design possibilities these have into consideration.

Consequences

Player-Artifact Proximity makes the physical position of Tokens or Tools into a gameplay feature, and thereby modify the Tokens and Tools. This also makes games have Real World Gameplay Spaces since the gameplay area is linked to the real world, and if this area is not denied to other activities it can also create Pervasive Gameplay. Having to move to come close to artifacts (or achieve a certain distance from them) makes Physical Navigation a consequence of Player-Artifact Proximity.

If Game Element Trading is supported for the artifact and proximity is required to gain Ownership, Player-Artifact Proximity gives rise to Player-Player Proximity.

Relations

Can Instantiate

Game Element Trading Pervasive Gameplay, Physical Navigation

with Game Element Trading

Player-Player Proximity

Can Modulate

Game Items, Real World Gameplay Spaces, Tokens, Tools

Can Be Instantiated By

-

Can Be Modulated By

Dedicated Game Facilitators, Extended Actions, Gain Information

Possible Closure Effects

-

Potentially Conflicting With

-

History

Updated version of the pattern Player-Artifact 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