騰訊游戲分享匯：天天飛車六大研發(fā)經(jīng)驗(2)

存的合理使用，對象池，資源加載卸載管理等。

作為一款3D游戲，我們也一直在尋找游戲表現(xiàn)和性能的最佳平衡點。一個基本的取舍原則可能就是性價比，看性能的損耗帶來的效果提升到底大不大，是不是用戶比較關注的。另外在這點上程序和美術之間也經(jīng)常會出現(xiàn)一些意見分歧，這很正常。對于程序同學來說希望客戶端特別省，輕巧而快速。對于美術同學來說希望畫面足夠精細，能夠最大程度的保留設計初衷可能是非常重要的。這個問題目前看來我們處理的還是比較好的，站在客戶端程序的角度，一方面有些原則我們必須要堅持，比方說不能使用復雜的實時動態(tài)光影，后處理效果等確實與當前大多數(shù)移動設備硬件性能不相匹配的技術，另一方面我們也應該和美術同學一起為游戲的表現(xiàn)品質努力，比方說我們實現(xiàn)了一個效果自適應模塊，能夠根據(jù)用戶的設備性能選擇合適的效果等級，既能讓配置較差的設備以比較流暢的幀率運行游戲，高端機型也能夠表現(xiàn)出更精細的紋理，更真實的光照，更多的場景細節(jié)，更華麗的特效等等，避免了畫面品質一刀切的情況，給了美術同學多一些的發(fā)揮空間。當然總的來講，我們的資源規(guī)范還是比較嚴苛的，不得不贊嘆我們的美術oa，在如此多的限制下，依然讓我們的游戲有很不錯的畫面品質。

車庫

高配畫面

低配畫面

端游經(jīng)驗用于反外掛，安全問題早作預案

相比端游而言手游面臨的網(wǎng)絡環(huán)境更嚴峻，我們不可能做到實時通過服務器校驗玩家的每一步操作，從延遲，穩(wěn)定性，流量上講都不允許。單局的玩法邏輯大都是在客戶端完成在結算時才統(tǒng)一上報服務器的，玩家就有可能修改一些關鍵數(shù)據(jù)，比方說分數(shù)，金幣，Buf持續(xù)時間等等，從而獲得非法收益，這就必然牽扯到令人頭疼的反外掛問題。

基于以前端游的積累我們初期就預想到了這個情況，比較早地開始了對抗準備。我們的外掛對抗體系大體分為三層，第一層是客戶端的防御，除了必不可少的協(xié)議加密之外，客戶端對內(nèi)存中的關鍵數(shù)據(jù)也都是密文存儲的并且加上了校驗碼，這樣通過燒餅之類的通用內(nèi)存修改工具就比較難定位數(shù)據(jù)的具體位置了，而且就算真的找到了內(nèi)存地址，修改之后也會導致校驗失敗，這樣客戶端就能偵測到內(nèi)存數(shù)據(jù)的非法篡改。第二層是我們自己服務器的即時對抗，客戶端在單局結算時上報的數(shù)據(jù)中不光有最終的結果還有一些和結果有關聯(lián)的中間數(shù)據(jù)，比方說實際生成了多少金幣，是否有出現(xiàn)某種特殊車等等，如果外掛只是修改了部份數(shù)據(jù)，服務器就可以根據(jù)校驗公式檢測出數(shù)據(jù)被非法篡改過了，服務端kenny以前在QQ飛車 (微博)就做過類似的對抗，經(jīng)驗非常豐富。最后一層是互娛安全組的后校驗，他們采用的檢測方法和我們服務器的類似，只是不會對作弊行為進行實時處罰。

還有一個要特別注意的是，在Android平臺上，Unity的C#腳本是以JIT方式運行的，apk包里的程序集dll文件很容易被Reflector等工具反編譯，一旦被別有用心的人知道了客戶端邏輯到底如何運作的，就可能做出一些比較逆天的外掛來。當時我們想了很多辦法，一開始是做混淆，但發(fā)現(xiàn)執(zhí)行起來不是很方便，對開發(fā)存在一定的限制。后來我們想到一個方法，我們可以對程序集dll文件進行加密，這樣通用的反編譯工具就打不開了，但苦于我們沒有Unity及其修改過的mono組件的源代碼， 也不擅長逆向工程，我們把這個需求提給Unity的開發(fā)商，可能出于某些原因，他們也沒有太積極的反饋，后來還是安全組給了我們支持，他們通過逆向工程實現(xiàn)了對程序集文件的加解密，之后公司開發(fā)/代理的Unity手游應該都有采用這個加密方案。

崩潰上報靈活處理是解決之道

針對移動應用，MIG研發(fā)了一套叫做RQD的崩潰上報系統(tǒng)，MSDK對它作了統(tǒng)一接入，所以凡是接入了MSDK組件的移動端游戲在客戶端發(fā)生崩潰時都會自動捕捉上報異常的現(xiàn)場信息，對分析崩潰來說最有用的可能就莫過于調(diào)用棧了。

RQD雖然很強大，不光支持C/C++，ObjC這些原生語言的調(diào)用棧的還原，也支持Java的調(diào)用棧還原，但可惜的是Unity開發(fā)的游戲大多的異常其實發(fā)生在C#層，iOS平臺還好，C#是以AOT方式預先編譯成了原生代碼，調(diào)用棧會被當作C語言的對待，從函數(shù)名上也能基本定位到C#中具體發(fā)生崩潰的地方。但Android平臺就沒這么幸運了，C#是被預先