如何计算吃鸡游戏的物理碰撞？
這是第126篇UWA技術(shù)知識分享的推送。今天我們繼續(xù)為大家精選了若干和開發(fā)、優(yōu)化相關(guān)的問題，建議閱讀時間10分鐘，認(rèn)真讀完必有收獲。
UWA 問答社區(qū)：answer.uwa4d.com
UWA QQ群：465082844（僅限技術(shù)交流）
服務(wù)器同步
Q1：由于吃雞類游戲需要強同步，很多時候可能使用幀同步，客戶端無法直接使用物理引擎，或者狀態(tài)同步情況下服務(wù)器需要計算碰撞等。此時怎么處理這部分的碰撞呢？數(shù)據(jù)結(jié)構(gòu)又是怎樣呢？
A1：如果讓我選擇技術(shù)方案的話，類似絕地求生這種3D自由視角的吃雞游戲我絕對不會選擇幀同步，原因有：
1）射擊游戲在玩家移動、開槍等操作上會有較強的手感體驗上的訴求，幀同步很難支持即時的操作反饋；
2）自由視角的吃雞雖然沒有戰(zhàn)爭迷霧，但是會有視距的問題，使用幀同步把所有信息廣播給玩家，外掛做起來簡單太容易，而吃雞手游中標(biāo)定其他玩家位置這樣的外掛又有很大的優(yōu)勢，所以本質(zhì)上不適合。
不知道題主說的幀同步和我理解的幀同步是否一致。然后，基于狀態(tài)同步，服務(wù)器可以跑物理，但是真實的物理完全在服務(wù)器跑，對于服務(wù)器的壓力太大，需要付出的成本過高，一臺物理機也可能承載不了多少同時在線的玩家消耗，你要評估下運維的成本是否可以接受。常見的做法：
1）簡化3D物理，根據(jù)上下文狀態(tài)只做部分關(guān)鍵判定，比如類似命中這樣的。不過因為物理中的數(shù)據(jù)計算比較敏感，浮點誤差都可能導(dǎo)致結(jié)果不一致，這里的工作量和坑應(yīng)該都不少。
2）使用2D物理系統(tǒng)代替3D物理系統(tǒng)來做，在物理計算中去掉高度，只做2D的碰撞，結(jié)合專門的檢測進程，是一種可行的檢測方案，性價比比較高；
3）客戶端判定，服務(wù)器驗證，先相信客戶端的判定，然后進行客戶端表現(xiàn)，然后服務(wù)器基于數(shù)據(jù)做驗證，這里可能會使用2D物理引擎，也可能在核心判定中再添加一些比如高度的信息等來做；
4）客戶端判定，加嚴(yán)格的反外掛方式，封號之類的。這種當(dāng)然你也要可以判斷出來玩家作弊，判斷方式可以未必實時去做，類似幀同步放后面通過回放模擬來做也可以，這時候有可能可以使用3D物理的來做（經(jīng)驗上依然不推薦，只是從實時變成離線，對于性能的要求沒有那么高了，3D成為一個可能性）。
5）先不做，等游戲火了有錢了再加，沒火的話，也沒什么專業(yè)的外掛團隊來使壞。
至于數(shù)據(jù)結(jié)構(gòu)，太細(xì)節(jié)了，根據(jù)需求自己設(shè)計吧。2D的直接集成開源的2D引擎就可以了。
感謝賈偉昊@UWA問答社區(qū)提供了回答
A2：同意賈公的觀點。順帶補充幾點：
1）這游戲除了角色，還有非常多的第三方信息需要同步，包括：門、載具和物資等。如果是幀同步，那還得同步彈藥量和消耗品等等...即使是端游，也是信息量巨大。所以用狀態(tài)同步比較現(xiàn)實。
2）不是特別熟悉虛幻引擎，而虛幻引擎用了NVIDIA的Physx，市面上的吃雞手游應(yīng)該都是以此為基礎(chǔ)做的，那么服務(wù)器如何實時或離線運算Physx應(yīng)該也是有參考的。聯(lián)想到之前有篇關(guān)于守望先鋒中同步平滑的文章，題主可以去參考下。
3）其實物理碰撞不是啥大問題，外掛中自瞄和透視才是大問題。早期的PUBG連人物移速都不驗證的，為了物理碰撞而采用幀同步，可能其他方面踩的坑要更多。
感謝史云柯@UWA問答社區(qū)提供了回答
A3：感覺樓上已經(jīng)解答的很好了，補充一個反外掛的辦法吧：可以把本來需要在服務(wù)器進行的復(fù)雜運算，先讓涉及到的客戶端發(fā)一個結(jié)果，再將結(jié)果和運算及參數(shù)發(fā)到若干客戶端來執(zhí)行，再做投票驗證，這樣可以降低一些服務(wù)器的負(fù)載。
感謝郭瑞@UWA問答社區(qū)提供了回答
A4：我再補充一篇來自ValveSoftware的技術(shù)文檔《Source Multiplayer Networking》:
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
這篇也是基于狀態(tài)同步架構(gòu)的。里面提到的延遲補償和客戶端輸入預(yù)測技術(shù)，是目前比較主流的、用來對抗延遲帶來的糟糕體驗的方法。
感謝張銳@UWA問答社區(qū)提供了回答
A5：吃雞玩家數(shù)量一般在100個以上，這種情況下用幀同步需要同步的數(shù)據(jù)量會很大，延遲也會比較嚴(yán)重。因為幀同步一般需要收集所有同場景玩家的輸入，然后分發(fā)給各個客戶端，讓各個客戶端用相同的邏輯自己去計算每個玩家的位置、狀態(tài)，游戲邏輯是跑在客戶端的。MOBA適合使用幀同步是因為一場比賽只有10個玩家。
我覺得吃雞還是適合狀態(tài)同步。狀態(tài)同步怕的是角色太多，導(dǎo)致需要同步狀態(tài)的角色過多，造成網(wǎng)絡(luò)同步數(shù)據(jù)量大。吃雞沒有什么野怪，全部是玩家，所以場景里角色就是玩家。可拾取的裝備需要同步的數(shù)據(jù)比較少，基本上需要一個位置坐標(biāo)就行了，玩家身上的狀態(tài)數(shù)據(jù)量要多很多。客戶端看不見的玩家、裝備，完全可以不用同步，因為邏輯完全跑在服務(wù)器端，客戶端只需按照服務(wù)器的邏輯做繪制就行了。
關(guān)于游戲手感的問題，FPS游戲?qū)ρ舆t的要求是所有游戲類型中最高的。如果玩家網(wǎng)絡(luò)不是很好，也很難優(yōu)化到比較好的情況。客戶端先行可以先做顯示的預(yù)判例如：擊中后的血跡。但是數(shù)值結(jié)果還是依靠服務(wù)器端的計算，否則很容易被外掛利用。即使服務(wù)器結(jié)果判定沒有打中，問題也不是很大，最多就是玩家看到有幾槍打中有血跡特效，但是對方?jīng)]扣血。這種情況大概率出現(xiàn)在網(wǎng)絡(luò)環(huán)境不好的情況。
感謝ZFK@UWA問答社區(qū)提供了回答
該問答來自問答社區(qū)，歡迎大家轉(zhuǎn)至社區(qū)進一步交流：
https://answer.uwa4d.com/question/5a90c4960b827e2c0bfdcfc4
計算精度
Q2：我的項目在坐標(biāo)比較大（20000,0,20000）的時候有如下2個問題：
1）模型移動會發(fā)現(xiàn)輕微抖動；
2）安卓上鏡頭轉(zhuǎn)動時發(fā)現(xiàn)模型閃爍，只有安卓這樣，iOS和PC正常。Unity版本2017.4.2，測試工程已經(jīng)上傳至UWA問答社區(qū)。
A1:
http://www.songho.ca/opengl/gl_projectionmatrix.html
在NDC空間中，離近切面近的點，Z的精度會比較高，離遠(yuǎn)切面近的點，Z的精度會很低。如果遠(yuǎn)切面的值過大，那么就會容易出現(xiàn)Z-Fighting。基于透視原理，基本上這個問題是無解的。只能考慮曲線救國的方法繞過這個問題。
感謝凱奧斯@UWA問答社區(qū)提供了回答
A2：補充個現(xiàn)成參考方案：World Streamer
這個是個超大世界Streaming的完整解決方案，里頭也實現(xiàn)了一個Floating Point Fix功能，就是解決坐標(biāo)過大導(dǎo)致精度不足的問題。具體的做法大家也提到了，就是把世界的坐標(biāo)拉回來，另外NavMesh這塊會有坑，最新版的World Streamer已經(jīng)支持Unity 5.6+的NavMesh移動。實現(xiàn)代碼可參考里頭的WorldMover.cs。用法可以參考他們文檔Floating Point Fix System的說明。
感謝招文勇@UWA問答社區(qū)提供了回答
該回答由UWA提供，歡迎大家轉(zhuǎn)至社區(qū)交流：
https://answer.uwa4d.com/question/5afb8a326b104d27ac3aad62
渲染
Q3：我們項目在做優(yōu)化，之前是在游戲內(nèi)將場景渲染在一張較小的RenderTexture上最后翻回BackBuffer，但是這樣還是會多出來一次RenderTexture的拷貝。從我以往的經(jīng)驗來看，可以直接修改BackBuffer的默認(rèn)尺寸，這樣就可以避免一次RenderTexture的拷貝同時也減小RenderTexture的尺寸，不知道Unity在Android上是否可以直接修改BackBuffer的尺寸。我們使用的是Unity 5.5.4，希望大神解答一下。其實這個就類似與高版本Unity的DPI設(shè)置，但是我們現(xiàn)在無法更新Unity版本。
有個思路是硬改安卓層Surface的大小，是否可行還有兼容性問題需要驗證。
另外隱約記得降低分辨率的時候Unity有個輸出，不支持硬件縮放的情況下才會走Blit的方式，Logcat里的輸出是這個：
Hardware resolution scaling not supported, falling back to software scaling (blit).
相關(guān)資料（后半部分）：
https://forum.unity.com/threads/standard-shader-for-mobile.368672
建議直接調(diào)低分辨率，安卓上Unity會有個嘗試硬件縮放的過程。
另外，Unity 5在安卓上總是會有一次全屏Blit的，并不會直接往BackBuffer里繪制。
相關(guān)參考：https://forum.unity.com/threads/big-performance-issue-with-unity5-on-android.338847
感謝littlesome@UWA問答社區(qū)提供了回答，歡迎大家轉(zhuǎn)至社區(qū)交流：
https://answer.uwa4d.com/question/5b7fc7b01e88b37d34e65361
渲染
Q4：我想了解下，PostProcessing 的Bloom，只開一個Layer和開所有Layer的消耗是一樣的嗎？因為是屏幕后特效，它只取渲染完成后的圖片做一次處理，所以想確認(rèn)下自己的測試是否正確。
官方Github上的文檔是這么說的：
這個Layer跟Unity其他地方的Layer作用類似，是用來做Filter的，所以渲染的效率是不影響，但是對于不需要Bloom的相機還是可以設(shè)置一下把它屏蔽掉，這樣可以更高效。
該回答由UWA提供，歡迎大家轉(zhuǎn)至社區(qū)進一步交流：
https://answer.uwa4d.com/question/5b7b702c339d267d357c6e00
今天的分享就到這里。當(dāng)然，生有涯而知無涯。在漫漫的開發(fā)周期中，您看到的這些問題也許都只是冰山一角，我們早已在UWA問答網(wǎng)站上準(zhǔn)備了更多的技術(shù)話題等你一起來探索和分享。歡迎熱愛進步的你加入，也許你的方法恰能解別人的燃眉之急；而他山之“石”，也能攻你之“玉”。
官網(wǎng)：www.uwa4d.com
官方技術(shù)博客：blog.uwa4d.com
官方問答社區(qū)：answer.uwa4d.com
官方技術(shù)QQ群：465082844（僅限技術(shù)交流）
總結(jié)
以上是生活随笔為你收集整理的如何计算吃鸡游戏的物理碰撞？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： boost学习之boost::lock_
- 下一篇： boost中bind的使用