※ 引述《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