All games are hard to make. But when ranking my own personal experiences as a dev, I’d say that single-player games are the most straightforward and predictable of projects (relatively, of course), rescuing failing projects is vastly more complicated, but building MMOs from scratch is the most challenging of all.
To begin, let’s define what I I’m describing as an “MMO” because that term’s definition has been stretched a lot recently. To me, an MMO is a virtual world. And in game terms, a virtual world is an intertwined set of polished features around a solid core game that allow players of diverse interests to find their own niche while also simultaneously contributing to common goals for the betterment of their team/allegiance/side. Preferably all of that is neatly packaged within a well-defined mythos and, oh yeah, the entire thing has to be staged as a persistent environment so it feels immersive.
That may sound enormously complicated, but it’s actually much harder than it sounds.
It’s going to take hundreds of people working together for years, spending $50-100M in the process to realize your dream, and it all starts with an empty Word doc. It can be a bit daunting if you think about it too hard.
But if you ever get the amazing opportunity to captain one of these ships, here are a few suggestions on how you should set your course.
Define the Core Game
The “core” of your game is the moment-to-moment gameplay that the gamer experiences during their most memorable game times. For many (most) AAA-games that core is a combat model of some sort. That’s not true all big games, but it’s true of the vast majority, because well…you’re allowed to build stuff in real-life, but you’re never allowed to actually wreck stuff like you can in a game. And wrecking stuff is ridiculously fun. Don’t ask me why, it just is. It’s therapeutic.
But back to the main point: Your project is never going to get beyond break-even unless your core game is fun. That probably sounds like a no-duh to most of you, but it’s amazing how many games just never really nail their core.
If your core isn’t fun, then you WILL fail.
Why? Because the “mystery meat” of the game industry is critical mass. The games industry is very much a “winners out” kind of deal. Once your game gets big, it tends to get bigger.
And that should come as no surprise, because every gamer…100% of us…likes to brag. Don’t get defensive or PC on me. You know you do. We all do.
Pop Quiz: What’s your favorite game?
Whatever your answer was, it has one thing in common with every answer that every other reader gave:
You’re good at that game.
Maybe you beat a challenging single-player game, or maybe you’re proud of the skills or items you gained in an online game that you love, but you’re good at it.
And humble pie be damned, you like telling your friends that you’re good at it.
Now combine that with the natural social tendencies of humans. We like to be recognized for being good at something. When you got good at that obscure game and tried to tell your friends about it, weren’t you disappointed when they couldn’t relate and didn’t care? On the flip side, hanging out with a group of gamers all playing the same game is usually a very fun conversation because you all have a passion in common and stories to share.
So players have a natural tendency to be attracted to games that lots of players are playing. Because that way, when they tell a story about it, it’s a lot more likely that people are interested to hear about it.
What this means for your game design is that your core gameplay better rock during that first critical 10-20 minutes of playing. They better have fun with it right away and, if you’re really clever, you’ll let them brag about it.
If you’re not successful with that first 20 minutes, then the only people that stay with your game will be the ones that are truly passionate about some unique feature in the game. You might make decent money that way and keep your team afloat or maybe even grow slowly, but your road will be harder and you definitely missed your shot at the AAA big leagues.
Lock and Load
Once you figure out a great core game, do not allow it to change! You’ll be tempted while you’re adding other systems to modify things you honed earlier. Don’t do it. All other design elements must bend around your core and adapt to it. Never the other way around.
Any change made to your core game after you define it should ONLY occur when it’s an obvious and resounding improvement to that core game. Even then, you need to be extremely careful, because all the systems you’ve built up until that time were built around your original core. Small changes often have huge ramifications.
But keep playtesting the game and tinkering as you go. Constantly encourage your team to play their own game. If they stop having fun, talk about why and see if something needs fixing. If you can’t keep your own team enthused, then your team is not fully engaged. Welcome to B-quality.
Build a World Around your Core
Considering how critical the core moment-to-moment gameplay is for your project, and considering how much effort you’re going to put into the systems surrounding that gameplay, it’s odd that the long-term success potential for your game usually comes from systems outside of that core.
Because when you’re building a virtual world, you’re building a game for people that like to grow with a world that’s ever-changing. You’re building a project that will entertain players for 5-15 years. Most games have an average gamer lifespan measured in months. It’s a completely different ball game when you’re building to keep them entertained for decades instead.
Your players need as many varied ways to “win” as possible. What you’re creating here are entertaining games within your larger game that allow critical and creative subsections of your player population to become famous/useful for their efforts, and in doing so, make the game a stronger whole by knitting players together.
Additionally, core gameplay has to be buttressed and interlaced with humanity (as in “reasons for players to act like humans instead of anonymous accounts with no culpability”) for it to stay interesting and engaging as a long-term world.
Effectively, you are creating user-generated content (UGC) systems within your game. Even the “required” standard world elemnts like guilds, trading, crafting, friends lists, etc. are just the early steps of UGC systems. You (the designer) provide mechanisms to the players and they run with it to do wonderful things and make the world interesting. But there are many designs beyond these foundational elements you can create to bring players together.
Unfortunately, most game designers don’t fully grok this. It’s the “weird science” part of game design, because what you’re trying to do is create vector forces within your player population, guiding them toward situations where the most fun can occur and the potential for social interaction is at its highest. The good news is that because you created the parameters of your world, you really should have a good idea at predicting what players will do with it, and with practice, you can get good at this.
Your biggest goal should be to create situations where the players happily and voluntarily rely on one another. Combat is not what I’m talking about here. People often don’t socialize in normal ways during combat, especially if the combat is action-oriented. You have to create other times, places and reasons for players to connect with each other at other times during the game.