Difference between revisions of "Player/System Action Composites"

From gdp3
Jump to: navigation, search
 
Line 1: Line 1:
 
[[Category:Dynamic Patterns]]
 
[[Category:Dynamic Patterns]]
[[Category:Needs work]]
 
 
[[Category:Needs revision]]
 
[[Category:Needs revision]]
 
[[Category:Needs references]]
 
[[Category:Needs references]]
 
[[Category:Patterns created on the Wiki]]
 
[[Category:Patterns created on the Wiki]]
 
[[Category:To be Published]]
 
[[Category:To be Published]]
[[Category:Staffan's current workpage]]
 
 
''Game systems where a player's actions can be initiated by either that player or the system, or where the execution of the actions are performed together.''
 
''Game systems where a player's actions can be initiated by either that player or the system, or where the execution of the actions are performed together.''
  

Latest revision as of 21:20, 5 July 2015

Game systems where a player's actions can be initiated by either that player or the system, or where the execution of the actions are performed together.

Letting players perform actions is vital in most games but in some cases game designers may wish to influence these actions during gameplay. This can be done by the system activating the actions irrespectively of players' intentions or by letting the execution of an action by actively modified by the system as it is being executed. Games that do either of these two things have Player/System Action Composites.

Examples

The auto-aim functionality found in games such as the Grand Theft Auto and the Halo are examples of Player/System Action Composites. Likewise, the possibility for players to write code or scripts in DragonMud, Ultima Online, and World of Warcraft that can make their characters perform actions are examples of Player/System Action Composites.

Using the pattern

Player/System Action Composites can either be created by letting actions that execute mechanically once activated be possible to be activated both by a player or the game system, or let input from both affect the execution of an action.

An important aspect of the latter is to make sure that the system part actually differs from "normal" execution of the action; this is most easily done by letting others not have the pattern or making the pattern active due to Power-Ups; here, the pattern is created by the combination of Power-Ups and Improved Abilities. Independent of type, they are most easily created through Automated Responses. Sometimes this is created through letting the Skills or Characters affect the action, i.e. using Player/Character Skill Composites together with Automated Responses (or, in more complex cases, Enforced Agent Behavior) to instantiate the pattern.

Supporting Player Augmentations can allow players to choose to have the pattern or not independent of gameplay events. Similarly, Player/System Action Composites can be modulates by having them as Optional Rules; this provides a way for players to select their Difficulty Levels.

Consequences

Player/System Action Composites quite naturally modify patterns related to actions modified by the pattern, of which Combat and Movement are perhaps the most natural choices.

The use of the pattern affects both Performance Uncertainty and Player Unpredictability, typically in making them less uncertain or unpredictable. It can both provide Player Agency and remove it, depending on how players perceive the effect of the system initiating or modifying the execution of actions.

Relations

Can Instantiate

Player Agency

with Optional Rules

Difficulty Levels

Can Modulate

Combat, Movement, Performance Uncertainty, Player Unpredictability

Can Be Instantiated By

Automated Responses, Optional Rules, Player Augmentations

Player/Character Skill Composites together with Automated Responses or Enforced Agent Behavior

Power-Ups together with Improved Abilities

Can Be Modulated By

-

Possible Closure Effects

-

Potentially Conflicting With

Player Agency

History

New pattern created in this wiki.

References

-

Acknowledgements

-