索尼圣莫尼卡高级技术策划：3A游戏《战神》的UI设计方法论

2023-06-17 16:06

「点击上方"GameLook"↑↑↑，订阅微信」

在一款游戏当中，UI是伴随玩家时间最久的一个视觉元素。优秀的UI设计可以让玩家持续沉浸在游戏体验中，糟糕的UI设计则很容易打破玩家的游戏体验，导致用户对一些功能完全不理解，甚至对整个游戏感到困惑。

那么，大作游戏室怎么设计UI的呢？在GDC2023演讲中，圣莫妮卡工作室高级技术策划Zach Bohn详细介绍了《战神：诸神黄昏（God of War Ragnark）》的UI研发，以及UI团队/个人在一个项目的作用。

他详细讲解了UI在游戏研发当中的作用，以及从事UI设计面临的挑战，并根据两款3A游戏的UI迭代过程，总结了圣莫妮卡工作室在UI设计方面的经验和心得。

以下是Gamelook听译的完整内容：

Zach Bohn：

今天分享的内容是“为3A续作打造UI”，这是我的第一次GDC演讲，所以感到有些不真实，因为就在十年前，我还是一个坐在台下听课的学生。我们接下来要讨论的事圣莫尼卡工作室团队是如何创作《战神：诸神黄昏》游戏UI的，这是2018年斩获无数业内大奖的3A游戏续作。

我们今天的目标是深度探讨我们处理这个超大型项目的计划和过程，具体而言是从UI角度来看待。

为此，我们会谈到三个话题：第一，我们圣莫妮卡工作室如何打造游戏UI？第二，我们会通过一些界面和屏幕空间来更好地了解打造UI需要什么；随后，我们会回顾2018年之后我们学到的一些心得。

不过在此之前，请允许我做一个自我介绍。我叫Zach Bohn，是工作室高级技术策划，负责打造和维护UI架构，包括部署你们在游戏里看到的几乎每一个UI元素。

在我的职业生涯中，我从事过很多不同的项目，刚开始是在独立团队，随后是中小型手游工作室。不过在过去7年里，我主要在这些大型开放世界3A项目担任UI策划，最开始是2018年的《（漫威）蜘蛛侠》UI策划，随后是《赛博朋克2077》，现在是《战神：诸神黄昏》。需要提前说明的是，为了提供更好的UI研发过程的例子，我可能会有些剧透。

圣莫妮卡工作室是怎么做UI的？

我们简单拆解一下圣莫妮卡工作室打造UI的过程，这里快速了解一下参与UI打造的团队，在游戏制作最高峰的时候，我们有11个人从事游戏UI的研发。对于不少人而言，这个数字可能显得有些荒谬，11个人只是做UI，听起来像是一个工作室内的微型工作室了。不过，这就是从事巨型项目研发的真相，实际上就是很多的团队一起工作和协同。

坦白说，我其实并不知道《诸神黄昏》整个项目研发团队有多少人，在疫情开始之前，我们有300人。不过，说回我们的团队，这里包括很多领域的人才，而且有新手和高级开发者。我就是图片里的TD，高级技术策划。

鉴于我的从业生涯经历，通常来说，打造UI只需要两个人。在我们的案例中，其实是部署端的TD支持与3D美术支持的结合，这些人创作了我们大部分的资源。考虑到项目规模之大，我们实际上需要冗余的人手，因为有太多的事情需要做。

我们的团队有几名2D美术师，他们的职责是概念美术，最后产出了大量的初始资源，随后转化到了3D工作流或3D环境中。我们有一个从顽皮狗工作室挖过来的UX策划，他们是游戏制作中期的时候加入，专门支持我们项目所有的可达性选择。

最后，我们还有一名玩法工程师，他负责游戏的UI脚本和其他的游戏逻辑。这个团队规模大致上适合《诸神黄昏》4年的研发，其实，我们本来还可以在项目结束的时候增加一个技术策划，因为事情实在是太多了。

这里快速说一下技术方面事情，我会简短介绍我们的引擎是如何工作的：简而言之，我们游戏里的所有东西都是预分配的，没有什么事运行时动态创作的，我们这么做主要是出于性能和稳定性的考量。因此，在我们的游戏里，一切都由waddef所有，你可以把它看做一个容器。

比如，一个关卡可以是个wad，游戏里有大量的关卡，但我们不会同时支持所有关卡，但我们有一些槽位用于一些关卡的一次性加载。如果一个关卡最后太大，比如我们的一些Crater这样的超大型XPL区域，它可以被分为两个或者更多的wad，以便正确加载。但有些内存是需要始终启用的，这些是永久性的wad，管理着进度与核心系统，UI就是其中之一。

因此，我们做的一切都需要很好地适应特定内存预算，如果UI出错，整个游戏就出错了。

在圣莫妮卡工作室，虽然几乎所有的资源都是2D，但我们通过Maya充分利用了3D工作流。在游戏里，它们全部绘制在与摄像机相关的屏幕位置。在此之前，我从事过的每一个UI管线都是2D的，因此这（对我来说）是全新而且奇怪的。

很自然地，在Maya里试图编写 UI是有一些比较大的困难，因为这个软件就不是为UI打造的，因此我们需要手动编写整个游戏里的每个布局。不过，我们的确利用了已经为游戏优化很好的材质和特效系统，这为我们很多的美术师释放了创意潜力。通常，尤其是2D工作流，你在打磨阶段会遇到限制，例如当你想要增加粒子或者支持具体混合模式的时候。

现在，我们可以使用和操作单个Maya组，通过圣莫妮卡工作室的一个工具将它们标记为游戏物体。在脚本端，我们有一个可以让我们在一个特定wad内全局搜索特定名字Maya物体的API。

我们的技术工作流完全通过Lua运行，这是一个圣莫妮卡工作室使用了很多年的typelist脚本系统。对于《诸神黄昏》有一个很重要的变化，其他很多部门都开始使用新的视觉脚本系统，不过，整个项目期间，摄像机和UI团队都在继续使用Lua。

接下来，我希望简单介绍一下3A游戏里的数据是如何管理的。对于很多同行来说，你或许比较熟悉Unity，通常都是将数据存储在检查器窗口（inspector window），直接与一个特定脚本连接，它们本质上是运行时关联脚本变量（runtime associated script variables）。

但在3A游戏领域，这些数据通常被作为静态数据存储，包括任务、装备、日志数据，它们在整个游戏中永远不会改变，始终是静态的。对于策划而言，它通常是用JSON编写的，或者其他简单的标记语言写入一个文本文件或者Excel文件。

最主要的区别是，在一个文本文件里，可能会有很多人在编辑，当所有人完成编辑之后，可能会比较杂乱。静态数据的另一个优势在于，很多情况下，它可以在游戏运行的时候随时做出改变，这可以让策划的迭代时间非常快。

静态数据由游戏引擎或者你运行的代码编译，这通常是用C++编写的，尤其是3A领域。不过，它需要游戏被重新编译，不利之处就是可能需要很长时间。

对于UI团队，我们主动在这一层之上工作，这给我们带来了灵活性，就像是在处理数据一样。UI逻辑要么是可以即时更新，要么就是通过重新运行游戏进行重新构建，然后，我们通过API从C++获得所有数据，它会给我们所有数据，也是我们所需要的，我会管理它在特定屏幕的视觉效果。

不过，在我们深入了解UI之前，我想要先往回一步做一个对比，《诸神黄昏》最后对于每个部门来说都成为了巨无霸项目，所有的一切都得到了拓展，以便让这个北欧神话拥有恰当的史诗感。在UI层面，就成为了地图、技能和HUD元素。

技术策划团队，也就是我和另一名同事，管理着相当于前作两倍大小的代码库，然而疯狂的事，我们的内存预算从未改变（58MB），我们必须在同样的空间里做所有事情，这真的是个很大的挑战。

但这同样也是巨大的成就，因为在过去的四年里，我们增加并打造了惊人的功能数量，接下来说说这些功能。

《战神：诸神黄昏》的UI设计

为此，我们主要覆盖三个不同的区域，我们会讨论很多关于实用功能方面的东西，说一点HUD相关的内容，然后详细说说菜单，这里我们会提到之前的游戏，以及一些经验。

实用功能

首先是实用功能，这里一部分是“开箱即用的体验（out of the box experience）”，简称OOBE，也就是玩家在看到任何logo、启动画面甚至字体之前就要体验的东西。2018年的《战神》有着非常简化的图像校准屏幕，但我们对OOBE的驱动因素其实是我们对可达性的专注。

我们希望优先在一开始就给人们选择，因此，为了打造这个菜单，我们从顽皮狗之前所做的几款游戏里汲取了很多灵感。不过，我们也做了一些小小的创新，这个登录页面就是很好的案例，因为如果他们想要跳过这里或者花点时间了解指引设置，我们希望为玩家提供一个非常快速的选择。

选择指引设置会带领玩家进入四个页面中的第一个，这只是我们的普通设定，所有标准选择都出现在这里，比如语言、字母和UI文字大小。这些实际上非常重要，它是包含在OOBE当中的，我们随后还会谈到。

但是，我们完全低估了可达性选项的技术权重，最终在几个方面受到了影响。右侧是所有UI所属的Lua文件视觉图，最大的是我们的设定菜单，我们的Lua逻辑接近8000行代码，只是对这些设定选项进行定义。

在理想情况下，Lua并不是存储这些信息的理想格式，而应该是与我之前提到类似的静态数据库。

我想要谈到的最后一个OOBE页面是可达性预设定，因为我们注意到顽皮狗遇到的一个OOBE挑战就是选择太多了，很快就会让玩家不知所措。

所以，为了让这个用户体验更流畅，我们创作者了这些预设定，让玩家们可以一次性改变很多个设定，它们包括视野、听觉、运动和动力。

我们的前段设定非常标准化，提供了所有的基础功能，新游戏、设定，就像2018年的《战神》那样，它和我们的引导过场动画存在于同一个屏幕空间，我个人比较喜欢这种前段设定，因为它可以直接给你一种无缝的游戏开始体验，而不是遇到一个很大的加载界面。对于很多玩家，尤其是剧情驱动的游戏而言，巨大的加载屏幕可能会毁掉游戏的初始体验。

不过，我们的方法有很多的额外开销。因为这是完整的场景，它需要关卡策划、需要照明、需要艺术方向，因此，核心创意团队需要很早就加入进来。所幸的是，我们知道自己要面临的是什么。

我们没有聊到的是回放视频带来的挑战，会放视频是对2018年《战神》游戏内事件的概览，我们的挑战最终就是引擎如何处理流媒体视频。因为，我们的引擎预分配一切，包括视频在内，而整体需要播放的视频是有限的，因此我们支持的最大视频分辨率只有1280×720，现在我们却要将这个巨大的视频投影到一面墙上，并且知道一些玩家会在4K电视机屏幕玩游戏。

比较疯狂的事情是，我们最终并没有改变任何东西。上面实际上是一个720p视频，只不过是平铺填满了整个屏幕，不过篝火的美术师量较低。

这里说一个心得，你需要做出取舍，这可能会导致我们改变流媒体视频预算，进而导致整个游戏的内存预算增加。不过，我们最终找到了一个创造性的解决方案，将劣势转化为了优势。

当你支持很广泛的设定选择时，我们有65至70个选项，这就会让分类变得困难。我们最后加入了一些比较微妙的分类，比如玩法，同时还增加了一些新的具体分类，例如文本和颜色、可达性以及音频提示等。

不过，我们最后在每个类别所包含的内容方面比较灵活。自动拾取在玩法类别，但它同时也出现在可达性类别，这样的设计是出于我们的一些观点，但也是通过大量玩法测试得到的经验。如果我们注意到玩家很难找到某一个设定，我们最后都会把它复制到其他类别里。

有了这么多的设定，一些由玩家控制，一些通过预设定控制，我们需要找到一个知道默认设定数值变化的方法，这时候就需要用到蓝色文字。这可以提示玩家他们是否改变了设定，还是预设值改变了设定，这样做起来成本很低，并且可以立即带来大量的结果。

我们最后为《诸神黄昏》支持的最大的一个可达性选项，就是完整的手柄自定义，我没办法低估它的影响力有多大，因为它影响了游戏的主要玩法。知道这个时候，策划对于整个游戏里的每个动作都有硬编码的特定按钮，所以这是牵一发而动全身的。现在，设置可以互动之后，他们根据上下文环境对动作进行具体设计，某个按钮可以是瞄准、可以是互动，也可以是躲避。

所以，如果你寻求加入可达性和背后社区的支持，完整的手柄自定义是用户要求最多的功能。

并非每个团队都有3A优势来支持数十项可达性选择，不过，我们也发现独立游戏采用了很多不错的方法，比如《蔚蓝》，它只给出了一些基础的玩法选择，但却给了玩家很多的选择可以让游戏玩起来更顺手。

还有，在《Overland》当中，你可以变换核心字体，选择读起来最通顺的那一个。

UI支持的实用功能当中，另一方面就是新手辅助（Tutorialization），我们在《诸神黄昏》支持70个不同的新手教学其中大部分看起来都是这样的：

它们只是利用了简单的侧边信息，以及在游戏内发生的事情。

不过，我们还支持游戏内15分钟的新手教程，主要是引导玩家学习装备、技能、变换速度等等。为了有效的辅助，我们做了很多，所以这里有一些建议。

第一，在一个非常连贯的空间里用连贯的视觉效果来展示新手教程，这样玩家们可以知道当他们想要建议的时候该看哪里。其次，每次只教一件事。从个人经验来说，将多个新手教程结合到游戏里，永远不会得到你想要的结果。

第三点可能只适用于续作，不过，稍微延迟一下新手教程的激活，以免玩家已经发现、或者他们从之前游戏里记住了怎么做。这是一个非常好的功能，它可以让体验更流畅，给玩家更多的沉浸感，而不用将玩家从游戏体验中拉到新手教程之中。

为了菜单新手教程的成功，我建议采用几个步骤。你要使用更多的视觉化，比如之前展示的弹跳的箭头，这可以帮助引导玩家该看屏幕的哪里。还需要设计新手教程的架构，以便它能够接管输入系统，确保只有特定动作被允许，以便让玩家进入这个过程的下一步。

不过，一定要保持游戏内菜单新手教程简洁，不要超过7步。因为在这之后，玩家们就会乱按，他们觉得新手教程应该结束，想要回到游戏中。

在这部分的总结，我希望总结一个在字体方面的小教训，因为我非常热爱这个领域，而工作室的其他都不在乎。如果你们对字体不了解，我可以介绍一下自己遵循的规则：只用两种字体，第一个是标头（header）字体，它将会是风格化的，代表了你的艺术方向，你用的次数相对较少。比如《诸神黄昏》，我们的标头字体是BERSERKER，这是我们内部创造的，捕捉到了北欧神话符文那样的感觉，而且只在两个地方使用，分别是游戏名以及切换区域的时候，这可以带来史诗感。

第二个字体是正文字体，这里希望同行们记住的事，正文字体应该是可读的，我们选择的事Gill Sans，是获得Adobe授权的字体，主要用于EFIGS，如果不熟悉本地化，他们分别代表的事英语、法语、意大利语、德语和西班牙语，这些帮你覆盖了大部分西方地区。

然而，还有很多市场通常需要特别的字体，因为EFIGS字体没有他们需要的符号，比如泰语、阿拉伯语、日语、韩语、中文，通常都需要完全独立的字体。幸运的事，Gill Sans已经支持了西里尔字母（Cyrillic），所以我们不需要为俄语再专门选一个字体。

我们在《诸神黄昏》节约内存开销最大的一个方法，就是利用定制图标字体，用Font Forge这样的应用，我们将黑白图标加载到一个字体表格，然后在游戏里通过统一字符编码（Unicode）值召回它们，这给我们帮了大忙。我们可以利用单个字体将其烘焙成2048×2048的纹理，然后进一步压缩，而不是为200多个图标增加材质和纹理成本。

利用这样的字体另一个优势在于，我们最后为作家制作了宏，以便他们能够将内联的特定图标嵌入到文本字段中，在新手教程里，他们用宏来替代，这样玩家就可以在游戏里所有地方认识这些符号，这个方法很好用。

接下来，我快速说一下未来圣莫妮卡工作室将会如何处理字体，目前我们是扫描游戏里的所有文本，然后将每一个符号放入纹理表单。我们对于《战神》图标字体以及之前展示过的标头和正文字体都是这么做的，它们是1024×1024，我们的图标字体有更多内容，所以它的大小是两倍。

在我们的游戏里，每个语言都有各自的wad，每次你切换语言，我们都会重新加载同一个wad槽，每个大概有10MB大小。但即便是压缩之后，我们运行的时候仅支持三种字体都是接近内存上限，这在某种方面给我们带来了痛苦的局限。

所以，我们最初的计划是开始寻求一些GPU为基础的渲染器，比如Slug，所以我们直接插入OTF或.TTF文件，然后直接让符号在屏幕上渲染，这给我们带来了巨大的优势，可以支持各种各样的字体风格。所以你可以从正文字体可以得到足够的多样性，这从图形设计角度来说是很成功的，能够支持细、普通、粗体、加粗字体，是美术师们一直要求的功能。

不过，另外比较有趣的事，这也解锁了表情。目前，我们所有的图标都只是黑白色，但是，如果我们使用表情，则可以给所有这些图标增加颜色，这给我们的美术师带来了很大帮助。所以，我们非常兴奋。

HUD

在圣莫妮卡工作室，故事是第一位的，而且有清晰的电影制作方向驱动着我们所做的一切。从UI角度来说，我们始终在寻求最小化屏幕上的呈现，以增强这种感觉；但在UX方面，我们还需要支持大量需要传递给玩家们的信息。

与UI其他部分相比，HUD在视觉上的变化与上一款游戏差别并不大。然而，我们改变了管理屏幕上通知的系统，最值得注意的是，我们将所有东西都放在了单一的全局序列，任何时候，屏幕上都只能出现一种类型的通知。

但问题是，我们在研发过程中得到的反馈是，玩家有时候等待这些信息的消耗的时间太久，因为都在一个巨大的序列中。如果你玩过游戏，我很确定你遇到过这个场景：

未来，我们会调整系统让他更区域化，我们在左上方有一个序列、右上方有一个序列，然后，如果有一个时刻UI信息非常重要，我们可以将它们连接起来，比如区域公告，或者让他同时存在，以便让玩家得到所有不同的信息。

所以，我们对《诸神黄昏》最主要的顾虑，实际是来自于支持新的定制化UI，这些UI都有具体的玩法用途。Muspelheim挑战、The Raven Arena以及Mystic Gateway都是非常好的案例。

因为，对于《诸神黄昏》我们知道一个关键功能，就是玩家需要能够在九大领域之间以及领域内的领域之间自由旅行。我们的目标是尽可能做到既直观又节约时间，这实际上意味着与前作相差很大的事情。

为了便于理解，这是领域履行在《战神》之中的功能展示，奎爷必须旅行到一个特定地点，提尔的神殿（Tyr’s Temple）并且和物理元素互动来改变所有不同的领域，这可以给人带来史诗般的体验，而且让整个过程更有意义。不过，从UX角度来说，这也是有局限的，玩家们只能从一个点进入一个领域，这让回溯和重新访问一些区域显得时间很紧张。

所以，在《诸神黄昏》中，所有的逻辑直接被移动到了大门上，这个UI是Lua逻辑与一些视觉脚本的混合，因为有很多动画在同时支持这个界面，它是屏幕空间UI与叙事元素的独特混合。领域图标，它们的锁定和解锁状态都是直接打造到出入口之中的。

但是，在游戏研发中途的时候，很明显玩家们在达到神秘大门之后失去了里程碑进度，这是很糟糕的。玩家们为何在这里投入那么多时间？在玩法测试期间捕捉的视频当中，我们发现玩家们跳出暂停菜单，试图弄清楚他们应该去哪里。

因此，为解决这个问题，我们直接引入了玩家寻找的信息，只是增加了两个元素。第一个是如果有一个任务在特定领域出现，那么任务图标直接出现在门上；其次，我们还对所有可接的任务保留了日志，让玩家随时可以看到每个领域都提供了什么。我们立即看到了玩家参与度和游戏内探索方面的变化，在游戏里奎爷鼓励玩家们去探索，而这样的设计可以直接支持玩家们那么做。

玩法测试和录制一些玩家游戏视频是非常有价值的，因为他们可能不会告诉你他们需要帮助，而是可能默默的忍受，我们也是观看了玩法测试视频之后才发现这个问题。玩家们任何时候打开暂停菜单，他们都会从游戏故事里出来，这种情况下，我们给玩家提供了正确的信息，以保持他们留在故事流之中，对于剧情向游戏来说，这一点很重要。

另一个定制化UI任务案例，你也会在很多不同类型的游戏里看到，主要是已知系统的变体，对我们来说，这就是boss血条。很早的时候，我们与战斗（设计）团队讨论boss，比如它们的血条需要什么样的支持，我们知道这是很好的，因为奎爷每次只打一个boss。

不过，还有一个独特的情况，也就是他与两个Valkyries战斗的时候，这之所以特别，是因为两个Valkyries使用同一个血条，所以我们最后只做了一个自包含元素，然后就结束了。问题是，几个月后，战斗团队回来找我们，说我们遇到了这样的情况，奎爷要和两条水龙战斗，你们能否（做个）支持？

当然，我们当然可以做，但实际上，对于超过两个boss的战斗，我们并没有很好的解决方案，因为屏幕空间就那么多。团队说这个设计不错，然后又离开了。

在游戏研发的最后五个月，战斗团队再次找到了我们，说遇到了一个与三个boss战斗的场景，问我们能否支持。我们当然可以支持，但却只有两个血条的空间，所以我们最后循环了Valkyrie的血条，以实现这种极具挑战的boss战斗。这可能是个好事，因为同时打三个这样的boss是不可思议的。

因此，在打造UI的时候，你需要处理灵活性和缩放性，你永远不知道何时需要在设计上进行预料不到的拓展，但你还需要知道一些限制。战斗团队完全理解屏幕空间的局限，你能展示的资源就那么多，最终，这会成为更好的设计。

菜单设计以及2018年以来的设计心得

在开始说暂停菜单之前，我们来看看2018年的《战神》团队是怎样的。众所周知，当时的战神研发团队是遇到了困难的，如果想了解更多情况，实际上还有一个专门的纪录片。但是，在UI方面，主要有两个核心问题，除了打造一款具有延展进度和菜单结构的深度RPG，UI团队当时拥有的资源是很有限的。

结果，整个游戏发布时的UI，其实是在六个月内完成的，这是不错的成就，但实际上是有代价的。因为当你的速度太快了之后，就会错过一些东西，所以，在2018年的《战神》在全球范围内受到欢迎，但UI方面却拖了后腿。所以，我们并不害怕坐下来探讨那些做的对，哪些是行不通的。

所以在《诸神黄昏》开始的时候，我们从UI角度有四个目标。我们希望让暂停菜单的角色拥有更大的视觉影响力，我们希望确保字体始终是可读的，我们希望尽可能的优化屏幕空间，我们希望UI很容易操作。

回顾奎爷和菜单，他在和UI争抢空间，而不是两者和谐共存。从顶部的标签到左右侧的信息卡，他只有很窄的存在空间，而且经常被UI元素遮挡。

为了让奎爷有更多空间，我们需要将他放到屏幕右边，这可以让我们更好的分开UI与角色模型。这个改变带来了一些的更新，标签按钮被移到了底部，属性面板被折叠并放到了对面。

我们右下角的菜单泵如今与动作对应，并且调整对应位置，这可以让我们对菜单进行缩放，看角色的近远景视角，并确保奎爷永远不会被UI所遮挡。

上一个项目的UI最大的一个弱点，就是文字从远距离看是看不清的，虽然发布之后进行了更新，并且有了一定的改善，但作用只能说是聊胜于无，这个类型的UI根本不支持这种类型的内容。因此，在新项目的时候，我们决定不再让这种事情发生，特别是小字，最让玩家感到痛苦。

很早的时候，我们就决定让菜单正文的字体永远不能小于24点，实际上，我们会提供更广泛的文字缩放选择。所以，不管玩家坐的离屏幕有多远，或者他们是否有视觉障碍，我们希望所有人都能读懂屏幕上的文字。

简单来说，这种文本缩放功能是非常成功的，一开始就改变字体大小的玩家比例让人觉得不可思议。到今天，我们发现60%的玩家都改变了游戏设定，这在以往是前所未见的。一旦你决定加入字体缩放功能，那就意味着你需要打造与之一起缩放的内容和技术，这通常被称之为动态布局，内容的位置会变化以适应其他内容。

屏幕中间的卡片就是很好的案例，它能够响应很多种情况，从属性、描述，到bink video以及lore entries。不管我们在这个卡片增加什么内容，我们都可以处理，这对于本地化是非常有帮助的，特定语言的情况下，一个简单的描述都有可能成为一大段文字。

作为对比，在2018年的《战神》中，所有的布局都是静态的，我们甚至没有改变或者优化可用的空间。中间的数据卡设计的时候是考虑最满的布局，这在游戏后期看起来很好，但在游戏开始的时候看起来有些令人尴尬。

最后，从纯粹的图形设计角度来说，操作起来有些不连贯。虽然完整屏幕是在同一个通用屏幕进行本地化，但根据菜单的不同，我们认为的按钮完全是不同的。有些按钮最终成为了武器菜单的图标，装备界面又换成了完全不同的图标，在附魔屏幕完全成为了一个列表。

到了技能树，又变成了一个个的节点。

所以，对于《诸神黄昏》，我们有一个非常连贯的侧边栏，它出现在所有地方，从武器和装备菜单，到技能树，一直到摊贩。

我们还做了视觉切换，我们深度探索的时候，菜单都会滑向右边，而上一级菜单始终在左侧。

菜单设计

我们今天的最后一部分内容，是《诸神黄昏》的菜单设计。但我们不会深度探讨每一个暂停菜单，而是讲述三个具体的案例：附魔、技能模组以及日志（Journal）。

我们的第一个案例，附魔界面是我认为最成功的UI设计之一。在2018年的《战神》当中，一个核心长线进度系统就是附魔系统，类似腰带或手环这样的装备有一定数量的附魔槽，附魔之后可以带来各种加成，从一些属性加成，到建造特点等，这些都可以通过有趣和独特的方式改变战斗。

直接在装备上设计附魔槽，可以让这个装备价值很高，但同时也带来了奇怪的UX问题：你无法同时看到玩家装备的所有附魔，而是需要对每一个装备逐个检查，让玩家很难有整体的了解。最终，这种设计导致与这个系统互动的玩家很少，尤其是深度方面的事情。

所以，战斗设计和UI团队想要为《诸神黄昏》解决这个特别的问题，因此我们创作了Amulet 树，这里可以同时看到玩家的9个附魔槽。不过在UI方面，这种设计遇到了一些挑战，我们的第一版做的和游戏里的其他装备屏幕相同，我们的目标是不论你在菜单的哪个位置，都可以有连贯性的操作。

因为每个附魔槽都是一个类型，然后展示每一个可能装备的道具，但这被证明是完全灾难性的。玩家和开发者都不喜欢这样的设计，因为就像2018年的《战神》那样，你完全丢失了已经附魔的所有进度。

因此，我们需要打破一些长期以来的传统。我们认为，用户体验比游戏幻想更重要，所以我们直接将UI放到了奎爷身上，而且研发了一个UI结构，匀速两个同时出现的列表，左侧是物品列表，右侧是槽位列表，这实际上也打破了我们之前的另一个传统。这种情况下，玩家们选择一个物品，然后选择一个镶嵌的槽位，这是具有突破性的，人们突然之间开始与之互动。

不过，这时候依然有些问题，所以下一个迭代是考虑上下文环境，我们直接让玩家可以在菜单列表上操作，让玩家可以返回之前的操作，也就是选择槽位然后再选择镶嵌物品。这可以让玩家可以快速改变镶嵌道具，根据自己的需要变化附魔属性，尤其是在游戏后期。

我们的游戏总监Eric Williams非常喜欢这个方案，以至于希望所有的配件也都这么设计。所以这个系统和界面被UI团队看做伟大的胜利，它融合了优秀的UI和UX设计。我们知道它很成功，因为没有人提到这个UI（的缺陷），相反，他们谈到的是自己的搭配以及附魔带来的可能性。

这里分享两个心得：如果核心系统是长线玩家参与的基础，那就需要持续迭代。不过，你需要在研发规划里投入时间，我们没有那么做，但后续投入了很多时间，到了最后完全是值得的。

不过，你还需要知道何时需要打破自己的规则。在我们的案例中，UX规则比我们的艺术核心更重要。

第二个案例是技能模组，以及2018年参与度较低的系统是如何被重做的。

在之前的游戏里，技能树里有一个系统叫做加成，它就在屏幕右下角，但可能很多人并不记得。从战斗角度来说，这个加成系统是非常有趣的，它为玩家打开了大量的可能性，这个系统的目标是持续保持战斗的新鲜感，哪怕是最后玩家已经解锁了大量的技能。但是，却没有人与这个系统互动，因为它和玩家们的优先级不匹配。

在这个菜单，我们已经训练了玩家数个小时，但只是展现了技能本身。不过，这些加成系统收到了属性的限制，这是完全在单独屏幕进行的，因此，这让我们投入了时间打造的系统完全是无用功。

到了《诸神黄昏》，我们希望另辟蹊径。同样，我们希望在游戏结束之前，一直保持战斗的新鲜感。不过，为了提高参与度，我们做了一件不同寻常的事情，我们完全隐藏了这个系统，在完成一系列任务之前，他们不会解锁与特定技能关联的技能模组，一旦完成任务之后，他们再次打开技能菜单，我们就通过新手教学的方式介绍这个系统。

我们并没有做一个只是被动激活的加成，现在这个系统需要玩家的主动参与，玩家们需要从一系列可能当中选择特定技能模组，这可以让玩家进行大量的尝试，但也给了我们工具，以限制玩家因为加成系统变得过度强大，我们看到了大量的玩家参与度和热情。

呈现很重要，尤其是需要主动参与的系统。不过，隐藏系统，尤其是面向高端玩家或者后期游戏的系统可以带来很大的帮助，因为这可以带来新鲜感。但是，别忘记辅助玩家学习，因为你要让玩家知道这是全新的，是他们之前没有见过的。

最后一个案例，我认为是我们没有能够合理交付的一个功能，也就是日志。

作为参照，这是2018年的《战神》截图，由于页面是扁平的，你看不出我们的技巧，其实所有的资源都是在书本之上渲染的。

这是《诸神黄昏》的日志，很多方面两者都是类似的，但这里的内容是直接在页面渲染的，你可以通过页面的一些特效和高光看到这一点。但我们觉得，这是3A游戏，我们希望更进一步，我们希望这些内容是立体呈现的，因此我们决定让这本书可以翻页，我们不知道迎接我们的将是什么。

一开始，事情是很直接的，你可以通过定制化渲染目标来实现翻页效果，这是很酷的设计。

当书本翻页的时候，就会有左右页，但当你翻回来的时候，同样需要处理接下来两页的内容。然而，由于每个类别的内容都有不同的标头，我们不得不对每个类别做单独的资源。让这个问题更复杂的是，我们决定允许不同标签之间翻页，这是个很糟糕的想法。

虽然玩家看起来效果类似，但它们背后使用了完全不同的脚本类别（scripting class），因此这导致游戏研发最后阶段出现了一些问题，因为测试者可以通过很多方式打破这种设计。修复问题用了很长时间，但直到现在，你还可以通过某种方式，让UI完全没有渲染。我可以向你们保证，大部分时候这个问题都是不会出现的，但不要操作太频繁。