How much documentation, or asset preparation do you do when going from a rough idea, to a relatively exhaustive action plan before starting production? Specifically for a tiny team of 1 or 2 members...

I've seen stuff like this http://www.cogsci.rpi.edu/courses/icg/atomicsam.pdf, but a 50+ page typed document seems excessive.

How detailed do you go with pre-production before starting to create a MVP or prototype, and what tools do you use to keep organized and stay motivated and on track?

Google docs so anyone can see the last version always. For a team of 1 or 2 I dont think you need anything else..a excel table on google docs with the milestones if you want to keep track of what everyone is doing (pending, doing, finished).

Keep it informal if its just for the team. Place your idea in short sentences like notes, try to have the first sections be just small sentences describing the core aspects, try to have lots of images, like concepts and mockups, this is the fast way to explain the game, to pass the idea.

Then later comes the detailed explanation, which will basically take the small sentences subject and go in detail. Have it properly and clearly indexed in titles and subtitles in the most logical way possible.

For a prototype,1 or 2 team, anything too deep is a waste of time or may become even an excuse to not start or give up half way.

something like

- your game in a sentence

- main aspects in notes

- platform(s)

- player possible actions in notes

- mockups

- concepts

(keep in mind why you want to play the game when writing those)

then the detailed

#Mecanics

-game "loop", the sequence of actions the player can do, this can be storyboard like

-gameplay detailed

-itens

-lvls

those arent a list of everything that will be on the game, its stupid to think you will get that right at first, just put your main ideas and explain so other person besides you get what you mean.

#Graphics/sound

-style, mood and technical stuff you are limited to(resolution(s), scales, file types)

-if you dont have an artist to sketch stuff here, grab references from the internet of what youre imagining

#lore

-universe

-story

-story as presented for the player(time events)

Dont fall for the trap of having a million page just for the lore...fuck the lore, this is not a book, have it at the end to not get in the way if it gets too big.Explain it in steps, do not get artsy fartsy.

The design doc will later be getting more detailed when the team members start to work on each aspect. Ppl should check to see if everyone agrees with what is being made, if there isnt any unwanted deviation.

Thats how I like it.

I don't actually se the point in old fashioned design documents anymore. It makes much more sense to have a design Wiki. Then people only need to save bookmarks to the bits that they are interested in. If one of your designers is a bit old school then they can still write sections as pdfs and post them on the wiki.

Wikis are great for design docs, and you can find free ones that are easy to use (don't use Wikipedia's system. It's the most famous one, but it's optimized for running a large website with lots of visitors rather than for simplicity). For tracking tasks, I recommend using Trello and creating boards for tasks that are To-Do/Being Done/To Test/Final. For the complexity of the game design doc (GDD) itself, after years of trying different approaches, I've come to favor what I call "Just in Time Design". It's pretty simple: you write your design in two separate phases. The first pass on the GDD is written during pre-production. You should write just enough information that people reading it have a good idea of how everything works and what will be required to create the game. It should cover every aspect of the game, but it shouldn't go into too much details. For example, you should include a description of each enemy type, but you don't have to go into specific details like the exact number of hit points or how many animations it requires. Once this document is ready, you send it to everyone on your team to get ideas and feedback (including about whether the design can realistically be made). The second pass on the GDD is written during development. Right before your teammates are about to start working on a given feature (say, the week before), you write a very detailed document about the feature. It should have enough information for your programmer to implement the feature without asking clarifications every 5 minutes and for your artist to do all of the assets. (On a large project I'd recommend to go into lots of details, but for a tiny team who's probably all on the same page, you can probably keep things simpler) Once your document is ready, you send a link to it to the people who will be working on the feature and organize a quick meeting to discuss it. During the meeting, your teammates can ask all of the questions they want and suggest ideas to improve things (this meeting is also important because it will increase the chance that your teammates will actually read the design, which you can never take for granted). Then you add these ideas and clarifications into the document, and that's what they'll use to implement the feature. The great thing about this approach is that it avoids a common problem of other ways of designing games. Usually, either you write everything upfront or you barely design anything at first and design as you go. Designing everything upfront never works because things invariably change between preproduction and the time the feature is implemented, making the GDD unreliable. Not designing upfront is bad because your team is lost and doesn't know where they're going, and you risk making the game way too big without realizing it. Designing the overall plan upfront then adding details as you is the best of both worlds, and it works great with Agile management, if you're using that.

I agree with Icebone.

my design document is very minimalist when it comes to lore and story related bits. as would be when trying to pitch to a producer or investor.

i put what a player should know upon buying the game first:
-the name of the game
-console(s)
-what the game's about (small pararaph about world lore here)
-what do you play as
-what is your objective.

then i flesh out the mechanics. i always start with the players moveset before anything else.
with the moveset i start with the single button inputs first, then work into the more advanced ones.
i like to design my games so that they are beatable with the basic inputs, but encourage the player to master the game through difficulty.

-jumping (many paragraphs about jumping)
>(advanced maneuvers involving jumping)
>a bunch of sketches involving frames and playerstates

-running (many paragraphs about running)
>(advanced maneuvers involving running)
>more sketches about frames and playerstates

-attacking (many paragraphs about the basic attacks)
>(advanced combat maneuvers like parries and nonsense)
>sketches of attacks and hitboxes
..and so on

Gimmicks are next. whatever notable game mechanic that really differentiates your IP from the others.
(think the soul mechanics from Dark Souls, light-based stealth from splinter cell, musical spells from 3d Zelda games)

UI mechanics are next. I think of UI designs that emphasize what the player needs to focus the most on
-main menu
-HUD
-in game menus
-etc.

items powerups, magic etc are listed next. i focus more on types as opposed individual items.
i'd have a separate bible document for properly listing things.

then locations are listed in order of appearance. short sentence describing each zone.

then enemies, in order of difficulty..
exact attack values, hp, and item drops and etc, i'd put in the bible doc.
-enemy sketches
-enemy locations
-enemy descriptions
-etc.

then bosses...

-description

-moveset
-sketches

detailed synopsis would be here at the end. nothing long and draining. just describing player events.
-hero's journey context
-the journey

-the destination
-the ending

for my current project i don't actually have a design document because i thought it through and had the image clearly in my head all since 2012. All i have is that, and a partial screenplay and storyboard. The short duration of the game also helps i guess. I also have Asperger's Syndrome wich propably plays a role here but i don't know. Anyway.....i recommend you to make detailed documents anyway anytime, and especially when doing large project!

Real games studios only write a few pages for a game design document.

See the real world example for GTA 1: http://classes.dma.ucla.edu/Winter12/157A/doc2/gta_gdd.pdf

Personally I usually don't write a gdd.

My last reasonable sized game used a small wiki because it had a team of four developers and my current game has no formal design document , however it is based on a very long novel sized story I wrote when I was a kid which I guess indirectly serves as the design brief.

What's the team structure? Are they designers? Coders? Artists? For example artists need almost no design doc (they just need the overall mood, art style, colour scheme). Coders need it much more, since they will be the ones who implement these, but again, not all of it, just conclusions.

Don't make a mistake assuming everyone in a team wants to be a designer or want to contribute to design. Design is just a small part of making a game, and not the most important one, just telling people what need to be done is frequently sufficient & preferred. In the end it's the execution that counts.

Personally I usually don't write a gdd.

I partially agree and partially disagree :D

GDD being small is *DEFINITELY* a good premise. Analysing my own games, the ones with smaller docs end up better and more profitable. Those with bloated ones ended poor or abandoned.

I would not go as far as saying no GDD at all. Actually, I also have numerous examples when a project was in trouble due to lack of GDD. The key is size. Are you able to put your idea in one or two sentences? If not, the odds are your game will sux...