作者：Scott Brodie

我日常工作中最重要的事情就是管理以下游戏设计循环：

1.听取团队成员和玩家的反馈；

2.决定要不要以及如何将该反馈植入游戏；

3.然后通过跟进这些变化是否能与玩家产生共鸣，从而验证这些决策的正确性。

我还没有精通掌握这个循环。但是，作为一名开发了《Highgrounds》的小型团队中的设计师，我发现这里存在一系列环节，可以让我更有效地与团队合作推进游戏设计：

Highgrounds(from gamasutra)

1.在找到解决方案之前明确问题。我遇到的许多反馈还只是粗糙的想法或灵感（例如，“游戏中应该存在一种能够阻击闪电球的角色”）。这种反馈一般缺乏实际意义，我们无法决定是否要将其添加到游戏中。为制定定性评估，我总会先去了解这种设计建议究竟是为了解决什么问题。

例如，玩家会提出添加一种能够阻止闪电球的角色这种建议，可能就是觉得闪电球的威力过于强大了，导致游戏中对抗闪电球的角色显得毫无竞争力，也更缺乏趣味。了解问题之后，就更容易判断这个建议是否有助于解决问题。如果这个解决方法没有用，或者会导致游戏其他部分出现问题，你至少也有了一个解决该问题的基本出发点。我还发现这更容易同提出建议的人展开对话，讨论为何我同意或不同意他的主线。这样你的反馈就是直接针对“共同的敌人”（问题本身）而不是团队成员想法或设计敏感性的对错。

2.阐述建议的基本原理。另一方面，如果是由我来提出设计建议，我认为很有必要解释游戏中存在的问题，以及为何我认为该建议是这个问题的最佳解决方法。我经常将游戏设计建议的这一部分称为调整游戏的“基本原理”。

如果我发现自己的反馈缺乏原理，通常就意味着我并没有摸透当前设计的实际问题，或者提出了一个没有必要的调整建议。

3.保存设计说明。在制定一个如何进行设计调整的决策之后，我总会建议将这种调整、问题以及基本原理记录下来以备之后所用（例如设置一个谷歌文档与全体团队共享）。为何要如此麻烦呢？有时候，你对游戏进行的一个调整之后可能会产生新的设计问题。而要解决这些问题，就很有必要记住当初为何要进行这些调整。如果有将之前调整设计的基本原理记录下来，可以避免你再犯同样的错误，确保新设计调整不会重复老问题。

4.使用“倾听辅助工具”。在我短暂的游戏生涯中，我有幸遇到许多很棒的导师。他们都有一个共同习惯，就是参加每场会议都会随身携带笔记本或画板。我发现这些记录板在游戏设计循环中帮助极大。

1）很显然，它可以在快速讨论问题和解决方案时进行设计记录。

2）它比餐巾纸、吸管、瓶子等经常出现于会议场所的东西更有助于讨论视觉概念。

3）它提供了一种关于开放性和倾听性的社交线索。如果你手动记录下团队成员所说的话，这可以让其他人知道你有认真倾听和考虑对方的想法。
笔记本本身并不重要，重要的是有意识地“记录”他人反馈的这一行为。他们的观点现在也许不重要，但可能在之后会非常有用。这一原则也适用于你同自己的团队之外的人接触的时候。在论坛上回复玩家，并及时回应被误导的发行商反馈，这些都是需要重视的情况。如果不这么做，你就有可能显得毫不讲理，长此以往你就会发现很难获得团队的反馈，而这些反馈却正是游戏获得成功的关键。

5.玩自己的游戏，了解自己的游戏。在小型团队中，设计师通常肩负重任，并身兼数职。当你有诸多琐事在身时，就很难腾出精力玩玩自己的游戏。但我认为很有必要深入了解自己的游戏，这样才会清楚为何一点小小的改动就会影响到高级设计。即使你知道游戏存在哪个问题，也很容易陷入错误的基本原理，因为你并不知道自己建议的设计调整究竟会带来哪些影响。

在《Highgrounds》这款游戏中有多达140个的角色，每个又有2-4种特殊技能，我尽最大的努力确保自己了解每一个角色的长处和劣势。你投入时间试玩和研究自己的游戏，最终有助于减少开发过程中的新设计问题。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

The Five Basics of Being a Game Design Problem Solver

by Scott Brodie

The following blog was, unless otherwise noted, independently written by a member of Gamasutra’s game development community. The thoughts and opinions expressed here are not necessarily those of Gamasutra or its parent company.

Want to write your own blog post on Gamasutra? It’s easy! Click here to get started. Your post could be featured on Gamasutra’s home page, right alongside our award-winning articles and news stories.

The most important thing I’m responsible for day-to-day is managing the following perpetual cycle of game design:

1. Listening to feedback from team members and players;

2. Deciding how or how not to integrate that feedback into the game;

3. Then validating those decisions by tracking how changes resonate with players.

By no means have I mastered this cycle. However, especially as the designer on the small team developing Highgrounds, I find that there are a small set of processes I can follow to more efficiently and respectfully work with the team to drive the design of our game forward. Here they are in no particular order.

1. Identify the Problem Before Finding a Solution. A lot of the feedback I encounter comes in the form of raw ideas or inspiration (“There should be a character who blocks lightning bolts!”). This feedback is often useless in actually helping to decide if the idea should make it into the game or not. To make a qualitative assessment, I always need to first understand what problem the design suggestion is trying to solve.

For example, behind the suggestion to allow characters to block lightning bolts may be a feeling that the lightning bolt ability is too powerful, making games against lightning bolt characters noncompetitive, and thus less fun. With the problem understood, it’s much easier to evaluate if the solution proposed will help solve that problem or not. If the solution does not help or will causes other problems in the game elsewhere, you now at least have a basis to work from to easily look for alternative solutions that WILL address the issue. I also find it easier to have a dialogue with the person providing feedback as to why I agree or disagree. Now your feedback is directed at a common enemy (“the problem”) instead of the merits of a team member’s idea or design sensibility.

2. Give Rationale Along With Recommendations. On the flip side, when it’s my turn to make design recommendations, I find it’s important to explain the problems in the game I see along with why I believe the suggestion I’m making is the best solution to that problem. I often refer to this part of a design recommendation as the “rationale” for the change.

If I find myself giving feedback without much rationale, it’s usually a telling sign that I have not fully thought through the actual issues with the current design, or that I may be suggesting a change that is unnecessary.

3. Keep Design Notes. Once a decision is made on how to proceed with a design change, I always recommend that the change, problem, and rationale be captured for reference later (a simple Google document shared with the whole team is usually enough). Why should you go to all this trouble? Inevitably, a change you make to the game now will reveal or create new problems in the design later. When it comes time to address those problems, it’s extremely helpful to remember why the previous changes were made in the first place. Having your previous rationale on hand will help prevent you from making the same mistakes twice, and ensure that new changes will not reintroduce old problems.

4. Use “Listening Aids”: I’ve been fortunate to have a number of great mentors over the course of my short career in games. A common habit between all of my mentors has been to bring a notebook or sketchpad to every meeting they attend. I’ve found this notepad serves a few important purposes in working through the cycle of design.

1. Most obviously, it allows design notes to be captured amid rapid conversation of problems and solutions.

2. It supports discussion of visual concepts better than the napkins, straws, and salt shakers that are typically available at meeting locations outside of work.

3. It provides important social cues about openness and listening. When you physically take note of what a team member is saying, it demonstrates to the other person that you are hearing and considering their ideas.

The notebook itself is not important, but making a conscious effort to “take note” of other’s feedback is. Their perspective may not be relevant now, but extremely useful later. This applies when interacting outside of your immediate team as well. It’s worth the effort to reply to your players on the forums, and respond to that misguided Publisher feedback that would be easier to ignore. Without doing the above, you run the risk of appearing unreasonable and longer term you will find yourself with less feedback from your team; feedback that could be critical to the success of your game down the road.

5. Play Your Game, Know Your Game. On small teams, it’s typical to take on a lot of responsibility and wear many hats. When you have so much else to do, it gets harder and harder to justify spending time just playing your game. But I find it’s critical to know your game well enough to understand how even the smallest changes will affect the high-level design. Even when you know where a problem lies in your game, it’s easy to land on flawed rationale because you simply didn’t know the full impact your suggested change would have.

In Highgrounds, there are now upwards of 140 characters with 2-4 unique abilities each, and I do my best to make sure I know each and every one of their strengths and weaknesses. The time you spend now playing and studying your game will pay off in the form of fewer new design problems to tackle later in development.

There are likely many other things to consider, but keeping these five basic ideas in mind can have a big impact on how often you and your team make the right change to your game.（source：gamasutra）