Strict Standards: (assassin) Declaration of SSLAuthPlugin::modifyUITemplate() should be compatible with AuthPlugin::modifyUITemplate(&$template, &$type) in /afs/athena.mit.edu/activity/a/assassin/web_scripts/wiki/extensions/SSLAuthPlugin.php on line 47

Strict Standards: (assassin) Declaration of SSLAuthPlugin::setPassword() should be compatible with AuthPlugin::setPassword($user, $password) in /afs/athena.mit.edu/activity/a/assassin/web_scripts/wiki/extensions/SSLAuthPlugin.php on line 47

Strict Standards: (assassin) Declaration of SSLAuthPlugin::initUser() should be compatible with AuthPlugin::initUser(&$user, $autocreate = false) in /afs/athena.mit.edu/activity/a/assassin/web_scripts/wiki/extensions/SSLAuthPlugin.php on line 47
In-game Workload - Assassin Wiki

In-game Workload

From Assassin Wiki
Jump to: navigation, search

Most of the examples so far involve considerations of GM workload in preparation for the game. However, some mechanics could be considered unfeasible because of the demands that they place on the GM or the player "during" the game. Some games allow GMs to confirm the reliability of information that they may have gathered on other characters, a mechanic introduced in Maelstrom (1998) by Jake Beal, Jennifer Chung, Ken Clary, Dudley Lamming and Patrick Pittman. This requires GMs to be available to provide information that will not contradict information provided by other GMs.

A number of games have similar mechanics that vary with the expected response time for such “background checks.� Maelstrom required these requests to be sent via email, which has an assumed time delay and allowed GMs to confer and respond to requests overnight. Other games, such as my own Tenchi Muyo: The Night Before the Carnival (2001), required GMs to frequent check and respond to new requests in envelopes in several different locations around campus. This particular implementation took GMs away from their important role as game referees and players became increasingly disappointed at the lack of timely information.

Excessively time-intensive mechanics are known as being “hosing,� borrowing from the MIT metaphor of “drinking from a fire hose.� The above example features a “GM-hosing� mechanic, where GMs do too much to achieve minimal results. The same term is used for mechanics that make players perform tasks that require excessive time or effort to make any sort of headway towards their goals. Usually, hosing mechanics make players feel that they have to spend the majority of game time attending to some uninteresting task, drawing them away from other activities that they may consider more interesting or entertaining but less crucial to their character’s success. Alternatively, a hosing mechanic may require a player to devote excessive mental energies to memorization or calculation to deal with quick-response situations such as combat, making it difficult or dangerous for the player to concentrate on other things in the game.

Note that GMs often aim to design mechanics that require the continual (but not continuous) involvement of the player throughout the game. The extreme opposite of a hosing mechanic is a trivial mechanic that requires a minimum of effort, time and decision-making on the part of the player. Designing these mechanics may also be a waste of time on the part of the GMs, as their inclusion into a game generates relatively little player activity and interest. GM teams want to make sure that the time, concentration and exertion required for a player to complete his or her goals are paced to provide players with interesting activities throughout the duration of a game: not too little, not too much, and not too boring.


Return to Tensions in Live-Action Roleplaying Game Design

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox