排序计算将在建库中执行完成，并将结果输出到文件。前端不需要做额外计算。作者统计功能调用作者统计函数后，程序将一个一个将作者名读入，同时维护一个字典树，在每个树的结点记录一个权值，统计该位置对应的作者名出现了多少遍。最后再遍历字典树，获得所有作者的具体出现次数，并由于作者出现频率远小于作者总数量，因此使用桶排序可以获得最好的排序效率，最终在O(n)的时间内完成排序，占用的空间也为O(n)。排序后按顺

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

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

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

这里是lz方法大二上的编译原理实验课，课设要求模仿编译器的原理思想，用编译语言设计能够识别单词和简单语法的编译，当时摸了两天左右写了小一千行，在这里再回顾一下思路，并留下对应的源码供参考。实验实现的方法有很多种，其中实验一的词法分析部分比较简单，这里重点分析语法分析部分。题目需求：实验一：词法分析这里用了stl::map等提前存储单词记录出现次数即可。这里就不展开详细描述了。一些具体细节的可参考g

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

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

在程序中，需要解析的DBLB文件大小为3G-4G的。因此每次启动程序前都读取一遍DBLP并全部写入内存的方法是不现实的，这需要我们提前在磁盘中建立对应的数据库文件，在第一次打开程序时进行建立数据库的操作，将需要的数据写入磁盘。之后对DBLP的数据查询只需要打开已经建立好的数据库进行IO操作即可。由于数据在磁盘和内存中的读取速度差距极大，在磁盘中删改添加数据效率是很低的，因此如何建立对应数据的索引，

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

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