【游戏编程扯淡精粹】自研引擎切 UE
UF2022 的两篇讲座，再加上 The Machinery 引擎项目失败
结合过去两年笔者使用自研引擎的体验，其实有一部分是共通的
Crystal Dynamics：如何从自研引擎转变到虚幻引擎5
- 游戏技术（featurelist）越来愈大，越来越复杂
- 物理引擎太难用了，你必须是一个物理学博士
- 老代码，硬编码，屎山 legacy code
- 你有 50 个人，做游戏还是做引擎
- 毕业生更容易适应新引擎
- 专家先预研新功能，multiuser-edit，streaming // 他们很在意资源制作流程
- ue的一些开箱特性
a. 光照渲染，lumen，naite
b. 资源校验，validation // 老引擎很难加
c. virtual shadowmap，virtual texture
d. VFX
e. 跨平台，PC上对的，其他平台差不多对了 - ue的问题
a. 定制材质要改引擎源码，which 容易出错
b. gameplay，大量迁移老代码（抛弃老代码的好时机） // 他们的 inventory 也烂的很 hhh
c. 程序和策划之间的脚本要分层 // 我觉得非程序用蓝图就好
从Liquid到虚幻引擎：我们为何不再选择自研引擎
11bit，frostpunk2 开始，本来升级了 liquid2，还是迁移 ue 了
liquid
- 程序员很开心，完全可以handle
- 美术很糟心，迭代太慢了
why UE
- 最小化项目风险，我们得目标是做游戏，不是技术
- 做研究很好，做游戏更加重要
- 搞引擎导致大量扩招引擎工程师，成本很高
- 人才流失 // 上面说到程序员容易 handle，但是人迭代了几波，新人就搞不明白屎山代码了，这个优势就变成劣势
- 更容易美术外包
升级 liquid2，ECS，可视化编程，这些工具很好，但是跑偏了
liquid 主要问题是业务风险
Writing Tools Faster
The Machinery，开发者这样的引擎经验，堪称完美，两人两年从零搭建
但是为什么失败了？
本篇是 Machinery 在 GDC 上分享如何做引擎编辑器 UI，笔者只节选一部分
问题小结
- 频繁切技术栈
- 花很长时间作工具
why 频繁切技术栈的理由
- Bad decision
- Tech 过时，继续开发非常痛苦
why 花很长时间作工具
- 所有东西都需要UI，UI管线（设计，代码，测试）
- UI特性：Undo, copy/paste, serialize, drag-and-drop
- Deep tech stack 导致难以理解，难以查bug，非负责人更加难理解
最后 Machinery 解决了问题，开发了几个核心技术
- The Truth，ECS DB，统一数据模型
- 自研 ImGui
Machinery / Stingray 有一个 UE 没有的功能，就是多人协作，同时编辑一个场景，依赖于这套技术
