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

文章目录

• 一，工具链

• 二，复杂的工具

• • [2.1 界面GUI](#2.1 界面GUI)
  • [2.2 设计模式Design Pattern](#2.2 设计模式Design Pattern)
  • [2.3 数据的加载和存储](#2.3 数据的加载和存储)
  • [2.4 资产引用](#2.4 资产引用)

• 三，资产加载Deserialization

• • [3.1 资产解析Parse](#3.1 资产解析Parse)
  • [3.2 资产版本兼容性（Compatibility）](#3.2 资产版本兼容性（Compatibility）)

• [四， 如何制作高鲁棒性的工具](#四， 如何制作高鲁棒性的工具)

• • [4.1 Undo & Redo、Crash Recovery](#4.1 Undo & Redo、Crash Recovery)

• [五， 如何制作工具链](#五， 如何制作工具链)

• • [5.1 Schema](#5.1 Schema)
  • [5.2 引擎数据的3种view](#5.2 引擎数据的3种view)

• [六， 所见即所得](#六， 所见即所得)

• [七， 可拓展性](#七， 可拓展性)

• QA

• 总览
  

---

一，工具链

• 用户到引擎架构图
  

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

二，复杂的工具

2.1 界面GUI

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

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

2.2 设计模式Design Pattern

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

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

2.3 数据的加载和存储

• 序列化（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倍。因此上线产品一般用这种形式。

2.4 资产引用

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

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

三，资产加载Deserialization

3.1 资产解析Parse

• 资产树状结构
  

• 树状结构在text和二进制文件里的形式：
  

• Endianness字节端序，不同端口规则还不一样，做游戏平台适配时需要注意
  

3.2 资产版本兼容性（Compatibility）

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

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

四， 如何制作高鲁棒性的工具

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

4.1 Undo & Redo、Crash Recovery

• Command：记录用户所有操作（分解为多个Command）并记录
  
• Command的定义：UID是唯一、累加的，用于记录执行顺序
  
• Command的3种主要操作：Add创建、Delete、Update

五， 如何制作工具链

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

5.1 Schema

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

5.2 引擎数据的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年内应该能解决