※ 引述《iLeyaSin365 (365)》之銘言：
: 隨便問個問題，
: 因為之前看到有大大自己開發遊戲引擎。
: 覺得很厲害，自己一輩子應該不會開發出什麼引擎。
: 不過也是有看到b站上有轉貼的簡易遊戲引擎開發
本來我也是這樣想，不過最近意外自製了一個小引擎。
所以覺得好像可以更好地回答這個命題了。
就像 kuku321 提到的，開發引擎不需要真的把商業引擎的完整功能組做出來。
實際上就是針對自己的遊戲需求實作自己要的功能組，多餘的都可以不用管。
: 想請問：
: 練習自己開發遊戲引擎，
: 會在使用引擎（例如虛幻引擎）上
: 學到什麼嗎？
: 或者說像是對於虛幻引擎的c++使用
: 有何增益
我的遊戲開發簡易歷程大概是：
因為沒遊戲開發知識，所以選了 Unity 開場
→試著用 URP 卻發現 URP 功能組殘缺
→退回去使用 Built-in RP
→理解了 Unity 頂多算有編輯器，算不上有關卡編輯器
→自己寫關卡編輯器與生成機制
→發現 Unity 的介面系統不可靠
→自己寫一個介面系統
→發現 Unity 物理判定的不可靠
→選擇性使用，特定情境下自己寫物理判定
→發現 NavMesh Agent 效能不夠好
→自己寫 Agent
→發現 Unity 的渲染不可靠
→自己寫渲染流程（←原本在這裡）
經過了這一連串的事情後，其實已經快只把 Unity 當作一個......整合介面了。
隱約醞釀有一種「是不是差一步就該乾脆寫自己的引擎」的感覺 XD
不過實際上至少考慮多平台移植就依然可以接受繼續使用 Unity，不過已經也已經很預備
跳槽 Godot 了。
經過這一長串旅程之後，我得到了一個啟發，就是：
終究會需要走到得看懂輪子原理或者造輪子的這步
這個成本當然可以轉嫁出去，例如說轉嫁給一個專家、一個套件、一個商業引擎。
但其實也就是要接受中間發生問題時，可能會出現不在你能力所及範圍內的慘狀。
譬如說近幾年嚴重荼毒 PC 遊戲界的 PSO Stutter，UE4 內建，開發者幾乎無能為力。
總之最近意外因為一些理由寫了一個小引擎，大致重製了我目前的遊戲的五成功能性。
用 Javascript 寫效能當然普普，渲染交給 Three.js 處理。
說到底其實也不過就寫一些這樣的更新循環：
https://imgur.com/u9jGzov
當然沒啥特別的功能組，也距離完全重現原本遊戲的功能組還很遠。
但其實也就在幾天之內已經可以完成了原本仰賴 Unity 開發的遊戲的劣化版。
甚至因為沒有任何包袱（或說任何架構都得自己刻），就讓我順手直接實作了 ECS，應該
也算稍微抵銷了點 JS 的效能低落。
當我已知自己要什麼功能時，就可以輕易寫出只滿足這些功能的輕便架構，其他多餘的東
西都可以直接無視。結果而論效果不錯，不需要忍受 Unity 開專案超慢的 Import，不需
要等 Unity 官方修好問題，因為有問題就是你自己造成的，立刻自己修起來。
當然我還是會繼續用 Unity 開發完手上的遊戲，但這樣小測試之後，我更確信說：
－自己寫一個引擎其實很簡單，畢竟不需要重現商業引擎的所有功能
－無論如何都是成本取捨問題，沒有絕對的優劣
－商業引擎的問題多半是為了泛用性、易用性造成的
大概就是總之這是我的個人體悟，簡單提供作為參考兼紀錄我現在的想法 XD