This is part 2 of a guest post by John Arcadian, of Silvervine Games. It covers the basics of using a wiki as a GMing tool (and complements Avlor’s post, TiddlyWiki as a GMing Tool, very nicely), but it won’t make much sense if you haven’t read Wikis for GMs, Part 1 first.
– – – – –
Now that we’ve covered the basics of setting up your first campaign wiki, let’s look at some of the things that really set wikis apart as GMing tools.
Groups and Tags
Groups and tags are essential to organizing and separating the information that you store in your wiki.
For example: You can create a group for all of your NPCs and an individual page for each NPC. The main group list would act as a list of NPC names, as suggested in Give Your Players a List of NPC Names — but clicking on the name of an NPC would also allow you to add detailed information and images to that entry.
This will also let your players update that NPC information with things they learn — or suspect — about individual NPCs. You may create Tensero the street juggler as a throwaway NPC, and give him a wiki entry just to share a single piece of information — but when one of your players updates his blurb with “Tensero seems to be connected to the royal family in some way,” you have a whole new plot hook which already works with your players’ suspicions.
You should be able to create groups merely by including more detailed information in the link — [[ npcs.tensero | Tensero ]], for example — or by adding an “NPCs” tag to the entry.
Passwords
If you’re using your wiki (or parts of it) for GM-only information, or if you’d prefer to not let the outside world see your campaign information, you can set passwords for editing and/or reading the wiki.
You can set passwords by page, by group or for the entire site. Setting passwords for the entire site requires some minor editing of configuration files. Remember to always have a backup!
You might want to create groups of pages and password protect them based on what you want your players to have access to. Like this:
- NPCs: Open access (anyone can read and edit this section)
- Plots: Read and write password (editing and reading are both password protected)
- Enemies: Read and write password
- Places: Open access
- Stores and Items: Write password (anyone can read it; only someone with the password can edit it)
History
If you do leave areas open without passwords, there is always the possibility that someone may change information which you would rather not have changed.
One of the most beautiful features of wikis is the ability to instantly revert to an old page if the information gets changed. By clicking on the History link on most wiki pages, you can go back through each change and restore and older version.
If a player posts information you don’t want accessible to everyone, or you realize you wrote over something that you desperately needed, you can always reverse the last few changes and repair the entry. Each change can also be logged by author.
With some editing of your wiki’s configuration, you can also require people to sign their names to the changes and keep track of who edited what.
Plugins/Recipes
While most of the information covered so far has been about basic uses of wikis, there are a lot of advanced features you can include with the right plugins/recipes.
A plugin or recipe will usually be a PHP script that allows the wiki to parse extra information or add extra elements. The larger the design team or scope of your wiki, the more plugins/recipes will be available. For our wiki we use:
- RSS Feed Displayers
- RSS Feeds
- INCLUDE HTML PAGES
- GEMINI SKIN
- Blog Simple
- Rich Edit
- Spell Checker
- Image Map
…and may use many others as our needs change.
One of the best uses for plugins we have found is to include the deadjournal pages for our developer journals. It drops the entire HTML page inside of the wiki content box.
You can also include HTML with some plugins and gain added functionality. This does, however, open up opportunities for people to hit your wiki with viruses if you don’t take proper security measures.
We also use image map to link areas on our world map to descriptions of towns and other features located in those areas, and we make new pages with a blogging plugin — and send them to an RSS feed with the feed plugins. These operations are a bit more advanced, but they’re really little more than adding lines to the configuration file and including the premade script in your scripts directory.
Out-of-Game Information
The final thing I’ll say regarding wiki use for gaming is that if you’re going to use a wiki to keep track of your campaign, you may encounter problems with out-of-game information.
If you make the wiki available to your players, they become more informed and involved in the game — which is very good. They also have access to a lot of information their characters may or may not have, though. If a player posts information about his character’s past which he never tells to anyone in-game, and other players make use of it, then sticky situations can result.
While most gamers are invested in the game and in maintaining its integrity, bad apples can utilize the wiki to their own ends, possibly taking advantage of loopholes in the programming to get to detailed plot information. So to echo the advice given on most wiki download sites, “Make sure you use any security tools provided.”
Outside of that, wikis are incredible and versatile new tools for player interaction, campaign management and worldbuilding.
– – – – –
Thanks, John!
What did you think of this introduction to using wikis as a GMing tool? Are there other details you’d like to add, based on your own experience with wikis?












I use WikidPad as my own personal wiki for my D&D game. It works like a charm. I’ve developed my own notebook/journal/encyclopedia for my homebrewed campaign and our game sessions. Everything is right at my fingertips. It’s the best tool I’ve seen so far.
It’s only available to me, on my laptop, but I’ve been thinking about making one that all of my players could log on to, to see information on locations and NPCs.
The combination approach — some private, some public — sounds like the way to go. If I create a wiki for my next game, that’s probably the approach I’ll use.
Nice article; thanks for writing it John– and thanks for hosting it Martin.