GAMES104：13 引擎工具链基础-学习笔记

news2024/11/14 14:40:58

一，工具链

用户到引擎架构图
工具链是衔接不同岗位、软件之间的桥梁，比如美术与技术，策划与美术，美术软件与引擎本身等，有Animation、UI、Mesh、Shader、Logical 、Level Editor等等。一般商业级引擎里的工具链代码量是超过引擎Runtime的，可见工具链非常重要（但大家都不愿意干工具呢··）。

图形用户界面GUI(Graphics User Interface)其实就是工具的操作界面

两种 GUI 实现方式：
1. Immediate Mode：每次绘制时由游戏逻辑直接发出绘图命令。在帧之间不会存储场景模型，需要不间断发出指令。好处是直接、简单、快，坏处是扩展性差、更多的工作给到游戏逻辑，压力大。
2. Retain Mode：图形库将场景的模型存储在内存中。如果需要绘制，图形库会将场景转换为一组绘图命令。如果不需要更新，就不用发出命令。好处是扩展性强，性能高、可维护性高，大部分游戏工具gui用这种，比如UE UMG、QT GUI等。

当一个工具由几十上百个功能时，就需要遵循设计模式来规划了。

MVC：Model（管理应用数据）->View（信息归总表）->Controller（总结指令）->，路径是单向的，原始数据不会被弄脏。最经典，变种也最多的设计模式。
MVP：Presenter从model里取数据呈现给view，然后从view的用户交互里反馈给model。超大型软件工程中的unit test（单元测试）适用，代价是presenter会比较臃肿。
MVVM：与MVP相似但是用ViewModel代替Presenter，执行责任上用设计师代替开发人员，完全把view和model区分开。现代最常用，好处是独立开发、方便测试和复用，坏处是不太好迁移、debug困难、对简单ui需要overkill了。
在游戏引擎工具链中，需要有非常强的工程可扩展性，一定不要自己造轮子，选择最成熟的结构和方案。

序列化（Serialization）和反序列化(Deserialization)其实就是save 和load，将游戏中的一些对象、数据转化成二进制块方便存储，也与后期的Network工作相关
存储形式：
1. Text File：TXT、Json、YAML、XML。好处是易读，容易debug。比如unity用subset of YAML，Cryengine用XML或Json。引擎推荐首先支持此类
2. Binary File：二进制，例如：UAsset（Unreal）、FBX Binary、unity Runtime等。好处是存储容量小，并且容易加密，安全性高。比如FBX Binary比FBX text占用小很多，同时还省去了语义的兼容过滤处理，总体加载速度能快10倍。因此上线产品一般用这种形式。

在游戏中，很多东西会重复出现，为了节省内存，我们需要资产引用：只存储引用，通过引用实例化（Instance）重复对象（Prefab），这是资产系统和工具链最核心的底层逻辑。

对象实例化变体（Prefab与Prefab Variant）
1. 通过复制的方式构建变体：复制原先数据并修改，但是比较低效并且丧失关联性。
2. 通过数据继承（Data Inheritance）的方式构建变体：继承原数据并override。

很多软件都只做到向下兼容，那怎么做到向上兼容？—在元宇宙、分布式部署这类场景里非常需要

Unreal ：给资产添加版本号，对于高版本新增的数据类型，读取时添加这些类型的Default Value，对于新版本删除的数据类型，不进行读取。----老师认为这方法不好
Google ：给数据的每一个属性定义 UID，并且相对于上一个属性的 UID 是单调递增的；读取时UID不认识就跳过，没有的用默认值。

鲁棒性（Robust）是指一个系统在面对错误输入、异常情况或意外事件时，仍能保持稳定性和可靠性的能力。

各个工具如Animation、UI、Mesh、Shader、Logical 、Level Editor，如果全部单独写的话，那将没有任何扩展性。我们需要找到这些工具通用的部分，因为任何复杂的结构都可以由简单的building blocks构成，我们需要一个标准的语言去描述它们：Schema。

Schema 结构的标准描述语言工具通用、可以生成标准ui；
比如圆定义为半径r，长方体定义为长宽高、曲线定义为key point等
可以数据继承
两种定义方式：
1. file：好定义；但需要代码生成器，可能有版本问题，同时无法定义api
2. code（UE）：可以包装function等，支持性好；但对鲁棒性要求高

工具体系的核心精神：所见即所得，即工具是什么样运行时就是什么样（与运行环境配置一致）

Stand-alone Tools：早期可以独立运行的工具。好处是工具开发简单，但是难以做到所见即所得。现在基本不用了。
In Game Tools：直接在游戏引擎上做的工具。开发成本高，需要做复杂的ui，但完全in-game editing，对生产效率提升帮助巨大
Play in Editor（PIE）：在编辑器里直接就能play（需要区分editor和play的数据，避免污染，但很难）或有PIE mode（类似沙盒，相当于做分身，更可靠）