[MUD-Dev] How much is enough? Communication design
rgabbard at swbell.net
Fri Apr 26 09:55:56 New Zealand Standard Time 2002
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
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
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
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
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
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
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev