※ 引述《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/cn.aspx?n=bbs/GameDesign/M.1684412656.A.BA4.html 最近因为一些因素也在碰这块，其实有感受到 SRP 架构的立意良善与易用性 XD 可惜官方除了整天大改规格以外，根本没多少官方资源在解释运作方式，後来都看第三方 的解析才能理解。 ※ 编辑: dklassic (111.251.110.239 台湾), 05/19/2023 12:29:43