enternalstar的博客

在MVC中，业务数据直接就是界面所需的交互数据，但在MVVM中，会有一个业务数据和界面数据的映射，例如业务数据中的UserName字段界面数据中可能仍是原样显示，但地区需要从“中国”显示为“China”在MVVM中，View中需要新增一个绑定逻辑，为PanelViewBind,其将V中的组件的数据与VM中的数据绑定，以便于双方中有变化时会自动通知对方取修改值。MVC是整个UI框架层级上的模式，PDI是在已有的UI框架模式下（不一定是MVC）的具体功能上的模式，他们的核心都是实现逻辑和数据的分离。

如果很多，我们要逻辑和数据分离，这里是方法层级的逻辑和数据分离，前文说的是功能层级的逻辑和数据分离。对于不同的数据单位，加载时的逻辑是相同的。加载前的信息和加载后的方法对加载时的逻辑而言都是数据，这是流程的逻辑数据和分离，比之前说的方法的逻辑数据和分离复杂点。有个数据管理的类，初始化时把所有需要的数据加载到内存中，提供不同的Get方法，让同一个界面获取不同的数据或者不同的界面获取相同的数据。数据单位要大而全，因为不同界面需要的显示数据虽然都来自同一个数据单位，但有的显示数据单位中的A，而有的不会.

分离的方式是显示的逻辑、获取数据的逻辑（耦合的方式没有该逻辑，其直接就有数据）、数据集合的逻辑，显示的逻辑和数据集合的逻辑不耦合，两者通过获取数据的逻辑关联起来，当新增显示时，显示的逻辑不变、获取数据的逻辑不变，数据集合需要新增数据，一个界面改变引起一处逻辑改变。交互会使得界面显示内容发生变化，交互的数据记录的是界面的状态。耦合的方式将界面显示的逻辑与显示需要的数据耦合在一起，当需要新增显示时，显示逻辑不变，但数据增加，即数据改变，导致需要修改显示逻辑，一个界面改变引起两处逻辑改变。

2.减少内存依靠lentInstance2Object来找到对象属于哪个池子，因为做了多层嵌套，会导致重复，可以给物体添加一个类来读取，就省去了lentInstance2Object。1.扩展编辑器保证在任意编辑ObjectPoolAsset.asset时，不会导致在InitPool()时报错，目前的代码里并没有控制。统一管理对象池，需要提供初始化、借出对象、回收对象、增加对象池、减少对象池、清空对象池的方法，比较简单。3.全部用ObjectPoolBase来实现不同类型的对象池的自由组合。......

在整个游戏过程中，对象非常多，可以根据一定的标准将对象分类：例如这些对象都属于UI、那些对象属于地形、还有些对象属于角色等等；有些对象只在第一阶段出现、有些只在第二阶段出现，有些只在第三阶段出现等等；有些对象属于某个剧情或任务中的；有些对象处于某个地点或范围等。如果我们希望对游戏中的所有实例对象做一个管理，那么做一个复杂嵌套的超级对象池来管理，这个对象池内部如何嵌套的，也即如何将对象分类，是需要根据游戏，也即业务来做的。我们需要事先考虑好，这也反映出是否可以整体把握游戏。在本文中，将对象做一个不同类别和不同

对于管理单个实例对象的对象池只需要考虑其实例对象的不断借出和回收，如果回收速度大于借出速度，说明缓存的对象够用，如果不够用扩容就好。我们不用担心内存不够了，几十个，顶多几百个对象是够用的。对管理多个实例对象的对象池而言，合起来管理的内存多大上千甚至上万个，有些缓存对象可能已经不需要了，但仍留在内存中，这会极大浪费内存。因此，我们需要将这些长时间不用的对象淘汰以节省内存。这就涉及到缓存淘汰的策略。常见的缓存淘汰策略有：FIFO、LRU、LFU等，这些都表示什么意思，网上有很多资料，这里就不多说了。这里我们要使

根据对象池所需要的数据和操作，先定义基本的接口操作方法为借出对象和回收对象。借出对象时要传入对象名字，标识想借出哪个对象；parent表示要借出的这个对象的父对象是谁；同时还有个缺省的参数数组。要统计的关键数据是生成的实例对象总数，缓存的实例对象总数，可缓存的实例对象总数。 【管理单个源对象的实例对象的对象池】我们知道一个对象池里的所有对象都是某个源对象的实例对象，也即调用go = UnityEngine.Object.Instantiate(SourceGo,parent)时，对象池里存放

如果不知道什么是对象池，请先了解下。关于对象池，我们需要知道池子里的最大容量和当前可用的对象数量；需要从对象池里获取和回收对象；随着生成的对象越来越多，池子会扩容，要有扩容的操作和策略，反之要有缩容的操作和策略。我们可以根据这些来定义简单的接口和相关枚举：可以看到没有定义一个大而全的接口，反而是定义了很多小的接口 ，这是因为大而全的接口可以拆分为ABC等部分，而另外的某个功能也会用到这些部分。 实现和注释请看代码

在很多的设计上都会有Trigger\Action\Event的概念，简单说下自己的理解。Event比Action抽象，一个Event可以包含很多Action，比如说攻击Event可以由多个Action组成，每个Event的结果可能不一样，例如有的攻击Event造成的伤害是100，由的是50。Action是GameObject对Event的响应。Trigger就是一个触发的条件，是一个GameObject和另外一个GameObject产生交互的条件，例如攻击伤害到达100，敌人死亡。State是描

【为什么要用对象池】有些对象需要在程序运行或游戏过程中重复的创建销毁，例如子弹、怪和粒子等。每次创建要分配内存，而这个对象生命周期很短，对象很快被销毁，内存要被回收，这会增大GC的压力，同时也会造成内存碎片。使用对象池可以解决这些问题。对象池预先初始化一系列可重用的对象，循环利用这些对象，有利于提高程序性能和内存使用率。【相关概念】池的大小：初始化n个对象，那么池的大小就是n，具体n取值多少依据具体情况而定 回收模式：指如何在需要的时候从对象池中取出对象，在不需要的时候将对象放回对象池

【使用】//先定义状态枚举public enum RoleState{ Idle, Walk, Jump, Attack, Dead}//随后继承状态机类、状态类、转移类public class StateBase : StateBase<RoleState>{ public StateBase(IFSM<RoleState> parent, RoleState stateId, Action onEnter = n

【如何省略写转移和状态类】在之前的FSM实现中，我们发现每添加一个新的状态时，需要写一个新的状态类，多个转移类，同时，还有可能需要修改已有的转移类的CanTransition方法，如何避免这些呢？无论如何，当业务或逻辑需要时，状态转换条件判断方法（即CanTransition）是必须要修改的。我们不能说不修改，而是要更改修改的地方。另外，在之前的实现中，状态转换条件判断，都是在状态下判断输入，因为输入可能是各种各样的，数量远超状态，如果switch（状态），那么输入改变时就会多一个 case。我

【状态模式】状态模式主要解决的是当控制一个对象状态转换的条件判断过于复杂时，把判断逻辑转移到表示不同状态的一系列类中，从而简化复杂的逻辑判断。（如果状态转换条件判断很简单，就没必要用状态模式了）【FSM的相关概念】输入：在上一篇文章中，我们并没有显式给状态机输入，在这个实现中给显式的输入，我们暂且认为所有输入都是string类型的。在实际运用中，可以写一个输入类。状态：表示对象的某种形态，在当前形态下可能会拥有不同的行为和属性。状态机：每一个时刻只能处于一个状态；拥有对象所有状态的集合；

【基本概念】有限状态机（finite-state machine，FSM)可以解决有限个状态转换的问题。具体的定义和相关的概念先不说，我们直接通过例子来理解。我们知道一个角色通常会至少有idle，walk，jump，attack，dead这五种状态，我们在操作角色时角色会根据我们的操作转换为不同的状态，那么角色如何根据输入转换为相应的状态呢，这就是状态机的要解决的问题。【我们的需求】按I键，角色变为Idle状态，播放相应动画按W键，角色变为walk状态，播放相应动画，也即角色开始行.

战斗AI设计的结果如下：最简单的战斗AI设计【实现结果】采用紧跟的追踪方式，Player选择了最近的目标为敌人，拖动敌人，Player跟随，当敌人距离过远时，Player没有了目标，停止移动。采用锁定的追踪方式，无论敌人移动到哪里，Player都会移动到敌人前进行攻击采用重择的追踪方式，在追踪敌人的过程中遇到更符合条件的目标就更换敌人【实现过程】采用nodecanvas辅助实现这个设计，由于目前的设计很简单，我们不用根据设计结果提炼出条件节点和行为节点，全部采用行为节点.

【最简单的设计】可以将战斗将分为三个阶段，分为了找到敌人、寻路到敌人和攻击敌人找到敌人的第一步时搜索敌人，这就要有一个搜索条件，即在什么样的条件下，可以搜索到敌人。最常见的搜索条件是半径角度法，即角色面前的扇形区域是角色的搜索区域，在这个区域内的人可以被搜索到。搜索到敌人后就需要移动到角色面前进行攻击，这就需要寻路，如果角色和敌人没有任何阻挡物，那么就是最简单的寻路方式，角色直接走过去，然后开始攻击敌人。这是最简单的思路，接下来要复杂一些。在搜索敌人的时候如果没有搜索到呢，常见的