Advertisement

Using a wiki solution to write game design

Started by July 19, 2009 09:13 AM
22 comments, last by omeomi 15 years, 6 months ago
Quote:
Original post by Sik_the_hedgehog
So, considering what I've read from the posts in this topic, I've reached the conclusion that it'd be cool if there was some kind of specialized wiki that has extra functionality to make documents for presentation in paper easily.

I wonder if such a thing exists =P

Yes, but they're not cheap. See Confluence, for example.

Quote:
Original post by sunandshadow
- With a game design project it is important for new people entering the team to read the whole game design document, and for current people on the game design team to be familiar enough with the whole game design document that they do not propose (too many) ideas that are inconsistent with what has already been decided. Becoming familiar with all of a document is much easier to do with a linear document than a wiki.

A wiki can be used to produce a linear document (see above link). Wiki software can even be modified with templates that establish dynamic links between individual pages so that the entire "document" can be read from beginning to end without having to re-navigate via an index page.

Quote:
- It is my experience that most game design team members either dislike producing documentation and won't do it voluntarily, or have no ability to write in proper sentences with good capitalization and spelling and all. Therefore it is better to have one or a few designated people writing the actual copy for the documentation, although others should be welcome to discuss design topics in a forum.

You can have people discuss in an internal namespace in a wiki, and then have technical writers or designated designers edit and promote that material to an official, public namespace.

Quote:
- A game's design really needs to be a coherent vision with lots of decisions made, and this does not emerge naturally from group discussion, it emerges much more naturally from having the designer take the group's discussions and rewrite them in a consistent and organized document.

The problem here is not the wiki, but the organizational structure. Wikis are just software; how you use them is a reflection of the internal hierarchy of your organization. There are different solution strategies possible for wikis, including collaboration.

Quote:
- A document which only one or a few people have access to edit, and which probably exists in multiple copies on various harddrives, is not vulnerable to vandalism the way a wiki is.

A real wiki has a strong permissions system and revision control. Implementations like MediaWiki, TWiki and Moin Moin lean toward access rather than security; others, mostly commercial, do not. Besides, relying on end user hard drives for data redundancy/backup is not a real solution.

Quote:
- Documents can be printed out to look nice (wikis can't) and documents in electronic form are just as searchable as wikis are.

Wikis can be printed out to look nice. MediaWiki and its ilk can't, but they are by no means the definitive word in wiki software. Sometimes you get what you pay for.

Please note that I am not pushing Confluence. It's just that I have used it at the job, when I worked at VIACOM on a project with the guys over at MTV. Serious companies use wikis to complete a wide variety of design projects. I only think the challenge faced by indies is the comparatively poor quality - architecturally (try implementing true access restrictions in MediaWiki; it's impossible) - of the cheap and free solutions.
The company I work for has gone for an agile and TDD approach to projects.

Each feature is a separate story complete with test acceptance criteria and its own document. The team uses a spreadsheet with links to all the documents as means of organizing and managing development. You can easily see who is working on what stories, expected delivery dates, and what is contained in each iteration.

I suppose you could do all that with wiki, but it becomes trickier if you want to include additional data beyond text in the in a story.
Advertisement
Quote:
Original post by sunandshadow

@DesignerWatts - 50megs can suddenly vanish if you are using that space to share or store music for the game, or any kind of movies related to the game. But, that may not be an issue for some projects, or earlier phases of most projects.




I totally agree. A 50meg file size limit and a total website size of 5 gig would be far to restrictive for a commercial game project if the space was used as a online file storage solution as well.

I'm currently using the 'super' version of what wikispace has to offer. They have larger and more expensive plans as well.

For the nature of my indie project the cost, usability and just general convenience a wikispace has given me has been great. Their tech support has been pretty damm good as well.

But I agree. For larger projects, especially those commercial in nature a wikispace would not be suitable. But I still prefer the use of wikis over word documents when it comes to the project side of things. The studio I used to work for implemented their own wiki on an internal server as they where just getting used to the idea before I left. But it was very basic and, apart from being able to add pictures to your pages. The programmers on that studio started to warm upto writing usability docs for their implimented systems which was a god send to the level designers.
In my current project, Game-Design was done with word-document, by 3-4
game-designers. Imagine the mess with various version of these documents
floating around (in email, on harddisks, network drives, ...).

Furthermore the "big" word-document was split into 4 parts, so everyone
editing it could work "simultaneously" on their parts, merging back
occasionally..... resulting in a big mess (On one occasion I found 3
completely different descriptions for the same issue, or also funny:
some parts weren't merged back).

Not to mention that it's really annoying to scroll through 300 pages
to try to figure out the changes since the last revision (I'd only like
to see the changes of this week, please).

I'd definitely prefer a Wiki, first of all because it's the one
and only official document - everything else wether email, doc-files
or whatever is invalid. Furthermore it add something which programmers
have been using for dozens of years: Version control - to answer the
not unimportant questions "Who, When, Why"...

visit my website at www.kalmiya.com
I prefer a combination of Word and Google Docs.
As for the whole I-need-to-read-the-whole-thing objection, even if you use a cheap wiki it seems that someone should be able to write a script or something that stitches the wiki into a single document. It might not be pretty, but it would do the job.

While I'm here, this program has been described as a "personal wiki": ZuluPad. Might be worth looking into.
Advertisement
I have been doing some XNA and wanted to create a decent environment for the other members. I decided to use pbworks. It is a fantastic site. It is basically a wiki, except I believe communicating using it is much easier. It's free, but upgraded versions cost money.

Some basic features:
Limiting who can view, write, delete
Locking while editing
Commenting on everything
Easy file adding
Easy section creation
Getting emails when things are changed

Please do not let the name fool you. It is very professional. I would recommend it to anyone: professionals, people like me(casual), and individuals
Me and a friend started an indie game project (we have about 14 people involved total now - artists, scripters, etc) and we thought to use a wiki too.

Well, in general people never use the wiki because we have a mailing list for the group and all discussion goes there (and nobody writes up documentation, even after we all say "we should write this down so we don't forget it when the time comes to implement it" haha).

Anyhow, something else is that it's been my experience that game design needs a "head of design" to make all the final calls (when necesary - ie in the case of heated arguments etc).

With a wiki, anyone can go in and write whatever they want about anything and once its in the document it makes it a little harder to say "well no, we dont want to do it that way", and at that point why have the wiki?

I work in the game industry (im a coder) and all my personal / indie projects ive started have ended because there was no clear goal or leadership for design, just a lot of "we could do <X>", lots of possibilities but no decisions. everybody wants things done their way and they think its the best hehe.

so yeah, basically i concur with a lot of what sunandshadow wrote (:

I think the best way to do it is to have a public realm of discussion so that people can toss in their ideas freely, but you need a person in charge of it all in the end who has the final vision.

They of course should listen to everyone else and hopefully use a lot of ideas people present but in the end i think that person should be in charge of the design document (and likely wont want to document it all in the end haha).

my 2 cents!
The NamespaceProtection extension for MediaWiki can make it less prone to vandalism. For example, you can set it up so you have a namespace called Project, and two user groups entitled ProjectDesign and ProjectDev. ProjectDesign can have full permissions to the pages, while ProjectDev can only view the pages. Any user not a part of either of those groups can't even access the pages.
Quote:
Original post by Daggerbot
The NamespaceProtection extension for MediaWiki can make it less prone to vandalism. For example, you can set it up so you have a namespace called Project, and two user groups entitled ProjectDesign and ProjectDev. ProjectDesign can have full permissions to the pages, while ProjectDev can only view the pages. Any user not a part of either of those groups can't even access the pages.

It doesn't hide namespace protected pages from the recent changes list. It's a hack, not a solution.

This topic is closed to new replies.

Advertisement