The original RedLines game spawned out of Ludum Dare. You can read about it's conception in a previous post and play it here.
 |
| RedLines 2 procedural level generator |
Game Design Document
I'm an amateur, so when I write a heading that says "Game Design Document" and proceed to share something titled RedLines 2 Design Document, maybe don't go preaching my style like a holy scripture. Or maybe do! Maybe it really is that good? (it's not)
Broken down into a list, here's what we're finding useful about a GDD
1. Minimising 'scope creep'
After Ludum Dare, I was creating and coding without worrying about my direction or list of features to implement. Without a deadline I can do ALL that cool shit I didn't have time for! Woah there slow down.
First, you need a deadline. A project is a temporary endeavor that you should always be thinking about how to finish. Second, if you didn't restrict yourself on content to make then you'll spread yourself thin and never ever finish.
 |
| taken from http://m.odul.us/ |
First, you need a deadline. A project is a temporary endeavor that you should always be thinking about how to finish. Second, if you didn't restrict yourself on content to make then you'll spread yourself thin and never ever finish.
Our design document makes an explicit statement about what the game is and separates ideas for new features into essential and nonessential. Be realistic. Stay your course. Finish on time!
2. Collaborative communication
I've invited some fellow game developers to help me finish RedLines 2. With a GDD at hand, I hopefully don't need to be online to answer questions about the project. If not, then it's my job to improve the document with answers to the questions I get asked.
Be wary about using a document as a communication tool. You cannot assume that everyone is reading your document - there must be other regular channels like instant messaging. Whoever is leading your project - it's their responsibility to keep everyone on the same page (DID YOU SPOT THE PUN?)
 |
| image source unknown (soz) |
Be wary about using a document as a communication tool. You cannot assume that everyone is reading your document - there must be other regular channels like instant messaging. Whoever is leading your project - it's their responsibility to keep everyone on the same page (DID YOU SPOT THE PUN?)
3. Feedback and discussion
 |
| taken from http://zethiskatana.deviantart.com/ |
With my master plan out in the open any old pair of eyes can scrutinise, criticise and comment right there in the document. Free feedback is awesome.
Tips for writing your own GDD
I wrote up some tips for writing a GDD here.
They're not for everyone
Charlie Cleveland, Lead Designer / Producer at Unknown Worlds (of Natural Selection 2 fame), recently tweeted that he doesn't believe in game design documents. He has a lot more experience than me. I can't be sure, but maybe Cleveland is referring to some more formal description of a design doc, set in stone before development begins? I know I've read about that sort of approach somewhere, but it seems silly to print out pages of designs that are bound to change when you start making and playtesting.
No comments:
Post a Comment