diff -r 3164c82ac16e -r bdef1afd1170 draft/elements14jan03.txt --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/draft/elements14jan03.txt Wed Aug 30 21:32:44 2006 -0400 @@ -0,0 +1,276 @@ +RPGnet + + + + Reviews Forums +News & Press Columns & +Info RPG Wiki + RPG Shop + + + + 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? + +Go to forum! +RPGnet + + + + Reviews Forums +News & Press Columns & +Info RPG Wiki + RPG Shop + + + Available Forums +* About the Industry * + Forum Folder + + Topics relating to the industry, ranging from game creation through + business. + +* Columns * + Forum Folder + + Individual discussions for the RPG columns + +* Outside RPGnet * + Forum Folder + + Forums for discussion of specific things outside RPGnet + +* RPGnet * + 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 * + Posts: *40163* Last Post: *01-04-2002 19:24* + + Soapboxes, Personal stories, Rants and Dialogs. Keep it friendly, + folks! + +* The RPGnet Awards * + Posts: *235* Last Post: *05-20-2004 18:07* + + Nomination forum for the RPGnet Awards + +* Trouble Tickets * + 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 + by Brian Gleichman, 11feb03 + * Rationales for Mechanics (or the Case for Designer's Notes) + by Brian Gleichman, + 14jan03 + * Layers of Design by + Brian Gleichman, 11dec02 + * Elements of Tactics + by Brian Gleichman, 01nov02 + * Elements of Complexity + by Brian Gleichman, + 20sep02 + + + Other columns at RPGnet + +[ Read FAQ | Subscribe to RSS + | Contact Us | +Advertise with Us ] + +Copyright © 1996-2006 RPGnet & individual authors, All Rights Reserved +RPGnet® is a registered trademark of Skotos Tech Inc., all rights reserved. +