[INFO] Before posting about an MMO, please read this...

The following is some advice I both learned the hard way, in having two false starts with my own project, as well as advice I picked up from other community members who have been down the same road as I am travelling and you would like to travel. Because MMOs are very popular and more and more appear every week, many people believe that they, too, can create an MMO. Well, you might very well be able to create an MMO, but before you go running off into the forums to get a team together and start asking questions about how to make that kind of game, take the time to read the below. Even though this is not written to discourage you, you still may not like everything written in this post, but you should note it for when you need it, and read it all the way through, even if you feel discouraged. You'll find some interesting advice and ideas throughout this posting.

Do not take it personal, but do take it to heart:

Golden Rule: Do not look for a team until it is absolutely necessary. What you should do is:

1) Understand what an MMO is: By that, I don't just mean that you should have played a bunch and know what you would like out of your own MMO, but you should read books about what it takes to create and- most importantly- maintain an MMO. An MMO is a business with a continuing life from the time the designer first thinks up a fuzzy idea for the gameworld until five or ten years down the line when the last server is shut down. And business means hardware costs (more than just a "sick rig", unless you want hackers crawling up your server's wazoo at 2am while you're sleeping), software costs (server OS, antivirus, dev apps, database apps, art apps etc), web hosting (you need a front end website), and community management (who's going to answer the help desk at 2am when the hackers turn your server off?).

That means you need to build up knowledge of the business side of MMOs, and it's not easy. You're building something that is not just a game, but a service. It's not impossible either, so go get the books and start reading!

2) Understand what you want your particular MMO to accomplish: After you understand exactly what it takes to build an MMO, and you're still confident that you have the desire to have a go at it in an indie fashion, then it's time to sit down and flesh out your ideas.

The first thing to realize here is that this is NOT the point to go get a team. This is the point where you need to have a by-yourself-meeting and come up with a backstory for your world, the areas, factions, and what makes the world tick at a high level. Find out what kind of gameplay you want to have in the game (if you can only describe that gameplay in terms of a half-dozen games it would be "like", then you're nowhere near done). Sketch out GUIs, NPCs, weapons, towns/cities, or even scenarios. Realize also that these sketches can be horrible or done on napkins, but it helps you understand what you want. If you don't understand what you're building, you cannot expect anyone else to build it.

And when you're done with the high-level view, delve into some details. Not everything needs to be fleshed out in this step, but the more you have on paper, the less you'll have to think about it later in the development cycle when you have other things to think about. Go ahead, geek out on your design and create documents like an encyclopedia, or diary entries or stories that get your point across. Don't be shy about it, let loose- it's the best way to be creative, and you'll find that some of the ideas you normally think would be crazy actually take your game world to new and more interesting directions!

3) Understand your skills: It takes more than just an idea to build an MMO, and I can tell you that there are 1000 MMOs slated to emerge by the end of 2009, all with ideas. About 95% of them will fail miserably, and some of the 5% will be close calls, but still miss the mark. But by this point, you know what they go through to make those games, and you know what you want yours to be like. Now it's time to look in the mirror and see what you have to offer a team.

Now, to be blunt, if all you have is an idea, then you'll get nowhere unless you have an idea and several million dollars. Don't be offended, but it's a fact that applies to us all, for all business ventures large and small. If you're a writer, then you can use your writing skill to some degree to get your visions across to the team, and you can write content for the game. Better still, if you have a bit of sketching skill (and if you practice, you'll probably find that you have enough to communicate your idea to a better artist that you'll bring on board later), or even better if you can pick up scripting and/or coding. Since we're talking about MMOs, you should also know some things about database design, SQL, installing, configuring and maintaining operating systems, and business. These last skills are must-knows.

What coding offers is that you can sit down and bend the game engine you choose to your will, or with scripting you can test out or implement gameplay features, which is invaluable if you want to be a designer. It's absolutely essential, in my (and many others') opinion. But again, you need at least one (preferably two or more) of these skills.

Other skills you should have are MS Office- specifically Word (documents) and Excel. Excel is a not-so-secret, but very overlooked weapon for creating, testing, and balancing gameplay. If you learn just a little bit of Visual Basic, you can put code behind Excel spreadsheets and test most of your core gameplay before you even choose a game engine! Imagination is key as well, since many game developers use pen and paper roleplaying methods to test gamerules before committing to the design, or use scraps of paper as mockups of the interface that they move around to get layouts correct. The point is: Learn and use skills and methods that get you where you need to be!

4) Understand what game engine is best for you: So, by this point, you have a grip on the work involved in MMO projects in general, the scope of your own project in specific, and you have some skills that you bring to the table (if not having some work done on the game mechanics already). So now look for a game engine that suits your needs. Not all game engines are equal, and no engine can be termed "the best". They all have slightly different feature-sets, and that means that you'll spent a couple of weeks (or even a month or two) comparing engines or reading their documentation to understand what they have to offer you (because just asking if they do on their forums will not yield as good information as if you understand what the docs tell you directly). Realize here that any engine you pick is likely to lack some feature you will need. That's just because there is no such thing as an engine that is "perfect" for your project.

After you sort through a bunch and narrow them down, you can compare costs, licensing, and support, because these things are usually not the same for different engines. Then make your choice, but make it well, because if you choose to switch engine in mid-production, it may sink your project.

The second part of this step is that once you've chosen your engine, make a list of the changes you'll need to make to the engine (and hopefully in your review of the engines, you also looked at how much effort changes to the engine are to get your features into it). That list you'll want to set to the side until Step 6, but get it done here...

5) It Begins! Start scripting/coding... BY YOURSELF: Seriously, you should start scripting or coding the gameplay without a team at first. Don't worry if you don't have the best graphics in your gameplay tests, as long as the gameplay is fun. Graphics will come, but icons with stick-figures, placeholder art like cubes, or "stock" art that comes with your engine or purchased for cheap can stand in for better, custom art that you bring in later. Remember what I said about using Excel and other cheap tricks to get your design moving along!

Right now is when you need to be laying the foundation of the game. You do this without a team for as long as you can, because when you finally need a team, you'll have working features, and artists can see their assets in the game right away. If you bring a team on with no functionality to test their assets against, they'll get bored and leave!

Try not to get "married" to features. Understand that sometimes a feature, while cool, may take away from the overall fun factor of the game, and should be tossed or redesigned.

6) You have gameplay, now you need a team! If you've done everything right, you have some skills, documents, knowledge, and gameplay mechanics (or rules) to attract a team, and a list of working features (maybe backed up by screenshots or vids) to show them the gameplay that they need to make look good!

Here's the truth behing the "my game idea is so great/unique, I can't share it": It's just not true. What is true is that any game developer out there who has it in them to create a game has a dozen game ideas floating around in their head waiting for the current project to finish so it can get a chance at being the next project. And because there are so many ideas out there, there is a chance that someone has your idea already, but came up with it themselves. There is nothing to be scared about in this- game development is all about how to execute your ideas- not the ideas themselves, and two game developers with the exact same idea can make wildly different games.

Here's the business part: Make sure you have equity agreements in place, as well as NDA's for intellectual property, and that means that you better not be stealing another game for your own, or you'll get sued from here to the moon! THIS MEANS ANY "FAN" HALO/DRAGON BALL Z/ETC- EVEN IF IT'S NOT A GAME YET, OR YOU'RE MAKING A "FREE" GAME! IT'S NOT YOUR PROPERTY TO USE!

Here's the other business part: Make sure you see 3d artists' portfolios, hear musicians' samples, read writers' samples, and get a feel for the knowledge of coders, dba's, and scriptors. If you don't, you'll get sub-standard or flakey people, and with no one to blame but yourself.

Here's the management part: Make sure you avoid being too bossy. Remember, you're probably not paying your team, and even if you were, no one likes to work for a jerk. It may be your idea, but their work means that they have a stake in it too. So refrain from being curt, short, snippy, arrogant, bullying, snide, sharp, or stupid with your team members. Some of them have school, some have significant others and/or children, many will have day-jobs. Some of them may feel their motivation decrease at some points, and it would be your job to keep them motivated. If they don't feel they can talk to you (and working over the internet already makes that hard), then they may just pack it in rather than stick it out.

7) Get to it: So you have a team. Good for you. Get to work, and push until you hit the finish line. Don't be a dick to your team- they're probably working for free, and they'll leave you. Don't deviate from your vision, or you may get lost. And keep development communities aware of your progress, because they can be the start of your viral marketing (and be your first customers!).

Network with other developers, go to conferences if you can, blog, post on forums, avoid flamewars (it is hard, I know, and we're not perfect, but do try), and let your enthusiasm precede you- especially on the days when you don't feel all that enthusiastic. Stay positive, stay motivated, and kick some ass!

8) Done! Just kidding, you're not. Now that you're ready to launch, you need to build the network infrastructure to handle it (you did network stress tests right? Load-balancing? Do you have payment software set up or are you going through a 3rd party solution? Security? Community managers? You did beta test, right?).

Launch day is the roughest, and expect lots of problems. Knuckle down and get to it. You might be awake for the next 48 hours... And then when that's over, the real work of maintaining the game begins :)

Well, there you go. It's not pretty and sounds discouraging, but if you can't take reading that, then you have no business doing this. Odds are, if you're reading this, you've made it through okay, so go back to step one and start doing it. You may fail. There's nothing wrong with that. Failure is a learning experience, and if you understand your failure and have enough chutzpah, then you might be able to take another swing at it. Or maybe you'll succeed, and I might be a customer. Who knows.

But if you just jump right at your project before you know anything about it, your odds for failing go way up.

Like I said, don't take this personally, but take it to heart.