為甚麼要用自研引擎？

每當提到「自研遊戲引擎」，第一個被問的問題永遠是：
「為甚麼不用 Unity 或 Unreal？」

這是個合理且必要的追問。在商業引擎生態如此成熟的今天，選擇從零開始， 確實是一條「不合時宜」的路。但正是這條路，讓我對遊戲開發有了最深的理解。

一、完全掌控每一行程式碼

商業引擎是黑盒子。當 Unity 的記憶體暴增、當 Unreal 的 GC 卡頓發生時， 你能做的只有「等待官方修復」或「在論壇上尋找 workaround」。

自研引擎沒有黑盒子。 每一行程式碼都是你寫的，每一個 bug 都是你可以追溯的。 效能瓶頸？打開 Profiler，追到最底層的 Vulkan API call。 渲染異常？從 Swapchain 重建一路查到 Shader 編譯， 沒有一層「中間件」是你無法穿透的。

二、極致精簡，極致效能

Unity 一個空場景的匯出大小是 15MB+。Unreal 空專案接近 200MB。

Nima_Engine 的整個執行檔 不到 5MB。加上所有資源素材（JSON 設定、紋理、音效）， 一個完整遊戲的打包體積是商業引擎的十分之一。

這不單是儲存空間的差異。更小的二進位意味著：

🔹 更快的啟動速度 — 沒有幾百個 DLL 要載入
🔹 更少的記憶體佔用 — 只分配你真正需要的
🔹 更短的編譯時間 — 全專案編譯以秒計，不是以小時計
🔹 更清晰的效能模型 — 沒有看不見的 middleware 在背景消耗資源

三、真正的資料驅動設計

Nima_Engine 的核心設計原則是 JSON 資料驅動：場景佈局、角色數值、 武器屬性、合成配方、商店價格、成就條件——全部以 JSON 定義。

這意味著可以在不接觸 C++ 程式碼、不重新編譯的情況下， 反覆調整遊戲平衡。修改一個武器數值？編輯 JSON → 熱重載 → 立即看到效果。

商業引擎雖然也有 ScriptableObject 或 DataTable，但它們的「資料驅動」 依然綁定在引擎框架之內。Nima_Engine 則從第一天就將「資料」與「邏輯」徹底分離。

四、ECS 架構的先天優勢

商業引擎大多基於 GameObject / Actor 的 OOP 繼承體系。 一個「會移動的敵人」可能繼承了五層類別，每一層都攜帶著你不知道的包袱。

Nima_Engine 採用 自研 ECS（Entity-Component-System） 架構：

🔹 Entity 只是一個 uint32_t ID，零開銷
🔹 Component 是純資料，沒有方法、沒有繼承
🔹 System 只處理擁有特定 Component 組合的 Entity
🔹 基於 Sparse Set 的 O(1) 元件存取，Archetype 分組確保快取友好
🔹 內建平行化系統排程，充分利用多核心

這不是「另一種寫法」，而是從根本上解決了 OOP 遊戲開發中最常見的 類別爆炸、菱形繼承、虛擬函數開銷等問題。

五、學習深度無法被取代

使用 Unity，你會學到「如何用 Unity 做遊戲」。
使用 Unreal，你會學到「如何用 Unreal 做遊戲」。

自研引擎，你學到的是「遊戲引擎是如何運作的」。

從 Vulkan 的 Swapchain 管理到 GLSL Shader 編寫，從 ECS 記憶體佈局到多執行緒排程， 從資產 GUID 依賴圖譜到 JSON 序列化——這些知識是平台無關的， 是你在任何引擎、任何專案中都能帶走的核心能力。

作為畢業製作，這本身就是最好的學習成果展示。

三者比較

結語：不是反商業，是選擇適合

我不否認 Unity 和 Unreal 的價值——它們讓無數開發者實現了創意， 也是業界標準。但對於一個 以 2D 塔防為核心、追求極致效能、 並且希望徹底理解遊戲引擎運作原理 的畢業專案來說， 自研引擎是最適合的選擇。