Jump to content
  • Advertisement
Sign in to follow this  

Game Design Standards?

This topic is 4861 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

(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
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
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!