在解锁全部功能模块、深度体验目前开放的所有系统之后，终于有机会相对系统地梳理终末地当前的一些游戏体验问题。下面的内容也会更多从一名游戏设计师的专业视角出发，聚焦手柄交互这一核心体验进行分析，也欢迎一起讨论。

首先是概念问题，相比键鼠操作，手柄输入有天生的约束，具体就体现在

所以在游戏决定支持手柄端的那一刻起，也就是在游戏交互预研确定交互框架的阶段，第一步就必须在有限按键上提前做语义分配，并在全局系统均要求遵循此要求。

作为设计师，对可用性启发一定不陌生，其中一致性和标准化的要求，对于键位设计来说，就是优先级最高的原则，规则不一致就等于增加额外的玩家负担。

每个物理按键都承载了稳定的语义表达，在所有游戏场景中要么保持不变，要么遵循可预测的、明确声明过的上下文切换规则，即同一语义在不同上下文的自然表达。

在实际的研发过程中，通常都会有一份文档化的全局映射表，后续所有功能的按键分配都遵循统一的优先级规则，而不能就近随意分配和逐案特殊处理。

以大家约定俗成的系统级别的A和B的语义分层为例：

A代表正向动作，是当前最自然该做的事情；B代表取消返回等全局行为，这也是目前主流游戏和玩家都默认习惯的交互语义。

如果从一些成功落地的项目中总结，键位设计中通常需要遵循的原则包括但不限于以下：

操作频率越高的功能，优先分配到物理位置越容易持续触达的按键上；在激烈操作中需要执行的动作，尽量不要分配到需要手指大幅位移的按键上；以切换角色为例，放在十字键中的操作舒适度其实不如修饰键+可触达面板键（比如LT+A/X/Y/B）来的好；低频操作不应该占用高价值键位。

在内容体量很大的游戏中，也一定会存在标准按键不够用的情况，这个时候都会倾向于引入修饰键（Modifier）的形式来拓展输入空间；即"按住LT键的同时按A键"类似这种组合操作。但在修饰键展开的子按键分配中，依旧需要和基础的语义保持关联，关联可以是含义对应，也可以是布局对应。

很可惜，这种组合键之间可推导的逻辑在终末地一系列复杂的键位交互中其实并没有看到。

LB+其他按键，RB+其他按键，LT+其他按键，RT+其他按键，十字按键+其他面板键，再加上长按操作，这几套操作背后的底层组合逻辑是什么，哪一套才代表着是进入子级相关操作，哪一套代表着父子层级切换。

没有规则约束，玩家就只能通过键位提示单独记忆，每一步都需要注意看UI提示，手柄端的体验也会大打折扣。

标准并不代表着死板，游戏中存在大量不同的操作上下文情境，世界探索、战斗、菜单、养成、基建、对话、小游戏等等，按键功能在不同上下文中是会变化的，但这种变化需要借助硬性标准使其变得有规律可循。

整体规则如果抽象成最简单的三条：像确认、返回这样的全局语义定义在所有上下文中不能更改；按键语义在具体场景中可以特化，但不可以是矛盾的；新系统中的按键映射必须让玩家从基础语义层和已有的操作经验就可以基本猜到（至少80%的键位映射）。

手柄-键鼠之间支持无缝热切换，其实对于现代三端互通的游戏，这已经是最基本的要求，尤其是对于终末地这样有着复杂系统的游戏而言。

探索/战斗用手柄以沉浸体验世界观为主，而工业基建这样重多层级和精准交互的场景，即使手柄端再如何优化，都达不到PC键鼠的操作效率（当然PC端快捷键设计也是可单开的另一个话题了后续聊），所以无缝热切换对于这类多场景切换的游戏应该是优先级很高的功能。

所以其实设计之初就要以三端游戏交互的一致性进行规划，同时对手柄端的交互做一些特殊处理，也不是简单做键位映射即可。

能看出来终末地很多系统中的手柄端键位安排，很明显就是 冲突后被迫驱动的逐案特殊处理的设计模式，举两个例子。

第一个例子，先按照默认习惯预设了A=确认的系统语义。在工业基建模式下，因为在正常视角下3C键位中A=跳跃，B=跳跃的占位冲突，所以选择设备和确认放置均改成了X，取消操作则由菜单键承载。而在俯瞰视角下，由于A/B键位均被释放出来，所以又遵循了A=选择/确认，B=取消的逻辑。在同场景下的两种关联模式，采用两种键位设计，对于玩家不能不说是增加了认知成本的。

而在滑索场景中，虽然A键已经被释放出来了，猜测出于PS5主机端游戏特有的体感交互设计，设计师动了小心思，确认前往的操作由LT+RT的复杂组合键位承载，模拟真实的精心调校的阻力反馈能够在手柄上体会到。

但由于其他更多手柄如Xbox没有自适应扳机机制，这种为了一个平台的触觉体验而牺牲了操作简洁性的设计，其合理性是存疑的，反而更多玩家其实承受了不直觉的操作成本。

作为对游戏整体体验负责的设计师，需要先确保所有平台上操作逻辑简洁统一，再在特定硬件上叠加手柄端特有的触觉增强层，而不是反过来让触觉体验倒逼底层操作架构做出调整。

当然如果后续整个游戏都期望在利用自适应扳机构建一套完整了触觉交互语言，LT+RT或许可以成为一个新标准，也就有了更大的设计上下文支撑。

第二个例子，切换探索和工业两种模式用十字右键连续单次点按承载，十字左键则给到了切换角色，当然这可以说因为HUD上键位实在不够用，所以一个功能仅能分配到一个键位，但从玩家实际体验，选项左右布局下来回切换的自然认知就会和当前的按键配置产生冲突。

而工业模式下正常视角和俯瞰视角的切换用点按R3和长按B互相切换，R3在上一层级既要承载切换模式又要在下一层级承载旋转镜头的交互，如果不看键位提示，是很难精准交互的，大概率就会触发其他交功能产生挫败感。

这样例子能发现不少，但实话讲，每一处的特殊处理如果单拎出看其实都能看到有一些设计考虑，但缺少的就是再退后一步去重新审视全局键位的映射逻辑并从源头开始规避不合理键位的分配，玩家因此体验到的N套局部合理但全局不一致甚至矛盾的操作规则。

随着后续系统和内容量增加，玩家需要面对的就是若干个特例，无法推导，无法记忆，只能每次看着界面上的键位提示小心翼翼的操作，本应在游戏内容上的注意力被迫花在键位操作确认上，也就打断了主机端特意要营造的沉浸感。

而下面两个例子，明显就能看出终末地手柄端的设计是在PC端成型后“仓促”移植而来的。

一个成熟地图系统的手柄端光标设计，一定会做光标移动的加速度曲线调教，比如靠近目标中心点自动修正方向的吸附机制，比如经过和离开可交互点位提供必要摩擦力产生沾滞感，类似这样的细节是手柄端初期设计就需要考虑的，而不是目前简单的在UI表现层提供一个自由光标图标即可。

另一个则是最核心的角色养成系统，在定义UI布局和视觉样式的时候就完全是基于移动端和PC端点击逻辑，没有明确的菜单和操作优先级定义，等到了手柄端移植，只是简单粗暴的加了键位提示栏（这样的界面很多），全部依靠玩家自由走焦确认实现，或许是觉得实在太粗暴了，就额外增加了快捷导航功能。

对于主机游戏交互而言，体验良好的键位设计方案，UI提示仅作为兜底备用，玩家不需要额外花费注意力去关注它的存在，全局手柄方案应该走在前，而不是在后面追赶功能设计。

但体验不佳的键位设计方案，实际上玩家每时每刻都要与之搏斗，甚至拼尽全力最终也无法战胜，所谓的手柄端适配仅为了证明有三端发行的能力，至于玩家的实际交互体验，对不起，我们已经“尽力”了。

玩家可能无法清晰地表达"这个游戏的按键一致性有问题"，但他们的体感就会是"这个游戏操作起来就是不舒服很别扭”，这种模糊且持续的负面感受有时候就比明确的bug更加影响玩家体验。

既然要面向手柄端玩家，那么键位设计就应该是一套足够简洁、足够一致、足够尊重玩家既有认知和肌肉记忆的规则，只有在这种稳定的交互逻辑下，玩家才能把注意力真正放在塔卫二的开拓与探索上，而不是反复适应操作本身。