# 开发 VR 多人游戏的技术挑战

整理学习自 CSDN 博客 http://blog.csdn.net/xoyojank/article/details/54669020

目前绝大数的 VR 游戏, 其实就是美术做个场景, 程序实现一下交互, 然后就可以拿去上线了, 难怪 2016下 半年 VR 热度开始冷却, 因为忽悠太多了. 单人和多人 VR 游戏的技术含量完全不是一个量级的. 只有耐心把地基打好, 才能建造一座高楼. 下面是从他人博客里抽离出来的我认为很有说服力的阐述了我们开发者开发 VR 多人游戏会遇到的主要问题与挑战.

Avatar

做为一个多人游戏, Avatar 是必须的. 而很多单机的 VR 游戏只有两只手. 有些多人 VR 游戏就是只做了一个头加两只手的形象, 说是”可信度”>”真实度”. 虽然这个思想是没错, 但只有头跟手在表现力上也太搓了点. 这么做的原因是 VR 设备只提供了头显和两只控制器的 Transform, 所以没办法完美地模拟出身体其它骨骼的运动. 或许有人说可以像其它网游那样使用美术制作的动画, 但是那样的话, 就失去了”可信度”, 毕竟面对面交流的感觉, 是需要身体语言的, 而 VR 设备三个骨骼的 Transform 就可以表达出很多信息了.

所以, 要想让玩家的 Avatar 生动起来, 必须把他身体的动作同步到 Avatar 上面. 但是, 由于没有身体的其它骨骼关节的信息, 只能依靠 FullbodyIK 的技术进行模拟. 目前看来, 做得比较好的中间件有 FinalIK 和 IKinema. 头部的转动 IK 是最容易实现的, 类似传统游戏中的 AimIK/LookAt 等; 胳膊的 IK 稍困难, 需要避免与身体的穿插, 还要保证肘部关节和肩部关节的角度不会超出约束范围, 不然会看着像骨折了; 下半身的 IK 是最难的, 因为双腿需要跟着上半身做弯曲/下蹲/转身/迈步等, 跳跃和弯腰更是目前无法完美模拟的.

VR 游戏中的移动

说到 VR 游戏中的移动, 很多人已经有个共识就是会晕. 所以, 对于小范围的移动, 通常是使用 RoomScale 的空间走动; 对于大范围的, 目前通用方法是使用传送. 虽然也有驾驶类的, 但是与特定游戏玩法相关性比较大, 这里不做讨论. RoomScale 的移动对于单人来说, 很好处理, 但是反应到其它玩家的 Avatar 上就是一个问题了. 因为在逻辑上, 他们的 Transform 并没有变化, 只是头跟手的 Transform 发生了变化. 如果 Avatar 的设计有腿的话, 就需要腿跟随头部移动和转向, 这样出来的效果十分诡异, 因为正常人是下半身带动上半身移动/转向的, 而VR里是头和手带动上半身, 上半身再带动下半身, 出现的动作就会不协调. 2017 年应该会上市很多 HomeScale 的头显, 采用类似 Hololens 的 SLAM 定位技术, 这时候腿部表现就是不可避免的了.

手势

除了肢体语言, 手势也是一种极富表现力的交流手段. OculusTouch 的 Touch 特性用来模拟拇指/食指/中指的动作, 进行一下组合就能实现很多种常见的手势, 配合肢体语言, 可以极大地增强面对面交流时的真实感. 当然这个没什么技术含量, 会做动画状态机就能做, 难的是手拿物体的动作. 如果只有固定的几种东西, 那就可以针对每个物体做不同的手抓住的动画. 但是如果想用双只手交替拿物体的任意部位, 这种预置动画是满足不了需求的. VirtualGrasp 就做了这样的技术, 可以让手指在不同物体的不同部位, 都能让手指贴到物体表面上, 做到了比较自然的抓握动作.

多人之间沟通

多人交流, 那沟通是少不了, 但是 VR 游戏没人会用键盘去玩的, 所以语音聊天成了多人 VR 游戏必须做的一个基础功能. 不过 VR 中的语音聊天不仅仅是像 YY 那样开个房间就好, 而是需要把声音空间化, 做成 3D 音效, 这样才像是从玩家 Avatar 的嘴里发出来的声音, 2D 音效在 VR 里是相当违和的. 再进一步, 需要考虑声音的反射和遮挡, 这个目前还没有在实际产品中看到比较完美的技术方案, 大家最多只是做个混响效果. Oculus Audio SDK 中有 Sound Spatialization 的技术, NVIDIA 有 VRWorks Audio, AMD 也有 TrueAudio, 因为大家都意识到, 在 VR 中, 声音的重要性, 不亚于画面.

说话口型

说话时有了声音, 那 Avatar 的嘴要动吧? 这就是涉及到 LipSync 的技术了. LipSync 不是什么新技术了, 在 AAA 游戏中用得很多, 只不过大家用的都是离线生成的口型数据, 而 VR 语音聊天是需要实时生成的口型的. 如果只是单音节识别, 还算比较简单, Oculus 的 LipSync 就是这样, 效果一般. 再进一步就是需要考虑前后声音的相关性, 做出口型的连续变化, 而不是简单的插值. 这方面目前看着效果比较好的是 SpeechGraphics 做的中间件. 最难的是情绪识别, 因为嘴能动了, 脸还是僵硬的, 看着也是很假. 另外, 语音识别什么的, 也是有可以用的时候, 毕竟在 VR 里做交互和做文字输入什么的, 没有直接说话来得轻松.

脸部表情

上面说到了脸部的表现, 最最基本的, 需要做个表情吧? 简单的卡通风格用贴图画就可以, 偏写实的风格就需要用绑定大量脸部骨骼或者导出 MorphTarget 去表现表情的变化. 一旦使用了基于 Mesh 的表情制作方案, 动画美术就疯了, 绑定一张脸的 Rig 就累个半死. 不知道 DCC 工具中有没有比较快速绑定脸部骨骼或者生成 MorphTarget 的技术, 不然制作成本是个问题. 好了, 等美术做好了几个表情动画, 问题来了, 我怎么触发呢? 体感控制器上就那么几个按钮, 总不能都用来触发表情吧? 那就做个 UI? 等你选完早就不笑了. 用身体动作触发? 老是会误触发, 一会儿哭一会儿笑的, 跟精神病一样.

眼神的控制

有了口型变化, 有了表情变化, 为什么还有两只死鱼眼呢? 这时候又需要做眼神的控制了. 随机眨眼是比较简单的, 难的是视线方向的控制. 因为目前的量产头显都不带眼动追踪的功能(只听说 FOVE 有), 所以你没法知道对面玩家的眼睛到底在看哪里. 那只能做个策略来进行模拟, 比如根据声音, 根据运动物体的位置, 根据头部朝向的目标等, 怎么调出来让人觉得自然也是需要很多精力和时间反复调整的.

物理模拟的坑

嗯, 脸部表现丰富了, 肢体动作也有了, 其它方面也要跟上吧? 头转了, 头发是不是也要甩一甩? 身体动了, 衣服是不是也要飘一飘? 这又掉进物理模拟的坑里了, 大量 AAA 级游戏都有比较成熟的方案, 不再多说.

物理最麻烦的不是模拟, 而网络同步. 在任何一个使用双持体感控制器的 VR 游戏中, 都少不了各种带物理模拟属性的物件, 可以拿起来扔之类. 而到了多人 VR 游戏中, 这些物件的运动一样需要同步到其它客户端. 可能这一秒还在你手上, 下一秒就被其它人拿去了. 另外, VR 游戏中现在大多是 90FPS, 手上拿的东西如果模拟稍微有点延迟立即就能察觉, 影响所谓的”手感”. 在场景多的物理对象很多的时候, 你用帧同步吧, 延迟太大; 你用状态同步吧, 服务器跑个物理引擎又比较吃力, 下发的数据量也很大, 不知道玩家带宽能撑住不. 再说了, 之前同步头和手外加语音聊天已经占用掉很大一部带宽了, 留给物理对象的已经不多了.

End.