1. 從一本書(shū)聊起游戲引擎到底是個(gè)什么東西第一次翻開(kāi)《游戲引擎原理與實(shí)踐》這本書(shū)的時(shí)候我腦子里其實(shí)只有一個(gè)很樸素的問(wèn)題我平時(shí)用Unity、Unreal做東西點(diǎn)一下播放鍵角色就跑起來(lái)了這背后到底發(fā)生了什么書(shū)里第一章沒(méi)有直接甩代碼而是先講了一個(gè)概念——游戲引擎本質(zhì)上是一套“把重復(fù)勞動(dòng)抽象出來(lái)的中間層”。這句話看著簡(jiǎn)單但真正理解它花了我差不多兩年時(shí)間。打個(gè)比方你要蓋一棟房子。如果沒(méi)有引擎你得自己去燒磚、砍樹(shù)、煉鋼每一塊磚從泥土開(kāi)始做。而游戲引擎就是那個(gè)“建材市場(chǎng)加施工隊(duì)”它給你準(zhǔn)備好了磚頭渲染管線、水泥物理系統(tǒng)、水電圖紙腳本系統(tǒng)、裝修工人工具鏈你只需要告訴它“我要一棟三室兩廳”它就能幫你把大部分基礎(chǔ)工作干掉。這就是為什么現(xiàn)在做游戲幾個(gè)人小團(tuán)隊(duì)也能搞出像樣的3D作品放在二十年前這得幾十號(hào)人干一年。這本書(shū)最讓我覺(jué)得值回票價(jià)的地方是它沒(méi)有停留在“怎么用引擎”的層面而是把引擎拆開(kāi)給你看里面的齒輪是怎么咬合的。渲染、物理碰撞、AI、工具鏈這四個(gè)詞基本就是現(xiàn)代游戲引擎的四根柱子。你平時(shí)在編輯器里拖拖拽拽背后就是這四套系統(tǒng)在瘋狂運(yùn)轉(zhuǎn)。我讀這本書(shū)的時(shí)候正好在做一個(gè)小的3D項(xiàng)目邊讀邊對(duì)照自己項(xiàng)目里的現(xiàn)象那種“原來(lái)如此”的感覺(jué)特別密集。這篇文章我打算按自己的閱讀順序和實(shí)際踩坑經(jīng)驗(yàn)來(lái)寫(xiě)不搞教科書(shū)式的章節(jié)復(fù)述。我會(huì)把書(shū)里講的核心原理結(jié)合我自己在Unity和Godot里遇到的實(shí)際問(wèn)題掰開(kāi)揉碎了講。不管你是剛?cè)胄械男氯诉€是做了幾年但一直停留在“調(diào)參”層面的朋友應(yīng)該都能從里面找到一些能直接拿去用的東西。尤其是那些“為什么我的角色會(huì)穿墻”“為什么渲染順序不對(duì)”“為什么AI像傻子”這類問(wèn)題書(shū)里給的答案比我翻論壇翻到的要透徹得多。2. 渲染管線從一堆頂點(diǎn)到屏幕上的畫(huà)面2.1 渲染到底在干什么把數(shù)學(xué)變成像素書(shū)里講渲染的那一章我反復(fù)看了三遍。第一遍覺(jué)得“哦就是畫(huà)圖”第二遍覺(jué)得“好像沒(méi)那么簡(jiǎn)單”第三遍才真正意識(shí)到渲染管線其實(shí)是一條高度標(biāo)準(zhǔn)化的流水線每一個(gè)環(huán)節(jié)都在做一件事把三維空間里的幾何信息一步步轉(zhuǎn)換成屏幕上二維的像素顏色。你可以把它想象成一條汽車(chē)裝配線。原材料是頂點(diǎn)數(shù)據(jù)一堆帶坐標(biāo)的點(diǎn)第一站是頂點(diǎn)著色器負(fù)責(zé)把每個(gè)點(diǎn)從模型空間搬到屏幕空間順便算算光照方向第二站是圖元裝配把點(diǎn)連成三角形第三站是光柵化把三角形變成一個(gè)個(gè)像素點(diǎn)第四站是片元著色器決定每個(gè)像素最終是什么顏色最后一站是輸出合并處理透明、深度測(cè)試這些收尾工作。每一站都有明確的輸入和輸出前一站的輸出就是后一站的輸入。這個(gè)流程之所以重要是因?yàn)槟阌龅降慕^大多數(shù)渲染問(wèn)題都能定位到具體是哪一站出了岔子。比如角色模型邊緣有鋸齒那是光柵化階段的事開(kāi)抗鋸齒就行比如兩個(gè)物體前后遮擋關(guān)系不對(duì)那是深度測(cè)試的問(wèn)題比如半透明物體看起來(lái)怪怪的那是輸出合并階段混合模式?jīng)]設(shè)對(duì)。我以前遇到渲染問(wèn)題就瞎調(diào)參數(shù)讀完這一章之后我學(xué)會(huì)了先問(wèn)自己這個(gè)問(wèn)題發(fā)生在管線的哪個(gè)階段問(wèn)完基本就有方向了。2.2 頂點(diǎn)著色器和片元著色器兩個(gè)最常打交道的家伙書(shū)里對(duì)這兩個(gè)著色器的講解非常接地氣。頂點(diǎn)著色器是“按點(diǎn)算”每個(gè)頂點(diǎn)跑一次片元著色器是“按像素算”每個(gè)像素跑一次。這意味著片元著色器的計(jì)算量通常遠(yuǎn)大于頂點(diǎn)著色器因?yàn)橐粠?huà)面動(dòng)輒幾百萬(wàn)像素而頂點(diǎn)可能只有幾十萬(wàn)個(gè)。這個(gè)區(qū)別直接影響了我們?cè)趺磳?xiě)Shader。書(shū)里給了一個(gè)很實(shí)用的建議能放在頂點(diǎn)著色器里算的就別放在片元著色器里算。比如一些變化頻率很低的光照計(jì)算完全可以放到頂點(diǎn)階段算完再插值給片元。我在一個(gè)移動(dòng)端項(xiàng)目里試過(guò)這個(gè)優(yōu)化把一部分逐像素光照改成逐頂點(diǎn)光照幀率直接從28幀拉到了45幀畫(huà)面效果肉眼幾乎看不出差別。當(dāng)然代價(jià)是光照過(guò)渡會(huì)稍微生硬一點(diǎn)但對(duì)于性能吃緊的移動(dòng)端來(lái)說(shuō)這個(gè)取舍非常劃算。還有一個(gè)點(diǎn)書(shū)里講得很清楚頂點(diǎn)著色器不能創(chuàng)建或銷毀頂點(diǎn)它只能修改傳入的頂點(diǎn)信息。這意味著你不能在著色器里動(dòng)態(tài)生成幾何體那是幾何著色器或者計(jì)算著色器的活。我一開(kāi)始學(xué)的時(shí)候老想著“能不能在Shader里讓模型長(zhǎng)出一棵樹(shù)”后來(lái)才明白這屬于幾何生成的范疇得用別的工具。2.3 渲染順序?yàn)槭裁茨愕陌胪该魑矬w看起來(lái)像鬼片書(shū)里專門(mén)用了一節(jié)講渲染順序這一節(jié)我建議每個(gè)做3D的人都反復(fù)讀。渲染順序的核心原則是不透明物體從前往后畫(huà)半透明物體從后往前畫(huà)。為什么因?yàn)椴煌该魑矬w有深度測(cè)試前面的畫(huà)完了后面的如果被擋住就直接丟棄省了片元著色器的計(jì)算而半透明物體需要和后面的顏色混合必須從后往前畫(huà)才能得到正確的疊加效果。我踩過(guò)的一個(gè)經(jīng)典坑是場(chǎng)景里有一塊玻璃玻璃后面有一團(tuán)火結(jié)果火看起來(lái)像是浮在玻璃前面。排查了半天發(fā)現(xiàn)是玻璃的渲染隊(duì)列設(shè)成了和普通不透明物體一樣導(dǎo)致它在火之前就被畫(huà)了火再畫(huà)上去的時(shí)候深度測(cè)試沒(méi)通過(guò)直接被丟棄。解決辦法很簡(jiǎn)單把玻璃的材質(zhì)渲染隊(duì)列改成Transparent引擎就會(huì)自動(dòng)把它排到不透明物體之后渲染。書(shū)里還提到了一個(gè)更隱蔽的問(wèn)題多個(gè)半透明物體之間的排序。引擎通常按物體中心點(diǎn)到相機(jī)的距離排序但如果兩個(gè)半透明物體互相穿插按中心點(diǎn)排序就會(huì)出錯(cuò)。這種情況書(shū)里建議用逐像素排序或者手動(dòng)拆分網(wǎng)格雖然麻煩但效果最穩(wěn)。我在做角色頭發(fā)的時(shí)候遇到過(guò)這個(gè)問(wèn)題頭發(fā)和身體穿插按中心點(diǎn)排怎么都不對(duì)最后是把頭發(fā)拆成前后兩層分別設(shè)置渲染隊(duì)列才解決的。2.4 渲染性能優(yōu)化別讓GPU閑著也別讓它累死書(shū)里講性能優(yōu)化的時(shí)候反復(fù)強(qiáng)調(diào)一個(gè)觀點(diǎn)渲染優(yōu)化的本質(zhì)是減少Draw Call和減少Overdraw。Draw Call是CPU告訴GPU“畫(huà)這個(gè)”的指令每次Draw Call都有固定開(kāi)銷所以能合并的網(wǎng)格盡量合并。Overdraw是同一個(gè)像素被畫(huà)了多次比如你畫(huà)了一個(gè)大背景又在上面畫(huà)了一個(gè)不透明的前景那背景被前景蓋住的部分就是浪費(fèi)的Overdraw。我實(shí)測(cè)過(guò)一個(gè)場(chǎng)景一個(gè)2D游戲背景是一張大圖上面有幾十個(gè)角色。一開(kāi)始每個(gè)角色一個(gè)Sprite RendererDraw Call直接飆到80多。后來(lái)用了Sprite Atlas把角色圖集合并Draw Call降到了個(gè)位數(shù)幀率從30幀穩(wěn)到了60幀。這個(gè)優(yōu)化在書(shū)里叫“批處理”Unity里有靜態(tài)批處理和動(dòng)態(tài)批處理兩種靜態(tài)批處理適合不動(dòng)的物體動(dòng)態(tài)批處理適合會(huì)動(dòng)但頂點(diǎn)數(shù)少的物體。還有一個(gè)書(shū)里提到的技巧是遮擋剔除。簡(jiǎn)單說(shuō)就是如果某個(gè)物體被前面的墻完全擋住了那就不畫(huà)它。Unity和Unreal都有內(nèi)置的遮擋剔除系統(tǒng)但需要手動(dòng)烘焙。我在一個(gè)室內(nèi)場(chǎng)景里試過(guò)烘焙完之后Draw Call直接少了一半因?yàn)榉块g外面的東西全被剔掉了。不過(guò)要注意遮擋剔除對(duì)動(dòng)態(tài)物體效果有限而且烘焙時(shí)間可能很長(zhǎng)場(chǎng)景越大越久。3. 物理碰撞讓虛擬世界遵守牛頓定律3.1 碰撞檢測(cè)和碰撞響應(yīng)兩件容易混淆的事書(shū)里把物理系統(tǒng)拆成了兩塊碰撞檢測(cè)和碰撞響應(yīng)。碰撞檢測(cè)是“判斷兩個(gè)物體有沒(méi)有碰上”碰撞響應(yīng)是“碰上了之后怎么動(dòng)”。這兩件事經(jīng)常被混在一起說(shuō)但實(shí)際開(kāi)發(fā)中它們是分開(kāi)處理的而且各有各的坑。碰撞檢測(cè)的核心是包圍盒。引擎不會(huì)去精確計(jì)算兩個(gè)復(fù)雜模型有沒(méi)有相交那樣太慢了。它會(huì)給每個(gè)物體套一個(gè)簡(jiǎn)單的幾何體比如AABB軸對(duì)齊包圍盒、OBB有向包圍盒或者球體先判斷這些簡(jiǎn)單形狀有沒(méi)有相交。如果包圍盒都沒(méi)碰上那精確模型肯定也沒(méi)碰上直接跳過(guò)。如果包圍盒碰上了再進(jìn)一步做精確檢測(cè)。這個(gè)思路在書(shū)里叫“粗篩加精篩”和數(shù)據(jù)庫(kù)查詢先走索引再掃表是一個(gè)道理。我一開(kāi)始不理解為什么角色明明看起來(lái)沒(méi)碰到墻卻被擋住了后來(lái)發(fā)現(xiàn)是角色的包圍盒比模型大了一圈視覺(jué)上沒(méi)碰到物理上已經(jīng)碰上了。解決辦法是調(diào)整包圍盒的大小或者用更精確的碰撞體形狀。3.2 剛體、碰撞體和觸發(fā)器三個(gè)容易搞混的概念書(shū)里用了一個(gè)很形象的比喻剛體是物體的“物理身份”碰撞體是物體的“物理形狀”觸發(fā)器是物體的“感應(yīng)區(qū)域”。一個(gè)物體可以有剛體但沒(méi)有碰撞體那它會(huì)受重力影響但不會(huì)和別人碰撞也可以有碰撞體但沒(méi)有剛體那它會(huì)擋住別人但自己不動(dòng)觸發(fā)器則是一種特殊的碰撞體它不產(chǎn)生物理阻擋只用來(lái)檢測(cè)“有沒(méi)有東西進(jìn)來(lái)了”。我在做拾取道具功能的時(shí)候一開(kāi)始給道具加了剛體和碰撞體結(jié)果道具掉在地上彈來(lái)彈去玩家走過(guò)去還會(huì)被彈開(kāi)。后來(lái)把剛體去掉碰撞體設(shè)成觸發(fā)器問(wèn)題就解決了。觸發(fā)器不會(huì)產(chǎn)生物理響應(yīng)但會(huì)觸發(fā)OnTriggerEnter事件正好用來(lái)做拾取檢測(cè)。書(shū)里還提醒了一個(gè)細(xì)節(jié)觸發(fā)器的檢測(cè)需要至少一方有剛體。如果兩個(gè)物體都是純碰撞體沒(méi)有剛體觸發(fā)器事件不會(huì)觸發(fā)。這個(gè)坑我踩過(guò)當(dāng)時(shí)兩個(gè)物體都設(shè)了觸發(fā)器怎么都不觸發(fā)事件查了半天文檔才發(fā)現(xiàn)需要加剛體。加了個(gè) kinematic 剛體之后事件正常觸發(fā)了。3.3 物理材質(zhì)摩擦力、彈力和那些反直覺(jué)的參數(shù)書(shū)里講物理材質(zhì)的時(shí)候我印象最深的是摩擦力和彈力的組合效果非常反直覺(jué)。比如一個(gè)球從斜坡上滾下來(lái)如果摩擦系數(shù)是0球會(huì)一直滑到底如果摩擦系數(shù)是1球可能滾到一半就停了。但如果你把彈力設(shè)成1球又會(huì)彈起來(lái)和摩擦力互相干擾。我做過(guò)一個(gè)彈球游戲一開(kāi)始球的彈力設(shè)成0.8結(jié)果球越彈越低最后停在地上。書(shū)里解釋說(shuō)這是因?yàn)槊看闻鲎捕加心芰繐p失彈力0.8意味著每次碰撞后速度變成原來(lái)的0.8倍幾次之后就趨近于0了。要讓球一直彈彈力得設(shè)成1但這樣又永遠(yuǎn)不會(huì)停。最后我的方案是彈力設(shè)0.95再加一個(gè)最小速度閾值低于閾值就停止彈跳效果比較自然。還有一個(gè)書(shū)里提到的坑是物理材質(zhì)的優(yōu)先級(jí)。兩個(gè)物體碰撞時(shí)用哪個(gè)的物理材質(zhì)Unity的規(guī)則是取兩個(gè)材質(zhì)中摩擦力較小的那個(gè)彈力取較大的那個(gè)。這個(gè)規(guī)則我一開(kāi)始不知道調(diào)了半天參數(shù)都沒(méi)效果后來(lái)才發(fā)現(xiàn)是被另一個(gè)物體的材質(zhì)覆蓋了。3.4 物理更新和幀率為什么低幀率下物理會(huì)爆炸書(shū)里專門(mén)講了一節(jié)物理更新和幀率的關(guān)系這一節(jié)解決了我長(zhǎng)期以來(lái)的一個(gè)困惑為什么游戲卡的時(shí)候物體會(huì)突然穿墻或者飛出去原因是物理引擎通常以固定時(shí)間步長(zhǎng)更新比如每秒50次但渲染幀率是變化的。如果某一幀渲染花了太長(zhǎng)時(shí)間物理引擎需要補(bǔ)上多次更新補(bǔ)的次數(shù)太多就會(huì)導(dǎo)致計(jì)算量爆炸物體位置跳變。Unity的解決辦法是插值和外推。插值是在兩個(gè)物理幀之間平滑過(guò)渡外推是預(yù)測(cè)下一個(gè)物理幀的位置。書(shū)里建議把物理更新頻率設(shè)成和渲染幀率解耦并且開(kāi)啟插值。我試過(guò)把固定時(shí)間步長(zhǎng)從0.02改成0.01物理精度提高了但CPU開(kāi)銷也上去了。最后折中用了0.0167差不多60Hz配合插值效果和性能比較平衡。還有一個(gè)書(shū)里提到的技巧是限制最大物理更新次數(shù)。Unity默認(rèn)最多補(bǔ)5次物理更新超過(guò)就丟棄。這個(gè)設(shè)置可以防止卡頓時(shí)的“死亡螺旋”——幀率越低物理更新越多CPU越忙幀率更低。我在一個(gè)低端機(jī)上測(cè)試過(guò)把最大更新次數(shù)從5改成3卡頓時(shí)的表現(xiàn)明顯更穩(wěn)定雖然物理精度略有下降但玩家?guī)缀醪煊X(jué)不到。4. AI系統(tǒng)讓NPC看起來(lái)不那么像機(jī)器人4.1 有限狀態(tài)機(jī)最基礎(chǔ)但也最實(shí)用書(shū)里講AI的第一種方案是有限狀態(tài)機(jī)簡(jiǎn)稱FSM。它的思路非常簡(jiǎn)單NPC有一組狀態(tài)比如巡邏、追擊、攻擊、逃跑每個(gè)狀態(tài)有進(jìn)入條件、退出條件和更新邏輯。同一時(shí)間只能處于一個(gè)狀態(tài)狀態(tài)之間通過(guò)條件切換。這個(gè)方案之所以經(jīng)典是因?yàn)樗銐蚝?jiǎn)單足夠可控。你隨時(shí)可以知道NPC在干什么調(diào)試起來(lái)也方便。我在做一個(gè)潛行游戲的時(shí)候守衛(wèi)的AI就是用FSM寫(xiě)的平時(shí)巡邏看到玩家進(jìn)入追擊追到一定距離進(jìn)入攻擊血量低進(jìn)入逃跑。整個(gè)邏輯用Switch-Case就能寫(xiě)清楚代碼量不大效果也還行。但FSM的缺點(diǎn)也很明顯狀態(tài)一多就爆炸。如果NPC有10個(gè)狀態(tài)狀態(tài)之間的切換條件可能有幾十條維護(hù)起來(lái)非常痛苦。書(shū)里建議如果狀態(tài)超過(guò)7個(gè)就該考慮用行為樹(shù)或者分層狀態(tài)機(jī)了。我后來(lái)做另一個(gè)項(xiàng)目NPC有巡邏、警戒、追擊、搜索、攻擊、撤退、求援、眩暈、死亡九個(gè)狀態(tài)用FSM寫(xiě)到最后自己都繞暈了果斷換成了行為樹(shù)。4.2 行為樹(shù)把AI邏輯變成一棵可讀的樹(shù)行為樹(shù)是書(shū)里重點(diǎn)介紹的第二種AI方案。它的核心思想是把AI邏輯組織成一棵樹(shù)葉子節(jié)點(diǎn)是具體動(dòng)作或條件內(nèi)部節(jié)點(diǎn)是控制流比如選擇、順序、并行。執(zhí)行時(shí)從根節(jié)點(diǎn)開(kāi)始按一定規(guī)則遍歷直到找到一個(gè)可執(zhí)行的動(dòng)作。行為樹(shù)最大的好處是可讀性和可擴(kuò)展性。你看著一棵樹(shù)就能大概知道NPC會(huì)干什么。加一個(gè)新行為只需要在樹(shù)上掛一個(gè)新節(jié)點(diǎn)不用改現(xiàn)有邏輯。我在一個(gè)RTS項(xiàng)目里用行為樹(shù)管理單位AI每個(gè)單位的行為樹(shù)大概有二十幾個(gè)節(jié)點(diǎn)包括采集、建造、攻擊、撤退、巡邏等。策劃想加一個(gè)“優(yōu)先攻擊最近敵人”的行為我直接在樹(shù)上加了一個(gè)選擇節(jié)點(diǎn)十分鐘就搞定了。書(shū)里還提到了行為樹(shù)的兩種執(zhí)行方式事件驅(qū)動(dòng)和輪詢。事件驅(qū)動(dòng)是條件變化時(shí)才重新評(píng)估樹(shù)輪詢是每幀都從頭遍歷。事件驅(qū)動(dòng)性能好但邏輯復(fù)雜輪詢簡(jiǎn)單但性能差。我一般用輪詢加一個(gè)更新間隔比如每0.2秒評(píng)估一次既簡(jiǎn)單又不會(huì)太耗性能。4.3 導(dǎo)航網(wǎng)格讓NPC知道路怎么走書(shū)里講AI尋路的時(shí)候重點(diǎn)講了導(dǎo)航網(wǎng)格。它的思路是把可行走區(qū)域烘焙成一張網(wǎng)格NPC在網(wǎng)格上尋路而不是在原始場(chǎng)景幾何體上尋路。這樣做的好處是尋路速度快路徑平滑。Unity的NavMesh系統(tǒng)就是基于導(dǎo)航網(wǎng)格的。我做過(guò)一個(gè)塔防游戲敵人從出生點(diǎn)走到終點(diǎn)用NavMesh尋路非常方便。但書(shū)里提醒了一個(gè)坑導(dǎo)航網(wǎng)格是靜態(tài)烘焙的動(dòng)態(tài)障礙物需要額外處理。比如玩家在路中間放了一個(gè)塔敵人得繞過(guò)去。Unity提供了NavMeshObstacle組件可以動(dòng)態(tài)挖洞但性能開(kāi)銷比靜態(tài)網(wǎng)格大。我的做法是塔放下去的時(shí)候重新烘焙一小塊區(qū)域的導(dǎo)航網(wǎng)格雖然有點(diǎn)卡但比每幀動(dòng)態(tài)計(jì)算要快。還有一個(gè)書(shū)里提到的細(xì)節(jié)是導(dǎo)航網(wǎng)格的生成參數(shù)。Agent Radius決定NPC能過(guò)多窄的縫Agent Height決定NPC能過(guò)多矮的洞Max Slope決定NPC能爬多陡的坡。這些參數(shù)設(shè)錯(cuò)了NPC要么卡在門(mén)口進(jìn)不去要么穿墻走捷徑。我一開(kāi)始Agent Radius設(shè)得太小NPC貼著墻走看起來(lái)像在蹭墻后來(lái)調(diào)大了一點(diǎn)路徑就正常了。4.4 AI的感知系統(tǒng)讓NPC“看得見(jiàn)”和“聽(tīng)得見(jiàn)”書(shū)里講AI感知的時(shí)候我印象最深的是視覺(jué)感知的視錐體檢測(cè)。NPC的視野是一個(gè)錐形區(qū)域只有在這個(gè)區(qū)域內(nèi)、沒(méi)有被遮擋、并且光照條件允許的情況下NPC才能看到玩家。這個(gè)檢測(cè)每幀都要做所以性能優(yōu)化很重要。我的做法是分層檢測(cè)先用距離做粗篩超過(guò)視野距離的直接跳過(guò)再用角度做第二層篩選不在視錐體內(nèi)的跳過(guò)最后用射線檢測(cè)做精確判斷看有沒(méi)有遮擋。這樣大部分物體在第一層就被過(guò)濾掉了性能開(kāi)銷很小。聽(tīng)覺(jué)感知相對(duì)簡(jiǎn)單通常是事件驅(qū)動(dòng)的。玩家開(kāi)槍、跑步、開(kāi)門(mén)都會(huì)發(fā)出聲音事件NPC根據(jù)聲音的距離和響度決定要不要去查看。書(shū)里建議給聲音加一個(gè)衰減曲線距離越遠(yuǎn)響度越低超過(guò)一定距離就聽(tīng)不到了。我在一個(gè)潛行游戲里用了這個(gè)方案玩家蹲著走聲音很小守衛(wèi)聽(tīng)不到跑起來(lái)聲音大守衛(wèi)就會(huì)過(guò)來(lái)查看。5. 工具鏈引擎背后的那些“看不見(jiàn)的手”5.1 資源管線從美術(shù)軟件到引擎的最后一公里書(shū)里講工具鏈的時(shí)候第一個(gè)講的就是資源管線。美術(shù)在Maya里做好模型導(dǎo)出FBX導(dǎo)入引擎這中間其實(shí)有一大堆自動(dòng)化處理模型要減面、要生成LOD、要計(jì)算法線、要壓縮紋理、要生成碰撞體。這些工作如果全靠手動(dòng)一個(gè)項(xiàng)目幾百個(gè)模型根本做不完。書(shū)里介紹了一種常見(jiàn)的資源管線方案約定大于配置。美術(shù)按照固定的命名規(guī)則和目錄結(jié)構(gòu)存放文件工具自動(dòng)掃描目錄按照規(guī)則處理資源。比如模型文件放在Models目錄下紋理放在Textures目錄下工具自動(dòng)把紋理關(guān)聯(lián)到模型上自動(dòng)生成LOD自動(dòng)壓縮紋理格式。我在一個(gè)團(tuán)隊(duì)里推行過(guò)這套方案一開(kāi)始美術(shù)很抵觸覺(jué)得限制太多。但用了兩個(gè)月之后大家發(fā)現(xiàn)再也不用擔(dān)心“這個(gè)紋理忘了壓縮”“那個(gè)模型忘了生成LOD”了效率反而提高了。書(shū)里有一句話我特別認(rèn)同好的工具鏈?zhǔn)亲屨_的事情變得容易讓錯(cuò)誤的事情變得困難。5.2 構(gòu)建和打包一鍵出包有多難書(shū)里講構(gòu)建系統(tǒng)的時(shí)候我差點(diǎn)笑出聲因?yàn)樘鎸?shí)了。書(shū)里說(shuō)很多團(tuán)隊(duì)的一鍵出包腳本其實(shí)是“一鍵出包然后手動(dòng)修一堆問(wèn)題”。構(gòu)建系統(tǒng)要處理的事情太多了代碼編譯、資源打包、版本號(hào)注入、渠道配置、簽名、上傳每一步都可能出錯(cuò)。我做過(guò)一個(gè)多平臺(tái)項(xiàng)目要同時(shí)出Windows、Android和iOS三個(gè)平臺(tái)的包。一開(kāi)始每個(gè)平臺(tái)一個(gè)腳本維護(hù)起來(lái)非常痛苦。后來(lái)參考書(shū)里的思路把構(gòu)建流程拆成幾個(gè)獨(dú)立的步驟準(zhǔn)備資源、編譯代碼、打包資源、生成安裝包、上傳分發(fā)。每個(gè)步驟是一個(gè)獨(dú)立的腳本可以單獨(dú)運(yùn)行也可以串起來(lái)跑。這樣調(diào)試的時(shí)候只需要跑出問(wèn)題的那一步不用每次都從頭來(lái)。書(shū)里還提到了構(gòu)建緩存的重要性。如果每次構(gòu)建都重新編譯所有代碼、重新打包所有資源那構(gòu)建時(shí)間會(huì)非常長(zhǎng)。合理的做法是只重新編譯改動(dòng)的代碼只重新打包改動(dòng)的資源。Unity的增量構(gòu)建做得還不錯(cuò)但有時(shí)候會(huì)抽風(fēng)該重新編譯的不編譯導(dǎo)致運(yùn)行時(shí)出錯(cuò)。我的經(jīng)驗(yàn)是如果遇到莫名其妙的運(yùn)行時(shí)錯(cuò)誤先試試全量構(gòu)建大概率能解決。5.3 調(diào)試工具引擎自帶的和自己寫(xiě)的書(shū)里講調(diào)試工具的時(shí)候強(qiáng)調(diào)了一個(gè)觀點(diǎn)引擎自帶的調(diào)試工具只能解決通用問(wèn)題項(xiàng)目特有的問(wèn)題需要自己寫(xiě)工具。Unity有Profiler、Frame Debugger、Console這些能解決大部分性能問(wèn)題和邏輯錯(cuò)誤。但如果你想知道“為什么這個(gè)技能在特定情況下傷害計(jì)算不對(duì)”那就得自己寫(xiě)日志工具或者可視化工具。我做過(guò)一個(gè)戰(zhàn)斗系統(tǒng)傷害計(jì)算涉及十幾個(gè)參數(shù)出了問(wèn)題根本不知道是哪一步算錯(cuò)了。后來(lái)寫(xiě)了一個(gè)傷害計(jì)算的可視化工具把每一步的中間結(jié)果都打出來(lái)一目了然。這個(gè)工具花了我兩天時(shí)間但后面省下的調(diào)試時(shí)間至少有兩周。書(shū)里還提到了遠(yuǎn)程調(diào)試。移動(dòng)端開(kāi)發(fā)尤其需要這個(gè)因?yàn)槭謾C(jī)上沒(méi)法直接看日志。Unity的Remote Profiler可以連到手機(jī)上實(shí)時(shí)看性能數(shù)據(jù)。但書(shū)里提醒遠(yuǎn)程調(diào)試會(huì)引入額外的網(wǎng)絡(luò)開(kāi)銷可能影響性能數(shù)據(jù)的準(zhǔn)確性。我的做法是先用遠(yuǎn)程調(diào)試定位大致范圍再在本地復(fù)現(xiàn)精確測(cè)量。5.4 版本管理和資源熱更那些年我們追過(guò)的更新包書(shū)里講版本管理的時(shí)候我最有共鳴的是資源熱更這一塊。熱更的核心思路是把資源和代碼分開(kāi)資源可以單獨(dú)更新不用重新下載整個(gè)安裝包。這樣玩家更新成本低留存率也高。但熱更的坑非常多。書(shū)里列了幾個(gè)常見(jiàn)的資源版本對(duì)不上、熱更后舊資源沒(méi)清理、熱更腳本和主工程不兼容。我踩過(guò)最慘的一個(gè)坑是熱更之后游戲直接黑屏排查了半天發(fā)現(xiàn)是熱更腳本里用了一個(gè)新API但主工程里沒(méi)有這個(gè)API運(yùn)行到那一行就崩了。后來(lái)學(xué)乖了熱更腳本必須做兼容性檢查不支持的API要有降級(jí)方案。書(shū)里還提到了熱更的原子性。熱更過(guò)程中如果斷網(wǎng)或者閃退不能把游戲搞壞。常見(jiàn)的做法是先下載到臨時(shí)目錄下載完了再替換正式目錄。替換的時(shí)候用文件鎖或者版本標(biāo)記確保要么全換要么不換。我在一個(gè)項(xiàng)目里用了這個(gè)方案熱更失敗率從5%降到了0.1%以下。6. 閱讀這本書(shū)的幾個(gè)實(shí)用建議6.1 不要跳過(guò)原理直接看代碼這本書(shū)里有很多代碼示例但我建議第一遍讀的時(shí)候不要急著看代碼先把原理看懂。比如渲染管線那一章代碼可能只有幾十行但背后的數(shù)學(xué)和工程決策非常密集。如果你不理解為什么要有頂點(diǎn)著色器和片元著色器之分看代碼只能看到一堆矩陣乘法學(xué)不到真正的東西。我的做法是第一遍讀原理第二遍讀代碼第三遍自己動(dòng)手改代碼。比如書(shū)里講陰影映射我第一遍看懂了原理第二遍看了代碼實(shí)現(xiàn)第三遍自己改了一個(gè)參數(shù)把陰影貼圖分辨率從1024改成2048觀察畫(huà)質(zhì)和性能的變化。這樣折騰一遍比單純讀十遍都管用。6.2 結(jié)合自己的項(xiàng)目邊讀邊改書(shū)里的例子是通用的但你的項(xiàng)目是具體的。我建議每讀一章就想想自己項(xiàng)目里有沒(méi)有對(duì)應(yīng)的場(chǎng)景。比如讀到物理碰撞就看看自己項(xiàng)目里的碰撞體設(shè)置有沒(méi)有問(wèn)題讀到AI就看看自己項(xiàng)目里的NPC是不是像個(gè)傻子。帶著問(wèn)題去讀收獲會(huì)大很多。我在讀導(dǎo)航網(wǎng)格那一章的時(shí)候正好項(xiàng)目里有個(gè)NPC卡在門(mén)口的問(wèn)題照著書(shū)里的思路檢查了Agent Radius和導(dǎo)航網(wǎng)格的烘焙參數(shù)果然找到了原因。這種“書(shū)里剛講完項(xiàng)目里就驗(yàn)證了”的體驗(yàn)比單純讀書(shū)要深刻得多。6.3 工具鏈那部分值得反復(fù)讀很多人讀引擎相關(guān)的書(shū)會(huì)跳過(guò)工具鏈部分覺(jué)得那是“打雜的活”。但我的經(jīng)驗(yàn)是工具鏈決定了團(tuán)隊(duì)的效率上限。一個(gè)項(xiàng)目如果工具鏈做得好美術(shù)和策劃能自己搞定大部分資源導(dǎo)入和配置工作程序就能騰出手來(lái)做核心玩法。如果工具鏈做得差程序天天幫美術(shù)導(dǎo)模型、幫策劃配表哪還有時(shí)間寫(xiě)代碼。書(shū)里工具鏈那一章我讀了四遍每一遍都有新的收獲。第一遍了解了資源管線的整體流程第二遍看懂了構(gòu)建系統(tǒng)的設(shè)計(jì)思路第三遍琢磨了調(diào)試工具的實(shí)現(xiàn)方式第四遍結(jié)合自己團(tuán)隊(duì)的情況做了改進(jìn)方案。如果你在團(tuán)隊(duì)里負(fù)責(zé)工具鏈這一章建議精讀。6.4 別指望一遍讀懂常讀常新這本書(shū)我讀了三遍第一遍大概懂了六成第二遍懂了八成第三遍才發(fā)現(xiàn)之前有些理解是錯(cuò)的。比如渲染順序那一章我第一遍以為“從后往前畫(huà)半透明”是絕對(duì)的第三遍才發(fā)現(xiàn)如果半透明物體之間沒(méi)有重疊順序其實(shí)無(wú)所謂引擎的排序只是為了處理重疊情況。所以我的建議是第一遍快速通讀不求甚解第二遍精讀邊讀邊做筆記第三遍帶著問(wèn)題讀把書(shū)里的知識(shí)和自己的經(jīng)驗(yàn)對(duì)照。每次讀都會(huì)有新的發(fā)現(xiàn)這大概就是經(jīng)典技術(shù)書(shū)的魅力。7. 最后聊幾句個(gè)人體會(huì)這本書(shū)最讓我佩服的地方是它把游戲引擎這個(gè)龐然大物拆解得非常清晰但又沒(méi)有失去整體感。很多技術(shù)書(shū)要么講得太淺看完只知道“有這么個(gè)東西”要么講得太深滿篇公式和代碼看完不知道有什么用。這本書(shū)在深度和可讀性之間找到了一個(gè)很好的平衡點(diǎn)。我在實(shí)際工作中遇到引擎相關(guān)的問(wèn)題時(shí)經(jīng)常會(huì)翻回這本書(shū)的對(duì)應(yīng)章節(jié)。比如有一次遇到一個(gè)渲染順序?qū)е碌漠?huà)面錯(cuò)誤翻到渲染那一章看到書(shū)里講的“不透明從前往后半透明從后往前”一下子就定位到了問(wèn)題。這種“書(shū)到用時(shí)方恨少翻到對(duì)應(yīng)章節(jié)剛剛好”的體驗(yàn)讓我覺(jué)得這本書(shū)值得放在手邊隨時(shí)查閱。如果你剛開(kāi)始學(xué)游戲開(kāi)發(fā)我建議先看渲染和物理那兩章因?yàn)檫@兩個(gè)是最直觀、最容易看到效果的。如果你已經(jīng)做了一段時(shí)間想提升項(xiàng)目的工程化水平那工具鏈和AI那兩章會(huì)更適合你。不管怎樣這本書(shū)值得你花時(shí)間慢慢啃啃完之后再回頭看自己做的項(xiàng)目很多之前不理解的現(xiàn)象都會(huì)豁然開(kāi)朗。