<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar -->
<!--X-From-R13: "Re. Qng" <pngNotn.pbz> -->
<!--X-Date: Fri, 1 May 1998 00:38:27 -0700 -->
<!--X-Message-Id: 199805010737.CAA25387#zoom,bga.com -->
<!--X-Content-Type: text -->
<!--X-Reference: 199805010411.AAA14739#relay,mnsinc.com -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:cat#bga,com">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00294.html">Previous</a>
| <a href="msg00296.html">Next</a>
]
Thread:
[ <a href="msg00292.html">Previous</a>
| <a href="msg00300.html">Next</a>
]
Index:
[ <A HREF="author.html#00295">Author</A>
| <A HREF="#00295">Date</A>
| <A HREF="thread.html#00295">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Subject</em>: [MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar</LI>
<LI><em>From</em>: "Dr. Cat" <<A HREF="mailto:cat#bga,com">cat#bga,com</A>></LI>
<LI><em>Date</em>: Fri, 1 May 1998 02:37:24 -0500 (CDT)</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Sender</em>: "Petidomo List Agent -- Kanga.Nu version" <<A HREF="mailto:petidomo#kanga,nu">petidomo#kanga,nu</A>></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
> On 12:12 PM 4/30/98 -0500, I personally witnessed Dr. Cat jumping up to say:
> >
> >Well, I don't know if many people do, given the "not much interest" you
> >cite from prior attempts.
>
> I've always suspected it was because nobody knew who I was and therefore
> couldn't take me seriously, but I also had this nagging feeling that I
> wasn't giving people enough credit. ;)
Occam's Razor still says to me "hey, if not many people are acting
interested, probably not many people here ARE interested". Just a hunch.
> How do you feel about 'modes' of operation, like a novice/expert toggle? I
> always detested them, myself, since it always seemed like neither of them
> ever quite fit the way I interacted with the game. Have you ever seen one
> done well?
I feel a strong need as a designer to have novice/expert toggles some
places, maybe three levels other places. For the one specific
instance of the DragonSpeak editor (that's the scripting language) I
could easily envision 5 or 6 levels, but that's something of a special case.
I have seen very few of these types of things, and I don't know whether
one exists out there that I'd feel to be "done well". I really don't
know that I have enough experience with the prior art to comment
meaningfully on what's been done before in this area.
Generally I think this sort of thing is most appropriate where you are
targeting (as with Furcadia) a very broad audience, and the more narrowly
targeted your game is, the more likely it is that a single interface for
everybody is appropriate. Indeed, I think multi-modes is something of a
special case that's only appropriate for mass media. If you have
millions of players, catering to a niche could still cover a pretty large
group of people. If you have ten players... Hey maybe some of them have
radically different tastes in interface than the others... I say tough,
let 'em live with it!
Regardless of whether you provide one interface "mode" or several, you
should make the game client as customizable as you can get away with,
while maintaining consistency with your other goals (which may or may not
require things like fixes window sizes and positions rather than
configurable ones - it just depends on what the goals are). There should
be template files that store all the configurable options about
appearance, layout, keyboard definitions, etc. And you should default to
a template that's reasonably comfortable to use, but provide several
others with descriptions of what they're good for (good for Laptops with
no numberic keypad - good for maximizing text chat space - good for
keeping all combat-related functions quickly and easily accessible, etc.)
Let players make their own templates and share them with each other.
Basically, most people at this stage in evolution are stuck being
monoperspectivists, which means that for any issue, they feel, act, and
think like there's only one attitude that people have (or should have,
anyway) about that issue. Of course the fact of the matter is, if you
have 1000 people, on any particular issue they're likely to have at LEAST
2 different opinions, preferences, etc. Possibly 3 or more. Sometimes,
239. And occasionally 1008.
One step up from the monoperspectivist is the person who knows
intellectually that other perspectives exist on issues, in the minds of
other people - but still can't grasp what it feels like to have that
different perspective, can't understand why anyone would think that, just
can't grok that other viewpoint. And it makes their head hurt to try to
think about it too much. So they end up designing and coding interfaces
(and game designs, etc.) the same way a monoperspectivist would. Which
is generally to code things exclusively to cater to "people with tastes
like me".
Well that works ok if you're a person who has tastes that match a lot of
other people's tastes reasonably well. (Or if you match only a modest
number, but you don't really care whether many people play your game or
not anyway.)
But I try to take one step past that. For broadest appeal, I try to
evaluate every interface decision by estimating the diversity of tastes
on that issue. If it's 99% option A, and 1% option B, you can probably
hardcode option A into your game - unless you have resources to spare and
can be a purrfectionist! If it's 92% A, and 8% B, that might be a good
candidate for saying "The game defaults to A, a pulldown menu option or a
checkbox in an 'options' dialog allows the selection of B." The idea is
to keep the knowledge that it's even possible to switch to option B from
bothering the 92% of the players who, most of them, don't even want to
know that. Out of sight, out of mind. Then you decide whether the game
stores the setting, so people that pick option B will get it again on
their next gaming session, or whether it always starts up in A and makes
you switch. This depends on the nature of the option, the reasons for
wanting to switch it, and the nature of the people in that 8% group.
(This scenario is an oversimplification, too - you might get 85% "always
A" people, 6% "always B" people, and 9% "use both sometimes, switch
depending on which I want/need at the moment". In that case, the reasons
and behavior patterns of the switchers play a significant role in
determining whether to make the switches persist to the next session or not.)
If you get a case where tastes are something like 70% A and 30% B, things
start to get a little more interesting. Here you may well want to make
the choice "in your face", so everyone knows that both A and B are available.
The penalty of not doing so, that as many as 30% of the players may fail
to choose the option that would make the game most enjoyable for them, is
getting pretty steep at this point. Exactly how you do this depends on
various details. Is it something people would want to switch back and
forth a lot? Button on the main game display, always visible. Is it
something where they probably want to pick the best choice of their tastes,
and then leave it that way forever? Several criteria. If it has a major
impact on how much people enjoy the game, you may want to make it a
one-time configuration question during setup, the first time they play
the game. Display very clear, well written text (and illustrations too
if appropriate) to make sure they understand the choice, force them to
say yes or no, and make the default button that's selected if they just
press Enter option A, since A is the 70% choice. Couple this with the
obscure pull-down menu or options dialog choice to change it later. This
works well for something people are fairly certain to A) know what they
really want in regards to, and B) accurately select that. If it's
something they might look at and go "gee I don't realy know what I'd
prefer in that regard, I was never offered such a choice in any previous
life-experience and haven't played this type of game before either", you
might consider sticking with the always visible toggle button. Or doing
the configuation step, but forcing a "did that work out for you or do you
want to switch from A to B right now" dialog to appear a couple days
later, for the people who will never hunt through pull-down menus and
options dialogs. Or you might want to strongly encourage older players
of the game to help newer players out with this decision, in some way.
If you have a 70/30 split on a question that's of more minor impact to
game enjoyment, you can do things like pop up a dialog two weeks after
they've been around and say "Now that you're more experienced you may
wish to refine you game settings to increase your conveniene and
enjoyment. Would you like A or B?" The real brilliance will come in
spacing these messages and dialogs out appropriately, even coming up with
complex triggering conditions based on user behavior rather than just time.
> This sounds a little like the MS Office Assistant. In my experience, most
> people seem to hate it. I for one like it, but not because of the help... I
> like that the little paperclip dances around and acts suave and
> sophisticated in the corner of the screen. In other words, I like the
> degree of levity it introduces to the process of boring memo writing. When
> it pops up help messages, I tend to be a little irritated. Are you familiar
> with this feature of MS Office, and if so, what's your immediate impression
> of it?
The danger with time based unsolicited offers of assistance is that
you're being an immense pest. I in fact spent one session running a
program last year that had the dancing paperclip. I found it amusing,
but think it rapidly would have become annoying had I used the program
regularly. The vast majority of designers/programmers seem to put these
things in so they happen WAY too often. You should be interrupted
seldom, and generally only for the things that are mostly likely to add
to the experience for you, rather than making you frown and say "The
choice between A and B is irrelevant, that's trivial and I would enjoy
the game equally either way and besides it's asking me how to fine tune
the interface to one of the game features that I NEVER USE ANYWAY! Go
away and get lost!"
Frankly it's not like we HAVE to be operating in the blind, with regard
to online applications. They connect to our servers all the time, we
could be having them tell us millions of little details about user
behavior, all the way down to how many inches per hour do they roll their
mouseball around on the little rubber mat? We could be, but we're not.
I ran a roundtable at the 1997 CGDC (being a believer in not obscuring my
meaning with jargon unknown to a significant percentage of the audience,
I'll clarify that that stands for Computer Game Developer's Conference)
on the subject of gathering player and activity data in online games, and
I got the lowest attendance of any roundtable I ever moderated. (Sex in
Computer Entertainment was highest for some reason - go figure! Though
when I ran the first roundtable on MUDs at the conference turnout was
also pretty good).
I think most of the development community isn't quite ready to get this
sophisticated yet.
Consider, though. Let's say 70% of our users will want to have the left
mouse button activate the flomgisticulator. And 30% of them would enjoy
the game much more if the left mouse button defaults to turning on the
phlogamzitronic shields. But let's assume further that most of our users
will have NO clue which of these things they'd prefer while they're
reading the opening text or going through the setup screens - they'll
need to play the game for days or weeks before they know it well enough
to make that choice. (Indeed, it takes 2-5 hours of play before the user
even finds out what a flomgisticulator is!)
So let's say we want Beekin the Help Dragon (who has somehow wandered out
of Furcadia and found his way into the weird science fiction game of this
example in some incomprehensible fashion) to pop up after an "appropriate
period". Problem is, we have NO idea what an appropriate period is,
because we have ZERO prior experiene with how long it takes players to
learn this game, which we only finished and released to the net five
minutes ago!
Data Collection Man to the rescue! Let's say we put that option in the
pulldown menu, the options box, or maybe even the "so obvious you can't
miss it" big button on the screen. Let people play. Record all the
times anyone changes that option setting... Now analyze that data!
We might want to look at when they make a LASTING change to the setting.
If they switch it back and forth a bit, maybe they went and fiddled with
it when they didn't reeeeeally know the game well enough to pick what
they would want. If they put it on setting B and leave it there for six
months, you can probably assume at the moment in time when they set it
they probably had some idea what they wanted. (Though there's always the
few oddball exceptions.)
Let's say 99% of the users are going and making their final, permanent
choice on their 17th day of play. Simple! We could have Beekin pop up
on day 17 and offer them the choice. But let's say the choice was buried
in a deep obscure settings dialog, and we think the average person might
be finding that a week later than they really woulda been ready for it,
just because it's in such an obscure spot. But that "one week" is a seat
of the pants guess, not something we've measured! No problem. Set
Beekin for ten days, have him ask "pick A now", "pick B now", "ask me
again in a few days", or "Go away Beekin, I'm smart enough to know that
it's under the Fleeble menu option if I need it". Now measure the
frequency of the different responses with Beekin set at 10 days! You can
very easily determine if Beekin is asking too early, by tracking how
people respond. If you ARE to soon, bump him back a few days and measure
again. (You DID keep your Beekin settings controlled on the server end,
rather than making it so people would need a new client to change those
intervals, RIGHT?)
Let's say we DON'T have 99% of the users all making the choice in the
same brief window. Let's say there's a big standard deviation on the
distribution, the day people choose their setting varies from day 10 to
day 42. Now we don't want to just split the difference and ask on day
26. Some people aren't asked until way later than they would have been
ready to answer and start enjoying the game yet. Other people would be
asked way before they're ready.
Let's presume "readiness to be asked this" relates to proficiency in some
particular areas of the game. Let's theorize that some other measurable
factors also relate to proficiency in those same areas. If we can find
one or more of those, maybe we can make a good personalized guess about
when to have Beekin ask you. Let's say we measure the number of times
per day you use the flomgisticulator, the number of times per minute you
click any mouse button anywhere on the game screen, and a dozen other
factors. Calculate correlation indexes to determine which of them have a
strong correlation between them and whether or not the player's made his
final choice of setting or not. Maybe it turns out that most people that
click more than 6.2 times per minute have made the choice, and most
people that click less than that haven't, and that clicks per minute
tends to rise over the first few weeks as people learn the game. Ok,
bingo, pop up Beekin's dialog box when they cross 6.2 clicks per minute.
If there's a good correlation between flomgisticulator uses per day also,
maybe you can improve your odds of making a good call by factoring that
value in too, and weighting the two criteria.
> Bringing into this
> the idea of pop-up help, after a person reaches some particular milestone
> you might want to pop up a request that they join the newbie helper team. A
> lot more people would treat that as an honor instead of a duty, as opposed
> to requesting that people specifically volunteer to join the team without
> prompting. You might ask at two or three different milestones, if they
> don't 'jine up', to see if they've had a change of heart.
I have grave doubts that good criteria can ever be found for automated
determination of good candidates. You could measure something like
percentage of time spent talking while in hearing range of one or more
newbies (players with less than N hours of playing time logged). But
this would catch a professional newbie-taunter as readily as a dedicated
newbie helper. It wouldn't distinguish a really good newbie helper from
a well-meaning but bumbling one. And it'd scoop up some people in the
net who just happen to hang around the starting areas a lot with their
friends, and don't happen to have much of any interest in newbies at all.
Besides, an invitation from a robot doesn't convey a fraction of the
surge of warmth through your body that you feel when being invited to an
honored post by a real person, especially a person of rank and signifiance.
One of our first four assistants told me he was all misty-eyed when I
told him how helpful he was and how he was practically the ideal example
of how we'd like people to be in our game.
The key to things like this is developing heirarchies, so that when you
have 100 times as many players you don't have a few staffers scrambling
to talk to thousands of people a day to keep up with this stuff.
Climbing up through the heirarchies and growing in social status becomes
the major focus of the game for some people. We're seriously considering
making it a major focus for most people. That and getting attention
(number of player-hours spent on your maps and stuff), which is the basis
of the currency system. The more diversion you're providing for your
fellow players, the more spending money you'll have.
Attention IS the currency of the future.
*-------------------------------------------**-----------------------------*
Dr. Cat / Dragon's Eye Productions || Free alpha test:
*-------------------------------------------** <A HREF="http://www.bga.com/furcadia">http://www.bga.com/furcadia</A>
Furcadia - a new graphic mud for PCs! || Let your imagination soar!
*-------------------------------------------**-----------------------------*
--
MUD-Dev: Advancing an unrealised future.
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<ul compact><li><strong>Follow-Ups</strong>:
<ul>
<li><strong><A NAME="00300" HREF="msg00300.html">[MUD-Dev] OT: CGDC</A></strong>
<ul compact><li><em>From:</em> Adam Wiggins <adam#angel,com></li></ul>
</UL></LI></UL>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00292" HREF="msg00292.html">[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar</A></STRONG>
<UL><LI><EM>From:</EM> Caliban Tiresias Darklock <caliban#darklock,com></LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00294.html">[MUD-Dev] Re: PK's: A solution?</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00296.html">[MUD-Dev] Re: atomic functions</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00292.html">[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00300.html">[MUD-Dev] OT: CGDC</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00295"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00295"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar</STRONG>, <EM>(continued)</EM>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<LI><strong><A NAME="00279" HREF="msg00279.html">[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar</A></strong>,
s001gmu <a href="mailto:s001gmu#nova,wright.edu">s001gmu#nova,wright.edu</a>, Thu 30 Apr 1998, 20:53 GMT
<UL>
<LI><strong><A NAME="00287" HREF="msg00287.html">[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar</A></strong>,
Dr. Cat <a href="mailto:cat#bga,com">cat#bga,com</a>, Thu 30 Apr 1998, 23:23 GMT
<UL>
<LI><strong><A NAME="00407" HREF="msg00407.html">[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Tue 05 May 1998, 18:21 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
<LI><strong><A NAME="00292" HREF="msg00292.html">[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar</A></strong>,
Caliban Tiresias Darklock <a href="mailto:caliban#darklock,com">caliban#darklock,com</a>, Fri 01 May 1998, 04:12 GMT
<UL>
<LI><strong><A NAME="00295" HREF="msg00295.html">[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar</A></strong>,
Dr. Cat <a href="mailto:cat#bga,com">cat#bga,com</a>, Fri 01 May 1998, 07:38 GMT
<UL>
<LI><strong><A NAME="00300" HREF="msg00300.html">[MUD-Dev] OT: CGDC</A></strong>,
Adam Wiggins <a href="mailto:adam#angel,com">adam#angel,com</a>, Fri 01 May 1998, 18:43 GMT
<UL>
<LI><strong><A NAME="00343" HREF="msg00343.html">[MUD-Dev] Re: OT: CGDC</A></strong>,
Mike Sellers <a href="mailto:mike#bignetwork,com">mike#bignetwork,com</a>, Sun 03 May 1998, 14:32 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
<LI><strong><A NAME="00419" HREF="msg00419.html">[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Wed 06 May 1998, 17:04 GMT
</LI>
</UL>
</LI>
</ul>
</ul>
<LI><strong><A NAME="00311" HREF="msg00311.html">[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar Crossfire MUD</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Sat 02 May 1998, 00:31 GMT
</LI>
</ul>
</ul>
</ul>
</ul>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>
