用手柄玩战术卡牌游戏：Ancient Duel 的手柄支持是怎样实现的

手柄支持通常属于讲求移动和瞄准的游戏。Ancient Duel 两者皆无。它是一款卡牌游戏：你看着棋盘，思考片刻，然后做出一个离散的选择。

而这恰恰是手柄适合它的原因。对决中的每一个动作都归结为同一张短清单：哪张牌、哪个位置、哪个目标、确认、返回。这正是手柄的母语，而对一台专长在于指向任意像素的设备来说，这套词汇反倒不甚合用。

手柄不该假装自己是鼠标

最省事的捷径是让摇杆推着一个光标在屏幕上移动。这做起来快，用起来难受：你最终是在空荡荡的绒布桌面上驾驭一个指针，用模拟量的操作去完成一个数字化的选择。

Ancient Duel 移动的是选择本身。摇杆或方向键在真正有意义的东西之间跳转——手牌中的一张牌、场上的一个单位、一个目标、一个按钮、一个标签页——而“确认”则发动当前所选的任何东西。你从不瞄准。你只是在说“下一张牌”、“就这张”、“是”。

整个输入层遵循一条我早早定下、从未打破的规则：它绝不重新实现任何游戏动作。它只移动焦点，然后让原本就在那里的按钮各司其职。自四月的一轮无障碍工作以来，游戏早已可以完全用键盘操作，所以手柄支持根本不需要触碰游戏逻辑。反过来也成立：键盘到不了的地方，手柄同样到不了。要让某个东西可以被导航，就是把它做成一个焦点停靠点，而不是写新的输入代码。

棋盘本来就是一张网格

在这一点上，卡牌游戏有着 3D 世界所没有的便利。Ancient Duel 的战场是一个固定、有限的结构：每方四个单位位置、中间一个指挥官格、一排策略区、一手牌、两个墓地、一个地形区。没有任何需要穿越的连续空间。

于是视觉布局本身就可以直接成为导航。左右沿一行移动，上下在手牌与战场之间切换，而肩键则整区整区地跳转，不必逐个走过中间的一切。右摇杆负责滚动，Start 键打开手柄设置。

焦点就是光标

用鼠标时，玩家永远知道自己指着什么，因为指向的动作是他们的手在做。拿掉指针，界面就必须随时回答三个问题：现在选中的是什么，“确认”会对它做什么，“返回”又会撤销什么。

这听起来显而易见，而大部分琐碎的工作正花在这里。一个打开时选择落在关闭按钮上的对话框，技术上可以导航，实际上毫无用处：游戏刚问你要丢弃哪张牌，高亮却停在 ✕ 上。如今对话框打开时落在第一个真正的选项上；选择目标的模式则把选择直接放到第一个合法目标上，而不是仅仅把所有目标一并高亮——那在有指针时没问题，没有指针就成了大海捞针。

好的手柄支持，不是每个按钮都能够到的状态，而是你不再去想怎么够到它们的状态。

永远不要相信按钮索引

这是我严重低估了的部分。

一只 PC 手柄可以声称自己使用标准布局，然后按固件的心情随意编号它的按钮。我用来测试的那只手柄正是如此，更糟的是，它从顶部起顺时针印着 1 / 2 / 3 / 4，而不是 A/B/X/Y。于是每一次按键背后都藏着三个彼此独立的事实，而只有第一个真正可知：原始输入、那颗按钮在塑料外壳上的物理位置、以及旁边印着的标签。一个把“确认”绑到“0 号按钮”的游戏，是在对三者中的两个瞎猜。

因此 Ancient Duel 有一个校准向导，它从不根据索引推断任何东西。它从你的手上学到物理位置，从你告诉它设备上写着什么学到印刷标签。标签从列表中选取而非输入，因为手柄上没有字母——而且这些标签并非装饰：如果你告诉游戏你的下方按钮写着“B”、右方按钮写着“A”，那么不管浏览器怎么认为，你手里拿的就是任天堂惯例的硬件，“确认”与“返回”也会随之互换。

你跳过的控制会保持沉默。不存在退回到某个猜测索引的情况，因为一颗能确认投降的肩键，恰恰就是校准存在的意义所要防止的那种失误。

不能要求鼠标的校准

这里埋着一个悖论。手柄映射错误的玩家，正是最需要校准界面的玩家，也正是无法通过正常菜单导航到那里的玩家。

所以整个设计遵循的规则是：你必须能够在没有鼠标也没有键盘的情况下校准、标注、保存、重新打开并修复一只手柄。在桌面上，鼠标和键盘作为便利可以用；但任何环节都不得依赖它们。

实际上，这意味着向导以“按任意键开始”打开，接受任何已连接手柄上的任何原始按钮，而这一按同时决定了哪只手柄拥有这次会话。接下来是确认与取消，二者不可跳过。从第三个问题起，你刚刚指认为右方按钮的那颗键会带你后退一步，所以按它足够多次就能退出向导——这是唯一一条不需要指针的出路。每个采集步骤都自行推进，因为一个刚被告知“按下下方按钮”的玩家，不可能同时再去按“下一步”。

为什么它从不询问摇杆

八个问题，每一个都是按钮。方向相关的问题一个都没有。

部分原因是方向本就是可靠的那一部分：在标准映射的手柄上，左摇杆以前两个轴到达，这让方向输入远比厂商随意编号的按钮可预测。但主要原因，是我在看着它出错之后才明白的一件事。一颗按钮要么按下，要么没有。而一根轴没有有意义的“松开”状态——磨损的摇杆会漂移，方向键的 hat 值会停在 3.29，扳机会停在 −1——其中任何一个都可能回答一个没人问过的问题，或者出于屏幕上没有任何东西能解释的原因，拒绝让某一步完成。不问，就消灭了一整类无法解释的行为。

按住方向会重复触发，速度可以自己设定；如果摇杆漂移，死区同样可以调整。

没有字母也要打字

然后你碰到一个文本框，而手柄此时无能为力。登录、给牌组命名、搜索卡池：所有这些都需要字符，而没有任何手柄上有字符。

所以在文本框上按“确认”会在屏幕上打开一个完整的 QWERTY 键盘。它只是一个普通层里的一组普通按钮，这意味着同样的导航方式可以在上面移动，“返回”也像关闭其他任何东西一样把它关掉。有实体键盘的玩家永远不会看到它。

有一个我没料到会重要的细节：这套布局使用真实的物理错位，与 ANSI 键盘相同的四分之一单位偏移。导航读取渲染出来的几何来决定“上”去往哪里，所以正是这个错位把 W 放在了 A 和 S 之间的空隙上方。更整的数字反而会出错——恰好半个单位的错位会让每个键到下方两个键的距离完全相等，而平局就交给了标记语言恰好排成的顺序。

手柄在游戏其他地方发现了什么

这项工作最有用的一点是它暴露了什么。鼠标让玩家可以直接指向想要的东西，从而掩盖界面的问题。手柄做不到，所以界面必须把这些关系明确表达出来——而有好几个地方结果并没有做到。

已保存的牌组不是焦点停靠点，这意味着没有鼠标根本打不开牌组。墓地和地形也是一样。组牌界面每当你加入一张牌就重建它的两列，销毁你刚按下的按钮并丢掉你的位置；现在它会记住那张牌和那个操作，并重新找到它们。浏览器自带的 confirm 和 alert 对话框完全在应用的焦点模型之外，于是被替换成页面内的对话框，打开时落在安全的那个答案上。

这些都不是手柄的 bug。它们是界面的 bug，只是指针一直在悄悄地替它们补救；修好它们，让游戏对那些永远不会碰手柄的人也变得更好。

Steam、沙发与 Deck

同一套代码运行在浏览器里、在用于 Steam 的 Windows 版本里、也在 macOS 版本里，三者使用同一个手柄系统和同一套配置逻辑——不过设置本身保存在设备上，而不是你的账户里。

这换来的东西很简单：PC 不再只是一张书桌。同一个版本可以在笔记本上玩，在接电视的机器上玩，也可以坐在沙发上拿着手柄玩。卡牌游戏比大多数类型更适合这种方式，因为 Ancient Duel 的自然姿态是靠在椅背上思考，而不是前倾着点击。

对于 Steam Deck 这类掌机，诚实的说法是：地基已经打好，测试还没有做。Steam Input 可以通过标准的 XInput 兼容映射暴露手柄输入，所以已有的模型原则上是一个有用的基础，而一款从不假设鼠标存在的游戏，是这类设备的重要前提。我还没有在真机上验证过 Ancient Duel，所以不会宣称它在那上面能用。另外还有一个电视模式，会加上一圈安全边距，因为某些电视设置仍会应用过扫描、裁掉图像边缘的一部分，这足以把投降按钮挤出屏幕。

同样的推理适用于任何未来的平台。主机版本需要的远不止输入方面的工作：SDK、认证、平台服务、打包、商店审核。但有一道障碍可以提前清除，而且它正是触及每一个界面的那一道——游戏不应假设鼠标存在。这并不意味着任何东西已经为主机做好了准备。它只是让一扇日后重开代价高昂的门保持敞开。

鼠标并没有被赶走

这一切不取代任何东西。鼠标和键盘的用法与从前一模一样，在桌面上它们依然更快。重点从来不是替玩家挑选输入设备。

用手柄打的对决并不是另一场对决。选的是同一张牌，挑的是同一个目标，做出并承担的是同一个决定。改变的只是这个选择抵达游戏的方式——而 Ancient Duel 对你手里拿着什么的假设越少，同一场对决就能在越多的地方进行。

Daniel Rusu
Ancient Duel 创作者兼开发者