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

[Caliban Tiresias Darklock]

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. ;)

>the main reason I don't talk about my work too much is because I have 
>hundreds of things to implement, most of which I thought up years ago, 
>and only one programmer (me) working on them.  

I have about forty different pieces-parts of a BBS system lurking on my
hard drive, which was a terribly ambitious project. Most of them are more
comment than code, and most are in flat assembly language. The farthest it
ever got was accepting logons and doing some teleconference stuff, but it
has some really impressive bits and pieces in the incomplete message base
system that I never managed to find time to complete. Lately I've been
looking at it and thinking it would probably work really well for a MUD if
I put some work into it, but I doubt anything useful will materialise. So I
know where you're coming from on that... some of these files are internally
dated mid-1989.

>> It's not much of a secret that I tend to prefer text
>> to graphical, based on certain economies of bandwidth and disk which come
>> from that, but I have to admit that when push comes to shove graphical will
>> pull more users. 
>
>This is a non-issue to me.  All functions wherever possible must be 
>executable using either mouse-only or keyboard only.  This just seems 
>intuitively obvious to me.  

Me too... I was just looking at the thought of what the user is looking at
here, not how he interacts with it. 

>Generally the "easy for novices" way of doing 
>a thing (usually, but not always, the mouse interface) should be the 
>easiest to notice (or have shoved in your face by the documentation), 
>while the "power user" interface should be not too hard to find out 
>about, but not "in your face" if you don't desire it and don't go looking 
>for it.


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?

>> To a degree, this can be remedied with natural
>> language processing, like shorthand: 
>
>This, to me, is a false grail.  

Agreed, though an intriguing concept from an AI perspective and something I
see people discuss here and there. 

>Regretably most software developers seem to 
>feel that the solution space is (or should be) "as many different things 
>that are possible to do as I can possible enable the users to do".  

I've occasionally fallen prey to this, since I find that the things which
are the most interesting to code are the things nobody in his right mind
ever looks for. It still traps me now and again, somehow, even when I know
going into it that no one will ever use the feature I code. I wrote a
web-based shopping cart application recently that took relative adjustments
to quantity; if you replaced the '4' in the quantity box with '-1', the
quantity would become '3'. I got a lot of weird looks for that.

>Players not feeling like they're wasting 
>time is a good thing.  Tightly map your interface to what's actually 
>doable.  And try to map what's actually doable to what players will want 
>to do and what will generate large amounts of the mystic quantity known 
>as "fun".

I'm reminded of a BBS door called 'CyberWorld' (I think), which was
basically MUD Lite. (Ooh, a potential new server name.) You could talk and
emote and pick things up and put things down and use things, and that was
more or less it. If you felt like building something, you could create and
describe an object, and put it into another object, which was sort of nifty
in a weird way. Programmable activity for objects was purely limited to
displaying messages. It was a popular hangout for a lot of people, because
you could do weird things like pick up a box, and put it inside itself.
Most of the people who hung out there proved to be programmers or wannabe
programmers. Unfortunately, it started to eat disk space like mad (once you
put a box inside itself, it was forever lost and just dead DB space) and I
had to get rid of it. But other things like 'Murder Mansion' 


>learning is an ongoing, dynamic process, and the help a users 
>wants/needs in their first hour of using your product is very different 
>from what they need in their second day, which is different from what 
>they need after three months.  But pressing F1 for help in any Windows 
>app is likely to pop up the exact SAME help menu with the same sub-menus 
>and documents every time, forever.  

Ouch... you know, I've noticed this and been frustrated by it more times
than I can count, and it never ONCE occurred to me to seek some sort of
reasonable solution? I think I just learned the meaning of "At that moment,
he was enlightened." ;)

>you have "Beekin the Help Dragon" pop up and 
>suggest "Say, now that you've gotten this far in the game, I think you 
>might want to learn how to be told automatically when your friends are in 
>the game.  Click [Here] to find out or [Here] if you're not interested."

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?

>It's because people learn how to do all the basic things in life from 

>other people.  That's what people are used to, what they want, and what 
>they're conditioned to do to seek out knowledge when they perceive that 
>they're missing something.  

Another whack on the side of the head. I feel really stupid now.

>The ideal help interface to me is a big button that says "help", and when 
>you press it a dialog pops up that says "Do you want to A) ask for help 
>from another user, or B) browse through the game documentation?"  

I like this concept... you know, what strikes me at this point is that I'm
not sure I can add much of anything to the discussion. I'm learning a lot
more than I feel able to meaningfully contribute. I hate that. But I'll try
anyway.

A corollary to this is that people generally like to be respected and
considered knowledgeable. So not only do the majority of people like to be
helped by a person, but they like to HELP people, too. 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. 

Several MUDs provide an avenue for people to join the staff after a long
period of devotion and scrutiny, but many of us feel like we don't have
appropriate opportunities to distinguish ourselves as potential staff,
since it certainly looks like the criteria mandate 'applicant must be
someone the existing staff like to hang out with'. (I'm reminded of the
Dilbert cartoon where Alice reads a position announcement that says
'Qualifications: The applicant must be an overweight guy named Bob with
glasses and a beard' and notes 'I think they may have someone specific in
mind.') Opportunities like the above would provide ways for people that
want to staff on a MUD (but *don't* want to start their own) to be
recognised. 

I'm still thinking a lot about how I'd remedy the help file thing, so I'm
not too useful for innovation at the moment. I'll make some other
observations tomorrow. ;)


--
MUD-Dev: Advancing an unrealised future.