Gamasutra: The Art & Business of Making Gamesspacer
Learning the Ways of the Game Development Wiki
View All     RSS
August 30, 2014
arrowPress Releases
August 30, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Learning the Ways of the Game Development Wiki

July 30, 2009 Article Start Page 1 of 4 Next
 

[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.


Article Start Page 1 of 4 Next

Related Jobs

AtomJack
AtomJack — Seattle, Washington, United States
[08.29.14]

Level Designer
GREE International
GREE International — Vancouver, British Columbia, Canada
[08.29.14]

Senior Game Designer
SAE Institute
SAE Institute — San Jose, California, United States
[08.29.14]

User Interface Design Instructor
SAE Institute
SAE Institute — San Jose, California, United States
[08.29.14]

Compositing Instructor






Comments


Roberto Alfonso
profile image
At work we use TWiki. I hate it, but mostly because I am used at MediaWiki (where I acted as administrator). However, in all a wiki is useful when working with documentation, since it is very easy to write (you almost don't think in the tags as you would in HTML). Also, being able to go back to any past version and check differences is, in itself, a huge advantage.



I would recommend anyone to try one, even if it is a single component that must be documented.

Jesus Alonso Abad
profile image
My personal experience using wikis to document development is really positive. It offers not only a collaborative way to create documents, but new ways to organize information.



As Roberto, I'm recommending everyone to try them.

Eric Scharf
profile image
While I, too, am old school with my documentation methods, I can certainly see, through your article, and have experienced the benefits of utilizing a Confluence.



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.

Dan Thatcher
profile image
As I look at the pros and cons that have been presented, it seems that the suggested solutions to the cons are challenging to implement. In other words, it seems that the con solutions actually create more cons.



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...

[User Banned]
profile image
This user violated Gamasutra’s Comment Guidelines and has been banned.

Renan Rennó
profile image
Maybe Google Wave will spice things up.

Christian Arca
profile image
I personally cannot deal with Wikis. We've tried using them at our studio and they result in a formatting mess. What we have resulted to doing though is using subversion for GDD document control. So as lead the edits are sent to me and I inspect the change log. If approved then the documents are committed if not then they go back to the designer who makes the appropriate changes. Sometimes it's a bit taxing but it's not all too bad.

Thomas OConnor
profile image
I've had success on two projects using Wiki as our production log. Our scrum meetings, backlogs, and burn charts are all updated on a Wiki (using MediaWiki), and so far everyone's had a pretty reasonable time with it. A bit cleaner than lots of post-it notes on the wall, but it does have it's hairy sides.



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!

Daniel Speed
profile image
We've used wikis for a while, and a bad one (or badly set up one) can really hurt you if it rapidly becomes slow and unusable and you can't find anything.



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.

Edward Williams
profile image
"Maybe Google Wave will spice things up. "



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.

Christian Arca
profile image
@Thomas - I'm going to take a look at MediaWiki. Unfortunately we were using our project tracking software for Wikis which had an intolerable system so anything and I mean anything worth document took at least 30 minutes to properly modify or add.

James Hofmann
profile image
I think the number one thing wikis need to work for project docs is automatic organization - for example, the category tags in MediaWiki. Without them information gets muddled because the pages for project documents won't naturally link to one another in the way that a Wikipedia article does. But once you can tag and group pages in different ways and auto-generate listings, it gets a lot easier to find what you need.



Formatting requirements rank #2, and they mostly seem to be an artifact of old processes.

Mark Venturelli
profile image
We have been using a Wiki tool for all our projects. I highly recommend everyone to try Zoho Wiki (http://wiki.zoho.com). It is free to use (with file size limit), you can organize the documentation easily in a parenting tree, make it private, allow only specific members to edit content, it has version control (including the most useful "ctrl+z"-style reversion) and you can configure it to email you every day with a list of changes made by your users, divided by section and date.



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.

Julien Tremblay
profile image
Having worked with both Word documents and Twiki, I can personally say that I prefer Twiki way over the Word method, simply because we could have multiple members could browse / edit information rapidly. But quite frankly, the cons of the information mess and structure from a Wiki is generally way too chaotic and results in more harm done than good.



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.

Neil Gower
profile image
I'll chip in that in a top-down style of organization, a wiki is not a good fit. Wikis work in collaborative environments where anyone can contribute to anything if they see the need. These are very different ways of working, and the culture clash is much harder to overcome than the install process of any wiki software. Before choosing a wiki, you need to know what style of team are you building.

Philipp Horwath
profile image
We (10 students) used the wiki environment at our university for the game development. In the beginning it worked just fine, but the problem was we didn't had a real project manager (or nobody of the students cared :) ). The result was that information was edited somewhere and data occurred twice. Also the problem was that people asked the information, before looking it up



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.

Daniel Speed
profile image
You very much get out of a wiki what you put into it - I'll reiterate that you cannot simply put one up and only expect good things for no effort. What you get is increasing payback over time, for diminishing effort (there's more existing documentation, standards, people are more familiar with editing and writing it...).



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.

Lance Rund
profile image
As has been alluded to previously, with a Wiki there is an intersection of several influences which are counter to each other. Some are obvious (the presence of an Edit button on the screen does not magically confer the viewer with the ability to write coherently), others less so. One which I've run into is particularly insidious, though. It's political.



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.

Jonathan Lawn
profile image
My experience is that it is fairly easy to set a culture so that everyone



- 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.

Andrea Di Stefano
profile image
I had a terrible experience on a student project using a wiki, mainly due to the effort required by text formatting. While most wiki functions are great (we used DokuWiki), in the end we reverted back to more conventional word processing tools, much easier to edit.



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)?

Daniel Helbig
profile image
Hi, I wrote a blog post about the reasons I believe a Wiki makes more sense for a GDD. I would highly appreciate it if you could tell me your opinion about it.



http://www.gamasutra.com/blogs/DanielHelbig/20090809/2707/Microso
fts_Word__Lets_bury_the_dead__20_Reasons_why_you_should_write_you
r_GDD_in_a_Wiki.php

James Everett
profile image
Back at GDC 2008 I did a poster session on 10 Tips for a Successful Wiki (text here http://www.brainofjames.com/?p=62 ) and have become a big fan for documenting projects.



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.

Loic Kohler
profile image
I guess now I have something to conduct some research on in the future of gaming and programming uh!. But I must say this was a nice read and I find that this was very useful.


none
 
Comment: