这篇文章会详细介绍我们镜匙在Gear VR游戏开发过程中遇到的种种问题及有趣的小窍门。
封面上的游戏是我们用UE4在上的第一次尝试，依稀记得之前在一个的群里提到过我们想用UE4开发一款移动端的VR游戏，群里各路大牛纷纷劝诫，告诉我们这不明智，于是乎，之后虽然继续在开发，但每一步都是硬着头皮走下去的。
具体的过程我会在下面分享出来，这其中有包括我们镜匙对VR游戏的一些想法，以及我个人对游戏这个奇怪的词语的理解，更多的还是在轻技术层面的一些讨论与报告，希望我今后的这些文章能够帮助到每个想要开发VR游戏，或者想去了解游戏的人。
背景：
我们在2015年年底制作过一款小巧的VR跑酷游戏《镜像酷跑》，那个时候的VR游戏远没有现在流行的各类VR游戏那么华丽，需要走动，拿起去抓握开枪什么的。
我们做的异常简单，只需要摇头。
感兴趣的朋友们可以去看看:镜像酷跑试玩视频
就是这款游戏，她使我们第一次体验到了在VR环境里高速前进且不会触发晕动症的爽快感觉。（当然，就目前看来，仍然会有10%左右的人戴上头盔就喊晕死啦，对此我们表示无奈）。
言归正传，我们在PC端做完这款游戏后，发现她并不是很受开发者们的青睐，因为大家都觉的这游戏太简单了，但是经历过不少展会与比赛的我们却发现，对于每一个初次接触VR的老百姓来说，这样的一款游戏很容易上手，玩起来很欢乐。
所以，我想这就足够了，在这个方向上深挖，没错。
于是我们就开启了PC端的联网版项目，同时也开启了移动端的跑酷VR游戏项目，毕竟最接近普通人的还是移动VR。
这个名字是我们很随意起的，因为为了让场景显得有些风格化，同时易于搭建，所以我们模仿了类似那种世界风格，同时加上一些Low Poly的景观物件，就构成了一个游戏发生的主要场景。
那个时候，我们对UE4的了解远远不够，对以及的了解也都是在表层，所以本着一颗实验的心开始了的制作。
正文：
1.我们怎么做？怎么优化？
照搬《镜像酷跑》的原型来做可以么？答案是：不行。
特效：
镜像酷跑里的模型及处处反射出霓虹灯式的画面效果，几乎没有一项是可以在移动VR上实现的，首先：是几乎不支持所有的画面特效的，也就是说，平时UE4那些上了材质就能显得高端大气上档次的渲染效果几乎全部都要舍弃，剩下给我们的只有一个叫做自动曝光的Auto 后期效果。
材质类型：
而在材质类型上我们也决定使用最简单的材质：基础颜色（Base Color），除了一些界面及文字上的显示上，我们用到了比较奢侈的透明材质用来显示数字和UI。然而事实证明这类型的材质会一定程度上的加大手机运行时的发热量。（好在后来的S7及以上机型均达到了非常好的散热效果，并无明显影响。）
光照：
光照类型在上目前仅支持两种模式，一种是 Lit，另一种是Unlit，在这里不论场景最终烘焙与否，我们都选择的Unlit模式，也就是说我们的场景中并没有被灯光照亮的物件，这样也就省去了灯光这一最耗费渲染资源的物件。
限制：
以下为Epic官方给出的有关在资源使用上的硬性限制，我们必须严格遵守这些限制，而且很大程度上要远远低于下面给出的数据才能保证未来有更多的优化空间。
由于移动硬件缺少 32 位索引支持，所有网格体类型可拥有最多 65,000 个顶点，不能超过此数字。
骨骼网格体可最多拥有 75 块骨头，不能超过此数字。
在 3D 网格体上尽量使用 材质 ID ，节约绘制调用的次数。
尽量使用 静态网格体 LODs 。
注意 3D 网格体多边形数量，尽量将其保持为 低多边形 。
为所有静态模型设置另一个 UV 集，使其使用 灯光贴图 。
尽量尝试使用 替代 替换远景的静态网格体，降低渲染开销。
使用 ECT2 纹理压缩格式。
X 轴或 Y 轴上的纹理尺寸均不可大于 2048 像素。
纹理尺寸必须为二的幂次方（例如 2、4、8、16、32、64、128、256、512、1024、2048）。
Gear VR 可将最大 512 MB 的纹理载入内存，但建议您将载入量控制在 128 MB 以内。
尽量使用方形纹理，因为其内存使用效率更高。
尽量尝试使用 纹理图集 ，减少内存中所需的纹理数量。
RGB 纹理遮罩/打包 可有效减少内存中的单一纹理。
仅限使用移动平台支持的 和 压缩设置。
在看到这么一堆硬性限制后，我们的内心其实是崩溃的，理论上在这样条件下做出来的游戏画面应该是惨不忍睹的。
然而事实上，确实是惨不忍睹的。。。（捂脸笑）
解决办法：
为了增添一些画面感，我们的技术美术在原有材质的基础上增添了不少新的效果，通过模型中具体的面与玩家之间的角度的不同来调节其本身颜色上的明暗程度，就可以模拟出一种貌似有实时光照的感觉。为了让地面的感觉更有纹理，我自己手绘了一些素描的贴图加在了本来的场景上。
除此之外，为了最大化的降低面数，我们事先在引擎内用这种Cube堆叠的方式进行场景设计，并在合格之后交由美术重新建模，将跑道上的面数降到极低，单位时间内场景内出现的总面数维持在5万面左右。
在这里说一个人尽皆知的小窍门，在跑酷游戏的过程中，我们让玩家眼前所看到的天空球作为一个跟随玩家自身的对象，借助引擎本身的类似“遮挡剔除”的功能来控制玩家视野内所出现的物件数量。
即使如此，我们在初次运行的时候，画面的帧率仍然无法达到30fps，这个时候我们发现，在大量降低面数的同时，我们忽略了引擎本身渲染批次的数量，也就是说单位时间内场景中的Draw Call过多，基本上每个均会占用一次渲染，但虽然每次渲染面数极低，速度很快，但其中的流程必须得走，也就是说，我们必须在的数量与其总面数之间取得一个良好的平衡，这个过程花费了我们不少时间，好在最终顺利将帧率提到了60fps。
你可能以为这就ok了？结束了么？不，才刚刚开始。。。
在画面上做出巨大的牺牲换来了稳定的60fps，然而现在还什么功能都没有添加呢。
这个游戏的核心在于跑的越远越好，获得的金币越多越好，所以遍布整个游戏的金币是必须的，那么问题来了，我们发现，光是在跑道上跑跑就罢了，勉强维持在30左右，但是这些时刻出现的金币可每一个都是单独的啊！加上金币后同一时间内画面内的数量瞬间接近100，帧率降至15pfs，药丸~
然而又是技术美术拯救了世界，关于金币的处理，我们找到了两种新的解决办法。
第一种就是将金币这个独立的蓝图作为实例添加进跑道，也就是与跑道的渲染序列一致，大家被一起渲染出来了。然而这个办法后来并没有采用。
第二种办法是将一连串的金币导入为一个，将额外的碰撞添加在相应位置，这样仅仅会增加一个，可能有人会问，那金币如何一个个显示被吃掉呢？这个就好玩多了，不过这里就暂时不说了。
剩下很多小窍门真的挺有意思，按我们自己人的说法那都是：奇技淫巧！
最终我们又在这个基础上添加很多其他的元素，并稳稳的保持在了60fps的刷新率上，这使得至少是一款可以流畅运行的VR游戏。
有人问我，你们这个游戏是用UE4做的？
我说：“嗯啊”
“UE4就这画面！”
“。。。。。。”（抹一抹眼泪）
下面是的游戏画面，在上录制的。
试玩视频
关于这个游戏到底怎么玩，有什么好玩的，我会在另一篇文章：如何设计一款VR跑酷游戏里介绍，这个部分主要还是讲UE4在上的开发。
下一章可能会讲游戏打包、签名这些，也可能会讲一部分程序上的坑。
下下一章可能会讲如何将你的游戏上传至三星或 Store。
总之，敬请期待~
/r/PD-- (二维码自动识别)
评论（0）