Someone asked me the other day if they should even bother applying for an MMO job. I make the career sound so crappy in other blog posts… maybe it’s best not to even try?

Well, it’s true that most MMO jobs are not worth it. But if you see a job that sounds interesting to you, I’d definitely encourage you to apply. There are amazingly fun, non-health-damaging MMO jobs out there. They are exceedingly rare, but if you don’t look, you’ll never find them.

There are two big dangers you have to watch for: “Am I going to be able to survive this job?” and “Is this team going to successfully make a game?” You need positive answers for both of these things before you agree to uproot your life and change careers.

Is This Job Going To Kill Me?

Pretty much every MMO job requires 110% of your time and creative energy — it tends to quickly become both your “day job” and your hobby… it takes everything you’ve got. That’s not bad in and of itself, and it can actually be really cool to be a part of something so focused… if things are going well. But “giving 110%” isn’t the same as “effectively living at the office.”

Since we’re being realistic here, I must tell you that you will experience the practice known as “crunch time”. This is apparently unavoidable: I’ve never heard of an MMO project that didn’t have any. (Even the IGDA, supposedly a pro-developer organization, thinks it’s a fact of life.) Crunch time is when you work 60-70 hours a week and get paid for 40. Sometimes the management will bring in food so you can work while eating. Sometimes they provide cots so you can sleep right there and get all the way up to 80-hour work weeks. Crunch will happen, and when it does, it will ruin any semblance of an outside life you had.

The question is this: are you working one crunch week a month, or are you going to be crunching every damned week for a year (as the Gods and Heroes team did, before their game went tits-up)? You need to know this. Even if you can survive 70 hour weeks for a year (and I promise you that it will leave you a soulless, worthless zombie), remember to factor the unpaid hours into your effective salary. If you’re working 60 hours and getting paid for 40, that’s a 33% effective pay cut. This will often make your hourly compensation laughably low.

So how do you know if you’re going to crunch forever? Well it can creep up on any team — you may never crunch until one day you’re told you will need to crunch for the next three months. Zing! That sort of thing is hard to predict during a job interview. But you can at least find out what the company and culture are like right now. Here’s some helpful things to watch for when you interview:

• First, obviously enough, ask about crunch time. It’s easy for them to say the right thing here, which is: “We don’t like crunch time but we expect to do a little of it before milestones.” That could be a lie, but at least it’s the right thing to hear. But you’d be surprised how many people will tell you something else:
  • “We’re in the middle of an extended crunch right now, but when this ends…”
  • “We don’t ever crunch. But we do expect you to work weekends.”
  • “We have a hard-working culture.” [In other words, if you can't work overtime without being asked, you're going to be ostracized.]
  • “We crunch all the time. Seriously, this job will kill you. But it’s gonna be worth it when we overtake WoW!”
• Get a read on the employees’ morale. In the extreme cases, this is easy: when I walked into the Gods and Heroes office building after 6 months of crunching, I could feel the waves of misery rising off the cubicle farm like steam. If you’re in an on-site interview room all day, get a read on how downtrodden and miserable your interviewers are.
• Ask how many people work all-nighters, just as an off-hand comment. This question can sometimes get interesting results.
• Watch for cots. Cots are a bad sign. Sometimes one cot can be written off as eccentric. (MMO developers are very eccentric.) Two cots is right out.

Does This Game Have a Chance?

The biggest down side of the MMO biz is the success rate, which frankly isn’t that high. Everybody thinks they’ve got the secret to success, but most MMO’s fail to launch, or launch to such low expectations and fanfare that nobody ever hears of them. That’s a sad fate if you’ve spent three years making the game happen. (And even though they tell you it will launch in 18 months, it will take three years.) How do you spot a likely flop early?

First off, you need to know if they have any money. I mean funding, in the bank, right now. If not, the odds they’ll actually find funding soon are not so good. They may have to lay you off in a few months. It’s normal for MMO teams to hire up without any real money to back the jobs… because if they can’t find a publisher, the company’s going to evaporate anyway so they might as well lay every resource on the line. (It’s normal, but it’s also terrible, since it often leaves you in an unfamiliar city without a job.)

If you’re satisfied that they have funding for a year or more, find out about their tech. This is a tricky one if you don’t know much about tech yourself. And it depends on where they are in the development process:

• Just Starting: If they’re brand new, then you’ve got nothing to judge — except the engineers they’ve hired (see below). 
• Pre-Production: If they’ve been in pre-production for six months, they should have some sort of engine demos or prototypes, and they should be able to show them to you and talk about what they mean. If they say “Oh, the demo’s having some trouble this week,” beware. In the best case this means their prototype is so unimportant that they don’t even keep it running from week to week. This is a sign that pre-production is not going well, or has stalled severely.
• Production: If they are in production already, they should have an engine that supports at least 50 users at once. If they don’t have that, then it’s a tell-tale sign they were rushed out of pre-production too soon, and are not technologically sound. (This is very typical… but then again, so is MMO failure.) 50 users is not a lot. If they can’t even manage this, they haven’t got anything under the hood.

Meeting the Engineers:

Making a complex MMO requires millions (sometimes tens of millions) of lines of code. It is an order of magnitude more complex than coding a simple FPS or other genre of game. Developers don’t believe this until it’s too late, and that is one big reason why they fail. Crafting a full-featured traditional MMO from scratch is akin to writing the software for a space shuttle launch. It’s seriously complex and has thousands of moving parts.

If the team doesn’t think making an MMO is very hard, and they have no people on hand who’ve actually launched an MMO before, odds are they are making a toy rocket, not a space shuttle. They just won’t be able to tell the difference until 18 months from now. 

Remember, confidence is meaningless: All engineers are 100% confident they will succeed at all times. Don’t be convinced by confidence. What you’re looking for when you meet the engineers is a sense that they really know what they’re getting into, and a sense that they are pretty smart people that have done this before.

• Ask about their networking guy and their graphics guy. At most successful MMO companies, there’s a “guru” for one or both of these spots. Having a pair of gurus definitely improves your chances. You’ll be able to tell who’s a guru by how others talk about them in low, appreciative tones. And no, I’m not kidding. :)  It’s sad that the industry still relies heavily on engineering gurus to make things happen, but they do.
• Talk to engineers about their plans. The things you want to hear from the engineers are:
  • “We’re keeping it simple.”
  • “We’re using such-and-such code for networking and such-and-such for graphics.”
  • “Bob, the lead developer, helped launch such-and-such-MMO-you’ve-heard-of.”
• The things you DON’T want to hear are:
  • “Tim worked for a simulation company and compared to that, MMOs are a piece of cake. So we’re writing a new engine from scratch.”
  • “We have a really innovative engine idea. We’re going to patent/license/resell it when we’re done!”
  • “We’re outsourcing our engine to [Russia/China/Iran]. We have some great contacts who we’re sure can get the job done.”

Admittedly, all of this is fluffy stuff. Unless you can talk the talk, you aren’t going to get a real solid idea of their engineering chances. So you’re going to have to gamble a bit. But at least use whatever people skills you have to try to get a read on their experience level.

Remember: don’t assume confidence means competence. Engineers are always confident. They will be truly surprised when the engine proves unworkable, or takes too long to complete. However, that is nevertheless the most common outcome. What you need to see is lots of experience, explicit and prudent plans, and working demonstrations that prove they’ve got what it takes.

You can also get clues by talking to the other departments. Is everybody on board with the notion that they’re making a simple game? (Or that they’re making a sequel based on a proven engine?) If a startup company has crazy innovative ideas about how the tech is going to work, they’re probably doomed. An MMO company’s first game should not focus on technology. Instead, it should use simple tech to great effect.

Oh, and if they won’t let you see the engineers? There’s trouble a-brewin’. Ideally, they will have you interview with someone from every major department without you having to ask. But if they don’t let you talk to engineers, ask. You should be allowed to talk to at least one engineer for a half hour. I’ve been in situations where the interviewers didn’t want to let me talk to other departments because it cost them political capital to do so. Guess what? It turns out that’s another tell-tale sign of doom: too much departmental friction means they’re not really a cohesive team.

Be Careful About Exuberance

Lastly, watch for over-enthusiastic pitch men. I find it’s easy to get caught up in the enthusiasm of the interviewers. Especially early on in the project, it’s hard for anybody to realize that they’re building a car without an engine. I guess the best advice I can give is to have a healthy dose of skepticism when you talk to people, especially if they’ve never made an MMO before and have grandiose plans. (The interviewers’ reaction to healthy skepticism can also be very telling.)

There are good MMO jobs out there. But they are rare. Expect four out of five MMO positions to be untenable wastes of time. Don’t go in expecting perfection — go in expecting to find signs of failure. Then you can be pleasantly surprised when you’re wrong.

I hope this helps somebody find a dream MMO job! When MMO development is going well, there’s nothing quite like it.

Next time, Sandra will address the same topic, so you can get another point of view.

Do you remember this part from the Wizard of Oz movie? It’s my favorite part:

				GLINDA
		You don't need to be helped any longer.
		You've always had the power to go back to
		Kansas.

				DOROTHY
		I have?

				SCARECROW
		Then why didn't you tell her before?

				GLINDA
		Because she wouldn't have believed me. She
		had to learn it for herself.

It turns out that Dorothy could have gone home at any time during the movie! But if Glinda had just told her that clicking her ruby slippers together would teleport her home, Dorothy would have been unable to believe it. She had to learn it for herself or she could never learn it.

We’ve all been there plenty of times, right? The Ruby Slippers Phenomenon is part of human nature. Of course I had to date that girl even though everyone told me it would end badly. Of course I had to make an indie casual game even though everyone said it would be a flop. No amount of talking would ever convince me.

In my professional life, I’ve made conscious effort to avoid this problem — that is, I’ve tried very hard to learn from the experiences of others. And I’ve had, eh… sub-par results. It’s really hard to believe in the slippers if you didn’t figure it out for yourself. So I’m not pointing fingers at other people who have the same issue. But we do need to try to avoid learning every lesson the hard way.

The #1 reason we dismiss other people’s lessons is by pretending that they “aren’t applicable here.” User-created quests are a great example. No achievement-oriented MMORPG has ever had user-created quests before, so there’s “no possible way anybody could know if it would work”. (Let’s pretend that Anarchy Online didn’t have a simple custom mission generator … remember, most game developers burn out within 5 years, so very few working designers were around for AO!)

When designers would bring up this feature (and yes, it’s been brought up on every game I’ve worked on), the veteran designers would tell them, “That’s going to backfire tremendously. People will exploit it to make the easiest possible missions, and you won’t like the results.” This is always countered by some variety of “you can’t possibly know that for sure!” But actually, working on a live team teaches that lesson very quickly. From AC2, I learned:

• Players subconsciously calculate the cost-to-benefit ratio of content when deciding if it’s fun. For most MMO players, more reward = more fun. (This is a bitch of a lesson to learn, too. “My custom-scripted quest was so incredibly cool! Why aren’t players doing the quest? Well, yes, the reward was a little sub-par, but so what? You’re telling me they aren’t playing it because of THAT? Players can’t be THAT shallow!” Ha ha, newb.)
• Players aren’t objective reviewers. If you ask them to grade content, they will grade more rewarding content higher than other content even if it isn’t as good by other metrics (like plot, writing, annoyance factor, or originality).
• Many players spend incredible amounts of time finding ways to min-max the system so they can get more power for less effort. That’s part of the fun for many players. So there are tens of thousands of people actively looking for mistakes, loopholes, and gray areas in your game. All the time.

“Yes yes,” the other designers would say, “those lessons from the live team are interesting, but that isn’t exactly the same situation as user-created content, is it? Nobody can say for sure if user-created quests are problematic.” Maybe, just maybe, users could be convinced to grade content fairly. Maybe they would discover how fun it is to run really well-plotted quests instead of just trying to level up as fast as possible. Maybe players can change their stripes. Nope. MMORPG players are as predictable as the sunrise.

When City of Heroes released its user-created mission generator, it was mere hours before highly exploitative missions existed. Players quickly found the way to min-max the system, and started making quests that gave huge rewards for little effort. These are by far the most popular missions. Actually, from what I can tell, they are nearly the only missions that get used. Aside from a few “developer’s favorite” quests, it’s very hard to find the “fun but not exploitative” missions, because they get rated poorly by users and disappear into the miasma of mediocrity.

This was not what the designers hoped for. Somehow they had convinced themselves that the number of exploiters would be relatively low — certainly not the vast majority of the users. But they were wrong, and now they’re stuck between a rock and a hard place. They feel they must counteract these abusive quests, “for the sake of balance”. But how? Well the first step is to ban people who make cheaty content. But what’s cheaty? Do they explicitly list every possible exploit condition? What if they miss one? Nah, then the problem would start all over again. Instead, how about if they just issue blanket threats that they’ll ban missions that seem “exploitative”, without actually explaining what is and isn’t “exploitative”? They went with the latter.

So now, any user-created mission that is “exploitative” will get deleted, and users who played it will get their XP retroactively lowered, or even lose their character. So what counts as exploitative? One or two of the “exploits” are pretty obvious, but it’s really unclear where the line is drawn. Their forums are struggling with this very problem:

Are all-boss maps ok? Are all-AV maps ok? Are custom enemy groups with only one mob ok? Two mobs? Three? Five, but with no minions?

Or do we not get to know before they sack us?

Bingo. You don’t know if you’re breaking the rules until you get punished. So the developers are creating a chilling effect on their own content generator. Now it’s risky for players to even use user-created quests. What if some customer service rep decides the quest is exploitative? You’d retroactively lose your XP. It’s best to just to stick to the old dev-made quests, the ones you know won’t get you punished.

They made the wrong call here. Without some guidelines about what’s legit and what isn’t, I would certainly keep away from most user missions. Their lead designer reinforced that they won’t be giving useful guidelines out, saying:

I would say that a good interpretation of abuse is “Disregard for the risk and/or time to reward ratio”.

This is startlingly unhelpful to people trying to figure out how to make ban-safe, but fun, content. To keep this fiasco from chilling the buzz, they need to publish guidelines about what is and isn’t “fair”, or better yet, code this fairness into their tools. As I write this, pick-up groups are running user-generated quests consisting of nothing but max-level boss monsters, so that doesn’t seem to be “unfair”… of course, since there’s no guidelines, who knows if those quests are about to get banned? Since deletion only happens after an “abusive” quest is reported to customer service, it could just be a matter of time before any quest you play gets banned and your hard work gets reversed. Worse yet, since the rules are secret and enforced by numerous people, it is very likely that they will be enforced semi-arbitrarily, and will tend to become more aggressive over time.

But the thing is, even if they make the rules explicit, it’s not going to help the “power-leveling problem” which is ostensibly the reason for all of this grief. Unless they remove all difficulty options from the system, there will always be easier and harder ways to level. And remember what I said above: users tend to prefer easier content with better rewards. This isn’t limited to user-created content — it’s true for designer-made content, also. But designer-made quests don’t get graded by the players. Player-voted content like this will always gravitate towards easy. And pick-up groups will always be picking the most rewarding content with the least annoyance. And the game devs will keep being unhappy about it.

I hope they can find a compromise that makes this all worthwhile, but even when they do, the costs will be huge. All the tweaking, pleading, balancing, and customer service time involved is hard to imagine. Man, the customer service costs alone are tremendous! Think about it: CoH now has customer service personnel evaluating tons of content and deciding if it’s “fair” or not. Plus they have to deal with “incorrectly flagged” content, plus handling the thousands of additional complaint calls … unless they make clever decisions quickly, the labor and maintenance costs of their system will be in the millions of dollars over the next few years. This is not what game owners like to hear. And to add insult to injury, what started out as a PR win seems to be turning into a PR failure almost overnight. Personally, I think the most tragic cost is that their developers will have to continue to tweak this system for months or years to come. They could be adding other features, but instead, they have to try to bandage this system over and over again. Even if they win the battle, they may lose the resource war.

I’m not saying CoH is doomed — this won’t kill them or anything, even if their user-content tools aren’t a success in the long run. I’m not even saying they were dumb for trying this. Every game has “proven the ruby slippers” about a few things. These are missteps that seem really obvious in hindsight, and were pretty obvious beforehand, too, but somebody had to try them… because they couldn’t quite believe it if they didn’t learn it for themselves. So I’m really happy that CoH added this. They’re proving the ruby slippers by showing that this sort of system takes tremendous effort — Herculean effort — to be successful. And I’m pretty sure the CoH team will never be happy with the level of “exploitation” that happens with the system.

Now maybe we won’t have to debate whether user-created quests in an achievement-oriented game are a good idea or not. Oh, who am I kidding? In just a few years all the designers will be new again and nobody will remember CoH’s hard-earned lessons. Sigh…

Run Screaming…

If I were to tell you that I was thinking of making an MMO with a database-centric design, using a DB to serialize entities from one sub-server to another, you would be in good company if you thought I was a dumbass.

Darrin West, the architect at Emergent Game Technologies, does not waver in his disdain: 

There are hidden costs of a DB-centric approach for migration. … In my experience, DB throughput is the limiting factor in scaling a shard. Please, please, run screaming from DB-centric!

No? If that doesn’t convince you, how about Bryant Durrell, former Tech Ops director for Turbine? Let’s see what he thinks: 

Relational databases: please no!

OK. It is completely obvious that any MMO is going to need a way to store data. I understand that the instinctive reaction is to use a relational database, because that’s what relational databases are for. However, I beg of you as the guy who needs to keep the things running fast and smooth, think twice.  

However, Emergent’s MMO engine still isn’t ready for development, and Bryant doesn’t seem to have leaked Turbine’s server technology to the internet before he left. So I know there are better ways, and yet I can do nothing about that.

… Or Embrace Your Destiny!

Sandra and I, along with a few others, are plotting out what it would take to make an MMO on our own. And if I plug realistic timelines into a realistic engineering schedule, it appears that two or three engineers working half-time on an MMO will never ever finish it if they have to develop the server tech themselves (or the client tech, or the tools pipeline, but those are a different post). Every single hour that is not spent on gameplay reduces the chance the game will ever come to market. This is the bitter pill to swallow: the best practices of MMO server development simply aren’t available to tiny indie teams, no matter how experienced they are.

There are some really cool technologies that could help, like Terracotta. This sucker is just what we need! Wait, you say it would cost us how much?! Oh. I see… these solutions are designed for rich companies, not indie developers. Well, maybe we can use that for our second MMO. 

SmartFoxServer: The Glorified, Extensible Chat Room

In the mean time, we can use SmartFoxServer to make a simple database-centric MMO. It’s got a decent track record: Habbo Hotel runs on it. SmartFoxServer (SFS) is really a simple piece of software: it’s a glorified chat room. This is, contrary to what you’d expect, its strength. See, it’s a really full-featured chat system. Authentication, multiple rooms, private messages, friends lists, ignore lists, bad-word filters, you name it. But that’s all it is. It doesn’t try to be a full MMO engine. And that means it’s relatively fast, elegant, and stable at what it does.

You plug extra modules into the back of your “rooms” to add extra functionality. You can implement entire MMOs as plug-in modules to SFS. And that is one road we’re considering. 

If you’re thinking to yourself, “Chat?! Come on, I can write a full-featured super-powered chat service in a month!” then you aren’t getting the “tiny indie MMO team” part. But more importantly, you’re wrong. 

There are a ton of details that getcha when you want to make a professional-quality MMO. SFS also provides logging, banning, moderation, customer support tools, and flood prevention. It’s all little detail stuff, none of it hard, but all of it time-consuming. You couldn’t actually code all the features of SmartFoxServer in a month.

SmartFoxServer Plus A Database Equals “MMO” (With Air Quotes)

Using multiple SFS Zones to run the areas of your MMO

Okay, so how does it work? Well, you use SmartFoxServer as your “front door”: it helps with authentication and, of course, chat. Then for the game logic, it calls your plug-in module, which in turn loads the player’s character from a central database. Each geographic section of your world is run in a separate SFS “zone”. Multiple zones may be on the same physical server computer, or they might not.

A client only talks to one “zone” at a time (well, maybe a couple at a time. But the point is, it doesn’t talk to all of them at once). When the player moves to a different area, the client literally connects to a different zone.

It’s really simple to code — that’s the whole point. In fact, if you’ve got a good handle on SQL, this is probably the simplest possible MMO server. When you’re a tiny indie company, simplicity is key. But there are down sides.

Embracing Your Destiny Sucks Sometimes

What are the down sides? Well, we’ve basically invented the server technology for EverQuest 1. But EQ1 wasn’t technologically advanced even when it launched, ten years ago. This is a poor man’s engine in every respect.

The biggest limitation is that your world will be segmented into very tightly-defined geographical areas. When the player goes from one geographic area to the next, they will have noticeable delays. This engine isn’t going to win any tech awards.

The physical size of each geographic area is unimportant to the server. Instead, the limiting factor will be the number of players that can be in a given area at once. The exact number of people allowed in one area will vary from game to game, but a good guess is about 50 players per area, max.

And lastly, you have a big bottleneck in your design: the database. It will be the limiter on how big each game shard can grow. And you will need shards: you won’t be able to have one world in which every player exists simultaneously.

The Poor Man’s MMO Is Good Enough

Gee, what if I have so many people playing my game that I can’t support them all without more hardware expenditures? Man, as a tiny indie, I’d love to have that problem. It means I have a hit on my hands, and in that case I will be able to find the financial support I need to get more hardware.

The flip side of the coin is more dangerous: “what if I spend months or years making cool server tech and then never make an MMO with it?” Wait… I already did that before. In fact it’s the easiest trap in the world for an engineer to fall into. But it will doom your project, indie or not.

As long as the game looks good and is fun, players aren’t gonna care that there are load times occasionally. Lots of games have geographic zones, actually. Don’t get hung up on it.

We haven’t settled on SmartFoxServer yet. There are several other simple server engines that we’re going to examine before making a decision. But none of them are going to be amazing MMO masterpieces.

There’s a simple indie mantra that I’ve been trying to take to heart: “design around the limitations.” Don’t try to remove the limitations: get creative and figure out ways to minimize their effect, instead.

The Need To Make An MMO

Sandra and I worked in the mainstream MMO industry for a long time, but a couple years ago, we stopped. We stopped because we better understood what we wanted: neither of us was real happy making MMOs. What we wanted most of all is to run MMOs. Unfortunately for us, running an MMO tends to require you to make one first. This is tricky, because the traditional AAA MMO takes three or four years and 50 people, and has a 50% chance of success at best. These are not odds we like.

So we’ve done other things — consulted on MMOs, web games, and all sorts of other things, and it’s actually been a lot of fun. But in the back of the mind there is still The Calling. So we tried to make our own indie MMO on the cheap. These were 2D or text-based, and we just couldn’t get into them. We needed our MMO to be 3D. We’re spoiled like that. And for practical reasons, we needed it to be web-based, because we can’t imagine being able to get a boxed product on the shelves.

But making an MMO is a huge undertaking. It’s not just a fancy 3D client; it’s also a scalable server, tools to develop and maintain it, and infrastructure to run it. But Sandra and I are experienced server engineers; we believe we can use off-the-shelf tools and some cleverness to make a reasonable little game server. And we are becoming more comfortable with various infrastructure approaches. But how do we get a 3D game on top of it? One that’s web based, too, and one with powerful development tools already made for us?

We tried various client applications, but they sucked. However, there’s a new contender.

Enter Unity 2.5

I’ve been watching Unity for a year or so now. It’s been frustrating to watch, because the numbskull developers created their first versions only for the Mac! (The resulting applications could run on any platform, but the development tools required a Mac.) When you’re an indie, it’s hard to justify doling out a few grand for a Mac in order to test-drive a piece of software you’ve never used before. This restriction didn’t stop Cartoon Network’s Fusion Fall from using the Mac-based version of Unity, but it kept most small developers, including us, on the sidelines.

However, two weeks ago they finally got around to making an accessible version of their program, one that runs on Windows or Macs. Finally! Sandra and I reorganized our schedules so that we would have a full week to experiment with Unity and a simple off-the-shelf server product called SmartFoxServer. Basically, we spent a week prototyping an MMO. Successfully.

What makes Unity special? Three things, in order of importance:

1. An enviably powerful tools pipeline, 
2. A rendering engine that works on any platform (and can run on web pages), 
3. And a very reasonable price tag. 

Let’s go over each one.

1. The Development Pipeline

“Development pipeline?” you may be thinking. “Who cares! How many polygons can it push? How many draw calls does it take to render things? Where are the technical stats?!” That’s basically irrelevant for us. We can design our game to run well under whatever conditions the engine allows. This is fortunate, because tech-wise, the engine just doesn’t seem that amazing. If you’ve played Fusion Fall, you may have noticed the low framerate for relatively simple scenes. It’s just something that has to be worked around.

There are lots of free or cheap 3D engines out there, and many of them are far more powerful than Unity in terms of rendering. But those were completely useless to us because they had no tools pipeline. A real MMO needs a client program, sure, but it also needs dozens of man-years worth of tools to build the content for the client. Indies don’t have the resources for that.

This is where Unity 2.5 shines. The Unity development environment integrates directly with Maya, Max, or various other 3D clients, plus code editors, sounds, and Photoshop files, to make a really compelling development environment. Import your 3D characters and drop them right into the scene, then start scripting them to respond to animations. Create terrain in Maya or directly from within Unity. Configure the built-in physics engine, position lights in real time, and then run everything together, watch it work, and fiddle with things on the fly. This is a great way to prototype stuff. It’s fast, it’s efficient, it’s … pretty alien to most programmers. If you’ve learned to develop in Flash, it’s sort of that mindset: it’s more resource oriented than scripting oriented.

Placing an asset on some terrain I just made

This can take some time to get used to, but it’s plenty powerful and elegant when you do master it, and it’s sufficiently versatile that you can use it for a whole lot of games.

On the other hand, this complex development environment makes it harder for programmers to manage lots of code. For instance, scripts are attached to assets and then the script’s variables are individually configured. This is done automagically and makes for a very cool customization experience. But if you decide that you need to change the values of a variable, you may not be able to find all the uses of that variable with a text-editor search: the user may have overridden those variables in the project itself, leaving you with no way to find the values programmatically.

It also presents some co-authoring issues: you’re all working on the same assets, after all. Unity did a decent job of letting you merge projects together, but that’s only if each developer is working on completely separate parts of the client. If you’re each fiddling with the same prefabricated object, you’re screwed. You can’t merge the binary assets: somebody’s work is going to get lost.

So this pipeline is ideal for small teams, or for larger teams who have spent some serious planning time figuring out how each person is going to avoid stepping on other people’s toes.

But let me just quantify this toolset’s value: Sandra and I were able to download the demo version, learn how to use it, and then create a 3D zone with mobile, animated avatars that talked, punched things, exploded, lit on fire, and so on — in a week. We also had to learn how to use the server library we picked, too. Fortunately for us, SmartFoxServer actually comes with a demo that shows you how to synch up multiple Unity clients. We achieved pretty amazing results in a week, but we took advantage of a lot of demos and free assets to make it happen.

Still… this is an unsurpassed prototyping tool. Even if you don’t use it for the final client, just imagine that you could get your next prototype up and running in a week, then iterate on the design every day after that. Now you can. I wish we’d had this when we were trying to prototype Star Trek’s space combat.

2. Web Based 3D Out of the Box

Another important advantage is its flexible runtime environment. It runs on Macs and Windows. It can be a stand-alone program or embedded in a browser. And it isn’t hampered by the “you must support the lowest common denominator” mentality that Flash has. For instance, your game can support multi-button mice, even though Macs may not have them. Conversely, you can program for that weird meta-key (the Command key, I guess?) even though its analog on PCs is the Windows key — and when you press the Windows key in a web page, the web page loses focus. But I’m very happy that they just gave us all the obvious capabilities and left us to figure out how to sanely use them, rather than oversimplifying.

The compiled files are nice and small, for what they are. I was able to get a pretty complex scene, complete with lots of scripts, animations, and networking, into an 8mb file. (Of course, users also have to download and install the Unity plug in for their browser; that’s where the “engine” code lives.)

It also has some complex tools for data streaming, which we didn’t get around to testing out yet, but they seem pretty robust. They also require a lot of planning, but that’s still a whole lot easier than coding it ourselves from scratch.

3. Cheap Price Tag

The price is very reasonable. It’s a couple grand for Sandra and I to each get professional licenses. That’s it; no percentage cut or anything scandalous like that. You even get free minor version upgrades added in (which is good, because that’s the only way they do bug fixes).

It’s not dirt cheap, but let’s be realistic: 3D games are still expensive. Sandra and I made an off-the-cuff budget that cost $40k for 3d artwork. That’s peanuts compared to a mainstream MMO, but puts it well out of the reach of the very smallest of indies. If you can’t afford a couple grand for an engine, you can’t afford to make a 3D game just yet. Maybe in five more years it’ll be at the cheapness level that 2D games are… but it’s just not there yet.

(There is also a cheap “indie” license that costs $200. This is a good way to get started with development, but the restrictions mean it’s not too practical for developing a complete commercial MMO. It should work okay for other 3D games though.)

What’s the Down Side?

So the good news is that this is a realistic way for a small team to cheaply make an MMO. Fusion Fall already exists: it proves that it’s possible. But Unity is not without it’s painful side. Once again there are three main issues:

1. Bugs
2. Language Issues
3. Documentation Flaws

1. Bugs

The primary down side is that Unity 2.5 crashes a whole lot. It’s essentially version 1.0 of the Windows line of Unity, and it shows this in its lack of stability. As the military would say, its “mean time between failure” is about one hour. This is not good. You’ll have to get used to saving every few minutes. But worse still is that two of our crashes caused the project to become corrupted. Maybe if we’d been more advanced with Unity we could have repaired and moved on, but as newbies, this was devastating. We lost many hours of work when this happened. We eventually instigated a “back up to a new folder every few hours” policy.

Obviously this needs to get fixed. Unity 2.5 has only been out a few weeks, so I am reasonably hopeful that they won’t leave us hanging for too long.

2. Language Issues

Unity has a schitzophrenic relationship with programming languages. Officially, it supports three languages: C#, JavaScript, and a variety of Python called “Boo”. But this is basically a lie.

It supports C# because it’s written in C#. This is the language you should probably use if you’re a team of experienced developers. However, none of the examples show how to use the code in C#. You will have to muddle with it for many hours to get the nuances.

It supports “JavaScript”, and this is the preferred language. The demos are all in JavaScript, and the code examples are in it, too. However, this isn’t really JavaScript. It’s an upgraded version that takes a bunch of ECMAScript features that aren’t in JavaScript. Then it tosses in some special functionality specifically for Unity. And then… it doesn’t document any of it. There is no language reference for their made-up version of JavaScript.

The support for “boo” is entirely mythical. I’ve seen no code for it ever, nobody on their forums uses it, and it goes without saying that there is not a lick of reference to it in their help. You’d be really stupid to decide to use boo for your project.

More annoying still? The languages are poorly interoperable. We were pulling in code from lots of different demos, and needed to use both JavaScript and C# code in the same project. It turns out that when you have two languages in use, there are dependency issues that can only be worked out by sticking your code in special “load me first” directories. Very kludgey. At least it can be done. 

3. Documentation Flaws

The “Unity Manual” is a tiny wisp of a thing. There are no real docs on how this stuff works. What there is, is a massive step-by-step tutorial that teaches you how to make a platform game in Unity. This is awesome… if you’re the sort of person who learns by doing. I am the sort of person who prefers to absorb all the data available and then start exploring. I simply can’t do that with Unity. Those docs don’t exist. For a commercial product they are significantly under-documented.

Expect to spend days just screwing around with the demos in order to have any clue what’s going on. Expect to search frantically through their forums in the hopes of understanding the syntax for their scripting languages and complex GUIs. Expect a few sudden jarring inconsistencies in what is otherwise a smooth and orthogonal interface.

The docs looked especially paltry when compared to SmartFoxServer’s luxurious documentation. Yes, SmartFoxServer is a much simpler piece of software than Unity. I don’t care though. Fickle that way. Need docs.

The Bottom Line

If the question is “can Unity be a viable MMO client?”, then it’s been answered by Fusion Fall: “yes”.  But the neat thing about Unity is that after spending a week with it, you would easily come to that conclusion on your own.

It’s not for everyone, of course. If you can’t deal with the relatively paltry graphics level allowed, or if you need your tools to conform to your existing pipeline, then you’re not going to like Unity. You have to be agile enough to work with it instead of against it.

But after a week of using it, I’d have to say that Unity feels pretty good. Maybe this program is the missing piece in our indie MMO plans.

Learning Is Fun …

Have you read Raph Koster’s book, Theory of Fun for Game Design? It’s one of those books that people are always telling game designers to read. But I hate it.

I hate Raph Koster’s book because it teaches such a shallow and non-universal lesson: that the core of fun is learning, and that a good game is one that teaches you everything it has to teach you before you get bored. This is a convenient definition for a lot of game designers, because it fits them. They like games that they constantly learn from. It’s almost like some sort of pre-requisite for being a game designer.

There are also apparently studies that show that learning new things releases endorphins in the brain, and I have no doubt this is true. So does eating chocolate, and acting out violence, and reacting to outside stimuli that you’ve come to associate with rewards, and sex, and… on and on.

To suggest that learning alone is the core of fun is a really … well, arrogant … thing to do. It reeks of the forced-grouping hypothesis that held sway over the industry for half a decade — made popular by designers who got into the industry after playing lots of EverQuest. Maybe you remember it: “MMO’s are all about interacting with other people. That’s what makes them different than single-player games! So we need to force people to group, even if they say they don’t want to, because they just don’t know what they’re missing.”

It’s crap. These bogus theories of motivation are a dime a dozen because:

1. Designers tend to create hypotheses that allow them to create games they like to play. (Duh!)
2. Designers aren’t typically scientifically minded. It’s not our strong suit. Like stone-age philosophers, we simply correlate what we see with the most obvious possible explanation. This is how superstitions get started, too: the mind loves to correlate things at the drop of a pin, even if they shouldn’t be correlated.

You can probably tell that this pushes my buttons. It’s fine for Raph to hypothesize, but the real problem is that his thin little treatise is used by a lot of other designers, many of whom should really know better, as a way to rationalize their personal style of game development. Entire systems of game design are now based around the idea that ”learning is why games are fun”.

It’s not a bad model for making certain types of games. Miyamoto’s incredibly fun action games fit this model well … up to a point. But learning is hardly the only way to have fun with games.

… But Other Stuff is Fun Too

The thing is, for most professional game designers, learning really is the most fun part of a game. We tend to instantly strip away the context, the art, the story, and indulge in the mechanics. “Ooh, here’s something new! This is great!” We subconsciously assume that other people are like us. (”I’m sooooo bored of traditional MMO mechanics, and everybody else is too!” Not so. You are projecting, wishing it to be true.)

But this interest in mechanics and learning is hardly universal — even for designers. What struck me when reading the “learning = fun” theory is how bad it is at explaining my MMO behavior. For months after I stopped regularly playing EverQuest 1, I kept logging in occasionally just to fish. I wasn’t learning crap, and I didn’t even care what I caught or what my skill was. I was immersed in a fantasy world and I enjoyed the simple escapism provided by watching the virtual sun set.

Escapism is fun for me sometimes, but so is the feeling of being a part of a well-oiled team. And sometimes I like to just beat the snot out of things weaker than me. And so is … huh, I guess I have a lot of reasons for playing MMOs. So do you.

So how do we unify all these motivations into a theory of fun? We don’t. That’s stupid. As H. L. Mencken once wrote, “Complex problems have simple, easy to understand, wrong answers.” Just because you can unify every source of fun into one simple theory doesn’t mean it has any hope of being right. Our brains are chaotic, confusing, complex creations. A lot of different things trigger pleasure in our heads.

So how do we tell why people play games? Well, we can start by doing some empirical research.

…Wait, really? Empirical research? In the gaming industry?

Yes. It is true. Nick Yee’s Daedalus Project is based on surveys of real MMO players instead of empty theorizing. This is why it’s more valuable than your pet theory or my pet theory. It’s probably fairly flawed, but it makes theories like “learning is the core of fun” look like sun-god-worshiping prehistoric nonsense in comparison.

Here, let’s look at the Model of Player Motivations Nick Yee uncovered. Because I know you didn’t bother to click that link above, I’m just going to steal some of the important charts from his website. (Sorry, Mr. Yee. Hope ya don’t mind.)

Nick Yee's Motivations

Another common source of “motivations” is Bartle’s famous player types. After many studies, Nick found that several of Bartle’s types don’t really map up very well. For instance, Bartle hypothesized that Explorers love finding new places in the world, as well as unraveling game mechanics. In reality, these two motivations don’t tend to appear in the same players too often.

Most players do have multiple different motivations from this chart, though — and that’s one of the most important takeaways from Nick’s work: most of us have many reasons for playing games, which vary from day to day and game to game. You probably have motivations in many of these categories. (You can even take a little quiz to see which ones.)

It’s true that many of these motivations can be mapped to “learning” — especially if you’re willing to make really tenuous connections like “competition is just a form of learning about other people!” and silly stuff like that. But many of them are just simple human needs, like being dominant, being liked, being part of a group, or escaping from reality for a while.

Pick What Your Game Is Good At

Every MMO in the “virtual world” vein supports a large number of gamer motivations; this is part of the secret to MMOs’ success. But no MMO can be great at all of them. I suggest you pick several motivations from Nick Yee’s chart (three or four at most) and be really good at them, then let the others happen as best they can happen.

It’s tempting to conflate motivations with demographics, but that’s a mistake. For instance, it’s true that slightly more females than males prefer “socialization” motivations in MMOs, but the gender difference is pretty small. Similarly, you may be tempted to assume that any game aimed at 18-24 males should be all about achievement. But that demographic’s motivations are all over the place, and older demographics are strongly motivated by achievement as well.

One method of getting a handle on your target audience is to create personalities to represent them. This is an old marketer’s technique: create a handful of personal stories and backgrounds, and then tailor a game to what those people would like. If you have a well-established IP, you can pull from the demographic data of your IP to help you figure out what personalities to use; otherwise, you’re going to have to do some research on the sort of people you envision playing your game. If you’re planning to reach out to existing MMO players, maybe you can start by picking some bios of traditional MMO gamers.

It boils down to the First Question: who is this game for, and why? In theory, you should know this before picking motivations. But on the other hand, if you don’t have a clue who your game is for, choosing several key motivations will at least narrow down your choices!

If I had to guess, I’d say that WoW’s three most powerful motivations are advancement, competition, and teamwork. EQ2’s strengths, on the other hand, might be mechanics, teamwork, and discovery. Asheron’s Call could be mechanics, discovery, and competition. All of these games are considered “hard core” MMOs. They just don’t focus on quite the same motivations to quite the same degrees.

Unfortunately you can’t safely pick, say, your three personal favorite motivations and run with it, because there may not be a large enough audience to support that mix. So when you have your polling contractor research your target demographic, make sure they include some questions that can highlight their motivations.

And please don’t tell me that your $20,000,000 game can’t afford to use a professional pollster, because if you think that, you obviously haven’t even looked into the prices. Hey, wait, you were just going to make a game without even deciding who it’s for, weren’t you? Shame on you! You’re not a novelist who can just write anything you want and hope somebody likes it; you’re spending a ton of money to create a service. You need to know who your service is for.

Thanks, Daedalus Project

I’d like to thank Nick Yee for his many years of researching MMO players. He recently put the Daedalus Project into hibernation, which makes me sad, because this is impossibly valuable data for any MMO developer. If you haven’t perused his data collection, you should go do that now.

His stuff isn’t perfect: there are some motivational categories that aren’t as strongly tied together as others, and his polling subjects were largely self-selected, which no doubt influenced the results. It’s also highly biased towards Western culture in general and EQ1 (early on) and WoW (later) players specifically.

But it’s a lot better than what you had before, because before you were just making stuff up and pretending it was universal. I know you were. Yes, I saw you doing it. Cut it out!

You still haven’t clicked the link above, have you? Fine, I’ll leave you with another Daedalus Project chart, stolen for your amusement. This one breaks down how various stereotypical statements relate to player motivations.

Nick Yee's Motivations - Breakdown

If you go to a game conference about MMOs, you’ll hear about how awesome microtransactions are and how they’re the key to the future. They have several huge benefits:

• Low barrier to entry for new players because the game is free.
• Although most players don’t pay anything, a small number of players pay a ton. These customers are so valuable that they more than subsidize the free players.

But before we toss out subscriptions and jump onto the micropayment bandwagon, let’s look at the down sides:

• In order to have enough payers, you need a larger number of players. If your goal is to earn a million bucks a month, you need 66,000 subscribers paying $15 each… or 300,000 free-players who might buy items.
• In order to appeal to enough people, you probably need to homogenize your game somewhat. (There are some weird and wondrous outliers like the micropayment-based text MUDs from Iron Realms, but those are developers  who understand a very shallow niche very well. That’s not the norm.)
• Your profits rest on such a small percentage of players that losing a few of them can really hurt your revenue. You end up needing to make two games at once: a game that keeps your payers happy, and a game that keeps your non-payers happy… and often those two games don’t have as much in common as you’d hope.
• The new economy makes this model much scarier than it was a few years ago. Multiple mini-transactions are more susceptible to penny pinching. “Is this cool hat worth $5? No, clearly I can do without it.” vs. “Is playing this game worth $15 a month? Clearly yes!” That $15 subscription works out to 19 cents an hour if you play the game 20 hours a week.

Game Designers Are Not Marketers

Let me put it another way. Everybody in the industry “knows” that microtransactions are the future… just like they “knew” that all successful MMOs had to require forced grouping like EQ did. That is, until WoW came out and proved them all dead wrong. As an industry, we’re really terrible at predicting trends. Sad but true.

Instead of talking to game designers, how about we talk to marketers? What do they think? Here’s what marketing guru Seth Godin has to say about micropayments versus subscriptions:

Whenever possible, sell subscriptions
Few businesses can successfully sell subscriptions (magazines being the very best example), but when you can, the whole world changes. HBO, for example, is able to spend its money making shows for its viewers rather than working to find viewers for every show.

How about entrepreneurs? What would they say? Why not drop a line to a successful entrepreneur and ask them which is easier: making a cheap product for a massive market, or making an expensive product for a niche audience. I guarantee they’ll say the latter, by far! The cost of appealing to the masses is humongous. The safe entrepreneur money is in targeted products. And subscription games can be more targeted than free games, because they need appeal to a smaller audience than free games.

Is The Secret Micropayments, or Just Web Play?

One thing does seem certain if you study the market: boxed MMO titles are rapidly becoming obsolete (unless you’re Blizzard or EA, and even in that case you probably realize that the boxed model won’t last forever). The model for a boxed MMO is: spend three years making a game, put boxes on the store shelf to much hoopla, sell a million boxes, then watch your player base slowly dwindle away. Put out expansions a few times to temporarily juice your populations up again, but eventually watch it become a tiny game.

The web-distribution model is different: create your initial web game as fast as humanly possible, put it up to start getting an audience for your product, and then slowly improve the game and increase your audience over time. This is great because:

• You don’t need to fight for shelf space at Wal-Mart — you can spend your marketing money on campaigns to pull people right to your website.
• By removing the box, you make it easy for people to get their friends involved.
• If you use emerging browser technology, you can have gamers playing your game within 30 seconds.

This is the model that, for instance, EVE Online has used so successfully, showing year-over-year growth instead of watching populations dwindle. But EVE isn’t a microtransaction game: it’s a free-trial game. After the free trial, you have to pay a subscription.

It’s true that a lot of the web-distributed games have used microtransactions. But that doesn’t mean they have to. As the number of web-distribution games gets larger, I think microtransaction-based games are going to get harder and harder to pull off successfully.

There are lots of decisions in here: is your game a boxed product or a web distribution? If the latter, is it a downloaded program or a browser-based game using a plug-in like Unity? Do you make money by subscriptions, or by micropayments?

Unfortunately, most developers don’t see these subtleties. They see “Boxed games are out! Microtransactions are in!”  Maybe they look at the fact that some free games rival Warcraft in number of players, and don’t completely consciously grok the distinction between population and profit. But like I said, the MMO industry (and the gaming industry in general) isn’t exactly known for understanding trends — they’re better known for blindly parroting what other people did in the hopes that they can be successful too. That doesn’t work very well. If you pick apart what’s going on, you can get a better view of how to make a successful game.

More Questions Than Answers

“Great, Eric, thanks, that’s completely unhelpful. So there are lots of questions that need answering? No crap. How do I answer them?!” I can tell you that … after you tell me who your game is for and what tools you have to reach them.

For instance, if you’re making an MMO for kids, you’ll need to get parents involved in the spending process. This may mean the parent buys “game money” for their kid to spend, or it may mean the parent pays the kid’s monthly subscription. If you’ve got no other sorts of leverage to reach parents, then micropayments probably work best — that way the kid can get hooked on the game and then bug their parents for cash.

On the other hand, if you’ve got other ways to reach parents (say you’re Disney with your own TV channel, monthly magazine, and fliers in every DVD box), then marketing straight to parents as well as kids will be very effective.

So you need to figure out who you’re aiming for, and how you’re going to reach them.

One Possible Game Plan

Now, if I had a few million dollars in VC money, I know what I’d do. I’d target the “boxed-MMO game runoff”. Those are users who’ve played several boxed titles before, are adventurous enough to leave their favorite game, but are clearly not sticking to one game. Although this doesn’t nail down the audience completely yet, we can already start to see important facts about our demographic. For instance, these are players who don’t need or want hand-holding about MMO basics like movement, combat, or banking. They want to get in and play ASAP.

This audience is also comfortable enough with the concept of an MMO that they are willing to pay to play them, but at the same time, they have the attention span of a gnat. I’d be pretty worried that they would visit the game website but not manage to even get started with the game, so I’d use a web-browser-based engine to get them in and playing as fast as humanly possible. Starting play within 30 seconds would be the goal. Let them play for free up to level 20, say, and then require a modest monthly fee to continue.

I’d put out the first version of the game in a year. It’d be crummy at first, but that’s okay, because it wouldn’t launch with any fanfare anyway. There’d be improvements every single week. As we started to get paying users, I’d choose the development focus based on what the players say they want, fleshing out the game in the direction these people need, so that they feel more comfortable bringing in their friends, and those people’s friends, and so on, growing virally every year.

If this sounds like the model that web 2.0 companies use, that’s not an accident. It’s cheap, effective, and frankly more satisfying for the developer, too. The nifty part is that the people playing the game will feel that the game is slowly being tailored specifically to them. And I can say from experience that adding features to a live game is a lot more fun than working on an unshipped behemoth.

In short, everybody wins.

Tobold, my favorite MMO-player everyman, recently posted a short piece on the value of combat targeting. He seems pleased that the developers of both Darkfall and Age of Conan tried to do something new with combat, but notes that the lack of targeting in Darkfall especially doesn’t do the game any real favors because it is too easy to exploit.

But here’s what interested me: if you happened to still have the boxed version of the original Asheron’s Call 2 game published by Microsoft, it includes a keyboard shortcut sheet. Look at the bottom left of the key map and you may see that the left Ctrl key maps to “Wild Swing”. That was an untargeted attack that could hit multiple enemies.

AC2 had a complete physics engine that made this feature easy to implement, but AC2 didn’t launch with this feature. It was cut, albeit too late to change the first batch of  box inserts, because — just as Tobold notes — it created too many exploitable scenarios.

But now that Age of Conan and Darkfall are doing it, untargeted combat is considered “innovation”. If you want some more innovative features, maybe your next MMO will have one of these crazy ideas:

• Real physical projectiles that can be dodged by strafing from side to side (both AC1 and AC2)
• A constantly evolving storyline that alters the face of the game world, adding and destroying stories, quests, cities, even landmasses on a monthly basis (both AC1 and AC2)
• A variable-length jumping system, where holding down the space bar longer makes you jump further (AC1, complete with puzzles that require you to use it well)
• The ability to travel quickly around the world, while still providing a sense of grandeur and rewarding player knowledge, by mastering an elaborate network of teleport portals and spells (both ACs)
• The ability to improve skills by spending your XP on them (both ACs)
• A “trickle down” guild system where new players automatically feed XP to higher-level members of the guild, thereby encouraging guilds to grow large, and to take care of their lower-level members (both ACs)
• The ability to inscribe your name and a paragraph of text onto every item you own (both ACs)

And on and on… I could list dozens more. AC1 and AC2 had tons of features, large and small, which differed dramatically from other MMOs at the time — while still remaining recognizably MMOs. Were all these innovations successful? Hell no. Many of them were design failures. But they were innovations.

The point here is not that AC1 and AC2 were more innovative than other MMOs. Every big-league MMO in existence has had scores of unique features. Sometimes they don’t get noticed because the designers don’t do a good job explaining why the feature is awesome. (Often they aren’t really that awesome anyway.) Sometimes the company’s PR department fails to trumpet the feature, usually because they don’t understand it or why it’s a cool innovation. Sometimes the game sucks in so many other ways that the flaws outweigh any new features.

So here’s my point: any twist on an existing mechanic you can come up with, any obvious combination of MMOs and other genres, I can pretty much guarantee you that many MMO designers have already considered it. They may have already implemented it in some game you’ve never heard of. Hell, they may have implemented it in a game you have heard of — do you really keep up with all the game systems in all the new games and new expansions?

But unfortunately, innovations and new features don’t automatically make MMOs successful. Being “new” doesn’t make a feature good.

Innovation isn’t the key to fun. Fun is the key to fun.

What’s a QA team without a spec? A goddamned nuisance and a waste of time, that’s what.

Man I hate when QA people do their jobs without specs! It’s so irritating. When Asheron’s Call 2 launched, there were thousands of outstanding bugs in the QA database that we opted not to fix before launch. Sounds bad, doesn’t it? But if you looked at them, you’d understand. Hundreds of them were bugs about how buildings were floating 2 virtual inches off the ground; if you zoomed the camera down to the floor and looked up, you could see that these structures were very slightly hovering.

Hundreds more were about items that “popped in” too soon or too late; the “art degrades” for the items weren’t set up right, so they seemed jumpy. And so on… thousands of little tiny nits.

Why does that piss me off? Surely those bugs should have been in the bug database, right? Even if they’re not fixed immediately, they’ll get fixed at some point! Right, true. Except for this:

Asheron’s Call 2 launched with over 3000 severe yet unrecognized bugs. It is not unreasonable to argue that AC2’s early failings were due to the lack of quality in things like crafting, combat, and skills. Every time the QA people entered a bug about a floating object, that was time they weren’t spending finding more serious bugs. For instance:

• Many of the crafting recipes were about ten times harder to create than intended. The creatures that dropped the needed parts spawned incredibly rarely, due to an oversight.
• Many of the quests could easily become broken if the steps of the quest were done in the wrong order. Fixing them then required the assistance of a customer service representative.
• Almost every skill in the game was broken in some way. Some skills literally did nothing; others were too costly or too powerful; some started out super strong and then got weaker as you leveled up the skill.

And so on. Serious bugs, very much worth fixing. These didn’t make it into the database at all; the live team stumbled upon them when players started screaming about them. What the hell, QA? What the hell?

I’m just being a jerk to QA here. One of the reasons that QA did such a terrible job on Asheron’s Call 2 was because there were almost no design specs.

It was the extremely talented Jesse Kurlancheek (a.k.a. “Devilmouse”) who was responsible for the skills in AC2. Because of the agreement Turbine had made with their publisher Microsoft, he was obligated to create at least 600 skills for the game before it shipped, broken into 30 different skill trees. Problem was, he only had three months to design and implement them all. Jesse famously told his boss, “I can either implement the skills, or I can document the skills, but there’s no time to do both.” And he was right. But they chose to implement instead of documenting, and the result was tragedy.

Without any idea of how skills were supposed to work, QA never looked at any of them. To be fair, QA should have at least poked around with them some, but they just weren’t motivated to spend any time on them because the designer would almost always say “no, that’s not a bug, that’s how it’s supposed to work!” So the QA team spent their time wandering around looking for objects that were hovering a tiny bit off the ground, instead. At least those were irrefutable bugs!

The lack of specs was devastating. When the game launched, the live team needed to get the game into a maintainable state. Without specs, we had no idea what Jesse had intended. Worse yet, a few months later, not even Jesse remembered what the intention of each skill was. So we created elaborate analysis software in order to locate skill deviations, and slowly reverse-engineered the intentions, like archaeologists exploring an ancient culture. The lack of specs cost us thousands of man-hours. It made us look like total dicks, too, when we fixed the outrageous bugs we found.

The “reap” abilities in AC2 stole the health of an enemy and gave it to you. However, as is typical of this sort of power, you couldn’t steal more life than you were missing. So if you were only missing 100 health, you could never steal more than 100 from the enemy. Tragically, there was an accidental minus-sign in the implementation. If you reaped somebody and you were fully healthy, instead of doing no damage, you did double damage. Reaps were the most effective attacks in the game, provided you hadn’t been hurt too much. It made PvP in particular a nightmare, and players were howling for us to fix it. When we fixed it, though, several classes became unplayable; it turns out they had only been fun at all because of that broken skill. So then we had to buff those in various ways, until the next major bug was discovered, which threw our rebalancing out of whack again. And on and on, over and over, a constant dance of chaos and confusion, for over a year, before we had created our own specs and could work towards stability.

If only the skills had been affected this way, we could have dealt. But the lack of specs permeated almost every aspect of the game. The quest areas were about half-documented; the monster spec was nothing but one extremely complex spreadsheet. It’s not like the AC2 designers didn’t know how to make specs, of course: they were given impossibly small time windows to do their work, and they did their best.

If our publisher had allowed us, it would have been so much better for AC2 to have launched with only half the classes, but with docs for all of the classes. Then the live team could just implement the docs, rolling out new things every couple months, and make Turbine look super productive instead of super incompetent.

In the end, specs save money for three reasons.

• Specs allow for collaboration on a design. If it’s all in your head, nobody can point out the flaws in your plan until you’ve implemented it already.
• An MMO that is supposed to run for 5 years needs at least a rough semblance of documentation, or the game’s maintenance will cost a ton.
• Specs are also mandatory if you want to use a QA team. If you can’t afford to write specs, just fire the damned QA team, or convert them to content designers or something. QAing without specs is an amazing waste of time and just makes everybody angry.

And just to be clear: I love working with a talented QA team. I am 100% pro-QA. But you must give them the ability to succeed. Without specs, you’ve set them up to fail.

The Problem With Rapid Content Creation Tools

When I was at Perpetual, the Gods and Heroes team had a quest-development process where designers didn’t need to write out all the details of each spec. They just opened the database and plop! they dumped their quest right into the game. And man, did they hate QA. They agressively, loudly, viciously denounced the QA department. QA was always telling them the wrong thing and never finding the real bugs. The QA at Perpetual was the scapegoat for all problems. Even the QA team lead was apologetic for how shitty they were.

But how could they be successful? The only notion of how these quests were supposed to work was in one designer’s head. Eventually, the QA team wisely stopped reporting bugs about quests. But there were still bugs in the quests.

When Perpetual’s Star Trek team was planning their content pipeline, everyone just assumed the same system would be used. This was a major point of contention for me: I wanted designers to write out every detail about the quest before they implemented it. “That’s ridiculous! It will double the time needed to implement quests! We can’t budget for that!”

Okay, fine. But if you can’t budget for specs, don’t budget for QA, either.

The past few days I’ve been helping prepare a pitch for a roleplaying game based on a kid’s cartoon. I can’t say the cartoon is my favorite, but I really have enjoyed diving into the IP — watching the episodes, reading the story notes the writers sent over, figuring out how things work, and trying to form a cohesive game experience around it all. I love this part — making a design fit into an existing universe — and it turns out it doesn’t really matter what the IP is. It’s always fun! The extra restrictions force you to focus on the goal of your project and keep you from meandering into random territories, plus the IP gives you a clearer view of your audience.

There are some things to keep in mind, though.

Games Are Not Mainstream Media

Remember, games are not a mainstream media like TV shows and movies are. (At least not yet! We’re getting closer… maybe in a decade we will be.) We have to keep our “semi-niche” status in mind.

A movie might take a tiny IP based on a book and literally reinvent it for a completely new audience. A video game cannot do that. Video games must take an already-mainstream IP and play off of it to make something that appeals to existing fans of the IP. Don’t ever forget that, because it means two things:

1. You must use an already-successful IP or you aren’t getting much out of using an IP, and
2. You cannot reinvent the IP to suit a different audience; you must work with the IP’s existing audience.

The IP Defines The Audience

One of the key reasons to work with an IP is that it helps to solve the most important design question: “who’s the target audience of this game?” The audience is: people who play games and also enjoy the IP you’re using. With that in mind, you can much more quickly figure out what sort of game to make.

For example, the average Star Trek fan is older (25 to 65) and typically middle class with decent incomes. The fact that these are older individuals means that a reflex-intensive game like a first-person shooter won’t be super appealing. (There have been some fun Star Trek FPSes, but they weren’t particularly monetarily successful because they didn’t take the audience into account.)

It doesn’t make sense to homogenize your audience too much, though — Star Trek fans enjoy the show for very different reasons. Some fans love the notion of exploring space; others are enchanted by the Utopian universe where mankind has overcome its petty problems. Still others watched Voyager primarily because Seven of Nine was hot.

When we polled the broader Star Trek audience we found that the average Star Trek fan that also plays video games tends to be male, skew a bit younger (late 20s), and enjoy certain elements of Star Trek more than other parts. They like the over-the-top races, starship battles, and the sexy aliens. The Utopian universe wasn’t that important, and most of them would only play the game if they got to be a ship captain (as opposed to a crew member). That helped define what sort of game to make.

So an IP isn’t a magic solution to defining your audience. You still need to poll your audience to find out what they want in a game. (Remember, polling consultants are your friend, and will pay for themselves many times over!) But your IP will narrow the problem down dramatically. Use this advantage. Don’t fight to escape your IP! Work with the IP to deliver something the target audience wants. 

Turbine’s Dungeons and Dragons Online is a great example of a game that didn’t let itself be defined by its IP, and suffered as a result. It’s a fun game on its own merit, but it was not inherently attractive to D&D players. Turbine would have been better off inventing their own IP for this game, and they would have saved money, too.

Your Game Isn’t Canon

As I mentioned, games aren’t mainstream media. But there’s an up side to this: for most IPs, the things that happen in your game are not going to be part of the IP’s canon.  That means you can take modest liberties with the universe in order to make the game more fun. Do this.

People will tell you that some IPs can’t be altered in any way or the fans will get angry. That’s not true. Well, it’s true that most IPs have some very hardcore fans that will resent any deviation, but unless you’re creating a very niche game, they are only a tiny part of your audience.

Star Trek’s most hardcore fans would be unhappy with a game that took any liberties with the IP — even something as simple as letting every player have their own ship makes them angry — but that’s irrelevant, because you can’t make a AAA game just for Star Trek’s most hardcore fanbase; it’s much too small. When you extend your reach to the entire spectrum of people who like Star Trek and also like games, you find that the audience is okay with some pretty dramatic liberties. And here’s the surprising bit: even the hardcore fanbase can become pretty understanding, if you explain and justify why you need to take liberties to make the game more fun.

On the other hand, sometimes the least maleable party is the IP holder. The Tolkein estate famously screws over game designers by forcing them to stick too close to the original IP. They don’t understand the point or audience of video games, and that’s their loss. You should think twice about working with an IP if you have to slavishly follow the canon.

There’s a Game For Every IP, But…

Technically, every IP can be turned into a fun game. It’s an entertaining design exercise: start with a tricky IP (let’s take, I dunno… “Night Court”). Inject action or intrigue elements (how about a post-apocalyptic setting?) and voila… you have a game. You’ve made Nightmare Court, a simulation game set in the year 2130 AD, where only the tough-as-nails (yet very funny) judge can keep the peace, all the while managing the courthouse’s food and electricity levels. Sell guilty criminals into slavery in exchange for water and grain. Make sure your bailiffs can subdue the laser-cannon-wielding mad men who break into court to rescue their friends … okay, that’s terrible, and I’m sure you can do a better job turning Night Court into a game, but the point is that most game approaches are going to ruin this IP, even if the resulting game is fun.

I remember a pitch session for an MMO based on HBO’s “Deadwood”. That would have been a hard IP to make into an MMO, so they pitched a secret ingredient: zombies. “Deadwood with Zombies will make an amazingly fun MMO.” And you know what? It’s true. A zombie game set in the grim, gritty world of Deadwood would be atmospheric, intense, innovative, and fun.

But HBO didn’t buy it, and they made the right choice. If you’re going to make a game based on a TV show, you need to be able to sell the game to people who watch the TV show. Deadwood plus Zombies worked for only a limited subset of the Deadwood-watching audience, so the IP wouldn’t have helped much at all.

Just for the record, though, you often can make an IP better by adding complementary gameplay elements. The Travel Channel’s “Lonely Planet”  TV show chronicled adventurers who explored remote countries. This could make a great game for the explorer crowd (which fits the TV show’s demographic pretty well) with just a few additions. Add some ancient treasures for the explorers to find, maybe a gang of bandits or two, and you’ve got yourself a fun exploration game. (However, Lonely Planet fails the “is it mainstream enough?” test, so it’s not much use.)

If you have the luxury of picking an IP to work with, make sure it’s one that can actually be turned into a fun game without breaking the soul of the IP.  Tweaks and adjustments are okay, but over-the-top alterations sap the IP’s strength and make it useless.

Designing For IPs Is Fun

Although a few types of designers will chafe against an IP, most designers find the restrictions liberating. That may sound weird, but it’s not. If you use someone else’s IP, they’ve already answered a bunch of hard questions for you, and now all you have to do is make a fun game within those restrictions.

Picking the right IP is obviously pretty crucial, but it’s just as crucial to work with the IP, allowing its natural boundaries to define your game, rather than hacking the IP to bits.

The recent major layoffs at Mythic have caused quite a buzz. Here’s what Mark Jacobs had to say about them:

With respect to customer service, quality assurance and play testing, prior to the launch of WAR, we hired additional people to deal with the rush of demand associated with an MMO launch and to insure the best possible experience for our players.  We accomplished that goal and as a result we had the smoothest-ever launch of a major MMO.  Since the launch last year, the demand for customer service has gone down as players become more familiar with the game.  Obviously, demand for a large QA and play-testing staff also falls after launch.  As a result, we saw a staff reduction which is in line with the company-wide initiative. In no way does this conflict with our commitment to customer service.  Staffing numbers will always map to consumer needs – it goes up when we launch new products and expand popular ones, and comes back down as players become familiar with the game.

What’s interesting here is that he suggests the layoffs only involved QA and customer service staff, but in fact it appears to have also involved large numbers of designers as well. Does design quality also “map to consumer needs”?

But let’s leave that aside. What he explicitly said here was that he fully intended to fire a lot of people he hired. Those people did not, contrary to popular belief, know that they were going to get laid off after the game shipped. You don’t get high-quality people to QA your game for minimum wage by telling them that they have no future. You let them believe they are “paying their dues” before they can move up the company ladder.

Scott Jennings discusses the feeling of betrayal that those laid-off employees feel. But Tobold wants them to stop whining and accept their responsibility:

If a company makes a good product, which is profitable, all the stakeholders, that is employees as well as shareholders, somehow get a slice of that profit.

…

So if a company makes a bad product, which makes a loss, the pain has to be shared as well. You can’t just say “let the shareholders take all the loss”. Not only would that be not very fair, but also it is not a viable path into a better future. Layoffs and restructuring are painful, but they are less painful than the company going belly up.

First, I want to know what company besides SOE gives their employees ANY financial reward for success. EverQuest 1 developers got fat bonuses for a while. They were the exception, not the norm. Nobody else has ever gotten regular bonuses for good work. There’s not even a promise of reward! These employees all know up front that they will get jack squat if they succeed, and they will probably get fired if they fail. And then, here’s the real kicker: they may get fired if they succeed, too, if the company needs to down-size or “meet consumer needs” or shit-can or whatever you want to call it.

 But it’s okay, right, because they had to know they were just temps who would lose their jobs, right? I mean, how could they NOT know they were being abused? So of course they deserve the abuse! Nice logic.

I don’t buy the line that all of the hundreds of people who worked on a game that failed are completely innocent and unaware of that failure, and that all the blame is due to high management.

Unaware of the failure? No. Incapable of fixing it? Yes. But Tobold doesn’t believe that. Not deep down. And he’s certainly not alone in that. What Tobold really, really wants to say is that, in the aggregate, barring occasional errors of judgment, employees who get laid off deserve what they get.

But if all of the employees in one of the game companies now firing people would have done their job perfectly, and created the perfect game, perfect game design, no bugs, perfect quality control, perfect customer service, and so on, the layoffs wouldn’t be happening.

An MMO development team is a machine full of cogs. That’s crucial to its success… if every one of those 100 employees had real power over the future of the game, there’d never be any consensus, and hence no game. Most employees have to give up control to a small number of people who lead the development on behalf of everyone. Those leaders are responsible for their underling’s jobs.

Tobold’s examples betray the typical misunderstanding of how the MMO industry works: he doesn’t realize that the industry’s miserable management practices are the root cause of almost all game failings. Tobold mentions how animation problems caused a major fuss in Age of Conan, and he implicates the artists responsible. But actually, the artists should have been following direction from the design team. If the design team failed to give the artists enough direction, that’s management’s fault for not facilitating inter-department communication correctly.

The real kicker in the Age of Conan example is that a proper triage team should have been able to discern the dramatic effect this bug was having and get the engineering team to hack in a temporary fix, rather than waiting for the art team to redo all the affected animations. Again, this was a failure of management. The buck has to stop where the decisions are made. Those people are the ones responsible for the vast majority of the success or failure of the game.

I am the first one to tell people that they need to rise up out of their “cog” positions and try to fix their game before it’s too late. But the reason I need to say that is because it’s hard. It’s not the norm. It’s a firing offense. Remember that at Mythic, people who speak out are fired and publicly humiliated (”burned at the stake”).

Tobold, can you tell me with a straight face that developers who must follow strict orders or be fired are just as responsible as the people who gave the orders? It’s insulting to blame the cogs. (I want the cogs to stand up for themselves even if it means getting fired, but that doesn’t mean they’re not cogs.)

So here’s the bottom line. Tobold may not have the balls to say this outright, but I will. If you get laid off by an MMO company, you completely deserve it. You bought into the broken and unmaintainable development process, you knew full well that you were being taken advantage of and that when you’d done your best work you would be fired. And if you didn’t know that, you deserve to be fired for not doing your homework before you got into the industry.