游戏设计者必备的一些软技能（一）

本文所说的设计师有可能是策划、也有可能是运营或者其他什么岗位。

许多学校提供游戏设计方面的素质训练，但接受这种培训并不足以成为一名真正的游戏设计师。要在真实的团队中茁壮成长，新入行的游戏设计师需要培养学校培训中未系统提供的软技能和新技能。在这里，我将分享一些从业过程中积累的经验。

在游戏设计领域，区分老手和新手的关键因素之一（不是全部哈）就是对软技能的掌握。软技能指的是与个人品质和行为相关的能力，这些技能在组建研发团队成员时变得越来越重要。

虽然团队合作、尊重要求和对自己工作的高标准是常见的基本技能，但今天我想分享的是一些更加具体的软技能，这些技能对于在工作室中脱颖而出至关重要。

1.始终确保你的设计得准确落地

编写策划文档并不等于设计会被严格按照你的意图实现。实现过程中可能会遇到多种问题，比如程序员或美工可能误解了设计意图而未询问，技术需求可能限制了设计的实现，设计文档可能不够清晰，甚至无法阅读。我曾经亲身经历过这些问题。

在这种情况下，虽然一些尽责的同事会主动询问或寻求指导，但并不是所有人都会这样做。因此，确保案子被正确理解和实现是设计师自己的责任。即便团队中的其他成员没有严格按照规格执行，如果最终的游戏效果平庸，设计师会受到指责。

为了避免此类问题，可以遵循以下方法：

1. 撰写尽可能精确且易于阅读的设计文档：避免开发一个庞大的设计文档，没人会去读它（我的合作伙伴技术就明确表示过）。相反，编写几个专注于单一游戏体验的文档，并逐个实现。
2. 主动展示设计：不仅仅是将设计文档发送给相关团队成员，还要通过口头说明和图表向他们展示设计的主线。
3. 检查开发功能的一致性：花时间测试游戏，确保开发的功能符合你定义的标准。

案例

为了说明这个观点，我将分享一个实际的案例（为了保护个人隐私，名字为虚构的）：

A是一款动作冒险游戏的策划，他设计了一个机制来管理游戏主角的队友行为，包括队友的移动、态度和行动，这些机制是基于关卡设计团队的地图定位。

A编写了一份详细的设计文档，并假设其他团队成员会准确实现他的设计。然而，美术团队在修改地图拓扑时添加了新的装饰元素，并改变了一些通道的位置，导致设计实现不一致。A没有及时测试这些新内容，结果发现功能性很差，游戏体验不符合预期。如果没有引起重视，这些功能可能会被忽视。

2.为会议做准备

一个组织良好的会议通常会有议程和讨论话题。如果你被邀请参加会议，说明你的贡献被认为是有价值的，因此团队期待你的想法和意见。

如果在会议中你被要求对某个议题发表看法，而你没有事先准备，可能会显得肤浅，甚至适得其反。你可能被认为是一个“无足轻重”的参与者，无法带来附加值。即使你试图即兴回应，也可能说出无意义的话，从而损害自己的形象。

为了有效地参与会议，你可以遵循以下方法：

1. 仔细阅读会议议程：如果会议没有提供议程，向组织者询问将讨论的主题，以便你能做好准备，展现出专业的形象。

2. 思考讨论主题：在会议前花时间思考将要讨论的主题，并在你的专业知识范围内进行准备。这种准备会让你提出更多相关建议，并构建有力的论点来支持它们。

以及一个准备不足的反面例子：

B被邀请参加由项目创意总监组织的会议，其他游戏设计师也会参与。议程规定讨论一个游戏中不尽如人意的特性：来自同一方的两个玩家之间的合作行动。

当创意总监提出这一议题时，B没有充分思考过这个问题，提供了一个非常笼统的提议。而另一个游戏设计师C则提出了具体的解决方案，并用图表加以说明。她引用了使用她提出解决方案的游戏来强化自己的主张。结果，B在团队中的地位受到了削弱，而C因提供了更有说服力的建议而为项目做出了更大的贡献。选择C的解决方案不仅因为它更好，还因为它以更有说服力的方式呈现。

3.谦逊并乐于接受变化

作为游戏设计师，对自己的工作和创意充满执着是正常的。然而，游戏机制仍然只是理论上的概念，在开发并融入游戏之前，我们无法确定它的实际效果。换句话说，一个看起来很好的设计，在实际实施后可能会令人失望。这种情况非常常见。

实际上，玩家的游戏体验是多方面因素相互作用的结果，包括游戏机制、设定、节奏、玩家目标和复杂性等。一种机制可能在某个游戏中提供了优质体验，但在另一个游戏中却可能产生负面效果。

因此，游戏设计师必须展现出谦逊和自我批评的精神。我们需要客观地分析自己设计选择的有效性，倾听团队其他成员的意见（哪怕别人不是设计师），并认真考虑游戏测试的反馈。

如果某个游戏机制效果不佳，设计师必须准备好从头开始。经验表明，简单的改进往往不够，通常需要从新的机制重新设计。

一些年轻的游戏设计师可能过于执着于捍卫自己的创意，把它当作个人问题。实际上，他们应该关注的是将他们的名字与成功的游戏联系起来，而不是让他们的创意停留在一个平庸或未发布的游戏中。

以下是一个关于坚持不变的设计可能带来的后果的例子：

D是一个多人游戏的首席设计师。在第一次游戏测试中，外部玩家和目标观众代表验证了游戏机制，但指出了地图存在的问题：相对于玩家数量，地图过大，玩家容易迷路，并且存在过多的瓶颈。尽管每次游戏测试都报告了相同的问题，D对地图的修改只是微小的，未能解决玩家反馈的主要问题。几个月后，面对D不愿意从根本上改变地图，工作室管理层决定将他替换，由另一名团队成员接替他的职位。