HeatherWiki is a collection of mods and a system of organization for using MediaWiki to house and organize design documents.

HeatherWiki is a system that is one-wiki-per-game making it the go-to source of information throughout production of that game. It is meant to house information contained in a design document with improved navigation, searchability and organization. It is meant to easy to update so the documentation will always be up-to-date. Finally, my mods are meant to automate functionality that allows the wiki to also maintain the structural information of an entire traditional design document. So all the pages you want to be compiled into the GDD can be merged into one document.

This white paper, entitled Why You Should Be Using MediaWiki for Design Documentation and How to Get Started, is directed toward producers and lead designers to advocate the use of MediaWiki as a tool for design documentation. It introduces the system and how it works, how the mods I built help, and how to get it up and running. It also discusses why using such a system over traditional design documents can be advantageous. Additionally, it covers some of the features that make MediaWiki specifically useful for maintaining a living design document throughout design and development of a game.

Most of the information about HeatherWiki is housed on the project wiki (also the wiki for Shelf Life). Some documentation is housed on a different wiki (the wiki for Revenge of the Duzzles) because the version of MediaWiki was updated and I moved the work to a different wiki.

This wiki houses most of the information about the project including how to use it, some general help pages on how to use MediaWiki related to games, features, and some of the code documentation.

When working on Invasion Cute, I attempted to use MediaWiki to house our design document because I felt early on that many of its features would be useful. However, I learned that without any system in place for how to organize it, that people would post information all over the place. There was no way of connecting the content back to a normal design document. I had in place a system that had people manually placing information about section numbers (which are used for structural information and reference) manually. These numbers were not updated and to rearrange the structure of the document required massive changes to the entire wiki.

I still knew that the framework could add improvements over a traditional document. So I decided to make a system. One section in the document is one page in the wiki. Structural information updated from a centralized location. Automated displays of structural information (section numbers, parent sections, sub sections). Automatic compiling of the contents of all the sections into a single location. These were the features I needed and added.

The result was a system that highlights the benefits of using MediaWiki rather than obfuscates them with the overhead of maintaining the wiki. The system is reusable, works well, allows you to copy and paste the entire document into Word if it has to be printed out, automates many features, and that I am very comfortable using on future projects.

For this work, I taught myself PHP and reintroduced myself to SQL (which I had not used since I learned it as a undergrad at Stony Brook). I learned a lot about how the backend of MediaWiki works, familiarizing myself with the database layout and the PHP control. HTML, CSS and wikitext (MediaWiki's markup language) were also used.

There is a lot more that could be added in the future to improve functionality. Some of the features I discuss in the white paper are very interesting but there is some overhead involved I would prefer to eliminate. Other features are those I rapidly added to The Trip's wiki for immediate use that haven't been tested or added to the other wikis.

I would like to vastly add to the existing documentation and move the source to a repository so others could also develop for it and improve on my work if they were interested. I think it is a project that has a lot of potential for widespread use and has room for many new features to further integrate it into the game production pipeline.

An early iteration is in use by Forever Interactive LLC of Chicago for one of their upcoming games. Additionally, I have used it on all three of the large game demos I built at RIT. Finally, students of Professor Jacobs's Interactive Narrative Class (Fall 09) used this on their design documents.

Authors of content for each of the other wikis used at RIT:

• The Trip (capstone*): Heather Arbiter, Jay Austin, Kapish Rawat, Josh Wilson
• Shelf Life (heatherwiki): Heather Arbiter, Michael Ey, Kelley Piering, Joseph Piertruch
• Revenge of the Duzzles (mediawiki): Heather Arbiter, Sela Davis, Michael Ey, Kelley Piering
• Alter Ego (sierrawiki): Bradley R. Blankenship and Karl Schmitt
• Aware (tangowiki): Mike Dapiran and Eric Baker

These authors are the owners of all game content depicted on the wikis.

*This wiki is private while the game is in development, see The Trip for details. Screenshots from this wiki are used in the white paper.

Faculty supervisors for the independent studies: Professor Erik Vick, Professor Stephan Jacobs

Other mods involved in HeatherWiki's production: Hierarchy (Fernando Correia), Maintenance (Ryan Schmidt), Parser Functions (Tim Starling), NavFrames (see documentation on HeatherWiki).