《刺激战场》是怎么做出来的？
在手机上用虚幻4怎么做百人战术竞技游戏？
从年初的吃鸡大战中胜出后，《绝地求生：刺激战场》（后文简称《刺激战场》）在海外也接连取得佳绩，不仅收获了多个国家免费榜Top 1，截止上周，游戏的DAU还突破了1000万大关。这款游戏的成功源于产品的高品质，以及对端游的充分还原，而为了做到这一点，腾讯光子工作室与Epic Games进行了深度的合作，借助虚幻4引擎，在移动端探索了诸多针对这类玩法的实现和优化方案。
在昨天Epic Games举办的UOD虚幻引擎技术开放日中，Epic Games也为《刺激战场》颁发了UOD年度最佳游戏的大奖，以表示对游戏品质和技术突破的认可。
今天的UOD大会中，腾讯光子工作室旗下，引擎研究工程师黄东海、游戏开发高级工程师刘小宁在现场分享了，《刺激战场》在借助虚幻4引擎实现游戏中8000mx8000m百人竞技大地图的方案，同时针对超大地图的优化做出了总结。
黄东海表示，在开发这款游戏的时候，他们面临着不小的压力。想要在移动端表现出高品质的画面，同时要呈现出超大地图尽可能多的细节元素，必须在制作的过程中必须做出很多的取舍，摸索更有效的实现方案。
以下为演讲内容实录。
大家好我是光子工作室的刘小宁。
我今天给大家带来两个议题，第一个是我们对大地图的处理方式，第二个是机型适配的一些细节。
我们先看一下，游戏采用的是8×8公里的一个大地图，从高空中可以看到里面有漫山遍野的树和草、植被，几万个房子小物件在场景里面，地形也很大。
我们在空中看到的树落地会不会变？是会变的，房子也会变，地形也会变。大地图的挑战总结为三个方面，一个是植被如何处理，一个是地形如何处理，还有一个是场景中大量物件如何处理。
这个是我们的树和草，在空中看到的树就是这样的一个树，我们把这样的树在玩家落地之前直接用Streaming Level卸载掉，大家会看到卸载掉之后不会有任何影响。草是对引擎原有的渲染方式做了一点优化，视野之外刷出来的草是不会绘制的，只绘制视野里面的草。
对地图加载的方面，我们首先看一下地图尺寸。我做了一个测试，将4×4km的地图分成64块，内存的加载算上地形组件，贴图一块是2M左右，我们直接把4×4km的地形做到8×8km，这样会节省四分之一内存。
通过调整LOD系数和SR.landscapeLODBias降低地形精度。将地形从地图中拆分为单独的level，避免因为速度更快产生的限地的问题。我们做了一个镂孔简模地表的方式，用一个极低面数的地表覆盖在真地形外围，以达到减面。
这是一个示意图，这个方案就两步第一个是离线简模地表生成，生成顶点数据，另外再每块地表下进行边界强数据的建立，顶点数自己可以控制，现在控制在2万面以下。运行的时候就是根据真地形加载了哪些进行挖洞，在假地表的数据上把这些顶点去掉，最后的边界建墙是为了真假衔接的地方有漏光，我们上下建墙通过这种方式来把这个问题解决掉。
场景中很多的物件怎么解决，绘制排序和动态合批，这个是Epic Games的小伙伴帮我们做的。我们在场景中大量使用了HISM这样一个组件，这个组件在我们的Epic Games数量达到两三万的时候，能够降低到十分之一，这样内存特别是DS端的内存降低的非常可观，数据达到上百兆，材质贴图按需加载，这点在安卓的低配机型上，我们不会加载中高地形所需要的贴图的数据，通过这种方式来进一步的降低内存。最后我们还使用了Streaming Level LOD的做法。
首先是Level LOD的生成，可以生成真实模型的简模。烘焙多级简模。运行的时候，根据配置距离加载不同的LOD级别的Level，根据游戏状态动态改变配置距离。大家在飞机上看到的房子都是上面的房子，落地之后是下面的房子。
再讲一下机型适配的问题，我们在项目立项的时候对安卓系统的分布做了一个调查，最新的数据也看了一下，我们的结论安卓4.3系统已经非常少，我们机型不支持GLES2.0。
我们对TOP100的机型进行了筛查，去年9月份1G机型还有三款，现在已经完全没有了，我们的目标要大于2G。
看一下iOS的分布，iPhone6是1G的，他的市场占有率去年9月份还很高，iPhone6是必须支持的，iPhone5S大盘数据比较少。
接下来就是一个分辨率系统的分享，因为这个东西安卓和iOS不一样，安卓配这个系数过程中就是720p的倍数，iOS是不同系统不同的分辨率，要查一下每个机型是怎样的去适配这个技术。
最后一点DeviceProfiles，iOS通过枚举来一一对应。安卓是通过匹配表进行匹配。三个点注意，SourceType，大家加一下内存，匹配顺序是从上到下，写在最上面的优先规则会优先匹配掉。最后一点TextureLODGroups里面的LODBias可以很好的做低机型适配的时候，把整体的降一级，有些人用最大的贴图尺寸，并不能把一些小的贴图整体往下降一级，这点引擎默认这个是不支持的，大家要修改两个代码把这个解决掉。
大家好我是光子工作室的黄东海。
我们这个项目立项的时候压力相当大，因为老板要求画质上高，肯定要比竞争对手高，再一个我们的适配机型，从我们希望的最低标准到最新GPU的835等型号等，性能差距大概有二、三十倍，这么大的范围我们都要适配。
我们在研发中实验过几乎所有可能的方案，我们试过整个场景的烘焙。最左边是我们最早的方案，我们烘焙的数据量一个场景就到1.3G贴图的容量，烘焙时间几乎要一个晚上，我们还有一些动态的光照，动态的天气系统，都对烘焙不太合适。然后我们也试过只烘焙Shadow Map，这个占贴图是200兆左右，运行开销是20-30兆，其实是可以接受的。这个方案我们已经完全实现了，通过修改引擎。最后还是没有用，主要还是因为动态天气，动态光照的问题。
最后，引擎内部的烘焙我们都没有用，包括IOC都是没有用的。因为没有烘焙阴影肯定是动态的，我们跟其他的几个游戏都是差不多，就是层级的Shadow Map，最多支持2级。最多支持一盏点光源，用在大厅界面。但是如果你没有烘焙就GII之类的都没有，产品在没有眼光照耀的地方就会很平，质感就很差，所以我们在3ds max里面烘焙了静态的太阳光间接光和天空光的AO都烘在了一张贴图里面，太阳光的GI下一个方向烘焙到RGB通道。
优缺点包体和内存占用少，滤导有大的建筑有70个，在场景里面有3000多个，如果在场景西面烘焙就是3000多个都要烘焙lightmap，为了控制整体烘焙大小一般都是64的分辨率，我们离线烘焙最多可以到512，小的建筑模型就比较小一点，可能128都有可能，能响应动态光照。工作流比较好，以前10个小时是看不到结果，然后你有错误要修改要重新返还工，这个是很痛苦的。我们单个建筑只要10分钟，如果好一点的工作站就是一两分钟，对工作流没有任何影响，随时可以，也可以不同的美术在上面。
这是一个开发过程当中的一个视频。太阳在绕着它转动，可以改变光线的亮度，改变颜色，改变强度，改变方向。到后面看到天棚光也可以改变强度改变方向，两个结合到一起就是一有一个尾照的动态的光照系统，是很量的，它只是一个512的lightmap。
我们都是采用动态阴影，动态阴影的消耗相当大，大概占了整个渲染的30%以上的时间。而生成shadow map的时间大概是5%。Shadow map造成的开销大概35%的样子，不优化也不太合适，我们有一些优化还有一些效果上的改进。一个是效果上的优化，两级CSM之间过渡也是硬的，让视觉效果好一点，多那么几个指令。
这就是一个截图渐变小时，层间的过渡，因为这个PC版都是有的，移动版是没有的，改起来也是十来分钟的事情。
有硬件厂商建议我们用Hardware PCF来提升硬件采样的性能，ES3.0及以上都支持，iOS A9，苹果6S以上都支持，6不支持。我们在支持的平台上都试验过，支持Hardware Shadow Map的平台都上都支持Linear采样，阴影采样次数从4-9次，减到1-4次。为了支持这个，稍微修改了一下Shader前端编译器。性能上获得不是特别大，只是轻微的变化，在中画质提升稍微大一点，4次减了1次，高画质9次减了1次变化并不是很大。
最大改善阴影性能的就是Shadow Cache，这个对移动版是没有的。这个东西对性能提升最大，我们从20的阴影消耗，提升到10%，差不多减掉一半，这个是很值得投入的。再就是CSM Stable，它有点小问题，稍微做一下缩放，每一次都不太一样，造成它会闪，稍微修一下就可以了，对指令的优化这个也要用，因为它是通用引擎。
我们的画质采样有两级阴影，中画质一级阴影，高画质采样两次，低画质采样一次。如果在高画质下采样次数过多，有些东西我们就专门针对它优化，降低到中画质的采样标准。比如草在游戏中是相当多的，人爬在里面几乎都看不到，它的填充率特别高，计算特别多，所以草的阴影我们会强制用中画质来采样，包括一些树、一些不太重要的小物件。这样就把整个屏幕真正阴影采样下降相当多，并且对画质几乎没有什么影响，大家不会注意这些小东西上的阴影是不是那么软，是不是那么的物理真实，这个也是值得搞的。
我们用了MSAA，现在有很多游戏都用MSAA，因为这个技术对画质提升相当大，手游一般是前端渲染，比较适合MSAA。并且对画质提升很高，他对高光的散还有一两线速的线条都会有很大的提升，整个画质提升相当大所以我们最终还是做了。
用于移动端的MSAA跟PC上的不一样，提升MASK材质的边缘效果，减少闪烁感性能开销比较小，只是低一些，不能低到忽略不计。他又因为不需要你之前的数据，他出来的时候带宽整个大的MSAA就没有了，所以他性能是比较好的，我们实测过在高通的GPU上，实际消耗就是20%，Mali就比较低了大概是10%。
我们是720P的，我们的硬件大多都是1080P，你720P其实不是完全的原生分辨率，如果1020做完全跑不动，三帧到不了，别说六帧。720P加MSAA的效果，比直接用1080P性能省，效果好。当然你的机器845、865那是无所谓，但那是以后的事情，现在肯定不行。MSAA高端机用四倍，中配用两倍，低配不能配。
这个东西因为MSAA本身是判断三角形站在子象素的哪个部分，覆盖掉就填到里面，最后做的时候，4个MSAA，那就4个子象素就看一下。把阿尔法值当作一个覆盖值去填到MSAA的子象素里，阿尔法值有一个MASK，在PC上可以指定，在移动上3.1之后也可以指定，我们用它内置的MASK来做。实际效果如下。
因为只有四倍所以差别不是特别明显，可以对比一下。这是草的边缘，改和不改的区别就非常大了，而且在手机上对性能几乎没有任何影响。所以这个是免费的东西，大家一定要做。
最后就是带宽上的优化，我们是用了HDR，高配有一个HDR，玩游戏有一个高配HDR的现代模式，我们也要考虑他的性能不能HDR玩不了，HDR带宽消耗特别大，所以我们也有优化。我们带宽优化有几点HDR render target压缩的浮点模式，大概少一半带宽。我们也没有用stencil。所以iOS下我们用Depth32F去掉Depth32F-Stencil8，这个格式相当于是64位的，为了对称没有办法做14位的。安卓下用阴影图默认是32位，其实我们用16位就够了，能省就省，对画质没有任何影响。
R11G11B10F这个格式到底对画质有什么影响，这个格式节省一半带宽，跟硬件内部有关系，有的硬件是原生的，有的硬件tile内部还是16F，出来的时候才转成R11G11B10F，中间会省那么一点。但是画质精度因为最多才10位的浮点，5位的尾数，5位的指数，应该画质会受损，网上有一个我看了分析，分析就是上面第一个图精度在小于0.25的时候，那个值精度是比RGBA8高，当的时候画质会损。
其实你如果用Gamma3，转到10位的浮点，出来的时候是可以所有的精度都比8位要高，但是我们并没有这样做，理论上是可以的，代价也不是很大，因为亮的地方虽然会受损，但暗的地方精度会更高，这更符合人眼视觉的响应，所以这样处理也是可以的。
我们没有用stencil，iOS下是用Depth32F去掉Depth32F-stencil8，节省带宽。我们尝试在安卓下解决，我们地形特别大，场景看的很远精度问题就很明显，水和地表建筑道路都有这些问题，他们在iOS下没有，只有安卓下，PC也没有，我们有PC模拟器的版本，但是我们尝试去解决这个问题，最后发现还是不行。
关键问题在GL_EXT_clip_conctrol变化的时候从1到负1，这里有一个-1+0.5和1×0.5的计算，×0.5没有损失，加0.5就有损失。加0.5就是按0.5的精度来走的，这个精度是不可挽回的损失。Vulkan和metal下深度精度没有问题。这个就是专门给移动用的，有这个扩展就可以控制他跳过+0.5×0.5的计算。我希望厂商都实现这个，因为这个确实很有用。
有人说用Vulkan不是所有的手机都支持。但Vulkan我们有测试，测试的所有机型都没有问题，所以我觉得这个值得去尝试。
最后正如刚才也说到的，安卓用Depth16可以少一点带宽，iOS不支持D16格式，只支持Depth32F。
好的，我的分享就到这里结束。