Sign in to follow this  
drackill

Game Design Standards?

Recommended Posts

drackill    128
(Just posted this in the wrong place sorry) here we go. I'm just wondering if there are any standards when it comes to Game Design, like specific layouts the industry uses? I apologise if this question has been asked before. If there is, could anyone post a link to one or recommend a good book that covers game design? Thank you for your time.

Share this post


Link to post
Share on other sites
JBourrie    1204
I've never read a book that really stands out in my mind as an exceptional tutorial on writing game design documents. Theres a good reason : every games needs are different. There are a few rules that you should follow to ensure that you have a good document, but other than that the expectations change with every project.

- Be sure to design everything. Don't assume that by saying "spacebar to jump" everybody will know how the game feels to play. How high do you jump? What is the feeling that the player should have while jumping? What interactions can you have while jumping? etc..

- At the other extreme, don't overdesign. Your document should have all of the relevant pieces of information in all of the relevant places, without all of the extra fluff. For example, if you have a heavy focus on story the GDD should discuss the basics and the rest should be in an appendix. Monster stat tables? Appendices, please. Exact level layouts? Leave that to the level designers, because level design is not a "plan it and it'll work" process.

- The game design document should be written in a way that if you give it to your team and then die in a tragic toaster accident, that the game that your team creates will be reasonably close to your original vision. This means no assumptions can be made that "they should think like me".

- The GDD should be written for all audiences that might read it. This means if you're the only one that's reading it, you can make certain assumptions, but otherwise you'd better consider the target audiences. For example, marketing wants to know why this game will sell. They will often only flip through the first few pages to get a basic idea, so the first part of the document should get the game description and it's best selling points out of the way. The programmers often only care about implementing their piece, so offer a strong index and make each module as self contained as possible.

- Don't assume that everyone will understand ever piece of the document. Reiterate points if necessary, such as when they affect multiple modules. You can require that your team read it, but that doesn't mean they all actually will.

- If you create a draft copy of your timeline along with your GDD, you will be able to keep a better handle on the scope of your project.

I have some example GDD's up on my website (www.jbourrie.com) under projects (Rumble Box and Thelema). While they were written for school, I assumed that the documents would be given to the suits, marketing, and programmers, and wrote them accordingly. While they are not perfect, I think they are a decent starting point to look at what your GDD could look like.

If you really need a book, the following books discuss GDD's pretty well:
Game Design : Theory and Practice
Swords and Circuitry


Hope this helps...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this