It’s not the MMORPG you are looking for

Posted by admin on July 10th, 2011 filed in Games

Did you ever see someone in a DIY store telling one of the employees: “I want to build my own house, where do I get bricks around here? What is this mortar and foundation stuff I keep hearing about? What do you mean, do I have a plot and building license already…?” That’s what it feels like when people in game development forums have to tell newcomers “Why You Shouldn’t Be Making an MMO”. It’s sad to see formerly enthusiatic posters silently disappear, only because they were ridiculed for (I’m exaggerating) asking why the game engine doesn’t have a “Save as MMORPG” menu item.

Because what these developers wanted is not necessarily an MMORPG.

Many seem to throw out the word MMORPG as a synonym for “especially awesome multiplayer game”, but there is a difference, especially if the sentence starts with “I want to create” and not with “My team of experienced senior developers and I want to create”…

  1. “Offline” games: Basically the default single-player desktop or mobile game.
  2. Online games: Single-player games that you play in a browser or (mobile, desktop) client. Sometimes you can share your highscore with other players online.
  3. Multiplayer games: A dozen or so players join an instance of an online game together. The game is hosted on the internet or a LAN. When the game ends, characters inventories and levels often reset to their original state, only few multiplayer games persist the game world.
  4. MMO (e.g. MMORPG): Massive multiplayer online games (e.g. MMO Role-Playing Games) have a massive number of players, several thousands at a time, in a massively complex game world. You have to persist players that log off, while synchronizing the game state of the thousands that are still playing. Hosting an MMO requires expensive datacenters and playing is typically not free.

If you want to become a game devloper, seriously, start out with a single-player desktop game to get the hang of it — and if it’s only reimplementing tetris or your favorite shooter. Don’t laugh this off, the task also includes laying out challenging levels, designing a user-friendly interface, creating a useful settings panel (e.g. let players change keyboard inputs), saving and loading games, keeping track of the score, not to mention designing numerous multimedia assets.

After you completed this “easy” task, proceed to the next level, the singleplayer online game: Split your code into a client and a server, and find the most
efficient way to communicate with messages: Stay abstract, e.g. simply send the server the input that the player triggered (mouse click or key press) and the object that was in focus — one concise type of message, not a dozen message types for a dozen different actions. Then the server acknowleges and figures out what happened, updates the game state, and sends out the updated state info to the client. Another new feature you add here is player authentication, and if you want to persist highscores on the server, you also need to look into databases. You definitely need access to a server that lets you run server-side applications.

Only after you completed a networked application, the next step is writing a multiplayer game. You can reuse much of what you learned from writing the singleplayer online game. You do not “only” need authentication, but also a way for players to join a game team and pick an arena for this round (e.g. Open Game Finder). During the game, messages need to distinguish by which client they were sent, and the server needs to distribute updates to all clients — fast. Here you can put everything to good use that you ever learned about synchronization, interpolation, optimization, and persistance, or use an existing framework (such as openwonderland.org or reddwarfserver.org). If you are a quick learner and stick to a well designed game idea, you can complete an indie multiplayer game together with a few pals. — Minecraft is a successful (but also quite lonely) example of this.

Now, a MMO is a whole other dimension of complexity. Behind a commercially successful MMO is a team of 100 developers and designers, who all have technical expertise and prior experience. You need not simply “a server”, but a whole datacenter that can handle thousands of connections (the article specifies that you’d better have several datacenters, on each continent. And yes, that’s as expensive as is sounds.) Unless you happen to write the next EVEOnline you need an efficient way to break the massive world into “shards” and stream it to users. The author gives a whole lists of “small details” that need optimizing (including memory management, caching, and optimal use of the hardware): Because the M (“massive”) means that one wasted microsecond, or one leaky byte, will be multiplied to a scale that causes lag and/or outtages. When an MMO crashes, you have a thousand people knocking on your door, not just a handful amigos rolling their eyes.

To sum this up: Most indie developers who say they want to create an MMO actually mean “a multiplayer game” — or in any case, if they were of aware of the distinction, they would be as content creating a multiplayer game instead. A multiplayer would be dramatically more realistic goal and would also gain you more sympathetic replies on developer forums. If you are one of them, think of it this way: The best way to become part of a team that creates the next big MMO is to show up with well-executed work samples in your portfolio: a desktop game, an online game, and a multiplayer game.

PS:

Here is a nice example of an indie game developer aiming for a medium-sized MMOFPS (MMO first person shooter). He has realistic goals, a timeline, some level models, a dozen team members, and — over 25 years of development experience. The concept art videos are from a similar EA game he helped create in the nineties. The demos with the square arenas are the backdrop for his new game.

Comments are closed.