这里不会说输入设备的处理细节, 只YY一下输入跨平台输入系统的设计方式. 先说下我们公司的方式, 有Controller接口, 主要针对console. Win32下,内部封装有mouse和keyboard, 但是对外不可见, 而是用mouse和keyboard"模拟"了controller接口.
对于跨平台的输入, 目前个人认为有两种方案, 一种就像公司中的方式一样, 使用统一的接口, 具体输入可以根据平台来实现. 这种方式比较容易维护, 但是问题在于, 不同平台的输入差距可能很大, 比如console通常用手柄,甚至是体感, 而PC通常是mouse和keyboard, 而移动端常常是touch screen. 这样以来, 抽象的难度很大. 统一接口时, 错综复杂过于臃肿, 而且特定的设备下的操作,即便有抽象, 实际上只针对某一个平台, 其他平台对某一个功能无法支持. 同时,如果又新的平台/输入设备出现, 那么有可能要扩展该接口,以支持该平台下的特殊操作.
比如手柄中的各类按键, 在touch上很难全部支持. 而touch screen上的某些操作, 实际上我们公司现有的controller也未必完全支持, 可能需要扩展. 而且game code里面有#ifdef来做跟设备相关的input handling, 比如根据平台引入的新的一些操作.
第二个方案, 就是单独抽象出所有的设备, 比如PC上有mouse和keyboard, console上有手柄, mobile上有touch, 如果有新型输入设备有加上新的设备抽象. 当然这种情况下, 并不是所有抽象都可用, 比如手机上无法访问mouse/keyboard. 所以所有这些接口不能直接被访问和使用. 否则依赖了特定平台的设备, 更换平台以后无法工作. 所以engine和gamecode都不能对输入设备有任何直接依赖. 那么如何处理输入呢?
使用action map. action是game/project related的定义,可以是一个事件或者一个状态, 比如"jump", 游戏种只需要判断"jump"这个事件是否触发就可以了.
也就使说, 游戏只依赖自己定义的一系列状态和事件, 这些状态和事件只跟游戏内容相关. input system使用action map, 将这些事件和状态map到对应的输入设备上去.
对于引擎而言, 不可能知道具体游戏的事件和状态. 所以, 使用配置文件是最好的方式.这样做的灵活性更高, 但是复杂的输入组合检测,和配置脚本的描述解析,可能会很复杂.
action map的配置文件包含了一些action定义, 这些定义跟game content相关. 还包含了action到input的映射. 不同的平台有不同的配置文件. 比如win32下, jump被映射到keyboard space, console下, jump映射到axis y+,而mobile上, jump被映射到 touch move y+.
Mouse Keyboard Touch GamePad
| | /
Input Action Map ------------------config file
| |
Game per-platform config
假设现在有一个新型的输入设备, 需要做的事情有:
1.对该设备的基本抽象和实现(code1).
2.在input system种添加对该输入处理的文字描述: input desc(code2)
3.在配置文件种添加映射: action desc => input desc.
其中code1可以由game engineer来完成, 作为game team针对引擎为游戏定制的中间件(或者引擎的支援人员为游戏做的中间件), 与引擎的核心解耦.
但是code2的代码(input system)位于engine中, 开发者要修改和维护engine的代码, 这可能是一个不良的设计.
如果在输入设备接口抽象里面, 添加了基于描述(文字)的事件回调/状态查询, 那么输入处理的文字描述被内置到输入设备内部, 由输入设备自己实现, 这样只需要做:
1.对该设备的基本抽象和实现(包含描述信息: input desc - 输入事件/状态到文字的映射 )(code1).
2.在配置文件种添加映射.
以上只是YY和设想, 或许会在Blade引擎里面验证一下, 实际情况可能要远比设想的复杂.