[quote name='PowerFang' timestamp='1299804762' post='4784209']
i think its because the design document is not doing anything.

Writing a GDD is not "not doing anything" -- it's "planning."
Planning is important in that it prevents time wastage, cul-de-sacs, and work do-overs.
[/quote]I totally agree about the first part, however "do-overs", etc are part of software development in the form of refactoring and aren't something to be scared about. If you are a fan of Agile methods of software development for example, they espouse not writing big up-front designs but jumping in and creating some working first version, from which you can evolve. I am not a devotee of Agile in the way many are - it's treated by some almost like a religion - but I certainly see no reason games shouldn't be suitable to the approach.

So you want an approach that gets you to something tangible, quickly? I'd like to deviate from the popular opinion that a GDD is the way to go and suggest another approach.

Take your idea - doing missions in space - and make that playable as soon as possible. Some silly UI where you run missions that involve running back and forth. An ugly text game that you can play is better than a beautiful idea that never gets expressed. Make a game for your eyes only - just so you can start playing it.
Then figure out what would be the best addition - and add that. Maybe it's multiple objectives. Or choosing missions. Adding small features, one by one, and keeping the code clean at each step. If you're having trouble getting started then over-designing is more likely to stall the project than avoid hacky code. With small changes, and eliminating duplicated code, it shouldn't be that big of a deal to re-write some code to fit the new scenario. Then make a habit for spending time and finishing features - when you decide what the next feature is - make a deadline for it. Eventually, you'll have your opus (or at least something you want to show your wife).

I definitely get that most people find a design document essential. For a project with multiple people, it keeps everyone in sync. For a project you might sell, it gives the elevator pitch. It can help an individual stay focused on what they're doing and limit their scope to what they intended. It's a essential part of a professional portfolio. If none of those are a pressing matter then I'm not sure it's worth the time. You can always add one later. I just think for a hobbyist, it's much better to move from the "in your head" to "playable" phases than writing down the overview if you're not excited to explain your idea

I'm not a planner so I really don't know how you should do this... but when I read your post I thought about ogame (www.ogame.com)

This game is basically a giant database, and a php script getting the data and doing stuff with it. Which I think is much simpler than making a game with directx or opengl
It might not be what you had in mind, but it might be an easier way to actually "do something" (like your wife says) with those ideas. (think also mafia wars, and games like that)

In fact I started making a game like that with a friend, but it died at about 20%... it was a cool game though... I should retake the idea again.

A GDD just makes sense to any game of sufficient scale, regardless of the number of people on the project. For the WinForms based experiment I did I just winged it but all in all it took me about a day to do. Games taking years to implement need some sort of road map ESPECIALLY if you're the only one on the project. Words on paper are not forgotten over time and they ensure the project stays what you wanted it to be. You don't want to get to the end of the project to be left thinking "this isn't what I imagined." That would frustrate me to no end.

It's basically a spec doc. Which, you need one of these even if you're going "agile" if for nothing else just to document the overall goal of the project. Even if in your GDD you don't put in every planet location it will still be useful.