Hey Guys!
I've heard Tepples suggest people make a game design document but I never found a template for one.
Anyone heard of such a thing? I tried the forum search to no avail. Google comes up with some very generic looking docs but is there something more specific for consoles?
I'm thinking of making an action/adventure RPG with heavy inspiration from Super Pitfall. Yes, I know some wouldn't see where "inspiration" and Super Pitfall meet, but, still!
Thanks in advance for any guidance in this
Game Design Document Template?
Moderator: Moderators
Just make a document that says what the gameplay will be like, maybe some drawing of like a screen you'd like it look like, enemies possibly, etc. Just like these:
http://dl.dropbox.com/u/2590713/SMB1.jpg
http://dl.dropbox.com/u/2590713/SMB1-1.jpg
http://nesdev.com/bbs/viewtopic.php?t=7 ... 91a7154a4c
http://wiki.nesdev.com/w/index.php/File ... n_form.png
That's all I found that may help inside the topic link.
http://dl.dropbox.com/u/2590713/SMB1.jpg
http://dl.dropbox.com/u/2590713/SMB1-1.jpg
http://nesdev.com/bbs/viewtopic.php?t=7 ... 91a7154a4c
http://wiki.nesdev.com/w/index.php/File ... n_form.png
That's all I found that may help inside the topic link.
You're welcome. It's not too qualitatively different from the flow you say you currently use, just a bit more detail in the "sketch out gameplay on paper" step. The more you have on paper, the easier it will be to get other members of your team on the same page.
Try looking through the revision history of the page about my nesdevcompo entry.
Try looking through the revision history of the page about my nesdevcompo entry.
I can easily create grids in TeX if you want it, of any pitch, with any kinds of row or column headers, different thicknesses of lines, all of that stuff. I can even make the NES PPU background plan form using TeX, and you could even write the entire document using TeX, or some "Literate NES" program.
Hey, I recently came across this article on game design documents which you might find useful.
Or maybe not since it says there are no real hard and fast rules, but to write in a way that your programmer's (artists, musicians, etc.) can understand, keep it concise, and you will need to revise as you work on your game, which seems like common sense advice to me.
Or maybe not since it says there are no real hard and fast rules, but to write in a way that your programmer's (artists, musicians, etc.) can understand, keep it concise, and you will need to revise as you work on your game, which seems like common sense advice to me.
From the article that Ian A linked:
This may help you understand why I sometimes spend a lot of time discussing obscure edge cases on this forum.An edge case is a problem that occurs only under extreme conditions. While others are reviewing your documentation, try to find edge cases in your own design. Test the extremes to see if it breaks down.
For instance, here’s a simple design:
“The player’s jumping height is equal to his strength divided by the weight of items in his/her backpack.”
Sounds reasonable. What if the weight of items in his/her backpack is zero? 18/0 means the player can jump an undefined height!