From ideas to implementation...

This post is an answer of sorts to a request on Twitter and one of the more common questions I get on mail, and see on the forums.

What exactly is the process that is used to decide on what features, content or changes you add to game updates for an MMO?

It is an interesting question to provide some insight into, because it is one of the areas that users wonder about the most, both from a selfish perspective 'Why didn't they pick the ideas I like?' and from a more pragmatic one 'Why did they pick that feature rather than this other one?', and is probably the most frequent source of the 'They don't know their own game' attack, favored by many veteran trolls.

Now, I can't speak for everyone, or every dev team, so this will be more of a look at the types of issues that you consider, and the order or importance of the different forces at play when a team has to decide what it is that they should add to a game to improve it. The exact details will vary from team to team, depending on resources, processes, platform and the stage your project is at (has it been around for several months, several years or many years?)...but what I can do is provide some insight into the questions that we generally ask along the way.

This won't be a 'this is why we are right and why you are wrong' type of defensively toned article, as it's really more of a gray area, none of us really know whether any given suggestion is the 'right' solution anymore than any of us could absolutely guarantee a sporting result. We might think we have made the right decision based on all the information to hand, but there is always the possibility it doesn't turn out the way we expect.

On a slightly side note...

Before we start, there is another reason this is a fun subject to write about. This particular topic is actually linked to one of the questions I frequently like to ask potential candidates when we are interviewing for designer roles. I will usually ask prospective designers to name a change to their favorite MMO that they really disliked. Most people can answer it quickly and easily, whether it was a direction change, a piece of poor content, or a class balance concern, they are usually able to jump right in with an answer. What I then ask as a follow-up is whether they can put themselves in the designers place and tell me why they think the designers of that game made that change? If it was such a poor change, why was it introduced in the first place and what did the candidate think the original team were trying to accomplish with it.

That is really when I see what I am looking for in a potentially talented designer. If they can answer that question as easily as they named the issue, then I know they are looking at is a designer. Much of the time it is question that trips people up, they haven't been thinking in those terms. It is a natural human reaction to consider any given change of circumstances purely in terms of how it affects you personally...a designer however has to be able to process the big picture. There is always, always, a reason why a change was made, and the good designers are those who are always asking themselves 'why?' when they are playing other games...

It is often far more insightful to analyze a change that you didn't like, rather than those you do like. Trying to establish the reasons behind a change can often lead you to the some interesting questions

..because there is always a reason...

Firstly...

...there is one thing above all else that is worth mentioning before we start, and that is the teams working on a game are genuinely always working to try and improve the game. They might not always get it right, there will be missteps and mistakes alongside the successes, but it will invariably stem from a genuine attempt to change things for the better.

So what are the possible reasons?

Top Level goals

The first choices you have are at the top level - what are the current goals for the project? This largely is the part defined by the business and the data behind your current player behavior. This primarily focuses on whether you need to focus on acquisition of new customers, conversion of trial or new customers into subscribers, retention of existing subscribers, or, if there are no major issues standing out, what balance you strike between those three areas.

Those are the areas that the business is concerned with, and most of that comes from analysis of the data, billing statistics and sales activity. The business will be tracking what are know as Key performance Indicators, or 'KPIs', and that will largely dictate the type of areas that the production teams are asked to focus on.

That is the top level, and really the usual extent of the business demands on actual design. Rather than being interfering or micro-managing, those responsible for setting these goals are purely interested in that top level view, and simply want to make sure the production team have the correct focus at any given time. What that focus is will depend on the project. Maybe I am just lucky to have worked with good senior management, but I have rarely found them to be micro-managing or interfering.

So once those goals are set, they are taken to the production team, and they are tasked with fining the best approach to meet the targets that have been set.

Define the approach

The targets will then be assessed by the team's production seniors, usually the producers and / or senior designers, and they will look to define some features or content additions that will help address those areas that the project has been asked to focus on.

So where do the ideas come for?

Ideas, ideas, ideas....

There are always enough ideas to go around. Really, actually having the ideas is the least challenging part of the process. There are always way more ideas 'in the mix' as it were, than there is time to do them all. Players have ideas and suggestions, designers have ideas and suggestions, and there is usually an extensive backlog of ideas that the developers have considered, or want to consider.

This is an area we rarely ever struggle with, as there is usually a lengthy list of things you would really like to do at any time...so the next step comes in deciding which of the things on that list are most likely to help you achieve your targets.

The list of possible ideas contains those suggested by players and designers alike. Really nothing is ruled out at the start. We also frequently re-visit items on those lists that were previously discounted. Things change, resources that were previously unavailable may become available, or a slot may open up in your schedule.

What that means though is that we are never short of possible things to do...

Judging demographics

This is also the stage where the team have to assess which part of the player-base they want a feature or content addition to appeal to. Or which segment they need to address, or have been overdue some content. The extent to which you have to do this will depend on the profile of your game in the first place. If it is has a pretty narrow focus this could be as simple as establishing what level range you aim the changes or additions at...but if you have a wider scope you may also have to assess which group of players you want a specific addition, or set of additions, to appeal to. This is where you could be faced with striving for the right balance between questing, dungeons, raiding, crafting, role-playing, PVE gameplay, PVP gameplay, mini-games, open world combat, solo content, team content, or guild content.

That is honestly the most challenging part of the equation for a mainstream MMO, as you most likely have some level of interest in all of those areas.

So the production seniors will pick the features that both fit within their deadlines and resources, and also have the potential to help the project meet the targets set for it.

Making the Choices

Here is where the team will try and match the possible solutions up against the targets, bearing in mind the technology and resources available to them. This is the stage at which a lot of potential ideas will be assessed for viability. Some filtering will be done immediately, and a pool of possibilities will be assessed in more details. That means that coders, artists and designers will be asked for estimates, and any deadlines and resource considerations will be taken into account.

Once that is done, the team will decide upon the features or content additions that are to be worked on, finding a balance between what will best serve to meet the objectives before them, and be achievable with the time and resource they have available on the project.

This is also where you bring in the technical experts whose areas may relate to the proposed changes. Will the databases stand up to it? Are infrastructure changes needed for it? Will it impact performance or rendering? Basically trying to establish anything else that needs to be considered.

Designing the details

So once the team management and seniors have decided on which features are the right fit they have to outline the plan for the team, and set people up with the relevant tasks involved in making the feature, or content addition, actually happen.

Personally here is where we go into a design then review stage. I don't like telling designers, be they content designers, quest designers or systems designers exactly how to go about any particular design. This part varies between different teams and companies, based on the size of teams, the structure, or those involved. Sometimes the design is already set by the seniors alone, and implemented by the team, sometimes it is more of an organic process, with the details also worked out by the designers. Personally I have always preferred to let the team work on as much as is feasible (while staying within the framework of the targets and budgets involved), as it leads to them owning the changes as it were, and being more invested in them being as good as they can be.

No business really has space for everyone to do as they like, but once the 'box' of you goals are defined, and you know the tools available, I have always found it more productive to let the teams decide how they choose to use those tools to fill the box, rather than trying to micro-manage them.

We then use a review process to keep tabs on things and ensure that things are kept on track.

Iterate, test, get feedback

Then comes the important bit...

You rarely ever get it right first time! So the next steps are vital for the feature working well when it is released.

This is when the content or feature will be released first to internal testing within the team, then to the Quality Assurance teams, and then to the players through test servers. At each stage feedback is taken from those testing and the feature is tweaked, poked, prodded and polished to try and get it into as good shape as is possible.

Most times that a feature doesn't work as well as it should, or has too many bugs, or doesn't quite meet the goals you set for it, it is usually because the designers, coders or artists didn't get enough iterations on it. It may be you ran out of time, slipped over budget or didn't get the right testing, but essentially all those things equate to losing out on a certain number of iterations that would always have improved the feature or piece of content in question.

Personally those features I can look back on and not be totally happy with how they worked out can almost always be linked back to us not getting enough iterations on them internally before we went live with them.

That is also the stage where the community feedback is important. Players look at things in slightly different ways to designers and QA testers and will bring another perspective into the equation. That is why I always like to have a 'test live' server on our projects, so that prospective builds can be shown to the public. It is a vital part of the process, and the players invariably find something we have missed.

The test live type servers usually build up nice, constructive and helpful communities as well that are really invaluable to us as developers as they give us some users that we can speak to directly and interact with for another perspective on things.

Wrapping up...

So there you have it, that's an overview of the sorts of aspects and considerations that influence our choice of features or content additions. This process really takes place on a rolling basis as well. It isn't a static 'start and finish' timeline, rather something that is going on all the time. That is the beauty of MMO titles, you are always able to keep on building and adding to the game. It also means that you are always on your toes, planning, trying to be proactive and reacting to changes in player behavior, opinion or activity...

...and with an MMO your jobs is never done!