Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
Learning the Ways of the Game Development Wiki
View All     RSS
May 27, 2019
arrowPress Releases
May 27, 2019
Games Press
View All     RSS








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 Previous Page 2 of 4 Next
 

Wiki Solutions

There are lots of different Wiki solutions to choose from. Wikipedia has a good list going, in fact.

If your main factor for deciding on a Wiki solution is cost, there are plenty of freeware options. Just keep in mind that you get what you pay for. They are feature-lite and lacking in support. I'd encourage you to explore this if you're just experimenting with Wiki. However, I'm sure you'll find that once you're committed, your desire for features will drive your decision more than cost.

A major consideration should be ease of customization. If you or someone on your staff is comfortable in a particular programming language -- CSS, PHP, Perl, Python or Java -- then you might want to choose a solution that is implemented with that language. However, the more powerful Wiki solutions will present a non-programmer interface for adding features via plug-ins and macro editing windows. In the spirit of open-source collaboration, there are hundreds of Wiki plug-ins and macros out there that may give you the specific features you want.

The examples I use in this article use TWiki and Confluence. Actual Wiki syntax can and will vary significantly with each Wiki.

Pros and Cons of Wiki for Game Design Documentation

The pros and cons below are based on using Wiki versus more traditional Word and PDF documents.

Pro

Con

Collaboration:

  • supports multiple editors working simultaneously on different topics

Design Mayhem:

  • too many cooks in the kitchen can lead to disjointed design and warring editors

Browser Friendly:

  • organized into branches with link pages
  • uses labels for searching & finding topics
  • easily links to external reference material

Constant Fluctuation:

  • instant publishing, erratic version control
  • lacks formal approval and sign-off
  • presents a moving target for team

Security:

  • no documents floating around or mailed
  • uses domain security to access
  • group and user level access control

Not Very Portable:

  • not formatted for printing
  • makes milestone submissions difficult
  • not organized for reading end to end

Pro: Collaboration

Wiki supports multiple editors working simultaneously on different topics. This appears to be the trend for all major undertakings. Take a look at Google Docs for an extreme case, where multiple users can edit the same spreadsheet at the same time.

Microsoft is working on a similar service for Office, but its implementation is somewhat different. Currently, it's more common to navigate to a Word document on the network, open it on your desktop, edit a paragraph, and hit "save" -- only to be told that the file is locked by someone else. That doesn't happen with Wiki unless users are editing the same exact topic.

Con: Design Mayhem

Everyone has heard of the adage and probably experienced it for themselves: "Too many cooks in the kitchen spoil the broth." Clearly the biggest concern for most designers new to Wiki is the lack of cohesiveness that comes from group design.

They have a reason to be concerned. I've seen Wikis that were completely disorganized, disjointed and more or less unusable as a design specification as the various editors war over its contents and presentation. Clearly not everyone is a writer -- or particularly good designer. There's another adage at play here: "Just because you can, doesn't mean you should."

In my experience, the best design documents were written by designers adept at technical writing who listened as well as they wrote. They were able to take the various contributions, notes, and feedback from the team to create a cohesive, attainable game design specification that represents the goals and ideas of the team. The role of lead documenter just doesn't exist in Wiki. It runs counter to its philosophy.

There are a few ways to avoid these problems without becoming a complete Wiki Nazi:

1. Most Wikis can be configured to block anonymous users from making changes.

2. Some Wikis offer version control and change history tied to user name, which offers some accountability and recourse should there be some undesirable change.

3. Additionally, most Wikis offer read-only access control per page by group or user. This is less than ideal. I've only ever used it to keep people from seeing embedded database passwords.

4. Establish a style guide for each type of content and create a framework to structure all the Wiki pages into categories.

5. Enforce a formal migration of Wiki pages so that proposed ideas, notes and specs under development are kept away from published specifications.

6. If there isn't a lead designer with time on his hands to edit Wiki pages, have a designated WikiMaster at the company whose job it is to clean up and organize Wiki pages.

Pro: Browser Friendly

Wiki works with any web browser. The URL uses the Wiki topic name in simple CamelCase, making finding pages very easy. All Wikis have some way to tag pages for searches -- essentially applying key words to make associating and searching for the topics very easy. Confluence calls them labels and TWiki calls them tags.

Wiki pages can also be grouped in parent-child relationships. It's fairly easy to make a switchboard page with a navigation tree to each topic. Depending on the Wiki solution you use, the navigation tree can be auto-generated.

Wiki makes it easy to have links to other Wiki pages, attachments, downloads or external reference material. If you have a YouTube video that's a great reference, you can embed it right on the page. You wouldn't dream of doing that in Word Documents. Even though it's technically possible, it doesn't print and it relies on an Internet connection that you can't be sure the reader has. With Wiki, you can be sure embedded reference material will display fine.


Article Start Previous Page 2 of 4 Next

Related Jobs

Sucker Punch Productions
Sucker Punch Productions — Bellevue, Washington, United States
[05.26.19]

QA Manager
Digital Extremes Ltd.
Digital Extremes Ltd. — London, Ontario, Canada
[05.26.19]

Senior Lighting Artist
Dream Harvest
Dream Harvest — Brighton, England, United Kingdom
[05.25.19]

Technical Game Designer
Deep Silver Volition
Deep Silver Volition — Champaign, Illinois, United States
[05.24.19]

System Designer (Player Progression)





Loading Comments

loader image