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.

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.

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.

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.

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.

your other leads should be pumping out their MDD,

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

[/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

Media Design Doc

Oh! Hadn't seen that term used before. Practices vary; practices evolve.