Help files, and help systems

[Rudha]

Hi,

I've been giving some thought lately to the help system, which, I think, is something some MUDs don't give a lot of thought to at all. I think one of the more important things for new players is to have a help system they can fall back on easily to explain game concepts to them.

But that, for me, is the thing that I end up wondering about: designing a help system that is intuitive and helpful.

The MUDs Ive played and administered before going out on my own foray with EB have either had very terse and usually unhelpful helpfiles that generally give the syntax and little more, or excessively detailed helpfiles that makes it difficult to locate certain pieces of information.

For that matter, I wonder if a HELP system is the only way to go about it, as well. Not to say Id be tossing my HELP system out, its far too expected to not have, but I have to wonder if someone has a better way of doing it.

Thoughts?

Maya/Rudha

[KaVir]

I thought I'd written up some stuff on help files, but I can't seem to find it. Anyway, here are some of the things I've found useful:

Accuracy: Many muds allow their help files to get out of date - in fact this is such a common problem that I've found a lot of newbies will ignore help files and simply ask their questions over public channels. Responding with "see help X, paragraph Y, line Z" a few times tends to get them into the habit of checking first, and it saves you having to answer the same questions over and over.

Clarity: I often find myself rephrasing older help files to make them less ambiguous and more concise, or elaborating on things that players don't really understand. It's important to work with the players on this, because as developers we have an innate understanding of our own mechanics, and we may overlook things that we take for granted.

Presentation: I make sure help files are formatted to be readable on an 80 character width terminal, and make careful use of colour to draw attention to certain things. I also fix typos whenever they're reported - we're running text-based games, so players tend to be pretty judgemental about poorly presented text.

Consistency: I try to keep a consistent format throughout my help files - commands always list the syntax at the top, for example, while spells have a standard section listing details such as requirements, casting time, mana cost, etc, and suggestions for further reading are always listed at the bottom. This gives the documentation a more uniform feel, and allows players to quickly scan for important information once they get used to the layout.

MXP: I've not really played with this much (yet), but for some help files I've provided MXP links, so that you can click from one help file to another with your mouse, or click the activation command directly from within the help file.

Dynamic: Just as you can have dynamic descriptions, so you can use the same system for help files. Often my usage is quite subtle, such as colouring requirements in an ability or spell help file to indicate whether or not you fulfill them. Other times I explicitly mention things about the viewer, such as the 'mccp' help file mentioning their client by name and stating if it supports MCCP, or the 'emote' command using the viewer's name in its examples. Occasionally I find it easier to provide multiple help files, for example 'help build' gives advice specific to your class.

Soundex: Players will often misspell a help file. A soundex parser can be used to offer them similar sounding suggestions - and combined with MXP, these can also be offered as clickable links.

Search: This isn't something I've implemented personally, but I've seen it on other muds, and it can be pretty useful at times. The ability to search through every help file for specific text can make it much easier to locate information you want.

Website: Some players prefer to browse through help files on the website. This seems to be particularly the case for blind players, as they can take their time without worrying about a flood of messages.

Wiki: Wikis are becoming increasingly popular, and they make it easy for players to update and elaborate on the help files for you, which frees up time you can spend on other things.

[Rudha]

Something I'd like to do, but Im not sure entirely how to implement in python, is something like to search partial matches. Code implementation we can discuss elsewhere I suppose, but I wonder how helpful it would be for the trouble.

To elaborate what I mean...

For example, a lot of MUDs shorten the "emote" command to "em", so say that they go HELP EM, Im thinking of it going "Did you mean: HELP EMOTE" kind of like how Google will suggest the search.

My problem with this is how to approach it when there are several similar things it may match. Ie, HELP STA. "Did you mean HELP STAY, HELP STAB, HELP STAMINA?" I suppose in the majority of cases it would alright just to list the matches, but I forsee problems if, for example, they go HELP E, which I wouldnt want it matching to every E help file out there. And then, how do you determine the most likely matches to include if you want to limit it the number of matches?

This soundex concept sounds related, but I'm not sure what you mean precisely.

Regarding dynamic help files, that's entirely possible if I extend my dynamic descriptions code a bit, and making it clear what requirements a player fulfills, or if they do or do not have the relevant skills. So that's a pretty good idea I could easily implement.

As to MXP, its helpful, but I don't want to rely on it too much, because not everyone is going to have it.

The usability of the MUD is important to me, and obviously the most important thing to make sure is very usable and accessible is the HELP system, in my opinion.

[KaVir]

[Rudha]

Brief off-topic tangeant: Rudha is gaelic incidentally. ("Red-haired". My first character was red-haired and I was having trouble with original names, and it kind of stuck from there)

Back on-topic: That could be useful, though I've never done something quite like that so I'd have to look through the implementation details to see how tricky it'd be.

One thing I'm struggling with as I'm writing some help files now since I hit a wall with a code, is finding a balance between presenting things clear and concisely, whilst including all the relevant information. There really is a fine balance between those two, I think.

Maya/Rudha

[Tonitrus]

Apologies if this is off-topic, but the topic does say "help systems" also.

On God Wars II, KaVir implemented a "what" command that tries to suggest things a character might want to do. Sort of a "what do I do now?" command. You could type the command for suggestions about what you might want to do next. I used it as a reminder for things I'd overlooked.

At any rate, I thought the "what" command had a lot of potential, and muds tend to already have "who" and "where", so I thought a "what" and "how" might be appropriate. "what" to suggest things that could be done, and "how" for expounding on how tasks are accomplished. It's pretty natural to start with question words when thinking up a question, so it seems natural to me to favor question words over a less intuitive "help" command. My own thoughts on the subject consisted of trying to find a way to guess at possible questions a person may be asking (either arbitrarily or through some imitation of natural language processing) and provide appropriate feedback, logging failures, and using the failures to generate more possible questions that can be asked.

This idea is still in its infancy, as I've done nothing with it since thinking it up, and I don't know how useful it'd actually be in practice, but it always struck me as something that deserves more thought.

[Rudha]

I had actually thought of a related kind of thing, but not in the same context. I was thinking I would let novice players (or, I suppose, lazy seasoned players) use WHEREIS <place> to find a path to a common location such as a major city, if they had some survival skill (which they can choose not to have, but it gets heavily recommended in the introduction).

Maya/Rudha

[KaVir]

[Deadsoul]

ive been trying to pulse help files through damage statements in order to relay real time help functioning. haven't had much luck with it yet, but, since the help file parses through the character, it tries to show the character what they are capable of. generally this only works through the spell and ability database, and uses all of its own database data, so I figured why not the same statements too.

[Rudha]

[Tyche]

I'd put the help file system on something like a wiki and let anyone, staff or player, maintain it or expand it. Of course this assumes it's stored so the mud server can also access it in game. If you allow categories or tags to be created and attached to the help entries you can abbreviate the search space of getting help on the help system. Of course soundex and regular expression searches are a plus too.

[Rudha]

The problem with that is that there exist bots and other malicious things out there that basically exist to vandalise wikis with adverts etc, as I discovered trying to set up a wiki for another project. That would be less of a problem if I had the resources to look after it and properly maintain it, but I really have enough on my plate at the moment trying to build a MUD essentially from scratch

Some method of categorisation would probably help quite a bit, though, I agree; both on the server end by reducing the strain of searches on the mud server, by reducing their necessary scope, and for the player by (hopefully) giving them a narrower, more precise field of results.

The thing that I do need to do in regards to that, is disentangle the keywords and the name of the help file from one another. In NakedMud you don't have a uid or a name for a helpfile, just a list of keywords that match, and that can be somewhat problematic.



I've been pondering the possibility of letting players annotate the existing help files and that being available somehow, but Im not sure how precisely would be the best way to go about that.

Maya/Rudha

[KaVir]

You could avoid most of the spambots by having each wiki account created when a player creates a character - no generic wiki spambot is going to connect to your mud and create a character first. You might still get mudders specifically targeting your mud, perhaps disgruntled players or rivals, but those are far less common. If they do become a problem, you could further limit the wiki accounts to characters of certain levels, or even just make it invite-only.

My concern with using the wiki entries for in-game help files is that they could easily become very extensive - I prefer to keep my help files concise. However you could probably achieve that by having a summary section for each wiki entry (perhaps using a template or something similar?). Then players could view the basic help file, and if they want more information they could expand it to reveal the full entry.

[Rudha]

One thing I've been considering is having the help system hook in to the wordpress system I have currently running the elvenblade.ca site. I could have it take only the page excerpt, and I could make a custom field for the help file for player annotations.

I'm very leery about having players able to edit the content which would be displayed in-game, as I don't have much faith in people not abusing that to their advantage, but I do think some sort of annotations could be helpful for players to note things I may have missed in the help file, or perhaps tertiary information, for example "You can also use skill X with skill Y."

I've been thinking a lot on integrating the website and the MUD together. As is, most MUD websites that have that kind of extensive information either have to edit both help files, and the website, when something is changed, or have one or the other fall out of date; many mud websites suffer from being pretty out of date for their own mud. If I can edit both the site and the help file at the same time, that would be brilliant.

Another thing I've been considering, which is with the same aim as help files but not directly related, is how to best make the actual command interface as intuitive as possible. I'm not sure how to do that best, but I want to make it so that, as much as possible, the commands people think of to do certain things, are going to do what people expect them to do.

Maya/Rudha

[KaVir]

I've been putting more effort into my help file system recently, and have introduced a few new options that seem to be working out quite well.

The first change I made was to implement Tonitrus's suggestion of logging failed help requests, and it's proved surprisingly enlightening - I've already made quite a few additions based on pretty reasonable help requests that I hadn't considered before.

The second change is an automatic search through all the help files if no match is found, and I've found that this really complements the soundex parser - the soundex catches typos and incomplete help requests, while the search picks up references in other help files, so between them they have a very good chance of pointing the player in the right direction. For example: