※ 引述《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 -- https://store.steampowered.com/app/1274830/ 自製的獨立遊戲《自動混亂》開發快完工啦！ 如果對類 Rogue、雙搖桿射擊遊戲有興趣的話不妨看看 XD https://store.steampowered.com/app/1423670/ --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.251.130.70 (臺灣) ※ 文章網址: https://webptt.com/m.aspx?n=bbs/GameDesign/M.1684412656.A.BA4.html 最近因為一些因素也在碰這塊，其實有感受到 SRP 架構的立意良善與易用性 XD 可惜官方除了整天大改規格以外，根本沒多少官方資源在解釋運作方式，後來都看第三方 的解析才能理解。 ※ 編輯: dklassic (111.251.110.239 臺灣), 05/19/2023 12:29:43