Like tools like trello for organizing big projects, like building websites, apps, or games because its great having all the ideas and features available and I can plan around them easier. I can embed wire frames and tasks list, inspirational images,

But I agree there is something about the having cards in my hand that I much prefer. I like having a stack of cards I can take with me when I unplug from the net. And I use cards for all my chapter notes and story points when I'm working on my writing.

for a long time i was searching for a good way to write gdd but after a while i think gdd is not the most important part.

It's not the most important part. In fact, it can come at the detriment of the most important part (sticking to documents when clearly, the product needs iterating and changes).

That being said, the question is asked in such a way that I can't help but underline this: just because it is not the most important think doesn't mean it isn't important. Making a GDD is good for a number of reasons:

- It allows others on the team to understand, or more importantly, to FAIL to understand elements you're seeking to make (which allows them to ask specific questions and insures everyone is on the same page).

- It forces you to go in-depth with your thought, not just macro-level. Putting things into words also forces you to make decisions. This is good because some questions need to be answered now rather than later.

first one is when endup the obssesion of your new ideas? when you reached the timeline?(for example in interview of cod:ghosts mark rubin said: dog gameplay wasnt in our main design and after watching a documentry we added that gameplay) but how they could controll that for a timeline or how they could be sure that should be great? or end your design when a good tester sais thats enough for this game?

You iterate as you go. You try to build the minimum viable product first (that's, the minimum set of features for your game to be considered complete/playable). It is possible features will creep in during this time, because what you considered the MVP yesterday may not be the same as what it should be as you go (playtesting will reveal that).

The limit between changing the focus of your MVP to make a better game and utter feature creep is slim. It takes cunning, experience, and a good flair to 'know when'. I'm afraid every context is so specific that I can't give you a general answer to that. Essentially: you know your game is ready when nothing on your backlog of things left to do is critical to implement. Defining 'critical' would be tough.

the next problem is most of the time your idea is amazing but (i dont know what you call it) its not a cooked idea and you cant implement it fun. how you should behave that? put it aside for another game and maybe another tools or engine or continue working on it untill it is good enough even if it takes much time.

I'm afraid I don't understand this one. Can you refine?

the next problem is most of the time your idea is amazing but (i dont know what you call it) its not a cooked idea and you cant implement it fun. how you should behave that? put it aside for another game and maybe another tools or engine or continue working on it untill it is good enough even if it takes much time.

There's no easy answer to that, but getting other people to take a look at it can help you decide. They might have suggestions, or they might just say "Nope, that probably won't be fun even if you keep polishing it."

It forces you to go in-depth with your thought, not just macro-level. Putting things into words also forces you to make decisions. This is good because some questions need to be answered now rather than later.

I wanted to say this, but you went ahead and did it for me, so's all I can do is just nod my head yes as I click +1 for Orymus3!

Seriously, though -- the above is very, very true. Any way you can think things through will pay off, either through cutting or through polish.

Every serious game project could use a GDD in my opinion. But write them after you have the rough gameplay /game idea figured out so you can start thinking how will different features scale and combine.

You can acknowledge not every part of the game development is driven and controlled GDD because some things you just need to try in-game and see what feels right like player movement speed. But at least you should think of story, graphical style, asset creation pipelines, schedule and aims...Ideally these are not things that you hack together as you go.

Those who use a "living" design document to track the process of their iterative design might also try Daniel Cook's idea of "Design Logs". :)