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.

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!