[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar

[Dr. Cat]

> 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:
*-------------------------------------------**  http://www.bga.com/furcadia
  Furcadia - a new graphic mud for PCs!     ||  Let your imagination soar!
*-------------------------------------------**-----------------------------*

--
MUD-Dev: Advancing an unrealised future.