So I did a Developer Journal and deleted it straight away due to sounding completely silly.

I called it "Project Will" and had to do with an MMO kind of thing that was a completely player-driven sandbox.

I want to outsource it but the costs will be ginormous. I want to develop it myself but I have absolutely no skills besides art. What do I do with this idea?

The dot points I posted:

An ambitious project to change the gaming landscape

Completely player driven

No NPCs, quests or built in lore

Online, persistent world

Combat is optional

Many occupations to take

Players will be able to build their own assets maybe making a profit

Players carve their own story

Native Oculus Rift support

Basically true sandbox

No intro or tutorials, straight into the action from the start

No mobs, players take care of that role

Griefing will somehow be disallowed

Players can opt out of PvP situations

Procedurally generated world as well as public events

Playable personas completely customizable from scratch, only with choosing their species and race

Multiple servers with different "procedurally generated" worlds respectively

There will be a limit in customization, materials in the world can only be used to customize

Limit in world size, maybe the size of France

Servers treated as "nations" somewhat, invading other servers maybe possible

Social interaction with other players very important but not mandatory

Players shape the lore themselves

Cave formations can be found and not instanced

World will start out with no buildings, players create their own using a separate application

Limits in what you can make, for setting purposes

Basically everything I thought of that has to do with the mechanics. The setting and style i'm not sure about right now.

Hope someone can help. :)

"I have a game idea!"

Your idea sounds a bit like Second Life, perhaps with a few more typical "game" type features initially available -- you might get some ideas from what they've done. :)

One of the things a lot of people need to consider when they have an idea that just isn't feasible to implement on their own is the concept of an MVP.

Flesh out your design and then choose a small feature set that you can manage on your own and implement this as a Minimum Viable Product which you can use to showcase your idea. Using this you may be able to encourage people to help you or even pull in investors.

I'll probably be flamed and told i am wrong for saying this, but big design up front is a throwback.

Make a very short design document and leave it open and flexible then dive in.

Be prepared to change the design often and follow an "agile" methodology.

There are many types of designs.

Some of them should be short. Some of them should be long.

The GDD is one of those where more is better. It is usually a living document that is adjusted many times over the course of the project, but that document should be quite complete before you delve too deep.

It needs to cover all the details that are important.

To give an idea of scale:

One of them a few years back for a small project (roughly $3M development) was all kept in wiki format. Since our counterparts at Hasbro insisted on a paper version we figured out how to print the pages on a wiki with minimum markup, turned out being about 400 pages.

For the several years I was working on Sims 3, every one of the hundreds of game objects has its own design document kept in a database. Every object has a design document with common features: a brief 1-2 paragraph description, a concept drawing, the size of the object's footprint, a step-by-step guide for every possible interaction (many interactions are linked, such as the common "view" used for statues and display items), and descriptions of the type of modifications it gives to the characters. For simple objects (e.g. themed dragon statue for the Dragon Valley world) the design was 3 pages due to concept art and depictions of how different sims interpret the item. For complex objects that get little additions in every expansion pack (e.g. the computer, the radio) design documents have grown to over 100 pages that are never really printed. Repeat the design documents for every single item in the game world. I was one of the few programmers who printed out every design doc before I began working on it. When we were talking about an object design and it crossed the 10 page mark, usually I'd have a discussion with the designer and we'd talk about simplifying the object.

Design documents like that need to be fairly in-depth. "Interaction: Play slots. (Little matrix grid showing availability by age/gender/species/needs.) Sim walks to the slot machine. animation, audio sim pulls a lever and the slot machine spins and makes a noise. Tunable odds of winning based on base odds, gambling skill, computer skill, and techniphobe trait, and if the machine has been hacked or not. If the sim wins, animation, audio, VFX the machine lights up with a noisy siren, the sim plays an excited animation, and money comes out. .... " and so on for about five pages. It is formatted nicer with indents and such to help with decision trees but that is typical of the content. They serve as an item-by-item feature set for everyone to implement. Each discipline can see what they need to provide. As a developer I can put a checkmark next to each line as I complete it. As a tester they can also put checkmarks on each item to verify it is feature complete and doesn't violate expectations.

Agile is great for the lower-level API, for the program code, for implementation details. It would be inappropriate for the designer to specify the API calls the programmer should make. But the designer must specify every important detail in the design which causes them to grow quite long. For more complex systems like AI the formulas should be completely written and rock solid before any code is written. For game objects every potential interaction needs to be figured out before the game object is written, the concept art needs to be provided and documented before models and textures are created, and the expectations for audio and effects and other systems need to be clearly communicated by the designers before the object's design is approved.