【游戏编程扯淡精粹】自研引擎切 UE

【游戏编程扯淡精粹】自研引擎切 UE

UF2022 的两篇讲座，再加上 The Machinery 引擎项目失败

结合过去两年笔者使用自研引擎的体验，其实有一部分是共通的

Crystal Dynamics：如何从自研引擎转变到虚幻引擎5

1. 游戏技术（featurelist）越来愈大，越来越复杂
2. 物理引擎太难用了，你必须是一个物理学博士
3. 老代码，硬编码，屎山 legacy code
4. 你有 50 个人，做游戏还是做引擎
5. 毕业生更容易适应新引擎
6. 专家先预研新功能，multiuser-edit，streaming // 他们很在意资源制作流程
7. ue的一些开箱特性
   a. 光照渲染，lumen，naite
   b. 资源校验，validation // 老引擎很难加
   c. virtual shadowmap，virtual texture
   d. VFX
   e. 跨平台，PC上对的，其他平台差不多对了
8. ue的问题
   a. 定制材质要改引擎源码，which 容易出错
   b. gameplay，大量迁移老代码（抛弃老代码的好时机） // 他们的 inventory 也烂的很 hhh
   c. 程序和策划之间的脚本要分层 // 我觉得非程序用蓝图就好

从Liquid到虚幻引擎：我们为何不再选择自研引擎

11bit，frostpunk2 开始，本来升级了 liquid2，还是迁移 ue 了

liquid

1. 程序员很开心，完全可以handle
2. 美术很糟心，迭代太慢了

why UE

1. 最小化项目风险，我们得目标是做游戏，不是技术
2. 做研究很好，做游戏更加重要
3. 搞引擎导致大量扩招引擎工程师，成本很高
4. 人才流失 // 上面说到程序员容易 handle，但是人迭代了几波，新人就搞不明白屎山代码了，这个优势就变成劣势
5. 更容易美术外包

升级 liquid2，ECS，可视化编程，这些工具很好，但是跑偏了

liquid 主要问题是业务风险

Writing Tools Faster

The Machinery，开发者这样的引擎经验，堪称完美，两人两年从零搭建

但是为什么失败了？

本篇是 Machinery 在 GDC 上分享如何做引擎编辑器 UI，笔者只节选一部分

问题小结

1. 频繁切技术栈
2. 花很长时间作工具

why 频繁切技术栈的理由

1. Bad decision
2. Tech 过时，继续开发非常痛苦

why 花很长时间作工具

1. 所有东西都需要UI，UI管线（设计，代码，测试）
2. UI特性：Undo, copy/paste, serialize, drag-and-drop
3. Deep tech stack 导致难以理解，难以查bug，非负责人更加难理解

最后 Machinery 解决了问题，开发了几个核心技术

1. The Truth，ECS DB，统一数据模型
2. 自研 ImGui

Machinery / Stingray 有一个 UE 没有的功能，就是多人协作，同时编辑一个场景，依赖于这套技术