jeuderologie: draft/elements14jan03.txt@bdef1afd1170

RPGnet <http://www.rpg.net>
<http://www.rpg.net/slib/ads/forward-ad.php?nextURL=http://www.gencon.com&imageURL=http://www.rpg.net/images/ads/genindy2006.gif>

Reviews <http://www.rpg.net/reviews/> Forums <http://forum.rpg.net>
News & Press <http://www.rpg.net/news+reviews/press.phtml> Columns &
Info <http://www.rpg.net/columns/index.phtml> RPG Wiki
<http://wiki.rpg.net> RPG Shop <http://shop.rpg.net>
<http://www.rpg.net/members/>

Elements

Rationales for Mechanics (or the Case for Designer's Notes)

*by Brian Gleichman*
Jan 14,2003

Rationales for Mechanics /(or the Case for Designer Notes)/

Why do rpgs use mechanics? Such a simple question, but one with such
complex answers. It seems obvious that those answers would be key in the
design process or in the judging of an existing game. After all, it's
only by way of knowing your needs that you can chart the nature and
placement of mechanical systems properly in such a way that the game
meets the desired goals.

Sadly it seems very common for rpg designers of the current day
(especially in the free or small print world) to skip right by that
question. It is painfully common for me to receive what is in effect a
blank stare upon quizzing a game designer as to the reasons and
rationales behind their design. Typically the only response is "I was
looking for something different" and "It does what I wanted it to do",
without being able to express what was different, or what it is doing.
The end result is I receive in answer a jumble of words typically tossed
on the back cover of a book as basic marketing ("Powerful yet simple
mechanics!", "Yes it's a floor wax and a desert topping!").

With this as the common response, there is little reason to wonder that
mechanics in many games seem almost pointless- seemly existing often
just because other games have included them. The result is typically a
distraction from (or misinterpretation of) the purpose of the game,
reducing what could have been a powerful design to yet another rpg that
will sit on the shelf.

Let's take a moment to consider some important and common rationales,
just so we're on the same page. I don't think these are by any means the
only reasons, but they are at the very least reasons every designer
should consider his mechanics in the light of.

I. Limiting Player Options

If any single rationale could claim to hold prominence in game design,
it would be this one. Why can't my 1st level /Age of Heroes/ fighter
kill an ancient red dragon with his penknife? Because the combat rules
make that all but impossible as a core requirement of design.

The natural result of any mechanic is to limit options. What those
options are limited to however determines the actual rationale for the
mechanic. In this specific case, the reason is to prevent specific
player actions and choices because they are unsuited to the intended
purpose of the game.

Advancement rules are typically guided by this rationale. The player
gets *X* amount of power within the game for *Y* amount of effort, not
no effort at all. Requiring a certain Strength level to break down a
specific door is yet another example while falling damage is yet another
(for those games limiting a character's ability to jump off 40 foot
walls to reach a battle).

II. Providing Meaningful Player Choices

The classic example here is combat mechanics (a subject I've already
spent some time on in my previous /Elements of Tactics/ article). The
idea is to present a complex and diverse enough set of choices in order
to make the decisions of the player important in determining the outcome
of the game events.

III. Inspiring Player Action

Examples of these are the Sanity rules from /Call of Cthulhu/ which
provide a nudge of when and what type of insanity the player is struck
with, but leave the exact details of expressing it up to the player and GM.

Psychological and Drama mechanics are normally created with this
rationale in mind, to respectively inspire role-play and story creation.

IV. Replacing Player Choice

These mechanics are intended to flat out replace decisions by a player
or GM.

Single roll combat resolutions are typically this type of mechanic, the
idea is to remove any tactical choices beyond that of the decision to
engage in battle (and sometimes even that isn't offered). Another
example is the use of straight up 'social' skills like 'bribe' and the
like. The concept is to remove choices and actions from extensive play
that are felt to be either beyond the ability of the players or outside
the focus of the game.

Another way of looking at these mechanics is as a simple and quick
method to resolve something so that the game can go forward. Removing
significant player input is perhaps the fasted way to achieve that goal.

V. Provide an Illusion

Some mechanics exist to aid in suspension of disbelief. Thus a game may
include detailed currency rules because the players have a hard time
believing that everyone in the world uses the same coins.

Some mechanics provide an illusion of Rationale II above. A typical
example is providing a wide range of combat maneuvers that suggest a
good selection- but upon using some math it's revealed that a single one
of the provided maneuvers is always the best choice. Sometimes this is a
result of failed design, at other times it's done on purpose (often
using dice pools mechanics in order to make the illusion more difficult
to pierce).

There are other possible reasons of course. I'm sure you can add a few
with a little bit of thought.

Once one knows the rationale for a mechanic, it becomes much easier to
determine the Layer of Design it applies to as well as its form.
Rationale IV mechanics for example tend to be simpler than Rationale II
systems by nature.

There's just one gotcha to keep in mind. A little thing called the 'the
eye of the beholder'.

Remember Rationale III above, a little thing about inspiring player
action? Most of the time I see such mechanics I'm not inspired. Instead
I see a Rationale IV mechanic- something that takes my choices away in
order to meet a goal of the game design (in the case of /Call of
Cthulhu/, it's enforcing the genre concept that everyone goes insane- a
type of railroading with respect to the role-playing of a PC).

Here's another example- Rationale II mechanics become little more than
Rationale V mechanics if the players can't grasp the actual effects of
choices in the system (dice pools tend to cause this effect by making
probability determination exceedingly difficult).

Take a few mechanics from a favorite game of your own and try fitting
them into each of the above rationales. With a little bit of work and a
talent for seeing things though the eyes of others- you may be surprised
how many rationales a single mechanic can fit in.

So in the end you may design a wonderful game, one that has developed
mechanics that fit their reasons for use at every point. But in the end
the final result may be viewed by others in a completely different light
than what you intended.

But all is not lost. The solution to this sad state of affairs is right
in the subtitle to this article.

Designer Notes.

Write them. Spend as much time and effort on them as you did in the
design of your game- for they determined the design of your game. Put
them directly in the book or on your website. Explain why you selected
the mechanics you did, what they do in your game, why you rejected other
possibilities.

You'll achieve four important outcomes.

First, you'll produce a better game. One tailored to your needs and
perfect for the type of play you desired.

Second, you'll provide the best guide there is to how the game was meant
to be played. And you'll do it in a way far better than the typical
stilted 'example of play' fiction.

Third, you'll define for the reader the terms on which your work is to
be judged, so that in that judging they are not looking for a game you
never designed. It is much better to hear "Even if I don't care for the
style, Game X does what it intends almost perfectly" instead of "This
games sucks".

And fourth, I won't get a blank stare when I ask you what makes your
game different or what you were trying to achieve. For not only will you
be able to answer that question, you've already written it for me
meaning the only thing I'll bother you about is the details of your
vision. And isn't the details of the designer's vision the reason for
making a game in the first place?

What do you think? <http://trio.rpg.net/pf/list.php?f=101>

Go to forum! <http://www.rpg.net/pf/list.php?f=101>
RPGnet <http://www.rpg.net>
<http://www.rpg.net/slib/ads/forward-ad.php?nextURL=http://www.gencon.com&imageURL=http://www.rpg.net/images/ads/genindy2006.gif>

Available Forums
* About the Industry <index.php?f=4>*
Forum Folder

Topics relating to the industry, ranging from game creation through
business.

* Columns <index.php?f=2>*
Forum Folder

Individual discussions for the RPG columns

* Outside RPGnet <index.php?f=82>*
Forum Folder

Forums for discussion of specific things outside RPGnet

* RPGnet <list.php?f=5>*
Posts: *118469* Last Post: *02-01-2006 06:30*

General discussion about the game industry and where it's going,
and other topics RPGnet readers would enjoy discussing.

* Tangency <list.php?f=61>*
Posts: *40163* Last Post: *01-04-2002 19:24*

Soapboxes, Personal stories, Rants and Dialogs. Keep it friendly,
folks!

* The RPGnet Awards <list.php?f=84>*
Posts: *235* Last Post: *05-20-2004 18:07*

Nomination forum for the RPGnet Awards

* Trouble Tickets <list.php?f=57>*
Posts: *741* Last Post: *01-03-2002 19:00*

Please let us know any problems with the site. Missing pages, bad
code, tacky color schemes-- whatever you think is broken. We'll read
this and fix things. Thanks!

------------------------------------------------------------------------

Previous columns

* Elements of Strategy </news+reviews/columns/elements11feb03.html>
by Brian Gleichman, 11feb03
* Rationales for Mechanics (or the Case for Designer's Notes)
</news+reviews/columns/elements14jan03.html> by Brian Gleichman,
14jan03
* Layers of Design </news+reviews/columns/elements11dec02.html> by
Brian Gleichman, 11dec02
* Elements of Tactics </news+reviews/columns/elements01nov02.html>
by Brian Gleichman, 01nov02
* Elements of Complexity
</news+reviews/columns/elements20sep02.html> by Brian Gleichman,
20sep02

Other columns </news+reviews/columns.html> at RPGnet

[ Read FAQ <http://forum.rpg.net/faq.php> | Subscribe to RSS
<http://www.rpg.net/rss.phtml> | Contact Us <mailto:www@rpg.net> |
Advertise with Us <http://www.rpg.net/ads/info.phtml> ]

author	fabien
	Wed, 30 Aug 2006 21:32:44 -0400
branch	ecjdr
changeset 92	bdef1afd1170
permissions	-rw-r--r--