作者： Craig Morrison

在大型多人在线游戏（MMO）的更新中，决定添加新功能，新内容或做出改变到底是怎样的一种过程？

当我们在面试新的设计师时，我总是让他们说说在自己最喜欢的MMO中有哪一点改变是最让他们反感的。很多人都能轻松快速地回答这个问题，包括方向的改变，新增加的拙劣内容或者侧重点的失衡等。而接下去我便会要求他们站在游戏设计师的角度，讲讲为何要做出这些改变？如果真的是一些拙劣的改变，为何会被提出来，以及面试者认为之前的游戏团队应该对此作何完善。

分析一些你不喜欢的改变远比分析那些你喜欢的内容有意义。尝试着去寻找改变背后的原因，那么对于那些有趣问题的答案，你便会瞬间恍然大悟了。

锁定最高级别的目标

首先你必须明确游戏当前的目标是什么？而这主要是由你的游戏项目以及当前玩家行为等信息所决定。并且主要是用于强调你是否需要争取新用户，将新用户转变成付费玩家或者挽留现有的付费玩家，而如果未出现其它明显的问题，你便需要努力去平衡这三个领域的内容。

arrow-on-target(from easyvectors.com)

游戏项目必须重视这些领域，并且通过数据分析，付费统计资料以及销售活动等方式获得相关内容；同时还需要追踪所谓的关键业绩指标（KPI），从而帮助开发团队更好地明确关注领域。

这便是最高级别的目标，并且是真正游戏设计的一般程度要求。比起干预或者微观管理，设定这些目标的人是从最高级别的角度出发，并希望以此确保开发团队不会脱离项目核心，其关注点也因项目情况而有所不同。

所以，确定了这些目标后请立即传达给制作团队，他们将采取最佳方法去完成这些预定目标。

明确方法

制作团队主管，通常是指制作人或者首席设计师，将评估这些目标，并将定义一些额外的功能或内容，以帮助明确既定项目所侧重的领域。

筛选游戏想法

我们总是有无尽的想法。所以，产生想法可以说是整个过程中最不具备挑战性的任务吧。比起实践所有的想法，你应该更会选择“混合”多种想法。不管是玩家还是设计师都有满腔的想法与建议，所以对于开发者来说，他们便需要去考虑这些汇聚在一起的广泛想法。

所以对于你来说，下一步做法便是判断在所有想做的事中，哪一件能够帮助你达到目标。

这些想法也包括玩家和设计师共同的建议；我们应该在初期阶段尽可能地包含一切可能的想法。我们也经常回头去考量之前淘汰的想法。世事多变，很多以前不适合的内容没准现在看起来就非常合适。

考虑目标玩家特点

这同样也是开发团队必须引以重视的一个阶段，即他们需要判断自己应该针对哪些用户基础添加新的功能或内容。或者他们应该完善游戏中的哪个部分或删去哪些不必要的内容。完成这项任务的程度主要基于你的游戏的首要属性。如果游戏的目标用户较局限，你便能够有针对性地进行改变；而如果你的目标用户范围很广，你便需要明确针对那些群体添加特定内容。也就是，你必须尽可能地达到不同内容相平衡，包括探索，地下城，袭击，争霸，角色扮演，玩家vs环境游戏设置，玩家vs玩家游戏设置，迷你游戏，开放的战斗，单独内容，团队内容或者协作内容等。

老实说，这应该算是制作主流MMO过程中最具挑战性的部分，而且在所有的这些领域中你可能会拥有不同程度的利益点。

所以，制作团队主管将选择那些同时满足时间期限和资源储备，并且能够帮助项目完成既定目标的功能。

做出选择

make choices(from thechoicedrivenlife.com)

在这个阶段，制作团队将围绕目标并基于自己所拥有的技术和资源选择任何可能的解决方法。这时我们将会评估许多潜在想法的可行性。除了果断淘汰一些没有意义的想法外，我们还需要更深入地评价那些具有可能性的想法。这就意味着程序员，美术人员以及设计师将参与评估任务，同时还需要考虑时间期限和资源储备问题。

做出选择后，制作团队便需要规划补充功能和内容了，并且努力做到既能够满足既定目标，也符合项目所要求的时间期限和资源范围。

做好这一点其实就等于邀请一名技术专业人士前来帮忙。数据库是否能够经受住挑战？基础设施是否需要做出调整？是否会影响游戏性能或渲染？……你应该尽可能地实践任何可能的想法。

设计细节

一旦团队管理者或主管决定了最合适的功能，他们便需要为团队的下一步工作进行规划，为每一名成员确定相关任务，包括设计额外功能或内容等。

可以说，我们进入了设计并审查阶段。我不喜欢指示设计师（不论是内容设计师，任务设计师或者系统设计师）如何执行任何特定设计任务。因为不同团队或者不同公司在面对这个过程时也会有所不同，这主要取决于团队的规模，结构，以及参与人员等。有些团队是由主管本身决定设计并交由其他成员执行，而有些团队，即使是再小的细节也需要设计师亲力亲为。我个人更倾向于让团队成员参与更多工作，因为这么做能够让他们清楚应该做出什么样的改变，并且更加专注于创造这种改变。

没有哪一个企业能够让所有员工自由选择自己想做的事，但是当你明确了自己的目标并掌握所需道具时，你便能够让团队成员自行选择所适合的道具，而不是采取微观管理的方法。

随后我们便开始进行审查过程，以密切注意并观察我们做出的改变是否合理，是否有效。

迭代，测试，接收反馈

首次尝试便能做好的事很少，所以当你发行了新功能后，下一步该怎么走更是关键。

你应该先让团队内部成员测试新内容或新功能，然后转移到QA测试者手中，最后再邀请玩家进行测试。在每一个阶段我们都能够接收到测试者的反馈，并需要根据这些反馈不断调整，改进并完善功能，尽可能地将其塑造成最佳效果。

很多时候，新功能总是会出现很多漏洞或者难以达到预期目标，而出现这些原因主要还是因为设计师，程序员或者美术人员忽略了足够的迭代过程。也许你会说缺少足够的时间，耗尽了预算或者未能进行适当的测试，但是如果这些只是你逃避迭代的借口，那么你就等于失去完善游戏功能或内容的绝佳机会。

回头看看我们之前发行的那些功能，结果都不甚满意，而主要原因便是在发行前我们未经历足够的迭代过程。

在这个阶段，来自于游戏社区的反馈也很重要。玩家看待事物的角度总是有别于设计师和QA测试者，所以玩家的反馈能够帮助我们从另外一个角度去看待同一个内容。这就是为何我总是希望在每一个项目中设立“实况测试”服务器的原因，以此让公众能够更好地了解游戏的发展，并畅所欲言地提供意见。这是一个非常重要的过程，玩家总是能够帮我们弥补一些错过的内容。

诸如实况测试这类型的服务器能够创造出具有建设性意义的社区，能够帮助我们在此平台上直接与用户进行交流，而以此从另一个视角去看待问题。

游戏邦注：原文发表于2011年3月13日，所涉事件和数据均以当时为准。

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

From ideas to implementation…

Craig  at Sunday, March 13, 2011

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!（source:usuallyfine）