How do you write a GDD?

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.

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.

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,

Media Design Doc

[quote name='third_ronin' timestamp='1313292639' post='4848845']Media Design Doc

I've never been on a project without a MDD.

[quote name='third_ronin' timestamp='1313301047' post='4848864']
I've never been on a project without a MDD.

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.

My question was focusing on the worthiness of a GDD that had no programming content, but I ended up answering my own question after some further thinking.
I was basically under the impression that a design document without any programming information would seem worthless or confusing, but I can lay the ground work for that easily enough so that if I were to share it with a programmer, they would have enough to go on.