基于unity的回合制网游战斗系统的研究与实现.docx

基于unity的回合制网游战斗系统的研究与实现.docx

《基于unity的回合制网游战斗系统的研究与实现.docx》由会员分享，可在线阅读，更多相关《基于unity的回合制网游战斗系统的研究与实现.docx（47页珍藏版）》请在冰豆网上搜索。

基于基于unity的回合制网游战斗系统的研究与实的回合制网游战斗系统的研究与实现现摘要本文主要阐述网络回合制战斗系统的实现，包括回合制战斗系统的整个流程（战斗开始、玩家下达战斗指令、战斗动画、战斗结束），和网络回合制战斗系统常见的主要功能（攻击、使用技能、使用物品）的实现，并且在游戏项目PKer中进行实践和测试。

在开发环境方面，服务器采用国内IOCP高性能开源框架“HP-Socket”（Windows平台），并且连接到Mysql数据库，客户端采用近年比较火热的强大跨平台引擎Unity3D（2D，C#）并且使用Sqlite作为嵌入式数据库。

除此以外，本文还对战斗系统实现所涉及到的相关技术如Unity引擎的协同程序、单例设计模式和分包算法进行简要介绍。

关键词回合制战斗系统,网络游戏，Unity3D，协同程序，游戏编程ABSTRACTThisarticlemainlyexpoundstheimplementationofnetworkturn-basedcombatsystem,includingthewholeprocessofturn-basedcombatsystem（battlebegins,theplayersfightinginstructions,combatanimation,battleends）,andthemainfunctionofcommon（attack,usingskills,usingitems）implementation,andinthegamePKerinpracticeandtestoftheproject.Intheaspectofdevelopmentenvironment,C+IOCPserverwithWindowsplatformandconnecttotheMysqldatabase,theclientusesUnity3D（2D,C#）andusesSqliteasanembeddeddatabase.Inadditiontothis,thisarticlealsoinvolvedtocombatsystemrelatedtechnologiessuchastheUnityenginecoroutines,singletondesignpatternandthesubcontractalgorithmarebrieflyintroduced.KEYWORDSTurn-basedcombatsystem,onlinegame,Unity3D,Coroutine,Singletondesignpattern目录前言1第1章绪论21.1回合制游戏简介21.1.1广义上的回合制游戏21.1.2狭义上的回合制游戏21.2回合制战斗系统简介21.3实践项目PKer简介2第2章开发环境和部分涉及技术简介42.1开发环境简介42.2Unity协同程序42.2.1Unity协同程序简介42.2.2Unity协同程序的运用42.3单例设计模式52.3.1单例设计模式52.3.2单例设计模式的运用62.3.3单例设计模式在Unity中的运用72.4分包算法72.4.1分包的原因72.4.2环形缓冲区（CircularBuffer）72.4.3分包算法流程图9第3章战斗动画实现方案的研究与对比113.1研究背景113.2实现方案一：

有限状态机113.3实现方案二：

协同程序（Coroutine）123.4方案抉择结论13第4章回合制网游战斗系统设计144.1回合制网游战斗系统设计144.2回合制网游战斗系统服务器实现思路154.3回合制网游战斗系统客户端实现思路154.4战斗系统框架结构（以实践项目PKer为例）16第5章回合制战斗系统实现185.1战斗系统相关消息结构体的定义185.2服务器战斗系统的实现205.2.1服务器战斗系统相关结构体205.2.2初始化一个战局235.2.3接收客户端的战斗指令消息235.2.4处理战斗指令并发送动画消息245.2.5说明275.3客户端战斗系统的实现275.3.1客户端战斗系统功能模块285.3.2客户端战斗系统相关数据类型285.3.3进入战斗后初始化战斗角色295.3.4下达战斗指令并发送战斗指令消息295.3.5接收战斗动画消息305.3.6收到战斗动画播放消息并播放战斗动画305.3.7战斗动画实现细述35第6章项目测试396.1进入战斗测试396.2普通攻击功能测试396.3使用技能功能测试406.4使用物品功能测试41结论43参考文献44致谢45前言随着网络的普及与迅速发展，网络游戏已经成为电子游戏中的主流。

网络游戏的战斗系统主要可分为即时制和回合制两种模式。

即时制战斗系统侧重于刺激、反应、操作性，战斗节奏快。

而回合制战斗系统侧重于休闲、战略、配合，战斗节奏慢。

早期的电子游戏由于设备硬件条件有限，大多采用回合制战斗系统。

随着科技的发展和设备硬件的提升，如今回合制游戏的数量比例有所下降，但回合制游戏在国内游戏市场依旧占据着想当大的份额，仍有大量玩家热衷这种战斗模式，几款众所周知的国产单机游戏如轩辕剑系列、仙剑奇侠传系列、古剑奇谭系列以及国内在线人数最多的MMORPG梦幻西游均是采用回合制战斗系统的游戏。

本人也是热衷于回合制战斗系统的玩家之一，可纵观近年来国内回合制游戏的发展，国内回合制游戏一直止步不前，轩辕剑系列、仙剑奇侠传系列、古剑奇谭销量下降，MMORPG梦幻西游也有降温迹象，甚至国内大多回合制网游只是复制在梦幻西游或“换皮”，缺少创新和突破。

本人希望在研究和实现回合制战斗系统的基础上，能够找到突破和创新点。

同时在游戏编程方面，即时制逻辑较为简单明了清晰，而回合制则比较繁琐复杂，而且在Unity引擎上实现回合制战斗系统的相关资料较少。

综上原因，本人撰写本文，希望能对志同道合者有所启发，同时也寻求学术交流。

项目将在2017年6月开源，开源地址https:

/By江正觊2016.6第1章绪论1.1回合制游戏简介1.1.1广义上的回合制游戏凡“我方与敌方在单个回合内轮流行动，只有轮到我方（自己）的回合或者是新的回合开始时，才可进行行动”的游戏，都可归类为广义上的回合制游戏，而且绝大大多数情况下，单个回合内敌我双方行动次数相同。

从广义上来说，回合制游戏范围非常广，棋牌、卡牌、战棋策略、回合制战斗模式都能归为此类。

1.1.2狭义上的回合制游戏狭义上的回合制游戏，是从广义回合制游戏中细分，特指回合制战斗模式的游戏，与即时制战斗模式相对。

1.2回合制战斗系统简介在回合制战斗模式下，每个回合开始时，敌我双方各自为双方战斗角色下达战斗指令，待双方所有角色下达完战斗指令或超过时限（回合制网络游戏均会设置下达战斗指令的时间限制）后双方所有角色开始行动，一般根据角色自身“速度（敏捷）”的属性数值轮流行动，期间若果某一方符合战败条件（某方全体阵亡或全体人物阵亡）则战斗结束，如所有角色行动完后敌我双方均没符合战败条件，则进入下回合，如此循环。

1.3实践项目PKer简介PKer是一个以回合制竞技和社交为卖点的PC和移动端跨平台网络游戏，是游戏与社交APP的融合体。

游戏主要玩法是玩家与玩家之间的回合制战斗PK。

通过移动设备GPS定位功能（PC端无法使用），能够快速搜索在你身边的游戏房间和玩家，与其开展战斗。

游戏提供一定数量的基础装备和宠物让玩家任意领取，故玩家可以随时更换装备和宠物，新玩家也能以此为基础投入到战斗中。

更强的装备和稀有的宠物通过合成、付费租用等渠道获得。

角色的属性和职业也可以随时更改，以便随时改变战术和改变在队伍里中的定位。

第2章开发环境和部分涉及技术简介2.1开发环境简介本文实践项目的服务器采用国内IOCP开源框架“HP-Socket”，并且连接到Mysql数据库，客户端采用近年比较火热的强大跨平台引擎Unity3D（2D，C#）并且使用Sqlite作为嵌入式数据库。

2.2Unity协同程序2.2.1Unity协同程序简介协同程序（Coroutine），通常简称“协程”，顾名思义，是一段协助的程序（方法），很多人以为它是另开一个线程执行一段程序，其不然，实际上它是从主线程每帧或每隔一定时间调用的程序。

当协程创建后，主线程中创建协程的语句后面的代码块会“挂起”，直到协同程序结束后，才会继续执行创建协程语句后面的代码。

当协程中的代码执行完或者使用yieldbreak语句时，协程才会结束，并且返回到主线程中的创建该协程的语句的位置，继续执行后面的代码。

协程中使用yieldreturn帧数/newWaitForSeconds（秒数）语句可以实现隔多少帧或多少秒后再执行后续代码。

另外协程可以嵌套协程，利用协程的特点和嵌套，可以实现很多复杂和有趣的功能，十分强大。

2.2.2Unity协同程序的运用协程广泛地运用在计时、延迟、控制物体运动、等待物体状态的改变、有顺序地让物体执行一系列动作等方面上。

根据协程的特点，协程中可以使用“循环+条件判断+yieldreturn帧数/newWaitForSeconds（秒数）”实现每隔多少帧或者多少秒后再次执行条件判断语句，当判断语句满足跳出循环，从而让协程代码执行完结束，回到主线程继续执行后续代码，利用此功能，可以很方便地实现某物体达到某状态后再执行程序。

示例代码：

主线程代码StartCoroutine（actor.Move（getAttackPosition（nTargetIndex）;Inti=0;协同程序Move方法publicIEnumeratorMove（Vector3destPos）while（transform.localPosition!

=destPos）transform.localPosition=Vector3.MoveTowards（transform.localPosition,destPos,GlobalData.BATTLE_SPRITE_MOVE_SPEED*Time.deltaTime）;yieldreturn0;上述代码中，主线程StartCoroutine方法创建一个协程Move，待协程Move执行完成返回后，主线程才执行i=0语句。

可是协程Move的返回条件有点特殊，yieldreturn0语句表示协程运行到此处挂起，等下一帧再从本语句继续运行，由于yieldreturn0在while循环内，所以不管yieldreturn0多少次，都依然在while循环内，而且while循环每一帧循环一次。

直到while不满足循环条件（即transform.localPosition=destPos），则协程能够完成使命执行完成并返回。

可以猜测到，所控制的物体可能通过Update方法或者其他方法每帧在移动，直到移动到目标地点，才执行主线程后面的代码。

2.3单例设计模式2.3.1单例设计模式单例设计模式是常见和简单的一种软件设计模式，单例模式下的类能确保在整个工程项目中只允许存在最多一个实例对象。

单例模式下的类通常不能直接通过构造函数new出一个实例，而且构造函数通常会设置成私有，外部不可访问。

只有通过类的一个静态方法可以创建或获取有且只有唯一一个的对象实例。

2.3.2单例设计模式的运用单例设计模式下的类往往具有通用性或全局性，用于保存全局数据，需要访问其变量的外部类只需要通过单例类的静态方法即可获得其唯一的实例，从而访问其内部变量。

示例代码：

publicclassClientSocket/单例类ClientSocketprivatestaticClientSocket_client_socket;/保存本类的唯一实例privatestaticMessageManager_msg_mgr;privatestaticSocket_socket;privatestring_web=;privateIPAddress_ip;privateint_port=8000;privatebyte_buf=newbyte1024;privateCircularBuffer_circularBuf=newCircularBuffer（4096）;privateClientSocket（）publicstaticClientSocketgetInstance（）if（_client_socket=null）/若实例不存在则创建，实例已存在则直接返回_client_socket=newClientSocket（）;_msg_mgr=MessageManager.getInstance（）;return_client_socket;2.3.3单例设计模式在Unity中的运用在Unity中使用单例设计模式，有时会有额外的意义。

在Unity中，通常一个类会作为一个组件挂载到一个物体上，可是如果进行了场景切换，当前场景所有物体以及物体所挂载的所有组件都会被销毁，这时如果想要所有场景都能访问一个类的实例以及其变量，则需要把该类设置成单例类，并且不能继承MonoBehaviour，而且不能挂载到任何一个物体上，这样就可以保证整个游戏中不管场景怎么切换，该类的实例一直存在，而且只有唯一一个实例，所有场景均可通过静态方法获取实例并且访问。

2.4分包算法2.4.1分包的原因TCP在发送消息时，如果发送间隔太短，发送方有可能出现一次发送多个消息的情况，而接收方便会一次接收到多个消息，另外，很多时候网络情况较差或不稳定，接收方迟迟收不到消息，过一段时间有可能一次过接收到此前该接收的多个消息，这些现象就是粘包。

由于粘包现象的存在，如果不进行分包，接收方可能只能读取到粘包数据的头一个消息，后面的消息将会丢失，甚至影响后续接收的消息，严重影响程序的运行。

因此，我们需要一个分包算法来检测粘包情况并进行分包，以便正确读取所有来自发送方的消息。

2.4.2环形缓冲区（CircularBuffer）在分包算法中，我们需要用到一个数据结构环形缓冲区。

之所以要用到环形缓冲区，是因为分包前我们要把接收到的所有数据存放在一个缓冲区中，分包时根据消息的长度从缓冲区里取数据，取出后缓冲区相应地移除对应的数据，这样反复频繁进行添加和删除操作如果只用普通的缓冲区（byte数组/char数组）的话，则要频繁地移动数据存放的位置，十分影响程序运行效率，为此需要引入环形缓冲区。

下面是环形缓冲区（CricularBuffer）类的UML类图（C+）：

图2-1环形缓冲区UML类图说明：

buf：

指向缓冲区的指针front：

缓冲区的数据的起始位置rear：

缓冲区的数据的尾部位置lock：

用于多线程同步的临界区，防止多个线程访问修改缓冲区数据size：

缓冲区数据的长度capacity：

缓冲区的容量CircularBuffer：

构造函数，创建一个指定容量为参数大小的缓冲区CircularBuffer：

析构函数，释放缓冲区clear：

清空缓冲区pushBuf：

往缓冲区尾部添加数据popBuf：

从缓冲区头部得到数据，并且缓冲区移除相应数据getBuf：

从缓冲区头部得到数据，但缓冲区不移除数据isEmpty：

判断缓冲区是否为空由于环形缓冲区使用front起始位置和rear尾部位置记录数据存放的位置，添加或移除数据不需要移动数据的储存位置，运行效率高。

2.4.3分包算法流程图图2-2分包算法流程图说明：

（1）定义或获得一个容量足够大的环形缓冲区（具体大小请根据实际情况考虑）；

（2）接收到数据后，往环形缓冲区尾部添加数据；（3）判断缓冲区的数据长度是否大于等于4（消息头的长度），本文实践项目的结构体消息头由消息类型（ushort）和消息长度（ushort）组成，共4字节。

若缓冲区数据长度小于消息头长度，则无法获取第一条消息的长度，也无法分包，也表明数据接收不全，回到

（2）继续接收数据，不进行任何操作；若缓冲区数据长度大于等于消息头长度，则开始进行分包；（4）从缓冲区头部getBuf获得4字节数据（消息头），不改变缓冲区数据，从消息头得到第一包消息的长度；（5）判断缓冲区数据长度，若缓冲区数据长度大于第一包消息的长度，则第一包消息接收完并可取，根据第一包消息的长度popBuf得到第一包消息数据，并且缓冲区移除相应数据，处理该消息；若缓冲区数据长度小于第一包消息长度（此时缓冲区数据长度大于等于4，但是小于第一包消息的长度），则说明第一包消息还没接收完，回到

（2）继续接收，不进行任何操作；（6）回到（4）,一直循环。

第3章战斗动画实现方案的研究与对比3.1研究背景笔者认为回合制战斗系统实现的最大难点，那无疑就是客户端战斗动画的实现。

回合制战斗系统的战斗动画，不是平常我们说的“动画”，它是由数据转换过来的动态动画，动画内容由数据决定。

例如动画数据是“某个角色攻击某个角色”，动画内容便是“攻击者移动到目标面前并播放攻击动作动画，目标播放受伤动作动画，显示扣血，攻击者返回到本来的位置”；再例如动画数据是“某个角色使用技能攻击某个角色”，动画内容便是“施法者播放施法动作动画，然后在目标身上播放技能特效，等到特效播放到某一帧，目标播放受伤动作动画，显示扣血”。

上述例子已经是回合制战斗系统最基本的战斗动画，更不用说多次攻击或者多次施法，可谓难上加难。

更何况，战斗动画的质量极大影响回合制游戏的可玩性，而且回合制战斗除了玩家下达战斗指令外，其余时间全部都在播放战斗动画上。

所以，笔者认为客户端的战斗动画实现是整个回合制战斗系统的重点和难点，为了正确谨慎地抉择实现方案，少走弯路，额外对战斗动画的实现展开了研究。

3.2实现方案一：

有限状态机这是笔者最先想到的方案，毕竟有限状态机在游戏编程中实在极为常用，相信不少读者也会率先联想到这种方式。

有限状态机代码示例：

voidUpdate（）switch（state）case（int）State.Standby:

break;case（int）State.Attack:

break;case（int）State.Magic:

break;有限状态机方案下，Update方法每帧检测记录状态的变量state，从而决定究竟要执行何种行为，当行为执行完或者某个事件触发时，通过修改状态变量state，改变执行的行为。

优点：

（1）灵活可变，随时随地都可以改变状态，从而改变执行的行为缺点：

（1）每帧都需要检测状态变量，影响程序运行效率；

（2）如果要实现一系列复杂的行为，代码量大而且凌乱，逻辑复杂，例如要实现“攻击者移动到目标面前，攻击者播放攻击动画，目标播放受伤动画，显示扣血，攻击者返回原本位置”这样的功能，可能需要不止一个状态机；（3）Update方法变得臃肿，很多时候Update还需要做其他事情；3.3实现方案二：

协同程序（Coroutine）在感觉方案一可行性不高的情况下，本人开始寻求其他实现方案，直到发现协同程序（Coroutine）。

若读者不了解协程可阅本文第二章，协同程序在本文第2章有简略介绍，此处不再作介绍。

个人感觉Unity的协同程序跟Cocos2d的CCSequence动作有点像，都能很方便实现按顺序执行一系列动作，而且协同程序比CCSequence更灵活。

协同程序示例代码：

IEnumeratorAttack（BATTLE_ANIMbattleAnim）BattleSpritesprite=battleSpritesbattleAnim.nActorIndex-1;yieldreturnStartCoroutine（sprite.Move（getAttackPosition（nTargetIndex）;yieldreturnStartCoroutine（sprite.AttackAnim（）;yieldreturnStartCoroutine（sprite.Back（actor.vOrigPos）;协程Attack（）能够简单清晰实现“控制某个物体移动到某个地点，完成后进行攻击，攻击完成后返回到某个地点”，一步完成之后再进行下一步。

优点：

（1）不需要在Update每帧调用，协程开启后根据代码逻辑等待（每）n帧/n秒自动调用；

（2）代码逻辑清晰（3）能够很好实现按顺序执行一系列复杂的行为缺点：

（1）如要中途终止协程，有一定的终止条件

（2）没状态机灵活，难以临时转变行为3.4方案抉择结论显而易见，经过笔者的研究和深思熟虑，本文采用了协同程序方案。

理由很简单，回合制战斗动画几乎全避开了协程的缺点，体现了协程的优点。

因为回合制战斗动画是由服务器发来的动画数据转换的，数据自始至终没有改变，客户端只负责播放动画效果，并没有修改数据，那么从数据转化为动画那刻开始，动画就不可能有变化或者中途终止，并不需要程序的灵活性。

这么看来，协程用在回合制战斗动画的播放很是适合。

另外，读者也可考虑行为树方案，由于笔者时间和能力有限，截至目前未能深入学习研究行为树，不知是否能比协程更好地实现战斗动画，所以本文未能提及，恳请体谅。

第4章回合制网游战斗系统设计4.1回合制网游战斗系统设计我们从回合制网游中不难发现，在客户端面前，我们可以看到一场回合制战斗可划分为以下阶段：

进入战斗-玩家下达战斗指令（很多情况下需要下达人物和宠物两个战斗指令）-战斗动画-战斗结束。

经过本人对上述战斗过程的研究、思考和分析，得出个人的回合制战斗系统实现思路，战斗系统流程图如图：

图4-1回合制网游战斗系统流程图4.2回合制网游战斗系统服务器实现思路

（1）战斗开始发送“战斗初始化消息”给客户端，“战斗初始化消息”包含所有战斗角色（人物和宠物）的名字、图形及动画控制器ID、最大Hp、当前Hp、最大Mp、当前Mp等数据，客户端只关心需要显示的内容；

（2）根据战斗角色的数量，等待接收并保存数量与角色数量想当的来自客户端的“战斗指令消息”，即等待所有战斗角色都下达完战斗指令；（3）接收到足够数量的“角色战斗指令消息”后，根据角色的“速度”属性数值，倒序（即速度高者先行动）处理每一个战斗指令所造成的影响，并更新服务器各个角色的数值，发送对应的“动画消息”给所有客户端，每处理一个“战斗指令消息”就发送一个对应的“动画消息”；（4）待所有“战斗指令消息”处理完并发送完对应的“动画消息”后，发送“动画播放消息”；（5）判断双方角色的阵亡情况，若一方符合战败条件（所有角色阵亡或者所有人物阵亡，具体根据游戏设定决定）则结束战斗，否则回到步骤

（2）进入下一个回合，如此循环。

4.3回合制网游战斗系统客户端实现思路

（1）若接收到“战斗初始化消息”，则进入战斗，并根据消息里的数据，初始化每一个战斗角色；

（2）显示人物战斗指令菜单，根据玩家的操作，发送“战斗指令消息”，人物战斗指令菜单消失；（3）若没有参战宠物，直接跳到下一步，若有参战宠物，显示宠物战斗指令菜单，根据玩家的操作，发送“战斗指令消息”，宠物战斗指令菜单消失；（4）接收并保存每一个来自服务器的“动画消息”或“动画播放消息”；（5）收到“动画播放消息”后，读取并处理每一个“动画消息”，转化为对应等量的战斗动画类并用容器保存，遍历容器播放