hi.

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.

as i am the only technical and programer in my team i know what my imagination will be and as i know most of the people in the forum are indie.

and as indie developer you have not much exprience and you just test your ideas that is this possible or not.

so most of the time a fixed design maybe doesnt work.

and even after writing first gdd you find that there is an idea that can be added to your game. but even the way i chose i think it has a big problem.

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?

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.

sorry for my bad english.

I am of the opinion that the best place to put a GDD is a paper shredder. Prototype ideas and see if they work. Writing up a whole concept serves no purpose.

I am of the opinion that the best place to put a GDD is a paper shredder. Prototype ideas and see if they work. Writing up a whole concept serves no purpose.

I couldn't disagree more... sort of. Prototype mechanics and design ideas in a super-agile way (i.e. Promit's paper shredder), but, in any large project, you are going to need a repository for story beats, dialog trees, the flow of locations, and all sorts of design document stuff. So shred EARLY, then document the important stuff. And don't shred it.

Also never consider the design document finished. It is always a work in progress. In fact, keep working on it after game release so you can put out a Remixed or Remastered version or whatever developers are always slapping up on Steam.

The primary use of a game design document is to clearly communicate the overall plan for the game to everyone in the development team, as well as to the publishers. It's suppose to cover things such as main gameplay mechanics, story, visual art style, user interfaces, target platforms, etc. Since this is a document used for general communication, it shouldn't include all of the nitty-gritty details (e.g., how much health a certain enemy has, or how much an item costs to buy). Those details would be in a separate document - likely a collection of loose papers, sketch pads, note books, etc. Before you even start creating a GDD you should have already created a prototype of the game, and you should already have a bunch of ideas written down on paper. The GDD is created only when these ideas have gone through some initial testing and the overall plan for the game is becoming more solidified.

Using a wikipedia for your gdd can also be a good alternative. This way you can always update your gdd as the game progress, and is maybe more friendly user than a big word document :)

Also :

The GDD is created only when these ideas have gone through some initial testing and the overall plan for the game is becoming more solidified.

Don't hesitate to write has many thing as you want on paper, or whatever else, bu I don't think it's really necessary to write a "formal" GDD in the early phase of the development.

Also never consider the design document finished. It is always a work in progress. In fact, keep working on it after game release so you can put out a Remixed or Remastered version or whatever developers are always slapping up on Steam.

Yep, that's why having a easily updatable GDD is important.

Using a wikipedia for your gdd can also be a good alternative.

I've been thinking about using a Wiki, particularly if I hire a freelance 3D artist. Have you had some success with Wikis, Navezof? I use Articy: Draft 2 for all of my in-house work and have grown very fond of it and HATE switching to anything.

Have you had some success with Wikis, Navezof?

I used a wikipedia in the game studio I was and I found it really useful as it is really easy to use and create. For exemple whan I had to implement a mechanism I had directly access to the mechanism's description as the game designer designed it. So yes, it was quite useful, well, that is when the contents where correctly updated ^^'

I also tried to use one for a personnal project with a team of one people, including myself, It was nice to create articles and filling your project's wiki, but not really necessary. I used the wiki which come with an Assembla solution. Which is really cool as there is a svn/git/whatever and ticket system and you can link everything (commit, ticket) to articles in the wiki.

Now, when I'm working alone I rather use google drive and simple documents.

For a team maybe a wiki is useful, but for one people it is maybe overkill :)

rather then a wiki or single document you can only use an online scrum board / collaboration tool like Trello

rather then a wiki or single document you can only use an online scrum board / collaboration tool like Trello

True, Trello is a nice tool for distributing tasks and organising your work (even in team), but not so much for defining the feature or as a replacement for a GDD.

rather then a wiki or single document you can only use an online scrum board / collaboration tool like Trello

There is something to be said about using a physical scrum board. I have one in my office with post-it notes all over it and I love the tactile, in-your-face presence it has while I'm working.