[MUD-Dev] Convincing Players to Read Documentation

[Bruce]

Jon Morrow wrote:
> The question is, "How do we convince players to read the
> documentation?"  Honestly, I don't know.  I make references
> to my help system several times throughout our guided
> tutorials in hopes of players following through them.
> But I don't feel this is sufficient.  Does anyone have
> other ideas?

Why is that the question?

Documentation is a solution to a problem.  I would not consider
it safe to assume that documentation is the complete solution to
that problem, but would prefer to realize that it is a larger
problem with a suite of solutions, of which documentation is just
a single solution, although an important one.

I think that the real question is something more like: 

 * How do we get users to learn the game?
 * How do we get users to learn the game before losing
   interest?
 * How do we get users to continue learning about the
   game after they've played for a while?
 * How do we keep the users up to date as things 
   change within the game?

Well, that's really just the start of a set of questions, but I
think it works for now.  This calls for a suite of solutions
working together in concert to solve the larger problem.

Part of the answer to this is "Write documentation!" but I don't
feel that the matter of documentation can be adequately addressed
without a more complete understanding of the larger problem and
the environment within which that problem exists.

Some other possible approaches:
 * Trainers - do they work? do they drive players away?
   why?
 * FAQs
 * Command parser hinting - In ColdCore, there was a set of
   commands which shared the name with counterparts to ColdCore
   commands on other systems.  When the user entered a 'foreign'
   command, the system would inform the user of the appropriate
   command string to use for that system, leveraging and building
   from their knowledge gained on other games.  It could even
   have gone and executed the other command, translating
   with a warning or silently.
 * Design: Does something need to be so obtuse?
 * Consistency: If the commands follow similar patterns, they
   are easier to guess and to learn.
 * Make them evident: Make things more evident from the output
   presented by the game.  Don't make the user play the guessing
   game as to what they can and can not interact with.

Something that I don't think most systems do is maintain a good
set of metrics.  What bad commands are often typed?  Which by new
users?  Which by intermediate users?  What strings are most often
looked for in the help system?  If your help system is
hyper-linked, what links are followed?  Are there typical
patterns in help searches?  Could those patterns be analyzed to
make the help system easier to use by placing the later data in
an easier place to locate it?

I'm leaving out major points, but I think that this gets my point
across.

Thoughts?

 - Bruce



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