代码拉取完成，页面将自动刷新
游戏会在两个阵营的固定区域在固定的频率中出兵。小兵只能沿着规定好的轨道进行行走，并按照各个防守塔的顺序向敌方进行进攻。
对于固定出现的小兵来说，不适合在其死亡之后删除GameObject对象，而应该使用对象池来管理他们，当小兵死亡时，只是将该单位的GameObject的active设为false，当要进行出兵的时候，从对象池中抽取active为false的单位出现在固定区域。
对于小兵来说，他们会固定的走上中下三条路线，不会穿越其中的任何一条，而Unity本身的Navigation导航系统不能对于一个地形进行分区，所以使用area对各个单位行走轨迹进行分区的方法就失败了。
在此，决定用**（伪）路径点寻路**的方法来控制小兵的行走轨迹，下面简单描述一下：
基于一个WayPointManager的MonoBehavior类来管理上中下三路的路径点（使用MonoBehavior的原因是可以在编辑器编辑路径点）
使用一个WayPointUnit来管理 单位上中下路的寻路 、 下一个路径点的寻找 、 寻找自己最近的路径点 功能。
理论上来说，只有要不断的攻打敌方基地的小兵才是需要路径点寻路的，其他野怪或者英雄依然使用unity自带的Navigation导航寻路。所以WayPointsUnit这个类是小兵独有的。但是，如果就此就为小兵设置一个单独的具体类，就未免太过麻烦，这里依旧把WayPointsUnit属性赋予CharacterMono类，只不过只有小兵才对其进行赋值，而其他单位这个属性值均为Null。
使用路径点寻路要改写单位的行为树。之前我的小兵行为树策略是指定敌人进行攻击的行为树，但是因为指定敌人的话，行走路线不能固定，所以要将指定攻击三塔、基地的行为树改造成 沿着路径点 指定行走的行为树，其基本逻辑用以下伪代码实现。
1 if(周围有敌人){
2 攻击、追击周围敌人
3 if(如果当前位置离最近的路径点距离大于X){
4 返回路径点，不管敌人
5 }
6 }else{
7 沿着下一个路径点行走
8 }
这个AI之所以可以顺利的进攻敌人的基地和三路塔,靠的是1-5行的第一个if,路径点规定一定会走到敌方塔或基地前,固小兵可以顺利进攻这几个位置.
5. 最近路径点算法: 最近路径点的寻找是整个AI性能的关键之处,在这里,我将这个算法定义为如下情况:
从当前下标往下找,一直找到一个离自己最近的位置,那么"最近路径点"等于离自己最近的位置的路径点的下标+1,这里主要是为了小兵不会走回头路(那会看起来很怪).下面用伪代码来描述:
for(int i=nowIndex+1;i<wayPoint.Count;i++){
// 找到离自己最近的路径点的下标,赋值为 nearestPointIndex
}
// 将当前路径点(即下一步要走的位置)设置为最近的点的下一个坐标
nowPoint = nearestPointIndex+1
首先要明确在MOBA游戏中,有什么数据/资源是需要我们从外部进行动态读取和更新的. 初步观察,应该是如下数据:
其中1/5/7可以归类为游戏中的各类数据对象,在外部存储时可以以文本格式存储(即json/xml/excel等格式),这些数据是需要进行动态更新与读取的.(方便对游戏中的各类对象的属性进行实时编辑与修改,方便版本更新)
其中2/3/4/6/8/9为资源文件,可以将它们打包为Unity可以读取的形式(assetbundle或其他打包方法).
综上所述,本游戏主要有两类资源,他们分别是文本类型的资源(json/xml/excel等格式)和assetbunlde类型(或其他)的资源,其中特效对象(prefab)/贴图(texture)/模型(mesh)通过assetbundle打包到外部,方便策划添加/编辑/修改.
最后再通过Unity加载这两类资源到游戏中,通过输入框架,将这些数据/资源文件变为游戏中的各个对象.
在本游戏中，我模仿了一部分魔兽争霸单位编辑器的方法来对单位、物品、技能对象进行编辑。 也就是，所有单位的数据都是先在编辑器中编辑好的，当编辑好后，这个数据就以（JSON、CSV、Sqlite、xml）的形式存储到了本地文件中。
在游戏代码中，通过读取这些本地文件，得到了一个个已经编辑好的单位、技能、物品的数据，通过这些数据来生成对象。
我使用JSON来进行外部组织数据，技能、单位、物品，都依据JSON的方式进行存储。
采用了类似RPG Maker的笨办法
在游戏开始时对游戏数据进行初始化，即在游戏开始时，读取数据库，对所有游戏数据生成一个模板对象，用一个数组或字典存储。然后在游戏中对这些模板对象进行深拷贝到一个个实例游戏对象中去.
主要步骤有以下几步：
如何初始化也是一个问题,这里我采用一个单例的MonoBehavior类来对外部数据进行初始化.
对于一个游戏来说,进入游戏后,有一个开始菜单,只有当点击开始游戏后,游戏才会开始.
在游戏开始的地方设置一个进度条(类似于魔兽、Dota那样),在进度条时对外部数据进行读取并初始化.
最终将外部数据(JSON数据)读取到一个字典中去,每个游戏对象需要使用到外部数据时,就读取该字典.
举个例子:
在红方阵营出现的小兵为在单位编辑器中编辑的003号单位.
这时,已经有了一个读取了所有单位信息的字典(或列表)
UnitDataList , 只需将红方阵营出现的小兵的CharacterModel赋值为 UnitDataList[003].DeepCopy()就好了.
DeepCopy是深拷贝的意思,不能直接赋值,因为在列表(或字典)中的是模板对象,直接赋值(也就是引用啦),会导致模板对象的值被外部修改(这是不允许的).
由于游戏中的大部分数据用JSON进行组织，而直接写JSON比较繁琐，所以在Unity扩展编辑器中编写一个用于输出编辑好的JSON数据的扩展编辑器。
对于这个扩展编辑器的编写，有以下几点要求：
emmmmmmmmmmmmm,如何设计技能表绝对是一个难题了,各个技能抽象的程度不一样,对外开放的接口也不一样.
在这里,我决定采用JSON的方式来存技能数据.
在JSON数据中,有一行数据,SkillType,技能类型,用于表示这个技能是什么类型的技能.在技能编辑器中(使用Unity Editor进行制作)根据这个SkillType来进行反射,生成对应的技能类,并在编辑器中生成这些技能类的可编辑字段.
而对于存储的JSON数据,则使用该技能开放的接口对应的属性进行存储.
简单的举个例子,目前我有两个技能,分别是召唤技能a和指定目标伤害技能b. 存储到JSON中格式就是这样的.
{
"SkillList":[
{
// 此处是零号技能,伤害技能
"Damge": 100,
"selfEffect":"001" // 这里存储的是对应prefab在AssetBundle下的名称
"targetEffect":"002",
"skillName": "伤害技能",
"iconPath": "001", // 这里存储的是对应texture在AssetBundle下的名称
"description":"这是一个伤害技能", // 存储描述
"mp" : 100, // 消耗mp
"skillType": 0 // 整数（对应枚举），描述这个技能的类型,用于反射
},
{
// 一号技能,召唤技能
"Summoner":"001", // 这里存储的是对应prefab在AssetBundle下的名称
"skillName": "召唤技能",
"iconPath": "002", // 这里存储的是对应texture在AssetBundle下的名称
"description":"这是一个召唤技能", // 存储描述
"mp" : 100 // 消耗mp
"skillType": "SummerSkill"
}
],
"SkillCount":2
}
为了和游戏的输入框架一一对应，在这里要严格规定JSON数据的形式，下面列出一个合格JSON数据的几项标准：
一个正确的JSON数据如下：
{
"Type":"", // 技能类型
"SkillName":"伤害技能", // 技能名
"IconPath":"default-itemIconImage", // 技能图标地址
"SkillLevel":1, // 技能等级
"Mp":100, // 魔力值
"BaseDamage":100, // 基础伤害
"KeyCode":113, // 按键
"SpellDistance":3.3, // 技能施法范围
"CD":5.5, // 技能CD时间
"SelfEffect":"001", // 施加在自身的特效的地址
"additionalState" : { // 此技能附加的状态,是一个JSON对象,包含了这个状态的类型,状态名,持续时间等等
Type: "", // 状态类型
name : "", // 状态名
description : "",// 状态描述
iconPath : "", // 状态图标地址
isStackable = false,//状态是否可叠加
statePassiveSkills = [1,3], // 状态被动技能列表,保存一系列的编号,这些编号用于指代技能编辑器中某个技能的ID
stateHolderEffect = "" // 当某个单位保持这个状态时,此单位会产生的特效
}
}
一个用于输入的XX表（技能表、人物表等）JSON数据的格式如下:
[
{
对象1
},
{
对象2
},
{
对象3
},
]
其中的对象同上面所说的规定的格式。
简单说明一下,在GamePlay数据类中,有许多数据都是要由外部输入的,到时会有一个全局的 “字典/列表/队列” 等来管理所有数据。
对于一个由外部输入的数据,在定义属性时,使用注释 "<==" 来说明,对于在游戏中依据某些数据动态生成的数据,则不使用此注释.
在我设计的GamePlay游戏逻辑类中，有Model类和Mono类这两种，其中Model类是相当于Java里面的JavaBean那种感觉，主要就是用来存储从外部导入进来的游戏数据，比如技能、物品、人物数据等。而Mono类对应的是Unity里面的MonoBehaviour类，主要用来管理游戏进程的。
举个例子，对于投射物，有projectileModel和projectileMono类，其中Model类是用来存储从外部导入的投射物数据，比如在外部数据库编辑好的某个投射物，他的射速、射线弧度、投射物到达目标地点后产生的屏幕特效、投射物与敌人碰撞后产生的屏幕特效等。
而对于Mono类，则用来管理一个具体的游戏里面的投射物的生命周期，在Mono类中，管理投射物造成的伤害计算、向目标飞过去的逻辑等等。
每个Mono类中都有一个对应的Model类充当他的属性。
因为平常都是从游戏外部通过 sqlite、csv、json 来导入数据进Unity的，然后导入的数据需要用一个新建的对象来保存它，但是MonoBehavior对象是不能随意创建的，但是游戏逻辑的部分又关乎MonoBehavior类，就是挂载到游戏对象上的类必须继承自MonoBehavior，所以只好在中间新增一个Model类来充当外部数据与MonoBehavior类的中介者。
一般来说，Model类只需要存储从外部导入的游戏数据就好了，相当于一个中间的存储容器.
但是，我觉得稍微漂亮一点的写法是把一些关乎游戏数据计算的方法也写在Model类中,比如:伤害计算公式等等.
关于一些非数值计算的游戏逻辑,写在Mono类中,比如音效、动画的播放.
所有技能都在外处使用编辑器进行编辑，以（.json\ .csv\ .xml\ .sqllit）的方式进行保存。 所有技能都会有特效动画的产生，特效动画还可分为立即释放型特效，投射型特效等，特效动画由外部进行指定，类型为GameObject，暂定以JSON的形式保存一个技能，其动画特效（释放时敌方产生的特效及我方产生的特效）是一个字符串类型，该字符串指定了在Resource/Prefabs/文件夹下的粒子特效预制体的名称。
对于技能系统的编写,有几个标准:
先用直白的自然语言描述一下技能系统，对于一个技能，它有两个大的分类，分别是：
可以将技能Skill类看成是Model和Mono类的结合类(实际上并不继承MonoBehavior,只是为了表示这个类封装了游戏逻辑),它即保存数据,又对战斗逻辑(释放技能后产生怎样的效果-这样的逻辑)进行计算.
对于任何一个主动技能，它最重要的几个属性是：
它最重要的方法以下几个:
Execute方法表示应用此技能的特效,即 施法开始-产生特效-造成伤害这一系列操作.更准确的说,这个virtual方法使得技能类几乎可以实现所有效果,只要后面的子技能类重写就OK了.
对于施法者来说,他不关心目前释放的技能是"主动技能类的哪个子类",他只要在释放技能的时候,执行Execute方法,就会自动执行不同的技能特效.
对于一个被动技能,它最重要的几个属性是:
重要的方法是:
Execute方法的基本思路和主动技能类似,这里不再赘述. 与主动技能相比,被动技能多了一个触发类型的属性,因为被动技能不能由单位主动释放,只能在某些特定条件触发的情况下,自动进行施法,与主动技能类的设计类似,被动技能类通过覆写多个子类,可以产生很多效果,而对于被动技能的施法者来说,它不需要知道这些效果的细节,只需调用Execute方法就OK了.
被动技能相较于主动技能有许多特殊的地方，这一切都是因为它拥有 “触发条件” 。为了响应这些触发条件，代码里面可能会零散的出现一些被动技能触发的语句，如 普通攻击的时候，遭受伤害的时候。
下面简单列举一些比较特殊的被动技能，以及如何触发他们：
同样是采用事件通知机制实现被动技能。
首先总结可能会导致单位属性变化的事件：
因为在我的设计中，状态、装备，皆是一个拥有技能的物体，所以它们的获得和失去也关乎着技能。
被动技能中的GainAttr触发类型的技能将会在上述事件发生时，执行它们的Execute方法，来对单位的各项属性进行重新计算。因为当上述事件发生后，单位的属性可能就会因为技能的变化而产生变化。
一开始我用的方法是，每次获得单位的属性都会遍历一遍单位身上的装备、技能、状态，以获得该项技能的准确数值（经过各个技能增幅后的），但这个方法太消耗性能，我采取的技能组配置技能策略会导致技能的数量迅速膨胀，所以只有在属性可能变化的时候重新计算一次就好了，不需要耗费太多性能。
持续施法技能，也就是像暴风雪那样，单位释放后会持续释放，同时每隔N秒对目标单位造成伤害的技能，在施法期间，如果单位进行了其他操作（如，移动、追击敌人、释放其他技能等）都会打断当前持续施法技能的释放。
持续施法功能通过技能类的Execute函数返回的布尔值来进行编写，当某一个技能Execute函数的结果为false表示该技能尚未执行完毕，人物状态机的Spell状态就不会进入其他状态，而是继续执行Spell状态下的OnUpdate函数，继而达到不间断的释放技能的效果。
一个持续施法技能通常有以下参数：
持续施法技能本身就是一个技能组，其包含一系列普通技能
技能类的多个子类是实现多种多样技能效果的关键,对于技能类的每个子类来说,他都会实现父类的Execute方法,同时,会留下参数(接口)供外部调整,这些参数就是这些子类的一些属性,比如召唤类技能,则可以调整它召唤的单位等等.
光环技能是特殊的被动技能，其拥有光环触发（Trigger）器，当单位（符合光环作用目标）进入触发器时，给单位一个状态（增益或减益），当单位离开触发器时，将光环状态从单位身上移除。
每一个光环技能对应一个触发器，当学习该光环技能时，自动为单位身上增加一个光环触发器（name为该技能+trigger）。
某些技能会附加一定的状态，对于这个状态，一开始我的设想是在外部输入一个个由策划编辑好的状态，然后技能指定要附加的状态ID就好了，但这个方法有个弊端。那就是，某些技能的定义是相当宽泛的，每个此技能类实例附加的状态都可能不一样，即使附加的状态是同一类型的。
所以，在这里我采取第二个方案。那就是，当创建一个技能对象的时候，会将其附加的状态（如果有的话）对象一并创建，举个例子，对于一个技能，他可能会在攻击时有几率对地方附加一个状态，那么它在JSON文件中的定义就像下面这样。
{
SkillName : "", // 技能名
tiggerRate : 0.0f, // 此被动技能触发几率
additionalState : { // 此技能附加的状态,是一个JSON对象,包含了这个状态的类型,状态名,持续时间等等
stateType: "", // 状态类型
name : "", // 状态名
description : "",// 状态描述
iconPath : "", // 状态图标地址
isStackable = false,//状态是否可叠加
statePassiveSkills = ["001","003"], // 状态被动技能列表,保存一系列的编号,这些编号用于指代技能编辑器中某个技能的ID
stateHolderEffect = "" // 当某个单位保持这个状态时,此单位会产生的特效
}
}
对于一个技能,他以上述JSON的形式写入一个文件中进行持久化。
当开始游戏,要读取技能数据时，会按照此JSON的形式来初始化一个技能。
在本游戏中，所有技能继承于BaseSkill，其中主动技能继承于ActiveSkill，每一个主动技能都对应一个操作，如PointingSkill表示对某个敌人造成一定的伤害，RangeSkill则是对一定范围内的敌人造成伤害，AdditionalStateSkill则是对某个敌人附加一个状态。
每个技能都会有两个放技能特效的目标，1是目标（目标敌人，目标位置），2是自身，给这个技能一个特效Prefab，他会在施法时自动产生一个具有生命周期的施法特效。
显然，简单的操作是不能对应MOBA游戏中的复杂技能的，所以这里每个技能实际上只是一个操作，而技能组（Skill Group）将这些操作整合起来，也就是说，一个技能，他是由不同的简单操作排列组合而成的。
简单的举个例子，对于魔兽里面的“地狱火”技能————天上砸下一个巨石，范围内敌人受伤+受到眩晕状态，随后召唤出一只地狱火出来。这个技能由以下三个操作组成。
通过编写大量的操作（也就是简单的技能）并对其进行排列组合，可以产生多种多样的技能效果。
对于复杂的技能效果，可以通过增加“原子”技能（即操作）来完成。
本游戏有四种技能组：
技能组分为对单体、对范围、持续施法这三种。
1.对单体 对单体技能组很好解释，即该技能组释放时，对目标敌人和目标敌人所在位置执行该技能组内的所有技能。
2.对范围 对范围技能组不会指定一个单独的敌人，而是指定一个位置，并具有一定的圆形技能范围，处于技能范围内的所有单位都会受到该技能组所有技能的效果。举个例子，一个简单的范围伤害技能应该是技能组内的有一个pointingSkill技能，然后在释放后，对每个在技能范围内的敌人产生一个pointingSkill的效果，也就是造成一定伤害。
3.持续施法 持续施法对应魔兽中“暴风雪”、“混乱雨”等技能，单位释放这些技能的时候，是一个持续的过程，在这段过程中，单位指定的目标、目标范围会受到技能效果影响。
简单来说，对于持续施法技能组，会在一段时间内，持续性地对目标（或目标范围）产生他技能组内所有技能的效果。
因为我使用了 技能组（SkillGroup） 的设定，所以实际上，当我们释放一个技能的时候，是将他所包含的所有技能都释放到目标身上。
这样就有了一个问题，技能释放的先后顺序，以及子技能是否同时释放。
首先看第一个问题，技能释放先后顺序。
在数据中，我使用了一个数组来保存技能组中的所有技能，按照自然而然的思想，那么一个技能在数组中的下标就是该技能的释放顺序。
第二个问题，技能延迟执行。
简单的举个例子，地狱火，地狱火技能=rangeSkill(范围伤害技能)
那么如何实现这个功能呢？
在这里我使用委托实现。在我设计的架构中，所有产生的特效对象都拥有 EffectsLifeCycle（生命周期）组件。如果我们要在某个技能释放完（也就是它的特效播放完）再释放某个技能，可以订阅前者的【生命周期】组件的OnDestroy事件，当前者的粒子特效对象销毁时，才执行下一个技能的效果。
那么，每个技能对象（当这个技能在方法组中时）身上又多了两个跟延迟执行相关的属性。下面进行列举：
在本项目中，所有技能都是由外部编辑器编辑好并输入到一个JSON文件的，就像《魔兽争霸3》地图编辑器里的技能编辑器一样。
这就带来了一个问题。项目运行后，按照流程，会将存储好所有技能信息的JSON文件读取，并生成这次游戏需要的所有技能类。并使用类似List这种数组来保存这些技能对象，最后通过skillList[ i ]来通过下标访问任意一个技能。
但是！！在本游戏中，每个单位都是有技能的，这些单位的技能毫无疑问应该是之前已经编辑好的技能，这会遇到以下几个问题：
根据上面两点，可以知道如果单位、物品、状态技能都是深拷贝自技能列表中的技能，那么可能游戏的内存消耗会相当巨大了，因为很多时候技能都是有共性的。
举个例子，比如多个技能之间释放的技能特效可能是同一个特效对象（Prefab）。这个比较好解决，只要在深拷贝的时候，不深拷贝特效对象就行了。
但是，同种技能之间的共性更多在他们的MP消耗，技能范围，技能图标，技能描述等属性上面。
举个例子，在游戏中有一招“地狱火”技能，随着等级的提升，它的MP消耗，技能范围可能会扩大，但是他的技能描述、技能名、技能图标这些是不会变化的。
而如果有一个英雄（比如“恐惧魔王”），他会这招“地狱火”技能，那么按照上面说的方法，他就深拷贝了一份技能列表中的地狱火。此时内存里有一份地狱火的技能描述、技能名、技能图标等属性。
这时，又有一个物品（比如“恶魔岩石”），使用这个物品的效果同样是“地狱火”技能的效果，那么按照上面说的方法，这里又得深拷贝一份技能列表中的地狱火。此时内存已经有两份同样的地狱火技能描述、技能名、技能图标等属性了。这就会带来多余的内存占用率。
同样的思路，如果此时又有一个状态，比如死亡后会释放地狱火技能，又得深拷贝一份。
这里其实可以敏锐的察觉到，其实，技能对象中，大多数属性是不用变化，不用深拷贝的，这些属性，不论这些技能是在什么对象上，无论这些技能是由英雄释放的，还是物品释放的，都是不变的。
而技能对象的另外一些属性，才是真正会发生变化的，比如它的等级（由英雄加点发生变化），缓存的CD时间（经过多长时间可以继续释放它，由上一次释放它的时间决定）等属性，是每个具体的技能对象不同的，而其余的基本都相同。
下面以主动技能为例，列举一下其中变化和不变的属性。
不变的属性有以下几种：
......等等
变化的属性有以下几种：
可以看到，每个技能不变的属性有相当多，而每个技能对象不同的属性却只有两个（暂时只有两个，或许后续会增加）。
这种时候，就应该使用享元模式来管理技能对象的数据。
使用享元模式管理，那么最后在每个单位上的技能不变的那部分属性都只需要引用技能列表中的技能就够了，而不变的属性则由它所依附的那个对象来使用。
那么如何使用享元模式来管理呢？
我的做法是，新增一个SkillModel类，每个Skill对象都会引用一个SkillModel对象，这个Model类中的属性即为这个Skill不变的属性，即技能名、技能描述等属性。
而该技能会变化的属性，即Level等属性，则作为Skill类的属性，在游戏中会发生变化。
最后，我们在外部编辑器编辑的SkillModel的属性，读取进来也是SkillModel对象，全局存储的也是类似List这类属性，而具体的技能则是必须通过SkillModel来进行创建。
这样，每次都需要深拷贝的一部分技能类的属性，就变成了公共的属性，只需要Skill类中存储一个指向这些Model类的指针的就行了。
前面提到，在本游戏中，由技能组设定（SkillGroup）类增加的技能的易扩展性，也就是多个操作来组成一个技能，技能的种类由操作的排列组合形成。
实际上，我们在外部编辑器中，输入的就是这些操作的参数。每个原子技能类都各自继承自ActiveSkill和PassiveSkill类，他们也会各自派生出其他属性。
举个例子，比如派生于ActiveSkill的AdditionStateSkill（为某个目标增加一个状态的技能），就会有一个独立属性StateID，即要附加的状态的ID，这是ActiveSkill所没有的。这个时候，按照上面的做法，还得再派生自基类ActiveSkillModel得到一个AdditionStateSkillModel类，若是有多个原子技能，就会有多个这样的Model类，如果要一个个都全部编写，那效率会比较低下。
这里我采取一个方案，在BaseSkillModel类中使用一个< string,object >类型的字典，存储这些所有的子类中的额外属性（相比于父类）。
而当要使用这些属性时，就直接从字典中取出该属性并进行强转。
前面提到享元模式中基类的属性就是在整场游戏中基本不会变化的属性，同时，这里的Model类还担任一项职责，那就是保存技能数据编辑器中的技能基本数据。也就是说，这个技能需要的mp，伤害等，一开始也是由编辑器输入的。
但是！对于一个技能来说，当它的等级变化的时候，它的一些属性理应也发生变化，如它的伤害，需要的mp，冷却CD等等。魔兽地图编辑器的做法是将这些属性按照等级变成N个序列值，某等级对应序列中一个值，但这样的话如果技能有100级，那设置技能的人岂不是要累死。。。
这里我采用的做法是在技能编辑器中设置基础属性，其变化属性根据公式及基础属性来进行计算。这样，在Model类我们设置的就是基础属性，即技能等级为1级时的默认属性，而当技能等级上升后，对应技能的属性会根据公式进行计算。
使用享元模式蛇者技能系统最重要的一点就是,可以很轻松的将技能(Skill)拷贝给某一对象(单位,技能组,物品,状态等),而无需使用深拷贝.
下面描述使用样例:
首先从AssetBundle中读取已设置好的所有技能对象
将得到的技能对象(Skill : BaseSkill)用数组的形式保存在内存中,之后要使用的时候,就直接访问这个全局的技能数组对象(假设为skills)
假设此时有一个物品它需要3号技能,那么,将物品的skill设置为 skills[3].copy();
copy方法的伪代码实现如下:
public override BaseSkill copy(){ BaseSkill skill = new BaseSkill(this.skillModel); return skill; }
上述代码的意思是,直接新建了一个新的技能对象,然后简单的让他的SkillModel指针指向这个需要被拷贝的技能对象的Model对象.
这是因为Model对象中保存了这个技能对象基本不变的属性(已预先在编辑器中设置好的),所以Model对象就是享元模式中不变的那个基类对象,只需简单用个指针引用即可.
在MOBA游戏中，一个物品有多种功能。下面简单举例：
可以看出物品其实可以看成是拥有一堆主动、被动技能的物体，只要携带在英雄身上（物体未消耗完毕），英雄就可以使用这些主动、被动技能。
物品格子类是物品的类的包装类型，它表示了在英雄物品栏中的一个个物品格子，其拥有当前物品持有数量等属性，用来处理具体的游戏逻辑。
在MOBA游戏中，有一个通用商店，其中会贩卖一些通用道具和装备，包括药品，新手出门装等等。这个通用商店在屏幕空间的右下角UI位置，点开来就能购买物品。
还有一个商店是在地图上游荡的神秘商人的商店，此商店要靠近神秘商人之后才能开启购买。
描述一下商店的操作流程：
当前方案要用到很多次GameObject.Insitate来初始化ItemPanelView对象，这是非常损耗性能的。下面列举一下我要使用的优化方案：
商店中展示的是一个个物品格子ItemGrid，对于每一个物品格子，当他的ItemCount为0时，其携带的物品会被置为Null。对于人物物品栏来说，这个设计是合理的，因为确实物品用完了就不能再用了。
但是对于商品的商品栏来说，这个就不合理了，因为商品被买完是会回复的。所以，在这里特地设置一个isCoolDowing状态，用来表示此物品已经被售完，正在冷却回复中。当某物品被卖完的时候（实际上不让它的ItemCount=0，而是让他的的最小值为1），也就是它目前的itemCount为1并且还有单位购买他时，设置它的isCoolDowning状态为true，并在Update中更新它的冷却条
在Moba游戏中,一个比较重要的系统的就是装备合成系统.
装备合成系统描述的是,一个高级装备是由多个低级装备合成而来,当玩家物品栏内有可以合成成高级装备的低级装备时,会自动进行合成.
为了实现装备合成系统,为装备增加两个属性:
对于游戏策划来说,他只需要设计每个物品的前缀装备就行了,也就是,每个高级物品,他需要的低级物品列表,对于后缀装备列表,我编写一套输入系统根据前缀装备进行自动输入.
一个最直接的原因是,实现装备合成的方法,我放在了人物的GetItem方法中,也就是说,当玩家获得一件装备时,系统会首先观察这个新获得的装备是否可以和目前装备栏的现有装备进行合成出高级装备.
这个判断的过程也就是查找的过程,如果没有后缀装备这个属性,要遍历整个物品表来查找是否可以合成.
当有后缀装备属性时,只需遍历后缀装备列表,查看是否物品栏内有装备可以一起合成这个高级装备.
状态是一种持续影响某一物体的表现，最典型的状态比如：中毒、伤害加深。
当单位受到中毒状态时，他会每隔一段时间受到一定比例的伤害。
而当单位受到伤害加深状态时，他会在遭受攻击时，受到的伤害加深。
更为特殊的状态，当单位拥有某一种特殊状态时，它的攻击会带有某种特效之类的。
从上面的描述中，可以看出状态有以下特点：
根据功能描述，可以把状态看成是一个在Update状态不停作用单位的一种Mono类。
但是，对于状态拥有的某些特殊功能，仅仅是上面这些还不够。对于状态的特殊效果，可以看出它的描述特别像被动技能。
在这里，可以将状态定义为：
状态的运行流程如下：
需要明确的是，每一个单位都在外部由编辑器提前设定。
英雄单位相对于普通单位，有以下三点特殊属性：
这三点属性的增加会导致单位的基本属性增加（攻击力、防御力、闪避率、hp、mp等等），下面给出详细叙述。
力量：
每点增加x点HP
每点增加x点hp回复速度
每点增加x点攻击力(主属性加成)
敏捷:
每点增加x点防御力
每点增加x点攻击速度
每点增加x点攻击力(主属性加成)
智力:
每点增加x点MP
每点增加x点MP回复速度
每点增加x点攻击力(主属性加成)
投射物是一个比较特殊的单位，在一些技能和单位的远程攻击里面出现，投射物一般有一个目标位置。
要明确的一点逻辑是，投射物本身是不具有伤害的，具有伤害的是发出投射物的单位，所有投射物都是由单位（继承自CharacterMono的所有子类）产生的，由该CharacterMono类指定伤害。
总结一下，也就是，由CharaacterMono类监听投射物的事件，当投射物到达目标地点后，触发伤害事件，调用CharacterMono的GetDamage的方法对敌人造成伤害。
对于一些攻击，如普通攻击等，需要计算敌我的防御值、攻击值，才能产生伤害，这些都是由Character类做的事情，投射物本身不进行任何伤害计算，他只是一个传递者。
对于一个投射物来说，他有两种飞行轨迹：
一种是直线的，也就是直接从某处平移到某处,这种飞行轨迹容易实现,只需让投射物对着目标地点进行均匀的平移就可以了
一种是有弧线的,这种飞行轨迹一般用于弓箭、炮弹、飞行生物降落的攻击等投射物上,这种飞行轨迹较难实现,因为对于弓箭这种投射物,它的旋转角度也会发生改变,对于从高处降下,基于DoTween插件可以较为容易的完成这项功能。
为了统一两种飞行轨迹，可以直接都使用DoTween插件中的DOLocalPath方法进行计算，对于弧线轨迹中的旋转基于DoRotate来进行旋转（计算好duration）。
在游戏中有很多地方需要播放音乐，我将播放音乐的单位（或者情况）分为场景音频、单位音频和UI音频。所有音频的接受者都是摄像机。场景音频、UI音频为2D音频，单位音频为3D音频。场景音频、UI音频的AudioSource在摄像机上，而单位音频的AudioSource在单位身上。
场景音频主要是整个游戏的BGM播放，由摄像机作为音频的播放者。需要注意的场景BGM是轮播的，也就是说，需要有一个脚本来管理轮播的BGM，以及决定是否轮播以及什么时候播放下一首BGM。
单位是游戏中主要发声对象，而单位在游戏中我分为两种，一种是生命实体（泛指一切拥有CHaracterMono组件的GameObject对象），一种是特效，特效粒子在后面进行解释，现在先看生命实体的发声机制。
他有可能在以下情况播放音频：
两种方法设置单位音频，一是为单位设置声音模块，基于观察者模式在单位特定事件触发（攻击、死亡、施法）时播放音频，二是基于反射对各个方法进行拦截，使用AOP的方法在单位执行特定方法（Attack，Spell）时执行。
因为基于反射的方法性能低下，同时基于AOP的方法只能在方法执行前后对音频进行播放，而不能在方法执行时进行播放（这样的话，可能会造成单位闪避了，但还是播放了单位受伤的音频），所以放弃方案2，启用方案1。
下面简单介绍一下方案一：
单位基于一个声音模块CharacterAudio来对单位播放的音频进行管理，CharacterAudio在初始化时，根据CharacterModel设置的基本属性（攻击时使用什么音效，死亡时使用什么音效，此处使用的是这些音效的地址），对Resource（也可以使用AssetsBundle）进行读取，根据这些音效的地址，读取一个个实质的AudioClip对象进内存，并以字典的形式保存到单位身上（CharacterMono）。
同时，声音模块拥有一个绑定方法Bind，在初始化时，声音模块订阅单位身上的事件，当特定事件触发（攻击、死亡），播放特定的声音。
在玩家对对应的UI进行点击的时候，会有对应的音频进行播放，大致有以下事件，下面简单列举一下：
在游戏中，特效基本为GameObject对象，因为一个GameObject对象可能同时包含多个粒子特效系统，所以在创建一个特效时，一般我都以GameObject对象为初始化的模板。
在游戏中，出现特效的时机一般为以下几点：
一个单位出现特效的地点有以下几点（根据单位身上的collider来判断位置）：
对于特效出现的时机，我目前使用的方法是将特效出现的代码 耦合 到技能类BaseSkill类中，在技能类的Execute方法中，负责在双方身上创建特效对象。对于特效对象的创建，使用临时对象工厂。
一个特效对象，是有其存在时间（生命周期）的，一般来说分为以下几种：
一开始的思路是通过一个临时对象工厂（TransientObjectFactory）来负责创建临时对象并管理临时对象的生命周期，但是，因为临时对象最常用的一个方法--在N秒后自动消失，播放完自动消失等特性，工厂如果不开辟协程，将很难实现这种效果。但是没开辟一个协程，都会造成内存的浪费，故这里放弃这个方案。
我采用的方案是，创建一个用于管理特效对象生命周期的MonoBehavior组件，还是用工厂模式来创建粒子特效对象，但是，这里的工厂模式不负责管理对象的生命周期，只负责创建，在创建时，工厂对象自动为这个GameObject对象AddComponent一个EffectsLifeCycle组件类。
EffectsLifeCycle组件在Update（或FixedUpdate）方法中检查对象消失条件，一旦满足对象消失条件（如：经历一段时间、播放完粒子特效），就Destory目标对象。
对于状态型的持久型特效对象，由状态对这些特效对象进行管理。也就是说，当进入某个状态时，自动产生某些例子了特效对象。当离开状态时，自动Destroy这些粒子特效对象。
下面列举一下各种特效对象生命周期的管理：
编辑器用来对游戏中常见的数据进行编辑,如单位属性、技能属性等等。编辑器可以让非程序员完全不用与数据存储格式打交道（也就是说，使用编辑器的人不用关心到底是用哪种格式来存数据，如txt/json/xml/sqlite）。
从而可以让策划快速验证一些东西，比如某些数值公式、自定义编辑的技能的效果等待。
好的编辑器，要做的事情只有两点：
第一点，必须要完全没有学习成本，并且可以大量减少策划和程序工作量。也就是说，对于数据和公式的编辑，是不复杂的（就算是复杂的，最后也要简化成基本类型的数据填写）
第二点，必须要在策划编辑完数据后（或者编写的同时）展示数据编辑后的效果。举个例子，对于技能编辑器来说，策划必须要知道刚才编辑的技能特效在游戏中具体是什么样的，最后编辑好的技能在游戏中释放后具体是怎么样的。
对于这类游戏数据编辑器，一般来说有以下几种开发手段。
| 编辑器开发方法 | 优点 | 缺点 |
|---|---|---|
| Unity自带扩展编辑器 | 1.可以同时打开多个窗口；2.可以直接使用当前程序集（由此可以利用反射技术）；3.不污染Runtime代码；4.方便直接序列化数据到Prefab和ScriptObject | 1.布局不不方便；2.编写数据展示功能较复杂 |
| UGUI | 1.布局可视化，所见即所得；2.数据展示方便，如粒子特效、技能的运行等均可方便展示； | 1.不方便更改，每次改完编辑器的代码要重新编译生成exe文件给策划 |
| 外部编辑器（即非内部Unity编写） | 1.可定制型强；2.更符合一般编辑器的制作思路； | 1.拿不到Unity项目的运行时信息，也就是说，无法依靠反射来获得项目的信息，这意味着每次Unity项目代码更改，都要重新编写此编辑器 |
在本项目中，我选择使用UGUI来做游戏数据编辑器。
使用UGUI来做对于数据的编辑和展示基本上是最方便的，即利于程序员布局，又利于策划观察效果。
关闭弹窗 关闭弹窗是编辑器的一个十分重要的部分。
对于策划来说，他很有可能不小心关闭编辑器，这时需要编辑器主动提醒使用者对数据进行保存。
在本游戏中我使用JSON为数据的存储类型，也就是说，当使用者无意中关闭技能编辑器时，会主动提醒使用者对数据进行保存再关闭，此时可以点选保存数据后关闭。将数据打包成JSON格式保存到一个地方。
需要额外注意的点：
整体视图（即选项卡视图）：
图片、模型、特效选择器
明确技能编辑器要编辑的属性：
要展示的效果：
（伪码）
if(周围有敌人)：
消灭周围敌人
else:
进攻3、2、1塔、基地
通用型AI选择敌人时遵循权值策略，即给周围所有敌人打分，并对分数最高的敌人进行攻击。每次执行策略至少持续1s后才会重新进行打分。
分数参考（100分制）：
单位剩余生命值（优先攻击声明值少的） - 30% 单位魔法值（优先攻击魔法值多的） - 20% 单位是英雄单位（优先攻击英雄单位） - 20% 单位距离最近（优先攻击距离近的单位）- 30%
下面列出英雄AI在游戏过程中所能获得的知识:
来自: https://cloud.tencent.com/developer/article/1146677?fromSource=waitui
当人物HP降为0时，人物死亡。 进入死亡状态的单位，停止目前一切动作，播放死亡动画，同时设置isDying为true，表示人物正在垂死状态中，当死亡动画播放完毕后，Destory该单位。（这个Destory可以有多种意思，在有对象池的情况下，这个Destory可能仅仅只是收回对象回池内而已）
写到一半,复杂度骤增,放弃.......................
施法考虑到技能有指向型技能（指向型技能又分为有必须单击敌人才能释放的单指向型技能和按照一定范围释放【类似WOW里面的"暴风雪"】的技能）与原地释放技能的区别.
所以在anyState的状态更新中判断用户是否按下了释放技能的按键(关于技能冷却,是否够mp放技能,都可以放到anyState的OnUpdate里面判断).当用户按下释放技能的按键且有足够条件释放技能时,设置CharacterMono中的prePareSkill技能类且使isPrePareUseSkill为True.
设置anyState状态状态的Transition类,该Transition定义了从anyState到Spell状态的规则.规则如下:
当isPrePareUseSkill为True且释放的技能为原地释放技能时,进入Spell状态,设置isImmediatelySpell为True
当释放的技能为指向型技能时(暂时不划分单指向型技能和范围指向技能),当玩家用鼠标单击敌人的时候,进入Spell状态,设置isImmediatelySpell为False
需要注意的是,施放技能状态和其他状态最大的不同是,施放技能状态会自动结束,并回到Idle状态.
生成一张全黑的贴图,在贴图上挖洞造成战争迷雾的效果.
战争迷雾分为逻辑层和表示层，表示层用于生成遮罩在整个地图上的贴图，逻辑层负责管理每个单位的逻辑可见状态。
在战争迷雾中，有两类物体。
第一类物体，我称为表示层物体，该物体会通过他的视野来更新战争迷雾的贴图，从而增加迷雾的可见范围。
在MOBA游戏中，对于表示层物体，他应该是跟主玩家（MainPlayer）的阵营一样，换句话说，只有跟主玩家阵营一样的单位，才能在表示层中消除迷雾，对于敌方单位（非主玩家单位阵营）的物体，不会对战争迷雾的贴图进行任何更新。
第二类物体，我称为逻辑层物体，逻辑层的物体会每时每刻更新他们的逻辑可见状态（用于在代码中判断某个物体是否在战争迷雾中可见），通过他的功能描述，可以分析的到，逻辑层物体是包含本游戏的所有带有视野的物体，而他们的可见状态（IsVisble） 则是相对于主玩家（MainPlayer）来说的，如果对于主玩家来说，他们是不可见的，那么IsVisible为False。
在MOBA游戏里面，鼠标指针会因为某些游戏逻辑而产生变化。比如
大部分UI跟CharacterMono单位类强相关，为了不让他们互相引用互相依赖，这里用事件（event）对他们进行解耦。
即单位身上每一个属性的改变，都是一个事件的发生，比如HP的变化、物品、状态的增加与减少等，这时，UI就可以监控（或者说订阅）这些事件，当事件发生时，UI自动更新它的表现形式（如HP变化引起生命条的宽度变化）。
警告UI是一个很特殊的UI，当玩家试图尝试某些无法完成的操作时，警告UI有必要提醒玩家这个操作为什么不能完成。
这些操作包含的部分十分广泛，比如（仅列举一部分）：
如果按传统的做法，那警告UI的Show方法就会散落在整个代码架构的各个角落，emmm，这是个很恐怖的事，也就是说几乎游戏里全部对象都引用了一份警告UI。只要警告UI出现了一点错误，这整个游戏就跑不动了，也就是，蜘蛛网式的引用。
这里使用中介者模式解耦，玩家控制的单位做什么操作，都会产生一个事件，当事件发生时，事件发生的对象发送一个消息给中介者，中介者将这个消息传递给对该消息感兴趣的对象（就是警告UI了）
使用这种做法，警告UI和各个对象不需要互相引用，只需要保持对中介者的引用就好了。（然而我这里根本没有中介者，事件发生就直接传到感兴趣的对象那了）
下面使用注解的方法似乎并不是更好的。看了知乎【Unity3d 拖拽赋值组件与通过Find赋值组件的优点与缺点？】这个问题的讨论，思考了一下。
实际上，注解赋值组件似乎并不是一个好的选择，注解这个方法实际上只是将拖拽的复杂度转移到了代码中，同时注解还带来了一个新的问题，UI结构不能发生太大的变化，不然每个UI组件的路径都要重新进行编写。通过代码赋值组件的优点大概就是安全性高把，组件之间的引用不会像拖拽那样容易丢失。
直接使用Unity编辑器的窗口来对各级UI引用是一种比较坑爹的行为，下面图片就是一个错误示范。
可以看到一个具体的UI视图（Prefab）里需要引用许多UI控件（Text、Image等），如果直接在编辑器里对他们进行引用是不方便维护的。
为什么呢？可以想象，如果中途有几个UI需要进行添加、删除，又要手动将他们从编辑器的引用中拖拽。这是极其不方便的。还有一点就是，如果Prefab出错或丢失了，那么之前在编辑器拖好的属性又要全部重新设置，这是很让人崩溃的。
这里我采用注解+反射的方法来解决这个问题。将手动拖拽转变为由代码来管理这些引用关系，即由代码来添加引用，而不是在编辑器里设置。
主要的原理是，在每个UI控件属性上注解一个他们的Path，在代码中，根据path和transform.find来查找这些UI控件并自动引用，从而避免手动设置引用的隐患。
所有UI上挂载的MonoBehavior脚本里的需要引用的UI控件属性都要通过UIComponentAttribute来进行注解。
简单举个例子，如下所示是一个人物属性视图，用于显示MOBA游戏中人物的等级，名字，攻击力等属性。
public class AvatarView : MonoBehaviour {
//==========================
// 此View管理的UI控件
// 英雄头像
[UIComponentAttribute(path="AvaterPanel/AvaterImage")]
public RawImage AvatarImage;
// 名字
[UIComponentAttribute(path="NameText")]
public Text heroNameText;
// 等级
[UIComponentAttribute(path="LevelPanel/LevelText")]
public Text levelText;
..................
}
可以看到所有关于UGUI的控件属性(即需要在编辑器拖拽的)都加上了注解。在代码中，即通过这些注解的Path属性来对UI控件进行查找，主要是在OnStart方法中进行自动引用。
自适应算是UI设计的时候一个小难点了，主要问题在于，显示技能、物品的提示窗口 大小 是不固定的，他们的大小跟他们自身显示的信息多寡有关，当显示的信息多时，窗口大，当显示的信息少时，窗口小。
对于这种自适应问题,通常解决方法是使用Vertical Layout Group或者 Horizontal Layout Group组件，对于结构并不复杂的UI控件（即不需要布局），可以使用ContentSizeFitter控件来进行自适应。
LayoutGroup多用来对复杂的UI进行布局（比如人物状态视图，或者类魔兽 Or RM的数据编辑器）
对于第1点功能，说明这个视图不能只靠数据绑定来完成，必须要有在Update方法下运行的计算剩余时间的代码。
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。