今天我要再开一个新坑，学习一下《Effective C#》,百闻不如一见，确实有必要好好梳理一下自己的代码方式。
第1条：优先使用隐式类型的局部变量用var来声明变量而不指明其类型，可以令开发者把注意力更多地集中在名称上面，从而更好地了解其含义。
第2条：考虑用readonly代替constC#有两种常量，一种是编译期（compile-time）的常量，另一种是运行期（runtime）的常量，它们的行为大不相同。常量如果选得不合适，那么程序开发工作可能会受影响。编译期的常量虽然能令程序运行得稍快一点，但却远不如运行期的常量那样灵活。只有当程序性能极端重要且常量取值不会随版本而变化的情况下，才可以考虑选用这种常量。
运行期的常量用readonly关键字来声明，编译期的常量用const关键字来声明
游戏开发
未读在Unity中UI事件有两种方式，一种使用数据接口的方式，另一种使用监听组件的方式。
使用数据接口通过继承数据额接口实现接口方法我们可以对Ui事件进行处理。
1234567public class APanel : MonoBehaviour, IPointerClickHandler{ public void OnPointerClick(PointerEventData eventData) { print("Ui被点击了"); }}
Unity提供了各种各样的数据接口给我们使用，这里不在一一赘述。
需要注意的一点是，使用Drag类的接口时，我们必须使用Drag接口，其他的BeginDrag、EndDrag等接口才会响应。{.blue}
使用监听组件我们最常用的监听组件是Button组件，我们可以给任意一个Ui添加一个Button组件来让Ui具有Button的效果。
在处理复杂的监听事件时，我们可以使用Event trigger组件。
Event trigger监听绑定和Button基本 ...
开始第一次打开《游戏编程模式》这本书已经好像已经是两年前的事情了，断断续续的算是读完了，其实花费的时间应该是大于9小时的，
相比传统的设计模式来说，本书结合了游戏设计方面的思考，让我这个游戏程序员读的很起劲。
感悟书中使用C++进行讲解，除了设计模式本身，也让我使用底层c++搭建游戏引擎有了一个基本认知，其实很多设计模式我们在平时已经在不经意间使用到了，只是不明确我们使用的是什么模式而已:heart:。结合之前学习的《大话设计模式》,这算是第二次学习设计模式相关内容了，但我自我感觉自己在代码架构设计方面还是存在一些薄弱。之后考虑再读一下《设计模式与游戏完美开发》，主要是结合C#看一下在Unity中使用设计模式的具体方式。
将工作推迟到必要时进行以避免不必要的工作。
说明但一组数据因为另一组数据的变动而变动时，为了确认具体需要变动的数据，我们为数据进行标记。
++一组原始数据随时间变化。一组衍生数据经过一些代价昂贵的操作由这些数据确定。一个脏标记跟踪这个衍生数据是否和原始数据同步。它在原始数据改变时被设置。如果它被设置了，那么当需要衍生数据时，它们就会被重新计算并且标记被清除。否则就使用缓存的数据。++
仅当性能问题严重到值得增加代码复杂度时才使用它
2022年6月14日00:38:00
++等待更新++
通过阅读《游戏编程模式》在我的理解下，服务定位器就是：++将需要全局使用的对象进行统一的管理++。
主要是为了解决单例对象在众多系统中被使用暴露了真实系统实现的问题，通过在单例系统外围包裹一层，然后通过访问外界的定位器来范围真实的服务对象。
当然这样就意味着，我们需要在定位器中对服务进行初始化管理。
Ps：使用这样的方式，我们就可以通过定位器快捷的替换服务器的具体实现对象，以指定使用例如测试音频模块、发布音频模块等的发布环境区分的子服务类型。{.red}
Tips: 其实对于上述的环境区分，我们也可以通过宏定义来处理。
时序耦合
在书中提到了一个++时序耦合++的概念，所谓时序耦合就是指两个或多个独立系统因为依赖关系导致，必须有A才能使用B的情况出现，解决时序耦合可以让我们真正让每个系统独立。
为了防止出现NULL的情况，我们可以为服务指定一个默认初始化方式或默认初始化对象，同时我们可以在想要禁用该项服务时，返回这个默认的空对象。
说明
服务定位器模式在很多方面和单例模式（第6章）非常相近，所以值得考虑两者来决定哪一个更适合你的需求。
Unity[插图]框架把这个模式和组件 ...
简单介绍UIBulider的使用
UIElement是一种类似于Html形式进行界面开发的方式,创建的EditorWidow包括以下3个文件。
C#-代码控制界面逻辑 类似于js
Uss-样式控制器 类似于Css
Uxml-基础骨架模板 类型Html
UIBulider界面
双击Asset打开编辑窗12345678910111213141516171819202122232425262728public class DialogGraphEditWindow : EditorWindow{ private static VisualElement rootMain; [OnOpenAsset(1)] public static bool OpenAsset(int id,int line) { if (EditorUtility.InstanceIDToObject(id) is DialogTreeGraphAsset graph) { var window = ...
状态机是对状态模式的一种使用。用于独立处理在各个状态的具体情况和转换关系。
开始当我们需要处理带流程响应的问题时，可以将其抽象为状态问题。
例如下图的我们需要处理OnEnter、OnUpdate、OnExit三个部分。{.red}
有限状态机
有且仅有可能处于一种状态，解决状态区分和转换问题。
有限状态机是下列几种状态机的基础，下面的状态机都基于有限状态机进行相关功能的扩充。
转换方式在状态机中，我们需要使用一种转换方式来进行状态切换，在Unity的Animator中使用条件参数进行跳转。我们可以使用类似事件的方式来跳转、或者使用任意能够保证正确进行 原状态到目标状态 转换的方式。
实现方式
对于有限状态机来说，我们只需要保证具有状态、转换关系即可。
状态状态是我们需要管理的核心，状态中可以包含转换关系Dict。
非继承式状态1234567891011121314151617181920/// <summary>/// 简单Fsm状态/// </summary>public class FsmState{ public string ...
说明
在URP中Unity通过定义RenderFeature来编写自定义后处理效果，实现SRP渲染管线。
1234graph LR Vlome-->RenderFeature --> RenderPass1 --> RenderPass2--> ...... RenderPass--> Shader--> ShaderPass1-->ShaderPass2-->......
流程如上
Step1 编写后处理ShaderSetp2 编写Render FeatureRender Feature
Render Feature是一个处理集，继承自ScriptableRendererFeature，可以包含多个Render Pass。
public override void Create()
用于在RenderFeature创建时调用，一般在这里进行使用到的RenderPass的初始化操作。
public override void AddRenderPasses(ScriptableRenderer renderer, ref ...
将指令抽象为一组字节码，通过字节码的排列组合定义游戏行为，使得玩家或者策划能够自由设计游戏行为（例如AI）。
数据驱动让游戏逻辑脱离编码的限制，赋予数据 行为。
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273class Program { static void Main(string[] args) { //使用这样的一种数据驱动的模式来编程,让游戏逻辑脱离编码的限制，赋予数据 行为 // //使用堆栈存储指令，每次将堆栈中的指令出栈执行再入栈，直到栈空 var stack = new Stack<int>(); var actlist = new List<int>() ...
通过创建一个类来支持新类型的灵活创建，其每个实例都代表一个不同的对象类型。
问题试着想象一下，如果我们来设计一个怪物的数据我们会如何？
名称
种族
生命值
攻击力
……
以及我们的Attack行为。
可以想到诸如这些的属性，在以这些数据的基础上来派生更多的特殊化数据。
传统设计按照我们的常规思维，我们很容易想到如下的设计方案。
123456789101112131415161718192021222324252627282930public abstract class MosterBase{ public string Name { get; set; } public int Hp { get; set; } public string Race { get; set; } public int Damage { get; set; } protected virtual void Attack() { }}public cl ...
