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

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

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

車庫

高配畫面

低配畫面

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

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

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

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

崩潰上報(bào)靈活處理是解決之道

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

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