Games104——引擎工具链基础

总览

工具链

用户到引擎架构图

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

复杂的工具

界面GUI

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

两种 GUI 实现方式：

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

设计模式Design Pattern

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

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），这是资产系统和工具链最核心的底层逻辑。

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

资产加载Deserialization

资产解析Parse

• 资产树状结构
  
• 树状结构在text和二进制文件里的形式：
  
• Endianness字节端序，不同端口规则还不一样，做游戏平台适配时需要注意
  

资产版本兼容性（Compatibility）

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

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

如何制作高鲁棒性的工具

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

Undo & Redo、Crash Recovery

Command：记录用户所有操作（分解为多个Command）并记录

Command的定义：UID是唯一、累加的，用于记录执行顺序

Command的3种主要操作：Add创建、Delete、Update

如何制作工具链

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

Schema

• Schema 结构的标准描述语言工具通用、可以生成标准ui；
• 比如圆定义为半径r，长方体定义为长宽高、曲线定义为key point等
• 可以数据继承
• 两种定义方式：

1. file：好定义；但需要代码生成器，可能有版本问题，同时无法定义api
2. code（UE）：可以包装function等，支持性好；但对鲁棒性要求高

引擎数据的3种view

• 硬盘Runtime中：二进制或者text格式；在乎加载和运算速度
• 内存中：二进制；在乎写入速度和内存占用
• 工具中用户：需要更可理解的界面和多样的编辑模式
  

所见即所得

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

• Stand-alone Tools：早期可以独立运行的工具。好处是工具开发简单，但是难以做到所见即所得。现在基本不用了。

• In Game Tools：直接在游戏引擎上做的工具。开发成本高，需要做复杂的ui，但完全in-game editing，对生产效率提升帮助巨大
  

• Play in Editor（PIE）：在编辑器里直接就能play（需要区分editor和play的数据，避免污染，但很难）或有PIE mode（类似沙盒，相当于做分身，更可靠）
  
  

可拓展性

将引擎作为一个平台，让用户可以用插件Plugin形式制作工具，比如unity商店。
那么引擎需要提供对应的 API ，比如增加按钮等，以增加引擎的可拓展性。

QA
工具链开发需要具备什么能力：对游戏制作和流程的基本理解（经验），软件工程能力、架构思维、设计师思维
工具链用web前端做的多不多：目前还不多，但随着h5越来越强大，未来有可能，因为底层逻辑很接近
协同编辑有没有很好的实现：基础理论已经成形，就是工程问题，5年内应该能解决

原文链接