28 Sep, 2012, Sargonas wrote in the 1st comment:
Votes: 0
I have been tackling the task of updating our muds helpfiles and it seems daunting to say the least. I was considering a new system that would work sort of like a 'wiki' , where the help system entries are editable by all players, or maybe a subset of the higher level players.

The initial standard helpfiles would still exist, such as 'help fireball' would give you the spell and its description. But then players can add more information they've been able to figure out, perhaps damage amounts, or notable mobiles that seem resistant or susceptible to fire based spells etc

Has anyone tried something similar to this, and if so any suggestions will be greatly appreciated.

I'd also like to hear other approaches to keep helpfiles current with a muds continuing development.
28 Sep, 2012, donky wrote in the 2nd comment:
Votes: 0
There's the "autodoc" approach, where you mark up the relevant code with help file information and have a parser that extracts and formats help files (whether command-line or HTML). The advantage of this, is that if your help file data is executable, then it can automatically include the correct in-use data and numbers (rather than having players divine it and add their guesses in).

I think the wiki approach you describe sounds like a good modern one that enables a MUD and its players to keep things in the best shape. If I were doing it, I'd just let everyone edit it but be prepared to recover from childish vandalism. And I'd look into some way that automatically extracts useful data and information from the code, in the same manner as the autodoc approach, and allows it to be included and formatted.
02 Oct, 2012, Oliver wrote in the 3rd comment:
Votes: 0
I've always thought it would be cool to actually parse .wiki files into the MUD engine as helpfiles. The helpfiles could then be edited in real-time through a web browser in a convenient Wiki format (complete with revision history, user accounts if necessary, etc).
02 Oct, 2012, quixadhal wrote in the 4th comment:
Votes: 0
Most wiki's nowadays don't store stuff in flat files, they push them into an SQL database. It makes it more portable and easy to have direct access from PHP/javascript/etc.

I'd still vote for writing a dumb web browser that just connects to your local browser (which the wiki is on), and submits a GET request for the page in question, just as you would from the web interface itself. Since you know what your own wiki sends, you only need to support a small subset of HTML, and really only need to pick out href's so you can build a list of "see also" links.

Up to you if you want it to be a menu-driven help system, where the user picks links to follow, or a command line one where they have to type "help foo".
02 Oct, 2012, Runter wrote in the 5th comment:
Votes: 0
quixadhal said:
Most wiki's nowadays don't store stuff in flat files, they push them into an SQL database. It makes it more portable and easy to have direct access from PHP/javascript/etc.

I'd still vote for writing a dumb web browser that just connects to your local browser (which the wiki is on), and submits a GET request for the page in question, just as you would from the web interface itself. Since you know what your own wiki sends, you only need to support a small subset of HTML, and really only need to pick out href's so you can build a list of "see also" links.


This is an appropriate tactic if you don't have control of the web server in question. There's absolutely no reason not to expose an interface that returns a json object on the get request for your game server, though.
02 Oct, 2012, Tyche wrote in the 6th comment:
Votes: 0
Just add a timestamp parameter to your helps and a command to activate a particular revision as the current help.
You've got yourself a help wiki. Special formatting and linking is just gravy. If you trust some players to create help files,
you can do the same with building/coding… :-)
03 Oct, 2012, quixadhal wrote in the 7th comment:
Votes: 0
The advantage to using an exsiting wiki package though, is that your help files are on the web, right along with the rest of your MUD's site. I know I'd find it easier to peruse help files in a browser than in-game, since I always have a browser and shell open, but YMMV. :)

Also, using somebody else's means you don't need to code it. If you can easily make the wiki spit out JSON for a given user agent, it becomes dirt simple to pull live data into the mud with only a tiny bit of your own glue code.
03 Oct, 2012, Davion wrote in the 8th comment:
Votes: 0
Sargonas said:
I have been tackling the task of updating our muds helpfiles and it seems daunting to say the least. I was considering a new system that would work sort of like a 'wiki' , where the help system entries are editable by all players, or maybe a subset of the higher level players.

The initial standard helpfiles would still exist, such as 'help fireball' would give you the spell and its description. But then players can add more information they've been able to figure out, perhaps damage amounts, or notable mobiles that seem resistant or susceptible to fire based spells etc

Has anyone tried something similar to this, and if so any suggestions will be greatly appreciated.

I'd also like to hear other approaches to keep helpfiles current with a muds continuing development.


Have you considered adding the ability to comment on a helpfile? When I used to write a lot of php, the function docs were helpful but scrolling down to read the comments was often more way more insightful and came with examples. Also, you can pick and chose who you take advice from in those helpfiles.
0.0/8