各位盒友好久不見！ 這兩個月沒摸魚，而是閉關手搓了一個 2D遊戲引擎（造輪子真好玩） 的核心部分。今天不搞抽象的，純技術向，帶大家看看遊戲背後的“發動機”是怎麼運作的。
相信大家都玩過《黑神話》《艾爾登法環》這類神作，但3D引擎太複雜（我也不會寫）咱們不講，咱們從更簡單的 2D引擎切入，用最直白的語言講清楚——遊戲到底是怎麼跑起來的？
想象你玩《空洞騎士》：角色移動、怪物攻擊、畫面渲染、音效播放……這些看似獨立的操作，其實全靠引擎在後臺協調。類比汽車：引擎就像發動機，遊戲邏輯是油門，渲染是車輪，物理系統是懸掛——缺一不可。什麼！你說你不會開車？沒喫過豬肉總見過豬跑吧
不過這麼說是有道理的，首先我們作爲人類作爲感官動物最直覺的就是看到畫面在變換，對於車輛你看到輪子在轉動肯定是第一反應是這輛車在動，那麼是什麼讓我們的“車”動起來的呢？毫無疑問是油門噠！你只需要給一腳油門，“車子”就神奇的動起來了，聰明的你肯定能想到是踩油門這動作告訴了“發動機”：“死機！快動啊！快動啊！”，然後“發動機”又去問“懸掛”系統：“這能跑嗎？怎麼跑呀？跑到哪？”，當“發動機”獲取到懸掛系統的回覆後最終傳給“輪子”：“你轉xxx圈，角度xxx”，這樣一套流程就下來車輛就完成了一個小的週期，隨後往復，就形成連貫的行駛，然後你就能倒車入庫，半坡起步啦！（有錯誤請指出，也不是很懂車輛結構）
不過呢現實中車輛是機械結構是耦合的，聯動的，在遊戲裏呢各個系統一般都被設計爲各幹各的，這被稱爲解耦，對於耦合系統呢這個很直觀很符合直覺的設計不過呢有個非常嚴重的問題：那就是當我一個零件損壞了依賴此零件的一切結構都直接gg了，而且呢動一發而牽動全身，有過修車經驗的小夥伴都知道發動機壞了還需要調教變速箱吧，而解耦系統呢，就是爲了規避耦合系統的缺點，不過呢各個系統都是獨立的，要怎麼樣才能溝通各個系統呢？
相信聰明的你也能想到：這不很簡單嗎？這不就和電話通信一樣嘛，撥打電話時想基站發送信號：“我要給xxx打電話”，然後基站協調一下經過多個交換機就爲你接通好了，不過有時候呢對方不想理你直接給你掛了。基於這個我們就可以實現一箇中樞，多個節點的結構，這樣我只要知道對方給我電話號碼，我就能聯繫上他了，如果要發生直接的對話，我首先得知道對面的位置吧，然後咱倆約個時間來見一面來談一談，這樣但凡地址時間變一下，我就被放鴿子了。不過也能看出解耦系統的弊端，原來明明可以直接傳輸消息，好比你和你朋友面對面可以直接交談，但是呢非要用打電話交流，這樣就會有中間商了，傳輸效率會比直接略低一點，而且很考驗對中樞的設計。一個不小心延遲就高到起飛了。
咳咳扯遠了，回到正題，我爲什麼要寫遊戲引擎呢？現成的unity，godot，ue這些引擎不香嗎？幹嘛自己寫？首先寫點個人原因，在兩年前就有這個企劃了，我艹！寫一個遊戲引擎，好酷（那時候還是高中生，比較中二）！不過就我個人而言，雖然自己寫多半都會中道崩殂，放棄。不過只要寫了就會對遊戲開發有幫助，對現代引擎/軟件架構更瞭解，也能對遊戲mod開發有更深的理解。像我我在之前寫了四五次了但是都放棄了，完成度遠遠不如這次，都是因爲耦合度太高了根本無法擴展，就不了了之了，不過呢還是能從中學到不少知識的。
到這裏我們導論部分結束了，最後貼一下我的引擎目前的成果：腳本系統（.net 9)，物理系統，渲染系統，資源管理系統（仿照的unity的meta），這四個大模塊已經實現，然後預製體，場景這些內容也已經過測試，功能正常，性能雖然不是一流但也差強人意（圖4爲性能測試 ：1w實體動態剛體的連續碰撞）。
下一期預告：如何設計一個燒燒的架構
喜歡的hym可以點個關注哦～
更多遊戲資訊請關註：電玩幫遊戲資訊專區
電玩幫圖文攻略 www.vgover.com
