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