1. Korea is the future. They are five years ahead of us and where Korea goes, the rest of the world will follow.  (I have been hearing this for at least five years. )
2. Free to play with micro transactions is the one true business model.
3. Client downloads are death.
4. We must look beyond the core gamer audience and embrace more casual players.
5. Women are 50% of the audience.
6. Don’t trust the client, it is in the hands of the enemy.
7. You game is a service.
8. MMOs are hard. No, they’re really really hard. Seriously. You can’t possibly imagine how hard they are.
9. Runescape is the second biggest MMO and is the one you should really watch.
10. Club Penguin is huge and is the one you should really watch.
11. Lineage is huge in Asia and is the one you should really watch. (These days it’s actually more likely to be ZT Online or some other game in China.)
12. Flash is the best platform to build your MMO on.
13. Web games are cheesy and no core gamer will ever play them.
14. Rudy’s has the best BBQ in Austin.  No, County Line is better.  Are you kidding me?  It’s obviously The Salt Lick.
15. The game industry is bigger than Hollywood.
16. Triple-A MMOs are a dead end. WoW is impossible to compete with.
17. Game X is going to take the top spot from WoW.
18. Games cost so much to make now that the industry is about to collapse under its own weight.
19. MMOs are just like MUDs and you should all learn the lessons MUDs learned X years ago.  (To be fair, I don’t think I’ve actually heard this one in a few years.)
20. All of these things happened in UO. Why won’t you people learn from UO?
21. The community around your game is incredibly important and you should take care of them.
22. Your players have no idea what they want. Don’t believe anything they say.
23. Forums are very important.
24. Don’t believe anything you read on forums.
25. Launch is just the beginning. The real work comes after launch.
26. Metrics, metrics, metrics.  Record everything!
27. Don’t record too much with your metrics. Too much data is just as useless as too little data.
28. Some people spend CRAZY amounts of money via micro-transactions
29. MMOs on consoles are the Next Big Thing.
30. Casual games are going to save the PC market
31. MMOs are going to save the PC market
32. My background in economics tells me…
33. WoW is a wonderful thing for the industry because of the way they expanded the market.
34. WoW has set expectations so high that you can’t make an MMO for less than X million dollars. (Where X>=30)
35. Person X is a jerk. Let me tell you this funny story about…
36. Company Y is so clueless that they will never put out a successful game
37. Fantasy is where it’s at! MMOs just don’t work as well in other genres.
38. Fantasy has been done. Players want us to move on to other genres.
39. There’s so much money to be made in Asia! Just make sure you internationalize your game first.
40. Gamers in Asia demand click to move so they can smoke while they play.
41. Players are going to trade stuff for real money no matter what you do. You might as well embrace it.
42. RMT causes huge amounts of fraud.
43. Gold spam is impossible to stop.
44. Our startup is the next big thing in MMOs.  Just look at this giant pile of money we raised!
45. Game development is all about iteration. Waterfall doesn’t work.
46. There’s this guy named Richard Bartle who proposed dividing players into four types…
47. You can’t use scripting languages in games. They’re way too slow.
48. Writing all your code in C++ is stupid.
49. Launch early, launch often.
50. You only get to launch once.

Everybody knows that building an MMO involves a lot of people, takes a lot of time,  and costs a lot of money. Fewer people know how much money, how many people, and what all those people are doing for all that time.  I thought I would share a bit of my experience on Pirates and give you some idea what those big MMO budgets are spent on.  All of the data behind this post is up on Zoho Sheet; feel free to do whatever you want with it. (Also, Zoho is much cooler than the Google Docs spreadsheet.)

There are a few things I should mention up front: These are not the numbers from Pirates.  We had a gradual ramp up of people and project scope over the course of five years and that’s definitely not the right way to do it. I also rearranged people to compensate for some of the staffing shortages we had on Pirates.

This “budget” also doesn’t include anything but people’s salaries. Most costs scale up with staff, including desktop hardware, office space, software, office server capacity, taxes, benefits, etc. You would need to add 40-50% to the dollar figures to take that into account.  I mostly care about the percentages, so I didn’t bother trying to include any of those items. The budget also doesn’t include any server, hosting, or bandwidth costs. Those can be pretty significant in the beta and live phases.

Most of the salaries were drawn from the 2007 Game Developer magazine salary survey. Those are:

Programmer	$83,383
Artist	$66,594
Designer	$63,649
Producer	$78,716
Tester	$39,062

There were three functions I didn’t have any salary surveys to draw from, so I just made up some numbers. I assumed Community people make about the same as Designers and that Operations people make about the same as Programmers. I put Customer Service people down at $30k on average, which is much more than front-line CSRs and forum moderators, but less than supervisors and managers.

Community	$63,649
Customer Service	$30,000
Operations	$83,383

I broke the project down into four phases: Pre-production, Production, Beta, and Post-Launch. Pre-production is a period where tools are being built and the game is being designed, but work has not yet started on much (if any) final content. Production is the Big Expensive Part when tons of content people crank out all the final assets for the entire game. Beta is the period at the end of production where your game is exposed to external players in a significant way, and includes closed and open beta. Post-Launch is obviously the period after the game has launched.I also divided the effort into three major areas: World, Systems, and Infrastructure. World is the construction of the game world, quests, dungeons, etc.  Systems is the development of character classes or skills, character customization assets, UI, and game systems.  Infrastructure is the less-glamorous stuff behind the scenes like core server code, operations tools, scheduling, and IT. I broke it down this way for the benefit of a future post that currently exists only in my head.

Pre-production

The purpose of the pre-production phase is to figure out the answers to a bunch of questions before the team grows to its full size and things get really expensive. There is an emphasis on programmers and system designers in this phase, because they have the most questions to answer. As expected, the programmers take up the biggest chunk in pre-production. They are both numerous and expensive. System development is also a big focus in Pre-production.

Production

This is where most of the money on the project will be spent, and most of that is spend on building the world:



Beta

During the beta phase other significant costs (such as operations and customer service) start to come in, but the content team is still going full bore on building out and bug fixing the world, so it doesn’t affect the numbers too much.

Post-Launch

The Post-Launch phase of the project is represented in this graph primarily because it takes a while to get money out of your players and through the various intermediaries involved, and into your bank account.  Even if you have 100k players on launch day you won’t see revenue from those players for a while.  If the game isn’t at least self-sufficient beyond that, then you’re in trouble.  The Live phase has a smaller number of world artists since you are not building the main world anymore at this point. Depending on the (paid or unpaid) expansion pack strategy of the game, this will vary.

Totals

Here are some graphs to break down the total amounts spent. See how world is the biggest chunk?  That’s why everyone is talking about user-generated content.

How closely to these numbers reflect the budgets on MMOs you’ve seen? I’d love to hear your thoughts.

At ION I gave a talk on our development process for Pirates. Darius Kazemi has posted a transcript of the talk. It’s also up at the Vault Network. I wonder how much buzz it’s going to get.

I’m giving the same talk at AGDC this year, so if you missed me at ION you can catch it there.

Andy Brice recently posted on getting feedback from software customers. With Pirates, our options are similar but somewhat tweaked.

We host our own forums for our user community to hang out on. On most MMOs about 10% of the player base actually uses these, and they self-select into a very hard-core and usually unhappy group. We can use the forums to find out what they’re unhappy about, but they probably don’t represent the actual player base very well. Still, listening to this segment of our community is important.

Click-cancel surveys are another common option. When someone goes to your site to cancel their subscription you ask them why they’ve canceled. SOE isn’t currently set up to run these, so we don’t have that data available, but many games do this kind of survey. This information is useful for finding exit points for players so you can eliminate them.

Recently I’ve started doing something a little different. I show up in game with no warning whatsoever and announce that I’m running an impromptu devchat. I offer to teleport any players who want to attend to an out of the way spot and then spend an hour or so answering their questions. I’ve run four of these so far (with one of our designers helping out on all but one of them.)

The biggest difference between what I hear in these impromptu devchats and what I read on the forums is the tone.  The forums are all about this OMG important issue or that OMG important issue.  The devchats have all been players asking about various new stuff that we might add to the game. (The answer is almost always “That’s a great idea that we want to implement, but we don’t know when we’ll get to it.”)  I think to get more feedback from players I’ll need to actually ask them some questions.

Maybe I’ll have to try that in the next one…

The other day I was on a conference call with SOE and said something like, “That build will go to testbed on Monday and to beta a week later.” Since we are going live tomorrow, they were confused by my calling anything “beta”.  I meant “live” of course, but we’ve been in closed beta for two years and just finished a month of open beta. Old habits die hard.

It did get me thinking about the difference between the two and the big change we’re going through when our first paying customers log into the game. The shift in vocabulary is really the least important change that launch day will bring. The biggest change is that we shift from doing players a favor by letting them play to them doing us a favor by being our customers.

When you’re in closed beta you have a huge pile of applicants begging for a small number of beta slots. They have to play by your rules or you will kick them out, and those rules are pretty draconian.  They can’t let anyone know they’ve been accepted to beta. They can only play during select hours. Their characters could be wiped at any time. They work for you.

When horrible bugs or completely broken builds happen in beta, people are upset, but they understand that such things are what they signed up for. The people who rant about stability problems in the beta forum are invariably attacked by other testers with cries of “It’s a beta!” These “beta-cops” have much more tolerance for downtime than the developers do, and often need to be reined in.  Extending downtime to debug a serious server problem is a frequent occurrence in beta. Beta downtime is often unpredictable and usually not announced more than a few hours in advance. You also tend to push the limits of your systems to see where they break, even though the breakage means hardship for players.

All of that changes when you go live. Once your game is live, yours is just one of many ways your customers can spend their time and money. You are lucky they picked you, and if you want to keep them, you will treat them well. You can’t tell them what they can say or when they can play. You can’t ever delete (or lose) any of their data without serious repercussions.  You work for them, and can’t ever forget it.

Your game must be up as much as it possibly can be. If another half hour of downtime will let you diagnose a problem that will take two days to figure out otherwise, tough.  (Obviously exceptions can be made if the half hour of debugging will save you a hour of downtime down the road.) Planned outages have to be announced at least a day, and preferably a week, in advance. Major changes can’t be on the test server for a few days, they need two or more weeks. Nobody gets check-in permission on the closest-to-live branch(es) unless multiple high-ranking staff members have signed off on the change.

Some things don’t change when you go live. Communicating honestly and frequently with your community remains essential. In fact, communicating with the community gets much more interesting after your NDA drops. They start to have an idea what they’re talking about when they can see what game you actually made. Of course keeping them involved in your decision making process is just as important in beta as in live, the audience just gets larger because the whole world can see the discussion.

At least I think that’s how it will go. I’m still 14 hours from launching my first MMO. Maybe those of you who have done this before can tell me how far off I am.

As promised, here are the slides from my “Adventures in Middleware” talk at OGDC 2007. Thanks for braving the 9am time slot to come and hear me yammer for an hour. I hope it was helpful.

I had a great time and learned a lot at OGDC. I’ll have to post more on that later.

Scott Berkun has a nice post up about why research labs fail at high tech companies. He has written a book called The Myths of Innovation that comes out next month.

I give up. I’m not going to finish this book, and I suggest that you don’t even start it. I made it through Chapter 9, which is about 2/3 of the way through the book, and that’s enough. My time is worth more to me than the remaining 140 pages.

Winning at New Products: Accelerating the Process from Idea to Launch is an incredibly dense and poorly written examination of the new product process in a wide variety of industries over the past twenty years. It has a few good points, to be sure, but it bombards you with those same few good points over and over. Most of the book is mind-numbingly obvious observations about what makes a product successful. I’ll just tell you those few good points here and save you the trouble.

The Good Parts Version

Robert Cooper has studied the new product process at hundreds of companies over the years and has gathered some useful data. Here are the few points I think it’s worth taking from the book:

1. Do your homework up front — Research your market, focus test your concepts, and get buy-in from your own management at the start of the process. If these things, don’t look right, figure out how to adjust your concept or cancel the project. Do all of this before you go into development and spend a bunch of money.
2. Dedicate people to new products — The people working on a new product team should report to the project leader of that team. Matrix Management just leads to less-dedicated teams and makes it much harder for the project lead to do his or her job.
3. Involve the customer every step of the way — Test your concept with them. Talk to them to get an idea what their actual needs are. Let them test the final product in the field before you sell it to everybody so you can work out the kinks. Your customer is your strongest asset in developing a new product.
4. Have a new product strategy — Your company is hopefully going to have more than one new product. Develop a plan for what markets you want to go after, and then develop products to fit your strategy. Adapt your new product strategy to meet changing market conditions once you see how your products are doing.
5. Have strong go/kill gates — Have a process by which projects are evaluated based on profitability, feasibility, and fit with the strategy. Actually use these gates to kill projects based on reasonable criteria and not just the internal political power of the project lead.

All of these are very good things to do. They also aren’t completely obvious, and it’s valuable to read about them and how they have worked (or not worked) in companies in the past. But a book with these five points is about 150-200 pages long, not the 400 that Winning at New Products weighs in at. This book has so much extra junk in it that it’s hard to find the good stuff.

Incredibly obvious observations

On page 101 of the book we find the two dimensions of market attractiveness:

1. Market potential: positive market environments, namely, large and growing markets, markets where a strong customer need exists for products, and where the purchase is an important one for the customer. Products aimed at such markets are more successful.
2. Competitive situation: negative markets characterized by intense competition, competition on the basis of price, high quality, and strong competitive products and by competitors whose sales force, channel system, and support service are strongly rated. Products aim at such negative markets are less successful, according to both NewProd and the Stanford Innovation Project.

So what he seems to be saying here is that a product that the customer needs in a wide open and growing market will do better than a new product that is going up against an established market leader that is already doing a good job of meeting the customer’s needs? Brilliant! That must be why he spent half a chapter explaining this concept. (What you see above is a summary of that longer version.)

Completely clueless about software

I didn’t expect the book to have any examples from game companies, but there also aren’t any examples from software companies. In fact, the following quote, from page 261, shows that the author doesn’t understand software in the slightest:

For example, in the development of a new software product, the proposal “to have most of the code written and partially debugged” is a very poor milestone. Words such as “most of”, and “partially” are not measurable, and further, there is no time frame. Rather, the milestone should be quantifiable; “to have 30,000 lines of code written and fully debugged by day 95 of the project” is more appropriate.

Judging the completeness of a software project by the number of lines of code it contains is ridiculous. Unroll your loops, boys! We’ve got a milestone to hit!

Not only can you not reasonably predict the number of lines a project will contain in advance, you are also usually better off if you have fewer lines rather than more. You really don’t want the criteria by which your programmers are judged to be number of lines of code they produce. You would be driving them to copy-paste-modify more, and pay no attention to re-use or reducing coupling in their code.

Most of the examples in the book come from manufacturing. Software development is much more like the “fundamental research projects” described on page 151:

Although a fundamental research project or science project may ultimately yield a new product, often the new product cannot be well defined at the beginning. Indeed, it may take months of technical research before it’s even clear what might be technically possible. [...] the Stage-Gate process described above may be inappropriate [...]

Obviously the average software project starts with a much clearer picture of the project’s goals than the average research project, but the “we don’t know what we can do technically” aspect of them is very similar.

Credit where credit isn’t due

The book, and the author’s website, state that 60% of the businesses surveyed use the Stage-Gateâ„¢ process. The reader is left to infer from this that these companies read Dr. Cooper’s books (or paid him to consult) and implemented their new product processes as a result. While I’m sure that has happened in numerous cases, it certainly isn’t the case in most of them. In many cases, the new product process in these companies predates the coining of the term “Stage-Gate”.

The author has attempted to apply Stage-Gateâ„¢ to any new product process in any company that has a series of steps with go-kill decision points between them. It’s sort of the reverse of what happened with Scotch Tape and Kleenex. He’s trying to associate his trademark with the successful new product processes in the industry even though no causality exists.

But what about Stage-Gate itself?

The Stage-Gateâ„¢ process, as described in the book and at Stage-Gate.com is not a software development process, it’s a new product development process. It operates at a higher level than project management processes like Scrum. It emphasizes cross-functional teamwork, but in the business-level context of Stage-Gate, cross-functional means Marketing, Manufacturing, Development, and Sales, not what we usually take it to mean: Art, Design, and Code. I didn’t really understand that when I wrote my previous stage-gate post.

Most of the people on a software project work on that project within a single stage (Stage 3 - Development) of the overall project. For those people, stage-gate doesn’t affect them except to define the criteria they must meet for development to be considered finished. For those of us who are in a position to influence the “what project should we start” decisions in our companies, we should consider something like stage-gate to make informed go/kill decisions on the projects. The criteria for our “want” driven entertainment products is not going to be very similar to the criteria outlined in this book for “need” driven products, but the idea of having defined stages and gates is a good one. We just need to figure out what it is we can measure in our industry to use as a basis for our own gate criteria.

I just came across an article on Data-Driven Design for game engines. We have found it to be very useful to data-drive as much of the game as possible. Though we haven’t managed to be as complete in our purging of hard-coded game-specific features, we have gone pretty far down the data-driven road. The biggest thing that we still have hard-coded (and I wish we didn’t) are the global enums… things like the nations, careers, control types, and outfitting slots that appear in the game. The stuff that actually USES these things all comes from XML files, but the constants themselves are all defined in the code. Unfortunately that means that every time we need to add something to one of those lists we have to make a code change and make the poor designer wait for a build, a sin that breaks one of my own rules.

Look at me reblogging 5 year old posts.

The single biggest factor that decides the amount of work you need to do to get your game out the door is the project’s scope. Time is money, so it’s also the single biggest factor determining the budget of your game. If your scope grows halfway through production, your game is going to slip. Making certain decisions early and sticking to them will have a big impact on your ability to ship your game in a predictable amount of time for a predictable amount of money.

Scope in Game Design

The best place to control scope is in your game design. A single paragraph in a design document can represent day or weeks of work for other departments, so it is vital that the game designers keep project scope firmly in mind at all times. To that end, here are some things that designers can determine at the start of the process to keep the scope constant.

1. How many player modes does your game have?

How often does the control scheme change in your game? Does the UI change with it? For many MMOs there is only the “run around and fight stuff” player mode, and the player’s avatar follows that control scheme consistently throughout the game. Some games, like Star Wars Galaxies (with Jump to Lightspeed) and Pirates of the Burning Sea have the standard MMO player mode for avatars and a very different player mode for vehicle combat. If you budget for one player mode but try to cram two in, your players will notice and they won’t be happy about it.

The number of modes will drive how many times you need to fine tune the UI, camera controls, and character controls. Every UI element in the game needs to consider player mode to decide if that UI element can appear in all modes unmodified or if it needs to be customized for one or more modes. If you are trying to build a game on the cheap, find a design that works with only one player mode. A second mode won’t double your budget, but it will increase it substantially.

2. How many players do you want to support in a single world instance?

Much of the budget of your game is driven by shard size. You will need a lot more space in your world to support 1,000 simultaneous players than to support 100. You will need more zones, quests, NPCs, mobs, long distance travel mechanisms, and map systems the bigger your world gets. Figure out how many people you need in the game to make the multi-player systems function and use that to drive the other number-of-players based decisions (like world size.)

3. How many parallel advancement paths do you have?

Many games allow the player to advance along many paths at the same time. WoW has level, two crafting professions, and honor-point based advancement. SWG had three major skill advancement paths (crafting, combat, entertaining) plus faction-base advancement. Each of these paths has unique ways to make and measure progress that are not present in the other paths. That means they each require design of new advancement systems and new code to implement those systems. To keep your costs down, use the same mechanism for advancement in all of your parallel paths. If players earn XP that they use to buy skills off a tree, use that for all your paths and differentiate based on how they earn XP. If the players advance down a linear path by using skills but spend currency on buying skills off the line, leave everything the same except the way they take a step down that path.

4. How many branching advancement paths do you have?

Many of your parallel advancement paths will have branching within them, or at least allow the player to select a small number of parallel paths out of a larger set. The number of options has a big impact on how much time you will spend tuning your game. You will also need unique skill icons, animations, particle effects, and equipment for many of these branches, so the number of options will directly affect your art budget. Determine early in the project how many branches you need to let the players feel differentiated, and stick with that number. Adding branches after launch incurs the same tuning cost as adding them before launch, but is something your players will love.

5.How important is replayability to the game?

Do you expect players to play through the entire game with several alts? How many different newbie experiences do you need to provide? Each of these parallel content paths costs scarce content creation time. If you aren’t expecting a lot of replay from the beginning there may be time you can save here.

6. Do you need a seamless world?

Does your game call for a seamless world? For some games the answer is definitely “Yes”, but many games will do just fine with hard zone boundaries. Some players will make noise about the loading screens, but that’s true of any design decision you make. Having zones didn’t hurt EverQuest or Dark Age of Camelot’s performance, and I don’t think that having a seamless world has really helped World of Warcraft’s.

Seamless worlds are more expensive than zoned worlds. On the art/world building side you have to build the transition areas in a way that lets you have the textures and geometry from both areas loaded at the same time. The world builders also have to deal with editing what’s effectively one continuous ground mesh for the whole world. Engineers get a lot of extra work from seamless worlds because of the server hand-off issues and issues with players acting across server boundaries. The game’s world building tools have to be much more sophisticated to support editing transitions between zones. Operations and customer support costs are going to be higher for a seamless world thanks to all the object-dup and object-lost problems that are inevitably going to crop up with the more-complex server technology required.

If your game requires a seamless world, by all means use one. If not, use zones and save yourself months of development time. Make sure you stick with this decision once you make it, however. Switching from one to the other is going to invalidate a lot of code and art.

Scope in Production

There are many production-level questions to resolve to determine the scope of your project. These factors don’t really affect the game design, but can change the way the game appears to your customers.

7. How big is the gap between your minimum hardware spec and your recommended hardware spec?

Your art and engineering teams are going to have to do the most work to make the game run well on your minimum spec machine. If your recommended spec has to look significantly better than that, you will probably be incurring significant additional art time for second versions of many assets. You will also require additional engineering for the switching between quality levels.

8. How high-end is your minimum hardware spec?

You pay for every pixel and every polygon that an artist produces. Higher poly budgets and bigger textures will increase the time it takes for your artists to develop assets. Because these things are driven by the CPU and GPU horsepower on the min spec machine, picking your minimum hardware spec can have a huge impact on your project’s scope. Higher system requirements will also affect the potential size of your market, particularly in Asia.

9. Can you buy technology, or do you have to build it?

Developing every new piece of technology for your game costs money. You can often constrain the scope of the project with middleware. There are game middleware products for just about everything these days, so even if the “whole game” middleware like Big World or Hero Engine don’t work for you, smaller “just one feature” middleware like Speed Tree, Path Engine, or Ageia’s PHYSX probably will. Of course middleware is never going to do exactly what you need it to do, so evaluating and integrating this middleware as early in the process as possible will allow your designers to deal with middleware limitations in the game design. You don’t want to get into production and then find out that a core element of your design and a core piece of your middleware are incompatible.

Scope your project early

Every single one of the 9 scoping decisions listed above is a decision that needs to be made early in the project. In fact, they are core enough to the process that you probably have answers for many of them in your first round of documentation. Make sure these are things that you talk about up front. Spend enough time prototyping your game that you can be sure that you have the right answer to each question. If you think you need to change the answer to one of them, take a step back and see how that will affect the project’s scope as a whole. Don’t allow your scope to drift gradually upward without ever having made the decision to change it.

Be realistic about your project’s scope. If you can’t build the game you want at a given scope, don’t just charge ahead and try to do it anyway. Either accept that your game is a bigger scope (and higher budget) or start again and come up with a game that you can build at the scope you can afford. There is no shame in building a game with a small scope. Puzzle Pirates, City of Heroes, and World of Warcraft are three games with very different budgets. The thing that they all have in common is that they have solid return on investment and are making plenty of money for their respective companies.

Once you decide on a scope for the project, make sure that everyone knows what it is. Let your team, your community, and your publisher know what your scope is the whole way through the process so that they can set their expectations accordingly. If you change your scope (and slip your target date), make sure you include the scope slip as one of the reasons you’re slipping the date.

Controlling the scope of your project is the first step to controlling the project’s budget and schedule. If you want to avoid slipping repeatedly or being forced to launch before you’re ready, scope creep is something you must watch out for. You will be glad that you did!