编者按

本文来自 GDC 官方 Youtube 频道，原内容形式为视频演讲，indienova 对其进行了编译整理，以图文形式分享。原链接见文末。

• 演讲人：达纳·南丁格尔（Dana Nightingale）
• 译者：世川

这一挑战与指标相关。指标是游戏开发中的数十条设计规则，这些规则能使游戏中的各部分彼此协同运作。通常情况下，游戏开发是这些规则从制定到执行的过程，严格遵守这些规则，就必定会产出刻板但清晰的游戏体验，这是决定性的结果。

为什么指标会指向这样的设计决定论？指标的生命周期是什么样的？

玩法指标诞生于系统设计师和游戏性程序员之间，像是：NPC 的移动速度有多快？他们能看到多远？他们的攻击距离是多远？它们会在移交给动画团队、角色美术和绑骨团队时进一步成熟，化为角色指标：NPC 的模型大小是多少？碰撞范围是多大？他们的视锥（Vision Cone）距地面有多远？然后，这些指标会逐渐成熟定型，关卡美术和场景美术会根据角色指标来定义世界的大小，回答门需要多宽？栏杆该有多高？建筑物的层高是多少？能让 X 名 NPC 共同活动的房间的最小面积是多大？一旦这些问题都解决了，指标就已经成熟，来到关卡设计师的手中，只要他们严格遵循这些指标，任务就完成了，对吧？

你可能会遇到一支受严格指标限制的关卡团队，他们最终只能机械化地构建出仅能满足指标的地图。我们不希望变成这样，也不会这样做。我们希望自己制作的混乱游戏的各个系统之间彼此碰撞，我们也能满怀热情沉浸在这个游戏世界的建设之中。给玩家以好的体验，和严格遵守支持游戏系统运作的设计指标，这二者需要达成平衡，因此我们需要灵活的设计指标。

在关卡设计师使用并测试这些指标的极限之前，没有人知道它们会如何在游戏中发挥作用。例如，每一个视觉范围指标都可能无法满足关卡设计师对视线设计的需要；关卡地图可能需要游戏性程序员的多次迭代，才能找到敌人的正确寻路路径指标；你的开发工具可能在指标崩溃的时候报错，这一点很不错，但也会阻碍实验性的尝试，毕竟设计师在尝试新想法时，总想突破极限；引擎会限制玩家附近的 NPC 数量，但关卡和叙事设计师却会让玩家去破坏一场派对——哦不，引擎说了，派对上只能放 5 名 NPC！可拾取物的交互范围可能相对物品密度而言太大，玩家很难选中目标物品；音频传播指标表明声音无法传到 20 米之外，但关卡和音频设计师正将叙事性剧情音乐（Digetic Music）导入地图，声音可能会尴尬地断掉了……总之，关卡美术、场景美术设计的一切撞上关卡设计师之时，都可能化为齑粉。这些指标是工作的起点，但为了让合作发挥作用，双方都需要保持工作的灵活性——当然，尽可能灵活，但有些事的确无法改变。比如，任务目标太复杂，就会占用太多 UI 空间。在 90% 的情况下，任务目标都可以用三个单词概括，但有时需要用更多词使得目标明确。UI 的字符限制必须考虑到本地化的需求，有些语言需要的空间会翻倍。

如果关卡设计师永远在实验性的尝试，希望系统和游戏性程序员同事跟上自己，游戏就永远无法达到可交付的稳定状态。关卡设计师遇到的许多报错警告都很烦人，但它们的存在都有其原因。否则负责构建管理（Build Management）的同事将为关卡设计师的一时疏忽而付出时间、精力和金钱的代价。关卡设计师可能会想让大量的视效和声音在整张地图上传播，但这就会达到引擎的极限。若关卡设计师提出一些看似无足轻重的需求，例如改变桌子的高度，可能就会产生多米诺骨牌效应，让角色美术动画部门进行数小时返工。这些调整必须谨慎小心，你很可能不会有第二次机会。

这是个困难的过程，但团队可以采取措施让进展更加顺利。场景美术可以了解系统设计的指标，在动画制作早期就制作出模块化灰盒套件，与后期为关卡美术设计的砖块套件相匹配。一旦指标发生变化，就能调整套件，轻松更新整个游戏。为关卡设计师创建工具，有助于将抽象的指标可视化（比如音频传播限制）。此外，还要尝试在渲染引擎的高级功能与关卡设计之间找到平衡。比如，如果做了毒气功能，而关卡设计师将它铺得到处都是，那帧率就会降低，因为他们难以预知后续影响。而给关卡设计师一个能让他们到处铺毒气的简易版本，就会知道这个临时版本要消耗多少性能，你就有了一个优化目标。无需多言，关卡设计师们，请一定遵循这些指标，但在其失效之时，记得反馈。

但如果你的关卡设计和关卡美术团队必须严格遵循指标，且对如何制定指标失去了发言权，你最终只会得到死板无聊、千篇一律的地图。指标必须能像其他东西一样迭代，拥有斡旋的余地。如果掩体的高度必须是一米，你的地图就会失去可信性，此时需要一个高度范围。这是一个平衡的取舍过程，有时必须严格遵循指标，也需要知道什么时候该让步，什么时候该坚持。如果你能围绕灵活指标这一点来设置工作流，一切都会变得容易得多，也能应对变化。但最重要的是，如果指标失灵，或是太过严苛，你必须发声。而在关卡设计师发声之时，也请务必倾听。

挑战六：转型阶段

游戏开发过程会因为各种各样的原因（比如稍后会提到的用户研究）发生变化，你可能需要在变化中快速响应。问题在于，每个团队的工作节奏都不同，一些团队已可能已经打磨完成，另一些团队才刚刚开始。你要如何在项目必须调整方向之时，尽可能减少时间和工作上的浪费呢？

试想这样的情况，关卡设计师和关卡美术团队一同工作，直到他们确定工作内容，达到预定的里程碑。这时，关卡设计团队会得到来自用户研究的反馈，他们会消化反馈、转变方向、继续工作。而关卡美术团队并没有得到反馈，毕竟这只与关卡设计有关。关卡美术打磨自己的工作内容，稳定版本，就算是完成了。但关卡设计上的改变不可避免地会导致关卡美术的改变，但过程同步得太慢，关卡美术团队已经打磨完成，如果现在要调整，不但浪费了打磨的时间，打磨过的作品还会更难改变。因此关卡无法修改，游戏可能会在未调整的情况下发布。

有些团队只有在其他团队的版本稳定下来后才能开始工作。每次上游团队调整方向，下游团队的工作进度就要无限推后。在地图仍在深度研发时，视效和音效团队无法真正开展工作，他们需要稳定的地图布局和地图内容。每当关卡设计调整方向之时，视效和音效的工作时间线就会后移。而等到关卡设计师的版本稳定后，视效几乎没有足够时间来完成自己的工作，也没有时间打磨和稳定版本。

有些团队的结构截然不同，很难同步迭代版本。他们一次只能满足一种功能需求，很晚才会交付给关卡设计师。游戏系统是受用户研究影响最大的部门，这就意味着在关卡设计工作转向稳定后的很长一段时间里，仍会出现新功能，或是需要调整旧功能。将这些功能集成到游戏中是个复杂且高风险的过程，会影响地图的稳定性，甚至导致功能运作错误。需要明确的一点是，许多功能都是关卡设计师提出的需求，但问题是这些新功能可能会影响到整个游戏，并不是每张地图都能很好地兼容它们。

这类问题必须具体情况具体分析，我也没有万全之策。但在减少负面影响上有两大原则：一是去孤岛化，二是为团队赋能。孤岛是团队仅在内部共享信息，不与其他团队同步信息的情况。应该给关卡美术与关卡设计师相同的反馈，让他们作为一个整体工作，共同迭代版本。初级美术也可以对反馈做出反应，而不是在关卡迭代了好几周后才得到任务。保持这种规模的团队之间的同步需要大量协调工作，每个项目监制都会说，因沟通不畅浪费工时的情况仍时有出现，但从工作成果来看，整个团队合作迭代是值得的。

关卡设计团队可以用白盒为地图填充音效和视效，这能让关卡设计师更具体地验证想法。如有必要，可以在关卡设计师团队反馈的相应调整阶段，为他们制作更多临时资产。但需要谨记一点，占位用的资产是不能对外的，否则在视效和音效设计师于地图上直接工作时，很可能会将其作为正式资产提交。这些填充了临时资产的地图能极大减少团队工作量，使他们对体量和工作种类有更清晰的了解。

开发初期的启动会议，会让团队中的每个人都了解项目情况。技术关卡设计师及关卡设计师团队的关键成员可以尽早参与其中，以消除团队信息孤岛。他们会与地图负责人合作，为新功能做好准备。理想状态下，一旦功能实现达到预期，关卡设计团队就可以准备好他们的地图。当然，你无法预见一切，许多功能完成得很晚，你只能尽你所能。

重点是，对整个团队最有效的工具，也是我的秘密武器，就是去孤岛化，以及为敏捷开发团队赋能。

我已经将所有关键职能部门一一列出。最近，我正带领着一支刚刚组建的敏捷开发团队，团队必须时刻保持轻便灵活的状态应对工作，如果整个工作室都处于敏捷状态，那就不叫敏捷开发了。团队成员有自主权——虽然领导和总监们也在其中，但队伍成员具有决定权。如果每个计划都需要先验证，你就需要数名领导确认其所有内容，团队就不再敏捷。这涉及到项目监制的自主放权，而团队的权力越大，责任也就越大。你的一切决策都会影响其他团队。

没有一劳永逸的解决方案，关键在于沟通。没有哪些团队的合作关系是完全相同的，每个人都面对着不同的挑战。如果想要消除工作上的孤岛，可以放权给其他团队，让他们能尽可能快地接收信息，优化工作状态，从而更快展开工作流程。要相信敏捷开发的力量，但谨记，敏捷开发必须精简且独立。

挑战七：标记的沉没成本

我们需要手动标记重点，这在每个项目实例，乃至整个行业中都很常见，许多开发团队都要面对这样的问题。Arkane 致力于减少标记数量，但想实现这一点极为复杂。因为在某些案例中，标记本身就是设计工作的一部分，例如，在某种情况下，你将某一区域定义为特定类型的敌人无法出现的区域，这样他们就无法横跨整张地图追逐玩家。而在另一种情况下，你只是决定了游戏中存在什么，而后用某种方式演绎数据，像是将某处标记为“桌子下方”，这样敌人就可以喊出“她在桌子下面”这样的台词了。

标记或缺失标记会对关卡设计产生怎样的影响？《耻辱》中有“闪烁瞬移”（Blink）的设定，这是一种短距离传送能力，基本不需要任何标记。我们偶尔会手动调整碰撞，让“闪烁瞬移”能在关键路径上流畅运行；但在大多数情况下，它无需标记就能运转得很好，这时，关卡设计师就可以专注于设计工作了。而在《界外魔之死》中，有“易位”（Displace）的设计，主角能够放置自己的替身，可以视为平行现实中的自我，并能在替身与本体之间随意切换，这涉及到了一名 NPC，因而十分复杂。我们必须将导航网格（NavMesh）放在玩家可能到达的任何地方，这代表着小程度的标记成本，但并不是设计工作，只是在合适的地方添加数据。

哪一类内容会产生大量标记工作，同时兼具现有数据演绎和设计工作两者的属性呢？例如，敌人不会自己战斗，需要有数据告诉他们应该去哪里、做什么。或者，你可以构建工具，让关卡设计师手动放置每一个掩体点，彻底掌控每一场战斗，但这会相当耗时，并会使未来的关卡布局调整变得十分困难。相比之下，使用 AI 规则或是程序性地生成掩体点有利有弊，缺点在于会极端依赖指标，但如果我们将遵循额外指标的时间视为标记耗时，仍然比全手工放置要节省时间，所以，优点就是它使迭代成为可能。

这有一个完美的个人案例：我是《耻辱 2》中机关宅邸任务的关卡设计师，如果玩家拉动拉杆，宅邸就会以各种各样的方式变形。这是我设计这一关卡的耗时统计——其实并非如此，但我想这会是外部观察者的看法。

下图更接近我设计宅邸机关时的实际耗时情况。宅邸机关和基础关卡设计大约花费了研发总时长（三年）中的一半，敌人金朵希（Jindosh）有根据你的行为做出反应的画外音，为他的台词设计特殊逻辑耗费了大量时间。尽管静态导航网格是由程序生成的，为所有能够变形的房间调整导航网格仍是一项艰巨的任务。要使音频能够正常传播，可能要耗费同设置机关变换一样久的时间，这绝对是标记成本，我当时使用的开发工具也并不便捷。情况有可能改变吗？当然。但在那时，这是我的唯一选择，于是我就硬着头皮上了。

我想解释一下沉没成本的含义，它通常来说指你无法收回的时间和金钱。如果团队必须转型，那么标记时间就会全部丢失，变成纯粹的浪费，因为很可能一无所得。这不像削减功能或是放弃创意，这些东西之后是可以捡回来的，你总能学到东西。但标记不同，浪费就是浪费。从更人性化的角度来说，标记过程可能持续数月，开发工具设计师的工作成果不理想，加上漫长的工作周期，可能会对团队的士气和心理健康造成不良影响。我在一生中的不同阶段都遇到过这种情况，花了数年才恢复。如果关卡设计师的标记工具特别不符合人体工学，可能会导致肌腱炎等疲劳性损伤，我左手的肌腱炎就是类似原因诱发的。RSI（重复性劳损，Repetitive Strain Injury）可能带来长期影响，会损害团队的心理健康，削弱士气。

为此，我会提供两种解决方案，和具体选择哪一种的决策过程。第一种是优先考虑工具的人体工学，优先指的是一种基于未来的长远目光，而不是等到某个时刻才开始设计；第二种是程序性功能（Procedural Feature），即几乎不需要标记的功能。

决策过程可见下图，首先你需要问自己，这张地图以后是否可能需要关卡设计师的调整？我们会选“是”，因为这就是本次演讲的重点。其次，从概念上讲，能否将其设计为程序性功能，即无需标记的地图？让我们保守地选择“否”：这一类型的功能需要设计来实现。第三，是否已有符合人体工学的开发工具可供使用？最好的情况下，答案为“是”，那就使用工具，并尽可能改进。但如果你没有这样的工具呢？你应该在听取关卡设计师的意见开发新功能的同时，优化自己的开发工具。

如果无需标记，有两件事你需要确定。在大多数情况下，未来编程、维护功能代码的时间会远少于关卡设计时间，难点在于，你的团队中有人能编写这类代码吗？这会比编写标记工具复杂得多，你可能在上面耗费数周时间但一无所获。如果答案是“没有”，那我们就回到开发工具的问题；但如果答案是“有”，创建一个能实现程序性功能需求，能覆盖整个游戏的系统，问题就解决了。但你仍需关卡设计师在最初就参与进来，因为这会与指标相关。

无论结果如何，都是为了按照原定设计将功能融入游戏之中，你必须保证其可迭代性和灵活性，避免团队在延续数月的重复任务中疲惫不堪，难以转变研发方向。你需要符合人体工学的开发工具，来保护关卡设计师的身心健康。

挑战八：游戏开发中的巨量信息

针对开发中的巨量信息，解决方式就是建立文档，不幸的是，这同样也是挑战。我们能在此基础上做得更好，但需要留意一些细节。

关卡设计中蕴含着庞大的信息量。起初，游戏的设计概念就来源于创意指导、叙事或是两者兼具。首席关卡设计师和战斗设计师会列出一份清单草案，上面是他们与首席关卡美术和叙事团队共同制定的战斗综述；技术关卡设计师团队会与工具开发者们一同初步设计关卡工具和工作流程规范；系统设计师则开始撰写功能细节指标；关卡和场景美术团队也会开始提供他们将要使用的所有事物的尺寸、形状指标。在此基础上，关卡设计师需要记录头脑风暴和关卡原型，并在设计地图时，写下所有地图、任务和游戏片段的设计细节。

而后，项目开发周期的不同阶段需要不同类型的文档。在头脑风暴阶段，文档可以是松散凌乱的，它们是设计者的笔记本，也是一座档案馆，这里的任何东西都不该被丢弃，温故而知新或是复用老创意是一个好方法。开发文档是一座巨大的文档库，其中事无巨细地包含着游戏的每个主题细节。曾经有人将其描述为“真相的唯一来源”，因此必须谨防其中信息冗余或是信息过时。删减内容需要附上明确标记或是直接删除；过期的规格文档必须及时更新或是直接删除。而交付阶段的文档则是不同类型的怪物，这些文档通常不由开发人员直接负责，但在撰写阶段需要开发人员的协助。它必须精简而全面，能够囊括 QA、项目监制及外部人员需要的全部内容。除此之外，关卡设计师需要定期检查维护他们的文档。

那么，我们该怎么办？我们将文档视为游戏开发的一部分，撰写维护文档是与其他任务同样重要的任务。我指的是整个开发团队，而不仅仅是关卡设计师团队。关卡设计师团队需要最新的指标文档，太多过期信息是一种隐患。

文档工作不应被视为有时间才会做的额外工作，这同样是有完整流程和审核步骤的工作，就像其他任务一样。如果你将文档的更新视为你庞大工作中的小小尾注，那么，你很容易就会因为相信自己会在之后完成文档，而提前把整个任务标记为“已完成”状态。

另一方面，如果你完成了工作，却没有及时更新文档，该任务则仍被标记为“进行中”状态，会让团队领导和项目监制无法准确掌握关键节点的实现情况。如果文档工作本身成为一项任务，那么我们就可以缓解这些问题。我们会为此分配时间，大家能清楚地知道什么事做了，什么事没做。处于下游、受你的工作内容制约的团队成员会很高兴看到你完成了工作；你的领导和 QA 负责人也会乐见于此。

作为一个总会花费大量时间甚至一整天来编写文档的人，我想提一些小建议。第一，文档必须明确负责人。不存在包罗万象的文档，对文档有疑问的人应该知道去问谁。第二，即使文档有专人维护，你也必须审查文档并指出其中的错误。我在战斗设计上经验丰富、认识清晰，但能让关卡设计师介入其中，查看设计细节，指出我的错误仍旧很有助益。第三，冗余会导致误导性文档的出现，你需要的是能同时存在于多个页面且只需一次更新，即可全部同步的数据库。第四，旧数据最好保留，但要将其归档。当你在搜索某项内容，却发现大半结果来自删减功能时，只会相当痛苦。第五，要知道该在何时将某些类型的信息归于单个文档之中。要搜索 50 个功能页才能找到所需的指标，实在让人头疼不已。还有最关键的一点，你想让 bug 易于处理吗？要想让 bug 处理变得精准且彻底，就需要好的文档环境作为支撑，否则测试团队很难完成这样的任务。

灵活的指标能将你从决定论和固化的游戏设计中解放出来，在团队的密切合作和反馈中释放更多可能。主要合作伙伴之间必须相互赋能，灵活调整方向，而不是各自为政。在可能的情况下，工具的开发可以集中于程序性的解决方案；若否，则可以在开发工具的同时，让它更符合人体工学。文档应被视为游戏开发中的一项正式任务，而不是现有任务中的附属物，它需要得到与游戏设计本身同等程度的产出指导。

结语

总之，这就是我所说的八项挑战、九种方案。我想你已经注意到了，这由大量艰巨任务组成，几乎与团队的每一个人息息相关。我甚至还没有谈及有关招聘、营销和用户研究的内容，这些都依赖于项目监制和构建管理，也没有提及 QA。但我认为这不失为一个好的起点，可以就此开启你的团队讨论：整个工作室要如何共同努力，创造出优秀的关卡设计。

原链接：https://www.youtube.com/watch?v=UrdZhnA-PaI&list=PL2e4mYbwSTbao5I-cAVbanrMNVGgGN7O3&index=63

* 本内容系编译整理，不代表 indienova 立场。未经授权允许，请勿转载。