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

让理想飞

UF2022 的两篇讲座，再加上 The Machinery 引擎项目失败
结合过去两年笔者使用自研引擎的体验，其实有一部分是共通的



在这里插入图片描述

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

• 游戏技术（featurelist）越来愈大，越来越复杂
  
• 物理引擎太难用了，你必须是一个物理学博士
  
• 老代码，硬编码，屎山 legacy code
  
• 你有 50 个人，做游戏还是做引擎
  
• 毕业生更容易适应新引擎
  
• 专家先预研新功能，multiuser-edit，streaming  // 他们很在意资源制作流程
  

ue的一些开箱特性

• 光照渲染，lumen，naite
  
• 资源校验，validation  // 老引擎很难加
  
• virtual shadowmap，virtual texture
  
• VFX
  
• 跨平台，PC上对的，其他平台差不多对了
  

ue的问题

• 定制材质要改引擎源码，which 容易出错
  
• gameplay，大量迁移老代码（抛弃老代码的好时机） // 他们的 inventory 也烂的很 hhh
  
• 程序和策划之间的脚本要分层  // 我觉得非程序用蓝图就好
  

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

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

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

why UE

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

升级 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 解决了问题，开发了几个核心技术

• The Truth，ECS DB，统一数据模型
  
• 自研 ImGui
  

Machinery / Stingray 有一个 UE 没有做完（Beta0.2）的功能，就是多人协作，同时编辑一个场景，依赖于这套技术
<hr/>这些技术很好，原理思路清晰，最后也做出结果了，并迭代了两个引擎版本，但是引擎要获得商业上成功实在是太难了，用户不会为了 ECS，多人编辑，这一两个 feature 的优势（甚至不算太大的优势）去切到 Machinery
UE 就像一个庞然巨兽一样，可以把各种 feature 都移植集成到自己身上，就算多人编辑 UE 做到 80 分，Machinery 做到 90 分，用户也会选择 UE
总的来说，新游戏立项，如果项目游戏类型和 UE 能适配，自研引擎可能很难干得过 UE

若

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

UE有的。。

圣星空

是的，这个功能我其实两个引擎都没实践过，刚看了眼UE的MulitiUser-Edit还是Beta 0.2 版本，不清楚有多少坑；StingRay 的这套方案理论上是 OK 的，Machinery 又另起炉灶重写一遍，应该是可用的