|
[Game design veteran Ryan -- most recently a designer on Fracture -- looks at the Wiki as a game design and development tool, asking -- is it the right tool to use to document game creation, and what are the pros and cons of using it to store design information about larger-scale games?]
Introduction
As a self-described old-school developer, I have written or
directed the creation of game design documentation since the early '90s, but
recently I had the opportunity to work with teams using internal Wiki websites
to document their game design specifications. I wasn't sold at first, given the
discipline that goes into creating clear, precise documentation, but I saw a
lot of positive aspects to the approach.
I did some asking around, and I found that quite a few people
have worked at companies that used Wikis. The vast majority were making
self-published games where the demand for documentation milestone deliverables
to a publisher didn't force a printed format onto the team.
I realized that
Wiki is probably something that's here to stay and I'd better learn to adapt. So I did a
little bit of research and found the pros and cons of using Wiki for game
design documentation and some methods for overcoming the cons. This article
seeks to share what I learned.
What is Wiki?
Wiki was invented by Ward Cunningham in 1994 as a way for
programmers at his company to share ideas. It is a simplified markup language
loosely modeled after Apple's Hypercard -- which, interestingly enough, is
credited as the forefather of HTML, the standard Web Browser markup language.
The difference with Wiki is that it is much simpler and hasn't spun out
of control in complexity like HTML has over the years. Anyone can edit it,
which is the point. It's not an information presentation
language: it's an information sharing language. It promotes
communication and group contribution through ease of access.
Over the years, Wiki has spread to other companies and to
public websites. The most famous is the online encyclopedia Wikipedia, written
entirely by individual contributors around the world. The prominence of
Wikipedia as a respected repository of information is the ultimate proof of the
success of Wiki's goals. Thank you, Ward.
Is Wiki Right for Game Development?
 Wiki was originally designed for use in a software
development company before being adapted for community and commercial sites.
From what I could gather, a few game companies have used it for quite a long
time. The fact that more and more video game development companies are starting
to use it should be no surprise. It's caught on.
Our industry has grown. The size of the projects, the depth
in the games, and the sheer amount of information is staggering. There is just
too much for a single designer or producer to write up. There is also just too
much information for a single design document, even if it were divided up into
sections. Wiki solves this issue because it allows many individual contributors
and a browser interface to organize and find information.
Perhaps this is just a side-effect of being gamers or an
influence from the MySpace, Blogger, and Twitter culture, but game developers
seem to have a small attention span and appreciate the bite-size pieces of
design that Wiki encourages. They don't like wading through 100 page design
specifications. Each Wiki page is a topic, and it can easily be linked to other
topics, be grouped into sections and be labeled for searching. In short, Wiki
makes design more accessible.
Why not use Sharepoint?
The answers are simple:
1.
Sharepoint isn't cheap. Many Wiki solutions are
free or fairly inexpensive.
2.
Sharepoint is cumbersome and is more of document
hosting solution than a website. I've literally waited minutes for a document
to transfer off the site and be loaded by my MS Office application rather than
come up in my web browser as a web page like Wiki does.
3.
A tool that's used is more useful than a tool
that's not. In my experience, Wiki is more readily used by the team members. It
gets more contributors and more readers alike.
|
Printer-Friendly Version
I would recommend anyone to try one, even if it is a single component that must be documented.
As Roberto, I'm recommending everyone to try them.
As with all team-oriented product development efforts, in games or otherwise, a successful experience with something like WIKI comes down to personal preference giving way to the greater good of team preference . . . or leading the way with an approach enjoyed and appreciated by the team. Habits are hard to break and robots are hard to find. I have been looking for them for years. ;)
Excellent job of providing an in-depth big picture perspective on the pros and cons of utilizing WIKI products. Thanks, Tim.
I've always liked the idea of Wiki's and have consumed my fair share of them, but I wonder if google docs or Adobe buzzword wouldn't end up being better solutions. I wonder this because they don't strip away the word processing behaviors that we are all used to but add the collaboration, version tracking and rich layout capabilities that game design docs need. With these tools, you can still create your design doc in your favorite word processor and then upload them so that they can be collaborated on.
I'm not totally convinced that my suggestion would really work, but thought I should throw it out there. GoogleDocs was mentioned in this article - but I would recommend taking a look at Adobe's buzzword as well.
Thanks for this great article. You got me thinking...
I hope that as more people use Wiki for design and production in the game industry, more plugins, tools, and evolutions of Wiki will appear to meet our unique needs!
With the formatting, it's true that as long as you're not being ambitious, wiki markup is generally easier than HTML - on the other hand, tables can be fiendish, and a lot of the sorts of extensions you'll see in use on wikipedia (for example) aren't shipped by standard with mediawiki as far as I know (which then requires you to detangle a web of templates to work out how you can get a nice, red "this is deprecated" warning box).
If you want it saved out, there's a few programs out there that can download and package up websites for offline browsing.
You can't expect to put up a wiki and get benefits instantly and for free, someone needs to lead the way on encouraging people to use it in the right way, work out how to deal with access, best practices etc, setting up templates (or some form of reusable code), and that's going to absorb the time of someone who could be doing something else.
All this aside, I much prefer a wiki to a massive document, especially because we don't use it for doing a design doc, but documenting engine features and how to use them etc (which doesn't need central approval). The benefits scale a lot when you're working with large teams and remotely.
I believe Google Wave will spice things up, particularly from the open-source nature of the platform, you can tailor it to what your company needs, should you have someone to do so. For smaller companies, it would be a great way to work on ideas and documents (thanks to the ability to mark up and comment waves) without the need for a lot of meetings that may be inconvenient for folks who have to telecommute.
Best of all, no need to set up a Wiki server.
E.A.W.
Formatting requirements rank #2, and they mostly seem to be an artifact of old processes.
So far we are impressed. And for all the people stating that Wiki can become a mess and GDDs can't, you do know that you can allow only certain people to edit, right? If you want to, you can have your designer as the only editor, old-school style, but the ease of use and browser visualization, as well as version control, will make the documentation much more accessible for the rest of the team than a 300-page pdf tome.
Why not use best of both worlds? I mean, the Wiki offers multiple-user information editing while Word offers the speed and time-saving text editing tools. Those are the biggest differences, right? I think that organizing a Game Design document in Word simply by splitting it in documents by subject (like Wiki does) can greatly increase how many people can edit information, since that seems the major issue.
For instance, instead of having a document called Economy_System.doc, containing all the information about your economy system and filling 25 pages, you could have it split in several documents, like so: Player_Income, Player_Outcome.doc, NPC_Income.doc, NPC_Outcome.doc, and so on.
On another note, I do agree that the change log is not present in Word documents, and that could be a hassle to deal with. That's why having a rigorous notification process is needed so that information affecting other departments is sent out. For this there are various solutions, including simply having new/updated information highlighted within a document and leave it highlighted until some kind of "Newsletter" for the project is sent out with all the changes. This is tedious, I know, but I'm sure someone could come up with a better idea.
I think we just struggled with the "Con's" of the article ;) but still the one major advantage is, that all the information is accessible to everyone.
I frequently spend a few hours going through, reading new documentation and telling people what they need to improve upon, reclassifying pages and adding TODO category tags and notes.
You have to keep in mind when documenting, who you are documenting for, and how you're expecting them to find the information you're putting there. Unlinked pages are almost useless, as are uncategorized pages (search is ok, but shouldn't be the primary way of finding information, I keep the special pages for these two items on the front page of the wiki to remind people what they need to do). The front page should probably link to your top-level categories, and you should probably be able to learn about and find any page within 3 or so clicks of that page. I've seen programmers produce pages that would barely tell anyone how to use the functionality that they've created, what it's for (and not), and why it was done in the way that it was.
It's also worth remembering what a wiki is not for: it's not there to stop people from asking you questions. If that's the most efficient method for getting the information (and in small teams it probably is), you shouldn't fight that too hard. If you're not there, through vacation, office hours, moving on to another job or simply because you haven't looked at something in a long time and don't remember 100% yourself, the wiki is there.
I also harass new employees to point out pages that they feel are missing from the wiki documentation.
Wikis have an aura of "democracy" and "inclusiveness" about them. There is an assumption that any person reading a Wiki is authorized to make changes and that those changes are meaningful. However, software development is not a democracy; successful projects are a benevolent dictatorship. Giving people an Edit button on a design document can give the idea that anyone can change the design... hey, cool, a Wiki, I'm a designer now and can gainsay the designers when I disagree with my non-designer viewpoint. Ditto for implementation guides... hey, cool, a Wiki, I'm a coder now and can second-guess the coders with my took-a-class-in-PHP-once sensibilities. Marketing strategies... hey, cool, a Wiki, I'm a PR guy now and can pipe in with my engineering viewpoint because engineers make the best marketers. Legal documents... hey, cool, a Wiki, and I saw "Law and Order" last night and read a Gamasutra column :) And if you didn't want to be granting anybody the ability to change anything, why did you go with a Wiki?
I've run into the above before. Many times, actually. WikiPedia has been so successful at what it did that it's attached its philosophy not just to the project, but to the tools that made the project happen. And sometimes that philosophy is entirely inappropriate.
- can add anything that's missing, so long as they express their confidence level in the accuracy of what they're saying
- can clarify anything, so long as they are sure the clarification is correct
- should email questions and comments to the most likely person to know the answer, not put them in the Wiki.
However you still need a editor with time allocated (or a concerted effort from a number of people) to maintain usefulness of the structure, the accuracy of the links and any index pages.
If you can do this, using a Wiki is a very powerful process which can replace almost all other documentation apart from code comments and external docs.
Thus, I have a question: are there some wikis (or similar) regrouping all of wiki traditional features and word processinf format feature? (that means, no messing with tags)?
http://www.gamasutra.com/blogs/DanielHelbig/20090809/2707/Microsofts_Word__Lets_
bury_the_dead__20_Reasons_why_you_should_write_your_GDD_in_a_Wiki.php
Two wikis I'd recommend checking out are Deki http://developer.mindtouch.com/Deki and Trac http://trac.edgewall.org/ (which also has robust ticket tracking.) Both have good WYSIWYG editors, though Trac's is a non-core plugin and more basic.
So long as your wiki is internal to the studio everyone being able to edit is not a problem, just disallow anonymous edits (a housekeeping detail rather than a security measure) and trust their professionalism. I've never had a problem with bad edits other than the occasional prank on people's personal pages.
Most publishers require a design doc that you'll need to deliver in Word or PDF format, but careful use of transclusion and some Word macros can make generating a GDD from a wiki a fairly painless task.