Help files
This is a game design feature. Over the months I will go over a few elements of game design. I am starting from the elements I consider most important and working towards more esoteric elements. The help files will be the first element I will tackle followed by user interface considerations.
Why are help files important?
Help files allow the players to figure out how your game works. It is no good having some super zoopy feature if it is not documented and no one even knows about it. They are one of the first elements of the game that the player will see when they enter the game, and are something that will be looked back on time and time again. For this reason alone time should be invested in the help files to make sure they are good and meaningful.
What makes a good help file?
Several things are important in a good help file, the major one being they must be consistent. If all of your help files look different it will be confusing for the player to find information. As with all things on a mud, and anywhere else, being consistent is an important consideration. Make a standard template for your help files and make all the help files follow this template.
Put your point across clearly and efficiently and don't make your files too dense and messy. It is much harder to read a page full of straight text than it is to read text that is spaced out with useful headings and breaks. This is fairly standard document formatting information, but it applies to help files as well. There is also the danger of putting in too little information. Make sure you describe whatever it is you are describing as if the person reading it has not heard of it before. Describing it in a way that makes sense to you is not always useful, because you already know what you are trying to say.
Cross-referencing is very important and useful; all files should be cross-referenced to things that they are relevant to. Make sure that the things being cross-referenced to actually exist, if it does not exist do not put it in the help file. Nothing is more frustrating than looking for help to find that all the files do not exist.
Other considerations
Some other things to consider when writing a help file system is the possibility of there being more than one piece of help that might be referenced by the same name. The way Unix handles this problem is by dividing up the manual into numbered sections, where each number is a different type of help. In a mud context this is not the most helpful system, as the players need to learn what all the obscure numbers mean. A help system should be helpful not obscure.
I will cover bug reporting in another article but the ability to bug report your help files is a consideration when designing a help system. You will end up some typos and spelling mistakes in your help files, or they will end up being wrong in some ways. You need some method of reporting this and dealing with it.
Make your help files clear and consistent, cross-reference them and don't waffle on too long. These are the important elements in making a good help file. Remember the help files and the title screen are the first things a player will be seeing when they enter a mud, this can definitely colour their opinion on how the mud feels and if they will stay.
