[MUD-Dev] How much is enough? Communication design

[Ron Gabbard]

From: "Sasha Hart" <Sasha.Hart at directory.reed.edu>
> [Justin Coleman]

>> There will always be a condition of "more is better", I think,
>> but I'm attempting to find a way to turn these players back from
>> the dark side of number crunching, and back into enjoying the
>> game for other reasons.

> Instead of hiding the values per se, might I suggest having fewer
> values (for a shorter ladder) and fewer or no ways to move between
> them. Obviously shoots a GoP game in the foot but may be a way
> around these problems which quantizing fine grained values into
> "terrible ,bad, okay, good, very good" may not.

Hehe, I like the 'range' idea a lot.  However, the target audience
you are trying to frustrate with this mechanism is the
powergamer... and they will not be denied!  How long do you think it
would be before people took a bag full of 'very good' weapons out to
the field and started running tests and posting the results to the
fan sites?  Quantitative values for items would probably be
well-known and posted before the game went Gold (assuming no
conflict with the non-disclosure).  This increases the 'power' gulf
between the powergamer that dissects the fan sites and the casual
gamer whose primary experience is in-game.

Let's maintain the assumption that the goal of a game designer is to
entertain the widest variety of player-types possible with all types
of backgrounds while giving the player the information and feedback
necessary for them to 'succeed'.  (SWG is going to face this issue
more than any MUD/MMO in history due to the fact that, well, it's
Star Wars and is going to draw tons of true noobs to the genre. The
post mortem on SWG should be interesting.)  Information has to be
presented in such a way that it doesn't overwhelm the player who is
just learning about different chat channels and how to pick up
items, while not being so shallow that the core gamers burn through
the content in 15 seconds.  One way of doing this is to treat the
software like you would any other document or communication.

I had the opportunity to take a course in Communications while
working on my MBA.  The professor, Craig Snow, taught a great model
for communication design that I've followed to this day.  He called
it PRIOS-CDT.  ( I highly recommend taking this guy's class/seminar
if you ever get the chance.  Last I heard he was teaching at Case
Western.)

  P - Purpose: What is the communication trying to accomplish?

  R - Receivers: Who are the target audiences (and possible
  secondary/tercery audiences) for this communication?

  I - Information: What are you trying to tell the audience(s)?

  O - Organization: How should the elements of the communication be
  ordered?

  S - Style: Should the communication be formal, informal,
  technical, legal, etc.?

  C - Channel Choice: What is the best medium for this
  communication, i.e., email, snail mail, voice mail, etc?

  D - Document Design: How should the document be structured to
  allow for the greatest level of readability?

  T - Timing: When should the communication be delivered?

Looking at these facets from a game development aspect...

  Purpose -- Is the goal to direct the player to the next step in a
  quest?  inform the player they need to reload their empty weapon? 
  inform them what the widget they're holding in their hands is?  or
  inform the player of the level of Internet latency?

  Receivers -- What level of expertise does the receiver bring into
  the game (affecting vocabularly and other cues that may seem
  obvious to core gamers)?  Is the receiver deaf or color blind?
  How much time is the receiver likely to spend on the
  communication?

  Information -- What are the critical elements of the communication
  that must be translated to the receiver?  What information
  'fleshes out' the critical elements?  How critical is this
  information overall?

  Organization -- If a piece of information is critical, don't bury
  it in 3 pages of NPC chatter or have the 'gun empty' click be so
  muted it is easily lost in the overwhelming 'battle music'.  Is an
  NPC shopkeep's inventory arranged by 'level' or by 'type' or
  random?

  Style -- Is the information best communicated in-character or OOC? 
  If OOC, should the communication be formal (as in the case of
  billing and serious customer service issues) or casual?

  Channel -- Should the information be given through text or audio
  or both?  Should the information be presented in its own window
  (as in AO's item and player descriptions), through an existing
  text window, and/or through a completely separate medium (such as
  the DAoC quest journal)?  Is the information permanent or
  transitory, i.e., does the player receive a 'letter' with
  instructions in their inventory or only a couple lines in their
  chat window that are soon gone.

  Document Design -- How should the information be laid out to most
  efficiently achieve the purpose?  What [mechanisms] can be used to
  hi-lite important information?  Is there a standard structure (as
  in the case of most item attribute descriptions) that present the
  information in a format to which the player has become accustomed? 
  Can 'skim value' be increased to allow the hurried gamer to get
  the critical information without having to read four pages on the
  history of MUDland?

  Timing -- When should the player be informed of their 'ammo'
  status?  Should the communication constantly present the amount of
  ammo in the gun?  Provide the OUT OF AMMO text/audio cues only
  after the gun is empty and has failed to fire one round? and/or be
  user-determined where the player can know the amount of ammo in
  the equipped gun by hitting a button?  Also, does the NPC give the
  quest information only once and then will only inquire 'Where's my
  widget?' in future conversations or will the NPC repeat the cues
  in case the player missed it the first time?

While it's a lot of work analyzing every communication element in
this format, it allows for the transfer of critical information to
the broadest audience while allowing the audience to 'read' what
they want/need and ignore the rest.  There really is no such thing
as too much information (in my opinion)... just poorly designed
communication.

Cheers,

Ron



_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev