107 lines
6.2 KiB
Markdown
107 lines
6.2 KiB
Markdown
|
---
|
|||
|
|
title: 打包项目的Debug方法
|
|||
|
|
date: 2020-07-07 13:49:28
|
|||
|
|
excerpt:
|
|||
|
|
tags:
|
|||
|
|
rating: ⭐
|
|||
|
|
---
|
|||
|
|
# 蓝图深入探讨Blueprints In-depth学习笔记
|
|||
|
|
就如大钊所说的，这个视频不管程序还是美术都值得学习一下。
|
|||
|
|
## 蓝图开销
|
|||
|
|
蓝图主要开销影响：
|
|||
|
|
1. 蓝图的节点数是一个较为影响性能的因素，而不是节点所执行的逻辑影响。所以在蓝图中执行循环操作会非常影响性能（执行节点本身的逻辑本质上还是c++）
|
|||
|
|
2. 执行遍历Actor（Get All Actor Of Class）也比较消耗资源。避免总是在蓝图中使用，可以提前把对象的引用保存下来。
|
|||
|
|
3. tick
|
|||
|
|
|
|||
|
|
90%的蓝图是不需要开启tick的，你可以在项目设置中关闭Can Blueprint Tick By Default。定时器与事件几乎可以解决所有问题。
|
|||
|
|
|
|||
|
|
检测蓝图tick中性能消耗最大的因素，将这个因素放入计时器中。但是视觉效果的更新就不适合了，所以这部分可能还是使用c++比较好。（例如海洋系统）
|
|||
|
|
|
|||
|
|
使用材质来实现一些简单动画可以节约CPU资源，效率会高一些。尽量将一些效果写进材质中，这样可以简化蓝图，提高效率。
|
|||
|
|
|
|||
|
|
## 蓝图debuger与可视化日志
|
|||
|
|
蓝图debug(可以获取断点中的变量数据)
|
|||
|
|
你需要在需要监视的节点变量（每个节点上的引脚）上右键，选择监视这个变量，之后就可以在断点触发后，在蓝图debuger中查看变量数据。
|
|||
|
|
|
|||
|
|
可视化日志：你需要在关卡开始时运行Enable Vislog Recording,之后就可以通过使用可视化日志指令：Vislog Text、Vislog Box Shape、Vislog Location、Vislog Segment。
|
|||
|
|
之后再启动游戏，可视化日志就会自动记录。
|
|||
|
|
|
|||
|
|
作者建议使用这个东西来记录AI运行情况。
|
|||
|
|
|
|||
|
|
## 查看所有使用tick的actor
|
|||
|
|
console中输入dumpticks指令。
|
|||
|
|
|
|||
|
|
## 内存与Asset载入
|
|||
|
|
不要在蓝图进行多重蓝图或者引用巨量资源，防止引擎在加载该蓝图时加载太多的Asset。
|
|||
|
|
|
|||
|
|
这里作者给出的建议是：
|
|||
|
|
1. 使用C++定义关键逻辑的基类。
|
|||
|
|
2. 创建一个继承该基类的蓝图类作为蓝图父类。
|
|||
|
|
3. 创建另一个蓝图类继承上一个蓝图父类。（相关的Asset会在这个层级的蓝图子类中引用）
|
|||
|
|
|
|||
|
|
PS.这样的架构还有一个好处，那就是你可以随时将蓝图中的逻辑移植到c++。
|
|||
|
|
|
|||
|
|
如果你调用了蓝图函数库中任意一个函数，那么整合蓝图库都会被加载，如果蓝图库还引用了其他资源，那么很可能整个游戏资源都被加载。所以一个正确的方法就是不要创建用于专门加载某一Asset函数来加载函数，而是使用通用函数配合变量的方式来进行指定资源的加载。
|
|||
|
|
|
|||
|
|
PS.使用GameMode来区分菜单操作逻辑与游戏操作逻辑，一个好处就是不用来回引用。（GameMode_Game与GameMode_Menu）
|
|||
|
|
|
|||
|
|
对于资源强引用，可以使用异步加载。此时资源引用器就会将其显示为粉色，意为弱引用。
|
|||
|
|
|
|||
|
|
你可以在设置，将bRecompileOnLoad设置为false（蓝图、关卡蓝图、动画蓝图）以提高打开编辑器的速度。
|
|||
|
|
|
|||
|
|
当然有资源加载就有资源回收，当物体量多时，回收资源会出现卡顿，此时你可以在项目设置中修改资源回收时间（Time Between puring Pending Kill Objects），这对于制作电影项目（非游戏项目）会比较好。对于巨量物体你可以在蓝图中勾选群集功能（Can Be in Cluster），当然最好的方法还是使用c++。
|
|||
|
|
|
|||
|
|
## 蓝图编译时间
|
|||
|
|
1. 蓝图中的蓝图节点数
|
|||
|
|
2. 蓝图中的类型转换以及其他类型引用
|
|||
|
|
3. 循环引用
|
|||
|
|
|
|||
|
|
如果类型转换的对象有这复杂的循环引用（比如各个蓝图类互相引用各自的函数），那么一个类型转换将会载入所有与之关联的蓝图类。这可以说是相当恐怖的。
|
|||
|
|
|
|||
|
|
想要加快速度可以使用：
|
|||
|
|
1. 将逻辑封装到蓝图函数中，可以减少编译时间。
|
|||
|
|
2. 将逻辑按照功能进行分类，再使用蓝图或者c++将其分离成各种Actor、子Actor、Component。
|
|||
|
|
3. 对于类型转换需要进行合理的管理。（比如将带有转换的逻辑使用c++封装成函数、使用蓝图接口、GameplayTag等）
|
|||
|
|
|
|||
|
|
## 蓝图接口
|
|||
|
|
使用流程：
|
|||
|
|
1. 创建蓝图接口Asset，并设置接口参数。
|
|||
|
|
2. 在需要编写逻辑的蓝图中绑定接口，并且实现接口逻辑。
|
|||
|
|
3. 在需要调用的蓝图中调用这个接口就行了。
|
|||
|
|
|
|||
|
|
使用蓝图接口的好处就在于，你不需要将对象进行类型转换。你可以使用Dose Implement Interface节点来判断是否实现某个蓝图接口。
|
|||
|
|
|
|||
|
|
## 使用GameplayTag的意义
|
|||
|
|
使用标签可以直接对标签进行判断，避免对象类型转化。
|
|||
|
|
|
|||
|
|
比如给Actor物体绑定一个CanPickup标签，在之后直接判断出来。
|
|||
|
|
|
|||
|
|
## Show 3D Widget
|
|||
|
|
蓝图中一些变量可以开启Show 3D Widget，方便调节数值。
|
|||
|
|
|
|||
|
|
## 自动测试框架
|
|||
|
|
### 使用蓝图进行测试
|
|||
|
|
在蓝图使用自动测试框架，其测试用的蓝图类需要继承Functional Test类。
|
|||
|
|
|
|||
|
|
Prepare Test事件：用于在测试前生成所需要的Actor与数据。
|
|||
|
|
Start Test事件：开始进行测试。
|
|||
|
|
|
|||
|
|
### 使用c++进行测试
|
|||
|
|
c++自动测试的视频我就找到了：https://www.bilibili.com/video/av79617236
|
|||
|
|
以下是学习该视频的笔记：
|
|||
|
|
|
|||
|
|
想要编写自己的测试类可以继承FAutomationTestBase类，并重写RunTest函数，之后系统会自动向自动测试框架注册。使用IMPLEMENT_SIMPLE_AUTOMATION_TEST宏标记为简单测试类型。以下是一段案例代码：
|
|||
|
|
|
|||
|
|
|
|||
|
|
使用IMPLEMENT_COMPLEX_AUTOMATION_TEST宏标记为复杂测试类型。以下是一段案例代码：
|
|||
|
|
|
|||
|
|
看得出可以通过这个方法添加子测试。
|
|||
|
|
|
|||
|
|
*启动自动调试：*
|
|||
|
|
可以使用Ue4的Session Frontend，也可以使用TeamCity，作者的团队也编写了一个测试工具进行工作。
|
|||
|
|
|
|||
|
|
#### 地图测试
|
|||
|
|
11:30处，作者展示一个小案例。大致步骤为：使用GetTest遍历地图文件夹下所有level。之后分别对各个level进行相关测试。比如模拟玩家操作等。
|
|||
|
|
|
|||
|
|
#### 项目经验
|
|||
|
|
23：00左右作者开始介绍项目经验，这个流程较为复杂，推荐大团队使用，这个直接去看视频吧。
|