1、左右滑动寻找所需的游戏脚本专区，点击相应的专区，寻找脚本

2、 通过搜索，输入所需的游戏名称，进入脚本专区寻找脚本

3、 进入辅助专区后，和刷微博一样，向下滑动，寻找功能符合需求的辅助。

4、注意看脚本的说明文字，了解脚本支持的分辨率和模拟器，如果脚本不支持手机或模拟器的分辨率，运行就会没反应的

上次已经让我军，友军和敌军都出现在了战场上，本章来说说如何让一个部队在战场上进行移动。在战棋游戏中，我军回合行动的时候，点击我军的某一个部队，会出现选择列表，选择【部队移动】一项后，会出现该部队可能移动的范围，然后点击范围内的某一位置，则部队就会向着这个位置移动。在这一过程中涉及到两个算法，一个是部队移动范围的搜索，另一个就是部队移动时的寻路算法。复杂指数来说，寻路算法相对复杂一些，之前研究AS3的时候，曾经写过一篇A*寻路的分析文章，有兴趣的朋友可以看一下。

其实A*寻路，主要应用在RPG或即时战略等游戏中，用于快速寻找最短路径，战棋游戏中在这方面要求并不高，所以广度优先搜索和深度优先搜索等算法都是无所谓的，不过由于我已经有了之前对AS3版本的A*算法的研究，就直接移植过来了。

原理，我就不多说了，想了解的可以直接看我的一文，下面我直接贴出完整代码，有需要的朋友可以直接拿去用。

//不在关闭列表里才开始判断 //如果该节点已经在开放列表里 //如果新G值小于或者等于旧值，则表明该路更优，更新其值 //如果该节点未在开放列表里 //如果父节点的F值较大，则与父节点交换 /*取开放列表里的最小值*/ //将第一个节点，即F值最小的节点取出，最后返回 //当二叉树只存在左节点时，比较左节点和父节点的F值，若父节点较大，则交换 //找到左节点和右节点中的较小者 //比较左节点和父节点的F值，若父节点较大，则交换 //比较右节点和父节点的F值，若父节点较大，则交换 //如果坐标可以通过，则首先检查是不是目标点 //如果搜索到目标点，则结束搜索 //如果未到达指定地点则取出f值最小的点作为循环点 //开发列表为空，寻路失败 /*判断是否可通过*/

这个寻路类通过设置queryType属性的值，可以实现【上下四方向】，【斜角四方向】和【八方向】三种寻路，下面我主要说说，这个类的用法。

LNode类是地图中的坐标节点，使用LStarQuery类来搜索路径的话，必须先给它指定地图，就是LStarQuery类中的_map属性，这个_map是一个地图数组，它内部的地图节点是由LNode或者LNode的子类来组成的。

比如说我随机生成了一个地图，0表示可通过，1表示障碍物。

这个地图显然跟LNode没有任何关系，自然也就无法直接在LStarQuery中使用，需要进行下面的变换。

//初始化寻路类的地图

经过上面的变换，就可以直接使用LStarQuery类的queryPath(star,end)来搜索路径了。参数star和end是两个坐标点，你可以使用lufylegend.js引擎中的LPoint类，也可以直接使用Object对象，只要带有x,y属性就可以了，其中star是起始点，end是目标点。

就是搜索，坐标(2,3)到坐标(20,16)之间的最短路径。

我写了一个测试的小demo，连接如下

想看效果的朋友可以点上面的连接自己试验一下，障碍物是随机生成的，如果一开始刚好没有可走的路径的话，刷新一下就好了。

所谓选择列表，就是当点击战场人物的时候，出现的移动，情报，待命等选择指令的列表，首先必须要有点击事件，在这里为了管理方便，我新建一个LSouSouSMapClick类来控制点击事件，首先添加和移除点击事件如下。

所以，当点击战场的时候，会调用下面的onUp函数和onDown函数

//点击战场，显示地形 暂略...

先来解释一下LSouSouObject.sMap.mouseIsDown这个变量的用处，它主要来控制地图的显示范围的移动，在Flash版的《三国记》中，点击地图的边缘部分，地图会向相应的方向移动，这里使用同样的方法。

具体的做法是，在LSouSouSMap的构造器中，添加时间轴

};其实原理也简单，就是当鼠标按下的时候，判断一下，鼠标是否点击在游戏画面的边缘部分，是的话，则通过设置self.backLayer的坐标让地图向相应的方向移动。

以上是地图移动部分，下面看看具体如何来添加一个选择列表。

//点击战场，显示地形 暂略...

checkCharacter函数用来判断是否点击了相应的我军，友军，或敌军，如下

当点中了战场上某一个军队，则会调用LSouSouSMapMenu.addSMenu函数，LSouSouSMapMenu类是为了管理战场上的选择列表而专门创建的，代码如下。

本次只用到了其中的一小部分，以后会继续完善，上面代码中的LSouSouSMapMenuSelect就是一个选择列表，代码如下

上面代码可以看到，只是当点击我军的情况下，才添加了选择列表，后面会继续添加友军和敌军的列表，有了上面的代码，就可以添加一个选择列表了，效果如下。

有了选择列表，当点击选择列表的【武将移动】按钮的时候，应该出现该武将的可移动的范围了，通过前面的代码可以知道，当点击【武将移动】按钮时，会调用LSouSouSMapMenuSelect.prototype.onclickMove函数，而在这个函数里又是通过LSouSouObject.sQuery.makePath函数来确定可移动路径的范围的，下面来说明一下makePath函数是如何具体来实现的。

为了便于控制战场上的寻路和寻路范围的确定，先来创建一个LSouSouSQuery类，并继承自A*算法类LStarQuery，如下

这里，不但继承了A*算法类LStarQuery，并对其进行了初始化，设定了_map的值，里面的LSouSouNode等，一会儿讲寻路的时候再具体说。首先这个LSouSouSQuery就拥有了A*算法的寻路功能，下面主要为它添加一个搜索范围的功能。

移动范围的确定，主要通过makePath，setPathAll和loopPath三个函数来确定，具体代码如下

setPathAll函数，将地图上有敌军的地方，设置直接消耗移动力为剩余所有移动力。

loopPath函数，以当前搜索点为中心，像上下左右四个方向扩散，每扩散一个范围，消耗相应的地形所在的移动力，直到移动力消耗为0。

makePath函数，主要进行开始搜索时的初始化工作。
因为在战场上，不同的地形所对应的移动消耗是不同的，不同的兵种在不同的地形上的移动消耗也是不同的，下面是兵种设定。

里面包含了该兵种的各种属性，其中Terrain属性是该兵种在不同地形上的移动消耗(Cost)和适应性(Addition)

当然，s01.smap地图中的地形设定，也要完善一下。

好了，最后，效果如下。

当遇到敌军的时候，移动力直接归零，比如下面的效果，左边是友军张飞，右边是敌军关羽，所以张飞左侧是可以到达的，而关羽的右侧是不可到达的，这就是战场上的人物遮挡，在战场上通过适当人物站位，可以有效的阻止敌军的攻击，和保护我军防御较弱的部队。

在A*寻路类LStarQuery中，是否可通过的判断是通过该节点坐标是0还是1来判断的，而战棋游戏中就不一样了，前面已经确定了可移动的范围，那么该范围内就是它可通过的路径，所以，在它的子类LSouSouSQuery中，要稍微修改一下。

这样LSouSouNode继承自LNode类，并添加了新属性isRoad，当这个属性为true的时候，表示该位置可通过。

原来的是否可通过的判断，也要相应的修改一下，如下

/*判断是否可通过*/
 

 每次搜索前的地图初始化部分，修改如下
 


 

 就是提前设定好各节点的isRoad的值，这样一来，在LSouSouSMapClick中，首先判断是否点中了移动路径的范围，代码如下。
 


 

 因为，不可能将人物移动到另一个人物之上，所以有人的地方要排除，最后，点击了路径之后，调用LSouSouObject.sMap.moveToCoordinate函数，如下。
 


 

 上面代码，如果搜索到了路径，则将路径赋值给当前正在控制的军队LSouSouObject.charaSNow，然后最后就是LSouSouCharacterS类的修改了。
 


 

 在LSouSouCharacterS类中判断路径path是否有值，有的话，根据path中的坐标节点，一个一个的移动，直到移动到最后一个节点，然后移动结束。
 

 然后，在LSouSouCharacterS的时间轴函数onframe中调用move函数就可以了，下面的预览图，刘备正在移动中。
 


 

 

 
 

 

 

 以上，本章就先讲这么多了，下一章可能会讲一讲攻击？
 
 

 本章为止的源码如下，不包含lufylegend.js引擎源码，请自己到官网下载
 
 

 

 

 ※源码运行说明：需要服务器支持，详细请看本系列文章《序》和《第一章》
 
 

 《游戏脚本的设计与开发》系列文章目录

 

 
 

这篇文章想主要说明一下在Unity3D游戏开发中是如何写游戏脚本的，对于Unity3D这套游戏引擎来说入门极快，可是要想做好却非常的难。这篇文章的目的是让哪些已经上手Unity3D游戏引擎的朋友学会如何更好的写游戏脚本。首先我们看看游戏主要是由哪几部分组成的，如下图所示，任何平台下的任何游戏核心都是由：数据、逻辑、渲染三大部分组成。

当你写过>=2个平台下的游戏时你会发现其实游戏开发很“容易”，为什么“容易”呢？因为此时你会发现所有平台下开发游戏的模式，如下图中的“数据”与“逻辑”两部分真的是完全一样的，这两部分是与游戏开发平台无关的。然而真正与游戏平台有关的紧紧是“渲染”这部分，因为各个游戏平台下的渲染接口是不同的。这也就印证了一点，能把J2ME游戏写好的程序员就必然能把IOS或Android游戏同样的写好。读到这里请结合一下你的公司情况，你可能会发现在你的技术总监两三天就能上手Unity3D游戏开发 Cocos2d游戏开发，这并不是他对游戏平台研究的透彻，而是他对游戏数据的掌控能力非常强，所以能很快玩转各个平台下的开发。

如下图所示，Unity3D这套游戏引擎在游戏开发中的权重如图中所示。其中包含100%的渲染部分 +50％左右的逻辑部分。（因为Unity3D封装了很多与逻辑相关的API供开发者使用）

下面我们回到Unity3D脚本架构的编写上，我们知道Unity3D在是可以创建游戏场景的，在每个游戏场景中又可以创建游戏对象，把每个场景的游戏对象融合在一起就是一款3D游戏。游戏场景之间属于同等级的关系，为了让游戏场景之前交互我们需要有一个凌驾所有场景之上的脚本，我称之为“全局脚本”。如下图所示，所有场景都能与这个唯一的全局脚本进行交互。举个例子，当场景切换时可将临时逻辑数据写入全局脚本中，切换完毕后再去全局脚本中取之前保存的数据，从而实现交互。（当然还有别的办法也能实现这个效果，但是我觉得这样做会更好一些，数据会更安全一些）

接着我们就进入场景中，游戏场景是由若干游戏对象组成，下面我好好说一说游戏对象。游戏对象是需要绑定游戏脚本才能完成它的生命周期。那么脚本的使命就会尤其的重要。因为游戏对象比较多那么脚本必然会出现交互的情况，如下图所示，很多初期Unity3D的项目中的脚本会编写成这个样子。错综复杂相互交互，这样编写的脚本有可能你的游戏能做出来，可是你在维护的时候团队开发的时候你会发现你的脚本非常的混乱，别的同事想改都不知道怎么改。（显然这样的作法时完全错误的）

我们想想为什么脚本之间要交互，原因很简单。是因为脚本中需要使用/调用另一条脚本或者另一条脚本对应的游戏对象某一项数据/方法，为了解决这个问题而导致最终的脚本非常混乱。为了避免这个问题，我在开发中会这么做，如下图所示，脚本之间切记不要做直接的相互交互，脚本之间只做间接的交互。每一个游戏场景都有一个凌驾所有游戏对象之上的单例脚本，在这条脚本中保存场景中所有脚本的公共数据。包括该场景的整体逻辑更新都是在这条单例脚本中完成。每条脚本都只与这个单例脚本做交互，和别的脚本一概不交互。（间接交互）

编写脚本时请注意，脚本只干属于自己最重要的事情，就跟代码中的函数一样，只干最重要的事情。切记和该条脚本无关的事情不要去管，不要在脚本中做过多的相互连带工作，让所有连带工作的话都放在全局单例脚本中来做。

这里我们举一个例子，主角砍怪或技能攻击怪，怪物受伤只到怪死亡以后屏幕播放一段胜利动画。

1.主角对象发动攻击，全局单例脚本接受按键事件后通知主角脚本播放攻击动画。

2.敌人对象接受到主角发送攻击消息时开始播放受伤动画，敌人脚本接收到主角的碰撞时询问单例脚本 主角是“普通攻击、还是技能攻击”，接着敌人播放对应的受伤动画，根据攻击类型敌人对象开始减血。

3.重复上面的操作，当敌人的血量《=0的时。敌人销毁自身对象，并且敌人脚本告诉单例脚本自己已经死亡。此时，单例脚本在调用“胜利动画”对象播放胜利动画效果。

上述逻辑我是完全按照刚刚图片中所说明的方式来写，这样做就可以很好的避免交互交互混乱的情况，其实开发中的所有类似这种交互的情况都能很好的用这个全局单例脚本来解决。希望广大Unity3D开发爱好者可以和我讨论，因为我知道架构设计没有最好只有更好。嚯嚯！！