Different kinds of documentation
Okay, enough game design for today.
I was thinking that I've been trying several different kinds of documentation. The classical "document", wiki and even Power Point to name a few.
If I have to chose a "favorite" I'd say it's the good ol' document, even though I could tell you enough stories about how they're not great untill your hair turns grey, if it isn't already. (I don't know how old you are or what color your hair is. And if you're bald, I don't mean to offend you.)
It's common for people to say that the best kind of documentation depends a lot on the team. The size, the people, etc. I absolutely agree with that, but I also start to think more and more that I depends even more on what kind of game it is.
Maybe something as "straight forward" as a Four of a kind puzzle game works great with a regular document, while a complex Role Playing Game might work better with a Wiki.
Unfortunately I don't know what kind of game works best with what kind of writing.
What kind of documentation do you prefer to read, to write or to work with?
I’ve designed for
 |
 |
 |
Follow me online
Tweets
- http://hills-and-valley-messenger.whereilive.com.au/news/story/small-children-look-at-big-issues/ Jayden is awesome!
- @essell2 When I log onto Gmail it starts playing music, and everytime I click something (like a new mail) a "funny" sound effect is played!
- @tanyajessen I know another thing people will want to do after starring at "Trishka's hot self"...
- I liked a YouTube video -- Bulletstorm Gamescom Presentation with Dev Commentary http://youtu.be/ElgC9HJUDks?a
- Our Lead Project Manager tells another producer to hop onto a cart with wheels and then he pushes her around in the office! Welcome to PCF.
Posts
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « May | ||||||
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | |||
Fresh out of the oven
- Game Over
- The “Designing Producer”
- PowerPoint Games
- Bulletstorm Videos
- The Humble Indie Bundle
- Are we allowed to skew the trailers?
- The acceptance of Video Games
- Teh importance of spelling
- Cleaning Game?
- When Epic met PCF
- I’m gonna be an Epic Game Designer
- Looks the same, plays different
- Spectator Game?
- Play while installing
- “Outside the game”-expectations
Categories
- Causerie (138)
- Game specific (30)
- Misc. (52)
- projects (27)
- web (29)
Latest comments
- 10 Die Hard Gaming Fans showing their Killer Tattoos on Sonic Poem
- Mary Griffin on Norse Mythology
- PowerPoint Symphony on PowerPoint Games
- PowerPoint Symphony on PowerPoint Games
- Makayla Gonzalez on An Actual Level Design Test
Tags
Archives
- May 2010 (7)
- April 2010 (10)
- March 2010 (13)
- February 2010 (10)
- January 2010 (11)
- December 2009 (10)
- November 2009 (12)
- October 2009 (15)
- September 2009 (16)
- August 2009 (12)
- July 2009 (14)
- June 2009 (16)
- May 2009 (10)
- April 2009 (16)
- March 2009 (13)
- February 2009 (3)
- January 2009 (11)
- December 2008 (19)
- November 2008 (14)
- October 2008 (8)
November 9th, 2009 - 23:44
I prefer [reading/working with] wiki style documentation as long as the wiki is easy to navigate and that new changes are clearly marked as such. I don’t want to wander around in a lonesome forest trying to find the princess, I want the princess come find me. Though I agree, static designs (and boy are they easier to work with) should be in a precise document since there is no need for any changes. The most important aspect is that any changes loudly should be made clear to any readers. I am allergic to changes that are silently added, often in the form of one page that is changed but another one isn’t. Make changes in all dependencies, because we (the developers) have to! And please, read it through. Does the document clearly contradict itself? It’s just sloppy to hand out something that does.
November 9th, 2009 - 23:52
Thanks for the input.
And I totally agree with changes having to be very clear.