UMEC Forum Index UMEC
United Mining Exploration Commission: A group of friends playing JumpGate-- "a MMORPG that launched smoothly, breaks from fantasy character setting, emphasizes PvP, and is the first persistent world space simulator that nobody talks about." ~Scorch
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

How the game was meant to be played...

Post new topic   Reply to topic    UMEC Forum Index -> News, Reviews & Articles
View previous topic :: View next topic  
Author Message

PostPosted: Thu Jan 16, 2003 5:08 am    Post subject: How the game was meant to be played... Reply with quote

RPGnet column
Brian Gleichman talks about the need for designers to keep journals, not to mention he lays out a pretty darned good description of the guts of the game and how "realistism" versus "gameplay" versus "suspension of disbelief" versus "designer vision" relate to one another.
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...'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".

The Layer of Design
Note the below list is scaled for complexity going from most complex to least.
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.
  1. 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).

  2. 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.

  3. 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.

  4. 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.

  5. 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.

The Compexity of Design
this is taken from another column by the same author, here
Go onto any gaming forum and you'll quickly run into someone making the comment that a certain RPG is "complex." It's not unusual for such a statement to draw replies of disagreement, and it quickly becomes obvious that we have yet another case of people using the same word for very different purposes.

Given how common it is to see the question "How complex is this?", I think it would be useful to explore the term some. Not only might it reduce some misunderstandings, it could even have a direct influence on game design.

I. Complexity of Implementation
This is how difficult the actual mechanical steps are. Let's look at a couple of examples pulled out of the middle of damage resolution:
    muffy translation:
  1. Least compex = RPG combat. (EQ) press "A" to attack and watch game AI take over; issue is simply do i or do i not press "A"
  2. Medium complexity = FlightSim combat (jumpgate) bullet trajectory mapped that deals with player aiming skills to hit target; issue is simply do i hit, not where i hit if i hit.
  3. Highly complex = FlightSim combat (wingcommander) this time actual subsystem damage is taken into account, not simply "hull hits"; issue is both "do i hit" and "where do i hit"
II. Complexity of Mass
Rules may be simple to Implement in every case; however, there may be a large number of very specific cases, each with their own simple rules.
    muffy translation:
  1. Least complex: this would be analogous to all gear with the same size slot would be identical (cookie cutter design. take for instance the rangers and nukes)
  2. Medium Complexity: this would be analogous to jumpgate's current situation -- one item being most optimal and used by everyone, but with lesser items available with slightly less effectiveness.
  3. Highly complex: this would be analogous to JumpGate actually having more than one optimal choice in different categories that were USED. (ie. a new laser that was size2 had more range than the others but less damage (& visa versa for the opposite)...something that wasn't nerfed like those horrible 1500m size1 lasers
III. Complexity of Concept
There are games with few rules, those rules very simple, that are still viewed as complex in the extreme, with uncounted possibilities that take even the greatest of players years to master.

Think Chess.

Mechanically, it's simple to move a pawn. The entire rules for the game can be contained on a few sheets of paper. But which pawn to move? What will the effect be? Those are questions that are far from easy to answer, and the choice can be far from obvious. I refer to these games as Complex in Concept to represent the fact that the difficulty isn't in the "how does one do it," but rather in "what does one do and how much will it affect."

In one sense, all RPGs rate high in this area due to their open-ended nature. Even so, I tend to limit this to those games where the player is presented with a wide number of options under conditions that require a great deal of thought in order to find an optimal choice. Games with complex tactical environments like Heavy Gear top the list here.

Complexity of this type tends to draw players who value the importance of individual decisions in a challenging environment.
    muffy translation: now i think he's just talking out of his arse. The topic is intriguing and i sometimes wonder if Chess is tactical or strategic myself -- WHEN I'M DRUNK! This is a philosophical question to ask. Of course Chess has nothing to bloody do with either and has everything to do with BOTH! The thing is i think this guy's done pretty darned good defining the strategic issues (complexity of mass; purpose) and the tactical issues (complexity of implementation; function), but where he's still murky is how to deal with issues that seem to be either a little of both or a complete lack thereof
    The Hobbit; JRR Tolkien wrote:
    Bilbo Yes, lots. No... I mean no, none at all.
    Tom Well, which is it? Yes or no?
    William Poor little blighter! Let him go.
    Bert Not till he says what he means by 'lots' and 'none at all'. I don't want to have my throat cut in my sleep by some of them 'lots'.
Unfortunately, i don't have a clue either. all i know is that there's a polarity between Tactics and Strategy (not really a dichotomy because they both are simply two sides of a single coin)...expanding that to the "chess" analogy, i believe that there's a separate context that talks about the actual "coin" and the absence of the "coin" -- all still dealing with the same meta-context of 'Complexity of Design'

*ahem* i'll probably need to use crayons at this point for both myself and my readers to follow what i'm blabbing about...
Meta-Concept: 'Complexity of Design'
a) there is no spoon
b) strategy (complexity of mass; purpose)
c) tactics (complexity of implementation; function)
d) both sides of the same coin. (ie. the "coin" itself)

My mission here is to eventually figure out what game element of JG relates to points a & d.
Back to top
Display posts from previous:   
Post new topic   Reply to topic    UMEC Forum Index -> News, Reviews & Articles All times are GMT
Page 1 of 1

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Space Pilot 3K template by Jakob Persson.
Powered by phpBB © 2001 phpBB Group