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
Hi everybody, I'm new to the forum. Been designing and programming casual games for several years now. When ever writing design documents so far, I've used Word. But as I experienced the ongoing iterations of development, that cause the development team to constantly access the design document for dozens of reasons, I thought to myself why not use a wiki as the place to write the design? Wiki can make the information more accessible, and more simple on the eyes. So my question is, do you guys have experience working with wikis as a platform for your game designs and what do you think of it? Would you recommend it? What flaws, if any, have you found? Comparing to a word document? Thanks! Guy.
I've really been pushing for the next project at my studio to have its internal documentation platform being a wiki. The pitfall is that when it comes time for a milestone delivery publishers are going to prefer a nicely printable document and not having to look at a wiki, so that requires some legwork from the planner to be able to turn around deliveries from the wiki. The benefits out weight this though, I think, because anyone on the team can both more easily access a wiki and contribute to it, meaning every part of the development of the game can be documented in a central location, making it more useful and likely that people will actually use it.
laziness is the foundation of efficiency | www.AdrianWalker.info | Adventures in Game Production | @zer0wolf - Twitter
Advertisement
I was just discussing this topic over lunch yesterday, oddly enough. My reasoning why I would not use a wiki (if I were ever foolish enough to attempt to lead a game design project again):

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

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

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

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

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

So all in all my preference for a design document is a single large file of a format which can include graphics and charts - openoffice/word, pdf, or html.

I want to help design a "sandpark" MMO. Optional interactive story with quests and deeply characterized NPCs, plus sandbox elements like player-craftable housing and lots of other crafting. If you are starting a design of this type, please PM me. I also love pet-breeding games.

For the indie project I'm currently designing and leading i've found the Wikispace I've paid for provides a lot of features that allow for a smoother development of the project.

You can find the project here!

Here are some of the reasons:

- It's easy to direct members of the team to certain design elements that they might be working on. If a programmer is scripting up new enemies I can direct them to a specific wiki page.

- The wiki i'm using; a wikispace is actually very easy to use, if you've ever posted on a forum, you can use this software. I can upload pictures, spreadsheets, video embeds and all kinds of other nifty stuff to compliment the written component of my design documentation.

- A wiki allows other members of the team to get into the design document and make their own additions or notes. The members on my team use the wiki to update their work journals. Vandalism isn't an issue due to security controls that are customisable and also the ability to back up the whole wiki in case something does go wrong.

- We have a 50mg file upload on a 5gig website. The cost of this service, including the fact that I didn't need to commission a custom website is quite cost effective for my needs.

- Wikis are quite editable and in that regard every time I update one page I don't need to reloaded a whole new document or let everyone know about it.


The core draw back of wikis is that lack of 'wholeness' that you get with that 100page odd slab of a design document. A wiki isn't pretty by any means, but it is functional and I will always take functionality over presentation in documentation.

It's hard for people to read the whole thing or know where to begin with it. But as a designer working on this project I think the wiki was the better way to go. As long as you communicate with your team members about the vision of the game and leave the design details to the wiki you can create an effective communication.

Some example pages:
Game Concept Overview
Level Walkthrough
Art Asset List

Cheers!
thanks for the info guys!

sunandshadow talks about the problem of not having a whole design document to show - how big an issue do you think this is?
I'm wondering whether prospective clients won't have a problem with this.

And what about working with flow charts in wikis? I'm guessing my only option is to import these as images files - right?

I think that other then that, I really feel what DesignerWatts and zer0wolf say in favor of wikis are more crucial, espcially DesignerWatts' note about: "It's easy to direct members of the team to certain design elements that they might be working on" - that's exactly what made me think about wiki as another option to work on (coupled with much simpler navigation).

I also feel, that in a way, wikis are to word documents, as object oriented programming is to procedural programming.
Quote:
Original post by gstation
thanks for the info guys!

And what about working with flow charts in wikis? I'm guessing my only option is to import these as images files - right?


That would be right. If you have a flowchart you'd have to save it as a image file and then upload to the wiki. That's not really a big problem though as it doesn't compromise the communication of the flowchart.


Quote:
Original post by gstation
I think that other then that, I really feel what DesignerWatts and zer0wolf say in favour of wikis are more crucial, especially DesignerWatts' note about: "It's easy to direct members of the team to certain design elements that they might be working on" - that's exactly what made me think about wiki as another option to work on (coupled with much simpler navigation).

I also feel, that in a way, wikis are to word documents, as object oriented programming is to procedural programming.


My wiki works because i'm leading a team of almost a dozen people. In that regard there are many different documents and instructions that I need to write out for many people.

However if I was working on a smaller project like a iphone casual game that only had 3 developers on the team, one of them being the designer. Then in practicality I'd just need to write out a detailed design doc.

In my opinion wikis are great for larger projects that require multiple people to know about different things. Keep in mind that while you may like for everyone on the team to read a big design document. Not everyone does.

And if we where talking about presenting a design document to a professional publisher. I would not direct them to the wiki. I would take the core pages of my wiki, format it in word and make it look like a presentable, professional design document.

Wiki for work.

Word for presentation.
Advertisement
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
Don't pay much attention to "the hedgehog" in my nick, it's just because "Sik" was already taken =/ By the way, Sik is pronounced like seek, not like sick.
Quote:
Original post by sunandshadow
- 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.
Not sure that is a particularly valid concern - all the wikis i am aware of allow at least some level of access control/permissions on a user-by-user basis, and have full history support, making editing entirely non-destructive.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

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


A very good question. I'm wondering what's the answer myself.

Since I'm searching for a good wiki solution, I'll post a solution supporting this if I'll find one, but it would be great to checkout solutions that people have already experience with.
Quote:
Original post by swiftcoder
Quote:
Original post by sunandshadow
- 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.
Not sure that is a particularly valid concern - all the wikis i am aware of allow at least some level of access control/permissions on a user-by-user basis, and have full history support, making editing entirely non-destructive.


It could certainly be a problem if someone decided to homebrew a wiki software and didn't implement all those features, or use an older or simply poorer-quality wiki software, or used a good one but just gave everyone administrator permissions. But yes vulnerability to vandalism can be avoided with decent wiki software used properly.

@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 want to help design a "sandpark" MMO. Optional interactive story with quests and deeply characterized NPCs, plus sandbox elements like player-craftable housing and lots of other crafting. If you are starting a design of this type, please PM me. I also love pet-breeding games.

This topic is closed to new replies.

Advertisement