光子工作室首度曝光：《刺激戰場》是怎樣誕生的？

從年初的吃雞大戰中勝出後，《絕地求生：刺激戰場》（後文簡稱《刺激戰場》）在海外也接連取得佳績，不僅收穫了多個國家免費榜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。

GIF

我們都是採用動態陰影，動態陰影的消耗相當大，大概佔了整個渲染的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。

好的，我的分享就到這裡結束。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！