m0_51776409的博客

灵感来源于MStudio老师的麦田物语教程中的ItemEditor编辑器扩展的很方便，在项目中但是不够通用（需要在脚本中一个个数据绑定和回调）其实左边的ListView可以保留，右边直接用Unity默认的Inspector绘制就好了（需要用到IMGUIContainer组件），随后写好create asset和delete asset的对应方法，这样就可以管理不同的so和prefab资产。

在前面两个章节中，我们实现了两个部分的内容：Runtime部分的节点逻辑、UI Toolkit绘制Editor UI。这一章节将会用到GraphView框架，完成我们制作的事件行为树剩下的所有内容。 GraphView是Unity内置的节点绘制系统，实际上Unity里内置的Visual Scripting(可视化脚本编辑)，URP中的ShaderGraph，都是GraphView制作。GraphView也属于UI Toolkit的一部分。在Unity 2021中属于Experimental

UI Toolkit是unity推出的一套全新UI系统。对比传统的GUI系统有着一套全新的工作流。在Unity 2021版本后已被内嵌到默认的编辑器中了。使用UI Toolkit可以很方便的构建属于自己的UI工具。在本章节中使用的是Editor UI的制作。在资源窗口右键，在Create->UI Toolkit->Editor Window中先创建我们需要的Asset。可以看到一个在UI Toolkit中的UI主要有三个模块组成：UXML，USS，C#。

​本文将开始介绍Runtime部分的事件节点逻辑。在本框架中，因为Grapview的节点图属于Editor部分，在游戏运行时是不会被加载进来的。因此首先我们需要一个离开节点图，也可以在游戏实时运行中执行逻辑的节点结构。文章涉及的事件触发思想其实已经在我之前写过的一篇文章中了，也可以算作之前思想的延续。这种方式因为直接使用了父子游戏物品作为组织方式，当大规模使用起来还是有点约束，因为触发器节点和事件节点形成的是一对一的关系，子物品也只能按照顺序执行事件下去，当需要处理一些分支/循环逻辑的时候就不太方便了，而

在自己做的比赛项目中，在初期的游戏系统部分完成之后，剩下的内容就是搭建游戏逻辑了。特别是在剧情解密游戏中，搭建过程就是跟着策划流程文档拼图游戏。之前有些过几篇关于设计模式和框架的文章，其实目标也是将一些可复用的逻辑抽象出来使用，优化制作管线和提高效率。因此便想到了做一个可视化的节点界面工具出来，方便在长期项目中策划同学也能参与进来编写游戏逻辑，减轻程序方面的负担。

项目中有设计点需要使用画笔的功能，已经做好了根据鼠标位置生成LineRenderer线段功能，但出现了一个问题：画板的界面是在Canvas UI层，但是LineRenderer的位置在世界空间中。可以先调整LineRenderer图层，我们在场景中新建一个摄像机，用于专门去渲染Line Renderer,并将摄像机内容输出到一个纹理上。然后在ui里新建RawImage，调整位置拖入纹理，就可以看到这个线段了。

在制作游戏中需要管理各种各样的项目资源，其中游戏中的剧情文字也是一种需要管理的资源。自己刚开始接触游戏开发的时候，第一次看MStudio里面的对话系统教学，只讲了怎么写脚本同步UI的设置，并没有讲有什么方式去管理这些对话数据，视频里拿的是txt来演示存储对话数据，导致我制作的第一个游戏也是那txt来写的，一个对话就是一个txt，管理起来肯定是不方便的。如何存储文字数据呢？这时候就可以使用Excel表格了，让策划在表格中编写完数据后我们就可以一键导入成ScriptableObject，有需要再编辑是也可以导出

那只能走走别的方向了，仔细想想，原来的shader也确实不太完美，因为我们要的是整个画面的黑白，而上面的shader则需要给每个场景物品都安装这个shader跑计算的话，无疑是降低了性能和扩展性的。我们可以放弃if节点，改用lerp在两个色域中做插值，就可以优化渐变效果，插值需要一个0-1的参数，我们选择使用“Saturate”节点，这个节点可以将一个浮点值映射到[0,1]的范围内，即输入大于1时=1，输入小于0时等于0，然后将结果连接到Lerp节点就可以了。这样我们这个效果就成功实现了。

当游戏规模开始大时，为了制作游戏后期的维护性，就可以考虑做资源管理和编辑器扩展了。一是可以集成一些制作流程，省去一些重复操作的步骤，二是更方便项目数据的规范和管理性。今天来分享一下如何在unity中做编辑器窗口的拓展，并实现一些简单的功能。例如根据模板自动创建脚本（System.IO）、创建预制体(AssetDatabase)、读取指定文件夹下的资源、根据鼠标选中的资源批量创建ScriptableObject等（Selection）。

最近在学习ue的gameplay框架设计和设计模式，再回过头看一下自己过去一年写的unity项目框架（屎山）代码，感慨良多。体会到了做游戏写脚本，语言语法只是表层功夫，学会它可以让游戏跑起来。走多远的关键，还是在数据结构/算法/设计模式的内功。过去一年，自己也看了很多unity教程，国内unity开发社区还是挺活跃的，新手阶段能在网上找到各种各样的教程。但学会教程≠会做项目，实践才是检验真理的第一出路。......

设计游戏时，框架设计时十分重要的，项目内容一大，各个功能系统间的耦合性就会不可避免的增加，如果初期时没有规划好，后期维护时成本就会大大增加。本期是在Unity实现一个简单的事件框架应用。通过预先在脚本中写好可供复用的具体模块，将事件的搭建流程搭建脱离代码，取而代之的是使用更方便的组合思想去构建事件。这可以减少脚本的编写量，也更好的去规范游戏的制作管线。在本期框架中，我们将游戏的各种游戏中的逻辑触发抽象成【触发器->执行行为序列】的流程，将触发器脚本作为父物品，各个行为作为该触发器的子物品。

在现代游戏引擎设计中中，使用的大多都是托管内存，基于此我们不必手动管理内存，造成内存泄露等问题。对于unity中的游戏对象，每隔一段时间，Mono的垃圾回收机制将会检测内存，将没有再被引用的内存释放回收。当我们使用一个新的游戏物品（实例）时，首先需要实例化它（Instantiate，实际上也是基于new的机制实现的），在我们使用GameObject完成后便摧毁它（Destory）但是，申请实例化时，意味着我们需要在托管堆上分配一块新的内存给Object，在回收时，我们需要等待回收机制收回

本期来设计一个游戏状态的怎么在游戏中表示和存储。保存游戏状态的目的一是方便根据玩家当前的游戏进度实行各种各样的逻辑分支，二是在存档时能记录实时的游戏数据，方便读档回到存档位置。...