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