zoukankan      html  css  js  c++  java
  • 游戏输入控制的五条黄金法则

    游戏输入控制的五条黄金法则

    已征得原作者Zachary Burke同意。原文地址:Gamasutra: Zach Burke’s Blog

    背景

    想像一下一个场景——你兴冲冲的开车去购物,就当你到了地方准备开门下车的时候,忽然发现这辆车居然没有把手?!?这个时候卖汽车的的商人告诉你:“噢,对,在这辆车里面你必须要爬窗户才能出来!”

    正如有一个可以打开的车门之于汽车消费者是一个最基本的需求一样,对于玩家而言,他们对于游戏也有着一系列最基本的需求。如果这些基本需求都没有达到,那么在玩家看到你游戏中最酷炫的地方之前,他们很大几率就已经早早的退出了游戏。

    那么在这篇文章中,我会给你介绍一些关于如何让游戏完美支持手柄以及鼠标/键盘的通用的规则。

    在这篇文章中,我们会做三件事:首先,我们将大致了解如何去检测玩家正在使用的输入控制器;接着我们将了解5条如何使得输入体验更加完美的法则;最后我们将去看看一些3A级大作是如何处理输入的。

    这篇文章主要是对于单人的支持游戏手柄的PC游戏,所以对于那些基于分屏合作的(译者按:原文是couch co-op,大意就是大家坐在沙发上合作玩游戏,若有官方翻译,请指正) 游戏的开发者来说,这篇文章仅供参考。

    输入选择引擎

    我们先来陈述一下我们需要解决的问题——我们的目标是让游戏同时支持游戏手柄以及鼠标/键盘控制,换句话说,玩家可以使用任意的输入方式去玩游戏。这就意味着如果玩家需要从鼠标切换到手柄时,他们不需要进行太多操作(例如从沙发上起身去按某个按钮或者搜寻无数的菜单按钮)。

    为了实现这个目的,我们需要一个引擎(一段循环执行的代码)去告诉游戏系统玩家想要用哪一种输入设备。整个引擎的逻辑可以细分为以下两个问题:

    1. 玩家想用手柄玩游戏吗?
    2. 玩家想用键盘鼠标玩游戏吗?

    玩家想用手柄吗?

    我们考虑如下这张图,代表着当对应的手柄事件发生时玩家是否是真的想用手柄。
    1

    我们需要记住,很多的游戏玩家的手柄总是与PC相连的,因此手柄连接事件对于玩家是否想要使用游戏手柄并不是一个充分的条件。

    但是为什么摇杆的运动也只是玩家可能想要使用手柄的条件呢?这是因为玩家的手柄摇杆输入的值是一个浮点数——有时手柄摇杆可能会产生噪声信号。所以有一种做法是去定义一个摇杆噪音阈值,当摇杆的输入的绝对值小于这个阈值时,则忽略这个信号。

    相应的,如果手柄上的按键被按下,那么应该可以确定玩家是想使用手柄来进行游戏的,此时直接切换至手柄操作即可。

    玩家想用键鼠吗?

    2
    鼠标的移动与摇杆的移动其实是基于同样的原理。当玩家想使用鼠标的时候,通常会使用移动鼠标的事件来通知引擎。但是与此同时鼠标也有可能存在一些小震动的情况(例如忽然撞了一下桌子)可能会影响判断。有一种较为简单的做法是设定鼠标移动的阈值,如果鼠标的移动小于这个阈值,则被认为只是震动,反之则认为是玩家想使用鼠标操作了。

    与之相对的,如果鼠标按键或者键盘按键被按下,那么应该可以确定玩家是想使用键盘/鼠标进行游戏,此时直接切换至键鼠操作即可。

    引擎逻辑

    根据我们上面的图表,我们可以写出在手柄与键鼠输入逻辑之间的切换逻辑,它将在后台运行从而将自动转换到当前玩家想要的输入设备对应的输入逻辑。

    我称这个引擎为基于时间戳的输入引擎(Timestamp Input Engine)。主要的逻辑是我们储存两个时间戳去标明手柄和键鼠的最后一次接受对应输入事件的时间。每一次检测到一个合法的输入事件后,我们将更新对应的时间戳的值。需要注意的是,我们应当使用游戏真实时间(elapsed game time),而不是每一帧的delta-time或者其他可能被暂停或者被调整的时间。
    3
    我们现在已经拥有了上一次手柄/键鼠最新事件的时间戳,那么真正的输入检测就是很简单的判断哪一个时间戳更大而已。
    4

    五条法则

    现在我们的引擎的逻辑已经确定了,那么我们将要着眼于如何满足上面提到的五条黄金法则。我认为这些法则是让玩家获得单人游戏中极佳体验的关键。

    法则1 —— 匹配输入设备的图标

    无论输入设备在何时改变,所有的在屏幕上的图标都应该对应着输入设备而变化。下图是游戏几何战争(Geometry War 3)中,当你把手柄上的电池拆下来后,用红圈圈出来的这些图标将会发生变化:
    5

    6

    法则2 —— 匹配输入设备的指针

    毫无疑问,当玩家使用手柄玩游戏的时候,他们绝对不希望看到一个处于画面中的鼠标指针,这种感觉相信大家都有。相对的,如果他们正在使用鼠标进行操作那么他们很有可能希望看到鼠标指针。

    随着Steam机器的普及以及Steam大屏幕的普及,很多游戏玩家都是坐在沙发上的。千万不要让他们站起来,然后走到PC旁边去把鼠标拖到屏幕下方——这种行为会让玩家很不舒服。同时,当你隐藏掉鼠标指针的时候,不要仅仅只是把鼠标指针变得不可见了,同时你应该屏蔽掉鼠标在菜单中的选择以及悬浮事件。

    法则3 —— 任意设备都能满足任意操作

    在游戏中的任意时候,都需要确保玩家可以通过任意的输入设备来遍历所有的菜单以及控制游戏,而不是在某种情况下只能通过特定的输入设备来操作。(译者按:这句话简单来说就是要确保键鼠和手柄能够完成游戏的一切操作,正面例子很多,反面例子可以参考御天降魔传)。

    法则4 —— DPad,摇杆以及鼠标都可以遍历菜单

    玩家一定要能够通过DPad,摇杆以及鼠标来遍历所有的菜单。这不仅仅是一个好的用户体验,并且这也能够让你的游戏对于所有的游戏手柄都有良好的市场。

    法则5 —— 手柄断开时暂停游戏

    当玩家在使用手柄,并且手柄连接断开时,游戏应该进入暂停状态。可能唯一需要注意的地方就是当玩家正处于菜单状态下时,如果手柄连接断开,此时输入设备应该自动转化为键鼠。一定要确认暂停菜单也是遵循法则1-4的。

    光之子在这个方面做的相当到位:
    7

    游戏示例盘点

    现在我们来看看一些在我的Steam账户中支持手柄的游戏,然后看看他们是否符合这几条准则。

    8

    几何战争3

    GW3的主要问题在很多其他的游戏中也存在,它的输入检测引擎很像这样:

    9

    这样一来就导致了如果你连接了手柄但是没有使用它的话,图标和你的输入设备永远不会匹配。

    另一个有意思的设计是鼠标计时器——即使当前你正在使用键鼠操作,并且按住了你的鼠标按钮,但是只要指针没有进行移动,那么在5秒之后鼠标指针一定会消失。
    GW3的菜单系统很显然是专门为了手柄而设计的,并且它的确同时支持摇杆以及DPad的操作,但是它并不支持鼠标。

    GW3的确在手柄断开的时候会暂停游戏,即便你是在使用鼠标进行操作时。

    吃豆人锦标赛 DX+

    吃豆人与GW3在输入检测方面使用了相同的检测机制,所以除非你把手柄拔了,否则图标与输入设备也不会匹配。

    鼠标指针永远不会隐藏,即便是检测到手柄连接了。

    在这样一个对于操作比较精密的游戏来说,如果手柄连接断开的时候游戏不暂停对于玩家来说是很不友好的。

    古墓丽影

    古墓丽影的输入引擎对于鼠标的移动没有反应,只有当鼠标按钮被点击后才会有反应。

    当手柄的连接断开时,游戏不会暂停。

    光之子

    在游戏输入方面,各方面都做得很好!

    生化奇兵:无限

    在输入检测方面做的很好,这款游戏对于鼠标的移动也有反应。只是当手柄连接断开时游戏不会暂停,这是一点小瑕疵。

    总结

    这就是我所知道的全部了——基于时间戳的输入检测引擎的大致介绍以及5条对于输入的简单法则。我再强调一遍,这是针对于单人游戏,因此请记住如果你的游戏是基于分屏合作的话,你可能需要去打破一两条上述的法则。


    写在最后

    和Zach的交流非常愉快,他是一个很谦逊很乐于分享的大神(居然还主动问我需不需要提供Visio文件,好感动……)。对于我这样初出茅庐的新手来说,确实感到了境界上的差距。

    不过话说回来,相比起走马观花式的阅读,在翻译的过程中我倒是收获到了更多的东西,也有了更深的理解——有可能这就是泛读与精读的区别吧。

    道阻且长啊,以后也会更加努力!

  • 相关阅读:
    Android数据存储之SQLCipher数据库加密
    Android数据加密之Aes加密
    Android自定义控件之自定义组合控件
    Android自定义控件之自定义属性
    Android自定义控件之基本原理
    Java设计模式之代理模式(Proxy)
    Android注解使用之使用Support Annotations注解优化代码
    Java学习之注解Annotation实现原理
    Android数据存储之GreenDao 3.0 详解
    Android性能优化之App应用启动分析与优化
  • 原文地址:https://www.cnblogs.com/arrowinmyknee/p/5470393.html
Copyright © 2011-2022 走看看