# I have an idea that I think could be successful, what do I do with it?

This topic is 1095 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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. :)

##### Share on other sites
Put the idea in writing, and start learning about making games. Decide if you want to make a career in the industry, if you want to get a job in the industry or do it on the side. Decide what role in games is right for you (programming, art, audio, design, marketing, executive, QA...). Keep polishing your idea while you prepare yourself for your career and learn the skills you need.

##### Share on other sites

"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. :)

Ahh SL is a big inspiration and I played it a fair bit.

Yeah, my ambitions are pretty similar. XD

I just don't know how to sustain the servers and such as a one man team.
Everything else I can do but most if not all MMOs/multiplayer games have teams of 100+

##### Share on other sites

I just don't know how to sustain the servers and such as a one man team.
Everything else I can do but most if not all MMOs/multiplayer games have teams of 100+

Consider the possibility that you can't?

##### Share on other sites
Do you have just the dot points, or are you actually designing it?
What you have at the moment is only the very, very starting point for a game idea. There's months of work ahead to turn it into a rough game design. Edited by Hodgman

##### Share on other sites

you're talking about a very large (at least) project, which will require skills, tools, and manpower.

you can acquire the skills and tools over time.

assume for the moment you can maintain the game alone once its done. not a safe assumption, that's the first hurdle to figure out a solution to - but if you can:

you could probably do it in 10 years or less. 3-5 years minimum for a basic implementation (if you're a fast learner).

recruiting additional warm bodies to the project will help with manpower and perhaps skills and tools as well - thereby cutting development time.

a rapid prototype might help in recruiting - and never underestimate the power of cash! <g>.

We'd all love to do games on the level of a Cecil B DeMille movie, but such things are usually simply not practical. and probably not profitable either. OTOH, if folks didn't do stuff like that every once in a while, we'd never have great works of art. profit isn't everything.

one thing that may work in your favor is the game seems to have an emphasis on player generated content, which may help with manpower if you can build a simple game framework that players can flesh out for you.

.

##### Share on other sites

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.

##### Share on other sites

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, animationaudio, 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. #### Share this post ##### Link to post ##### Share on other sites One of them a few years back for a small project (roughly$3M development) was all kept in wiki format.

I agree with 99% of what you said. When an investor has provided \$3m, they want to see the big GDD to know they will get a good return on their investment.

For Indies, lone wolves, and newbies starting out it is my personal opinion that a large GDD can be a deterrent that puts people off their big idea. I guess sometimes this is good because it teaches them that their goals are too lofty and to scale back a lot.

Other times it could frighten away someone from gamedev.

Definitely,  for those wanting to get a taste of real world software development, do it your way. :)

##### Share on other sites

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.

Or Landmark. Which not surprisingly, is created by SoE who have lots of combined MMO experience already.

Negazina, I think you are pretty close to figuring out what your limitations on the design are. Setting up and maintaining the infrastructure to support a MMO with thousands of players has a very different set of problems to solve outside the domain of gameplay design and programming.