Jump to content
  • Advertisement
Sign in to follow this  
Purgatorio

How do you write a GDD?

This topic is 2527 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

Question: "How do I, as a writer and game developer, create a thorough enough GDD without understanding the programming aspect of the game?"

I'd like to create story outlines and GDDs for the ideas I currently have, for use as either samples with my resume or for (ideally) potential projects down the line. The problem is that I do not program but would like to include game mechanics and other relevant etcetera in the document; it's my assumption that if I were able to gather the necessary team components to work on one of these games, that the information I have supplied will be sufficient to explain the general idea.

Now, my dilemma stems from the fact that I have no way of knowing whether or not a game mechanic is feasible for a programmer to accomplish, nor do I understand the difference between the different game engines and how these might affect the game in the grander scheme. It's not practical for me at this time to learn programming, or to learn the 'fundamentals' of these engines mostly due to time constraints and existing work I have. As a writer, however, I am capable of producing everything else outside of the programming aspects of the GDD. But is that enough?

So, why do I bring the programming aspects up? I've seen examples of GDDs and the majority of their content seemed to be technical -- and I want to know if a GDD without the technical specs is worth anything in the 'bigger picture'. I believe that, yes, it would, but I'd like to know more about composing these documents solo with what abilities I actually possess. I'm sure any foundation is useful in the creation of a game, especially one that is organized and laid out in easy-to-understand language. Yet again, I'm curious to know if I have the wrong impressions or if anyone else can shed any light on this topic.

Share this post


Link to post
Share on other sites
Advertisement

Question: "How do I, as a writer and game developer, create a thorough enough GDD without understanding the programming aspect of the game?"

I'd like to create story outlines and GDDs for the ideas I currently have, for use as either samples with my resume or for (ideally) potential projects down the line. The problem is that I do not program but would like to include game mechanics and other relevant etcetera in the document; it's my assumption that if I were able to gather the necessary team components to work on one of these games, that the information I have supplied will be sufficient to explain the general idea.

Now, my dilemma stems from the fact that I have no way of knowing whether or not a game mechanic is feasible for a programmer to accomplish, nor do I understand the difference between the different game engines and how these might affect the game in the grander scheme. It's not practical for me at this time to learn programming, or to learn the 'fundamentals' of these engines mostly due to time constraints and existing work I have. As a writer, however, I am capable of producing everything else outside of the programming aspects of the GDD. But is that enough?

So, why do I bring the programming aspects up? I've seen examples of GDDs and the majority of their content seemed to be technical -- and I want to know if a GDD without the technical specs is worth anything in the 'bigger picture'. I believe that, yes, it would, but I'd like to know more about composing these documents solo with what abilities I actually possess. I'm sure any foundation is useful in the creation of a game, especially one that is organized and laid out in easy-to-understand language. Yet again, I'm curious to know if I have the wrong impressions or if anyone else can shed any light on this topic.


This isn't fact, just my opinion:

I feel that it would be possible to write a GDD, but you must understand your limitations and also stretch them to the limits. You may not be able to program, but if you have played enough games you should have some sort of idea how to break your idea down into more definitive parts that a programmer would better be able to tackle. Make it as clear and concise as possible while not losing your overall view, and also leave some room for flexibility and consultation/amendment.

Share this post


Link to post
Share on other sites
I feel that it would be possible to write a GDD, but you must understand your limitations and also stretch them to the limits. You may not be able to program, but if you have played enough games you should have some sort of idea how to break your idea down into more definitive parts that a programmer would better be able to tackle. Make it as clear and concise as possible while not losing your overall view, and also leave some room for flexibility and consultation/amendment.
[/quote]

Thanks for the reply.

That's a very simple, logical approach. And yes, I could certainly break down the mechanics for anyone else to grasp. Part of my inquery was also aimed at the typical lengthiness of a GDD, and whether or not a programmer or employer would be sifting through 50 blank pages to read the 3 that actually have something written on them. But what you said is useful in that I can do my best to populate as much of the GDD as I can by myself. As long as my work is there and coherent, I think that can get the point across.

Share this post


Link to post
Share on other sites
Most GDD gets rewritten over and over in order to adapt and develop, so I would not get too worried about every single thing making sense. If a certain feature is not possible, you and your programmers will most probably be able to find an alternative solution, however you need to write down the original idea in order to give everyone a grasp of what you want from that certain feature. Also, as poster above mentioned, as designer you gave probably played quite few games so you should have an idea of boundaries for what is possible, and I somehow doubt (no offense) that you can comeup with an impossible-to-implement-in-some-way feature in a single player game unless it is something very dynamic or smart AI.

If you need help on structure of GDD, I would suggest checking out "Level up!" book, it got a nice GDD template at the end.

Share this post


Link to post
Share on other sites

1. That's a very simple, logical approach.
2. As long as my work is there and coherent, I think that can get the point across.

1. That's the only kind of approach to use!
2. Yep.

Share this post


Link to post
Share on other sites
Remember GDD's are living documents that are meticulously updated throughout development. A LOT will change as you learn what is really possible within your development cycle vs. what you thought was possible.

Start with the broad strokes: high concept, target platform and audience,game play, art style, audio, scale, etc. A good lead artist will provide the visual representation of the lead designers vision, and a good Lead Programmer will tie everything together, making the game itself possible.

And remember, as you flesh out your GDD, your other leads should be pumping out their MDD, and TDD. ALL your leads should be providing detailed production documentation.


Good luck and get writing ;) Documentation is a crucial (but sometimes neglected) part of development.

EDIT: BTW, make sure you create and update a readme that covers revision history for each document.

Share this post


Link to post
Share on other sites
Why don't you write games for something you DO understand? Design some card games or board games.

That way you're not writing in such a rarefied space.

Share this post


Link to post
Share on other sites

[quote name='third_ronin' timestamp='1313214135' post='4848520']
your other leads should be pumping out their MDD,

:blink: :unsure:
[/quote]

What did I miss? The Art Lead should be working on the Media Design Doc, and the Programming Lead should be hammering out the Technical Design Doc. Everyone writes documentation :P

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!