【正文】 的戰(zhàn)斗指令后，分別發(fā)送對應的戰(zhàn)斗指令消息。并且從戰(zhàn)斗初始化消息中的battleSprites數(shù)組中，對比玩家ID（客戶端在登錄游戲后，理應早已得到玩家ID，那么在這里與battleSprites數(shù)組的玩家ID進行對比）查找自身角色和寵物的索引，用變量保存該索引，用于下達戰(zhàn)斗指令。 //目標總數(shù)（nTargetIndex數(shù)組中值不為0的個數(shù)） public ushort nReactionIndex。 //行動類型 public ushort nParam。 客戶端戰(zhàn)斗系統(tǒng)的實現(xiàn) 客戶端戰(zhàn)斗系統(tǒng)功能模塊圖54 客戶端戰(zhàn)斗系統(tǒng)功能模塊說明:(1) 戰(zhàn)斗系統(tǒng)主要包含戰(zhàn)斗角色、戰(zhàn)斗動畫和戰(zhàn)斗指令菜單三個模塊；(2) 戰(zhàn)斗指令菜單類型分為人物和寵物兩種，分別用于下達人物和寵物戰(zhàn)斗指令，并發(fā)送戰(zhàn)斗指令消息給服務器；(3) 戰(zhàn)斗角色由角色圖形、動畫控制器和血條組成，通過動畫控制器切換不同動作的動畫，主要負責戰(zhàn)斗角色的圖形顯示；(4) 戰(zhàn)斗動畫模塊主要有動畫計數(shù)、把接收到的所有動畫消息轉(zhuǎn)換為戰(zhàn)斗動畫類以及播放戰(zhàn)斗動畫三個功能；(5) 動畫計數(shù)主要是為了等待戰(zhàn)斗中所有正在播放的角色動作動畫、特效動畫播放完，角色動作動畫或特效動畫開始時會+1動畫計數(shù)，結(jié)束時會1動畫計數(shù)，動畫計數(shù)為0后，當前單位行動結(jié)束，下一個行動單位開始行動；(6) 播放戰(zhàn)斗動畫模塊根據(jù)戰(zhàn)斗動畫類數(shù)據(jù)播放不同行為的動畫（主要使用協(xié)程來控制戰(zhàn)斗角色的移動、切換戰(zhàn)斗角色的動作動畫、添加特效等）。最后，發(fā)送戰(zhàn)斗動畫消息給戰(zhàn)局所有玩家。最后，發(fā)送戰(zhàn)斗動畫消息給戰(zhàn)局所有玩家。(2) 使用技能：本文的實踐項目通過數(shù)據(jù)庫配置所有技能的相關數(shù)據(jù)，包括技能的ID、作用目標數(shù)量、特效動畫ID、特效播放方式（僅在客戶端使用）、Mp消耗、傷害公式等。下面是不同的行動類型的不同處理方式：(1) 攻擊：聲明一個戰(zhàn)斗動畫消息，nActionType賦值為“攻擊（枚舉或自定義宏）”，根據(jù)戰(zhàn)斗指令消息里的nActorIndex行動者索引和nTargetIndex目標索引從戰(zhàn)局中獲取對應的戰(zhàn)斗角色（battleSprites[nActorIndex]和battleSprites[nTargetIndex]），若目標死亡則從對應隊伍的存活者列表中隨機一個新目標索引。 倒序遍歷時，先判斷發(fā)出該戰(zhàn)斗指令消息的角色是否已經(jīng)死亡，若死亡則不能進行任何行為，直接跳出進入下一次循環(huán)。本文實踐項目從IOCP完成鍵可以獲取玩家數(shù)據(jù)進而獲取玩家所在的戰(zhàn)局指針（BATTLE*）。本文假設一個戰(zhàn)局最多能5位玩家對戰(zhàn)5位玩家，包括每位玩家可出戰(zhàn)的一個戰(zhàn)斗寵物，所以一個戰(zhàn)局最多能有20個戰(zhàn)斗角色，故battleSprites戰(zhàn)斗角色數(shù)組長度為20，讀者可根據(jù)自身游戲邏輯進行變更。 //物理防御力 short nMat。 //當前Hp short nMpMax。 //戰(zhàn)斗人物/寵物名字 UINT nImageID。 //客戶端數(shù)據(jù)（CLIENT_DATA包含客戶端IOCP完成鍵、套接字、玩家游戲數(shù)據(jù)等數(shù)據(jù)，本文不闡述，請讀者根據(jù)自身游戲服務器架構(gòu)設計）USHORT nType。 //隊伍2存活者索引listUSHORT nSpriteTotal。 服務器戰(zhàn)斗系統(tǒng)的實現(xiàn) 服務器戰(zhàn)斗系統(tǒng)相關結(jié)構(gòu)體圖51 服務器戰(zhàn)斗系統(tǒng)的相關結(jié)構(gòu)體的關系圖//戰(zhàn)局結(jié)構(gòu)體struct BATTLE{UINT nBattleID。 //行動者Hp影響（＜0:扣血，＞ 0:加血，0=無任何影響） [MarshalAs(, SizeConst = 10)] public short[] nActorMp。 //行動者索引 [MarshalAs(, SizeConst = 10)] public ushort[] nTargetIndex。 //結(jié)構(gòu)體長度}。 //目標索引public ushort nParam。 //結(jié)構(gòu)體長度public ushort nActorType。 //最大MPpublic short nMp。 //戰(zhàn)斗人物/寵物名字public uint nImageID。 //戰(zhàn)局ID[MarshalAs(, SizeConst = 20)]public BATTLE_SPRITE_INIT[] battleSprites。以下是Unity客戶端（C）中定義的相關結(jié)構(gòu)體消息，服務器的定義與其一致，但由于服務器（C++）與客戶端（C）的編程語言不同所以定義語法有些許區(qū)別。 回合制網(wǎng)游戰(zhàn)斗系統(tǒng)客戶端實現(xiàn)思路（1）若接收到“戰(zhàn)斗初始化消息”，則進入戰(zhàn)斗，并根據(jù)消息里的數(shù)據(jù)，初始化每一個戰(zhàn)斗角色；（2）顯示人物戰(zhàn)斗指令菜單，根據(jù)玩家的操作，發(fā)送“戰(zhàn)斗指令消息”，人物戰(zhàn)斗指令菜單消失；（3）若沒有參戰(zhàn)寵物，直接跳到下一步，若有參戰(zhàn)寵物，顯示寵物戰(zhàn)斗指令菜單，根據(jù)玩家的操作，發(fā)送“戰(zhàn)斗指令消息”，寵物戰(zhàn)斗指令菜單消失；（4）接收并保存每一個來自服務器的“動畫消息”或“動畫播放消息”；（5）收到“動畫播放消息”后，讀取并處理每一個“動畫消息”，轉(zhuǎn)化為對應等量的戰(zhàn)斗動畫類并用容器保存，遍歷容器播放所有動畫；（6）當前回合所有戰(zhàn)斗動畫播放完后，判斷雙方陣亡情況，若一方符合戰(zhàn)敗條件（所有角色陣亡或者所有人物陣亡，具體根據(jù)游戲設定決定）則結(jié)束戰(zhàn)斗，否則回到步驟（2）進入下一個回合，如此循環(huán)。這么看來，協(xié)程用在回合制戰(zhàn)斗動畫的播放很是適合。}協(xié)程Attack()能夠簡單清晰實現(xiàn)“控制某個物體移動到某個地點，完成后進行攻擊，攻擊完成后返回到某個地點”，一步完成之后再進行下一步。協(xié)同程序示例代碼：IEnumerator Attack(BATTLE_ANIM battleAnim){ BattleSprite sprite = battleSprites[ 1]。 …… } ……}有限狀態(tài)機方案下，Update方法每幀檢測記錄狀態(tài)的變量state，從而決定究竟要執(zhí)行何種行為，當行為執(zhí)行完或者某個事件觸發(fā)時，通過修改狀態(tài)變量state，改變執(zhí)行的行為。 實現(xiàn)方案一：有限狀態(tài)機這是筆者最先想到的方案，畢竟有限狀態(tài)機在游戲編程中實在極為常用，相信不少讀者也會率先聯(lián)想到這種方式。例如動畫數(shù)據(jù)是“某個角色攻擊某個角色”，動畫內(nèi)容便是“攻擊者移動到目標面前并播放攻擊動作動畫，目標播放受傷動作動畫，顯示扣血，攻擊者返回到本來的位置”；再例如動畫數(shù)據(jù)是“某個角色使用技能攻擊某個角色”，動畫內(nèi)容便是“施法者播放施法動作動畫，然后在目標身上播放技能特效，等到特效播放到某一幀，目標播放受傷動作動畫，顯示扣血”。 分包算法流程圖圖22 分包算法流程圖說明：(1) 定義或獲得一個容量足夠大的環(huán)形緩沖區(qū)（具體大小請根據(jù)實際情況考慮）；(2) 接收到數(shù)據(jù)后，往環(huán)形緩沖區(qū)尾部添加數(shù)據(jù)；(3) 判斷緩沖區(qū)的數(shù)據(jù)長度是否大于等于4（消息頭的長度），本文實踐項目的結(jié)構(gòu)體消息頭由消息類型（ushort）和消息長度（ushort）組成，共4字節(jié)。因此，我們需要一個分包算法來檢測粘包情況并進行分包，以便正確讀取所有來自發(fā)送方的消息。 }……} 單例設計模式在Unity中的運用在Unity中使用單例設計模式，有時會有額外的意義。 private CircularBuffer _circularBuf = new CircularBuffer(4096)。 private string _web = 。 單例設計模式的運用單例設計模式下的類往往具有通用性或全局性，用于保存全局數(shù)據(jù)，需要訪問其變量的外部類只需要通過單例類的靜態(tài)方法即可獲得其唯一的實例，從而訪問其內(nèi)部變量?？梢圆聹y到，所控制的物體可能通過Update方法或者其他方法每幀在移動，直到移動到目標地點，才執(zhí)行主線程后面的代碼。 yield return 0。根據(jù)協(xié)程的特點，協(xié)程中可以使用“循環(huán)+條件判斷+yield return 幀數(shù)/new WaitForSeconds(秒數(shù))”實現(xiàn)每隔多少幀或者多少秒后再次執(zhí)行條件判斷語句，當判斷語句滿足跳出循環(huán)，從而讓協(xié)程代碼執(zhí)行完結(jié)束，回到主線程繼續(xù)執(zhí)行后續(xù)代碼，利用此功能，可以很方便地實現(xiàn)某物體達到某狀態(tài)后再執(zhí)行程序。當協(xié)程中的代碼執(zhí)行完或者使用yield break語句時，協(xié)程才會結(jié)束，并且返回到主線程中的創(chuàng)建該協(xié)程的語句的位置，繼續(xù)執(zhí)行后面的代碼。角色的屬性和職業(yè)也可以隨時更改，以便隨時改變戰(zhàn)術和改變在隊伍里中的定位。游戲主要玩法是玩家與玩家之間的回合制戰(zhàn)斗PK。從廣義上來說，回合制游戲范圍非常廣，棋牌、卡牌、戰(zhàn)棋策略、回合制戰(zhàn)斗模式都能歸為此類。本人希望在研究和實現(xiàn)回合制戰(zhàn)斗系統(tǒng)的基礎上，能夠找到突破和創(chuàng)新點。而回合制戰(zhàn)斗系統(tǒng)側(cè)重于休閑、戰(zhàn)略、配合，戰(zhàn)斗節(jié)奏慢。除此以外，本文還對戰(zhàn)斗系統(tǒng)實現(xiàn)所涉及到的相關技術如Unity引擎的協(xié)同程序、單例設計模式和分包算法進行簡要介紹。在開發(fā)環(huán)境方面，服務器采用國內(nèi)IOCP高性能開源框架“HPSocket”(Windows平臺)，并且連接到Mysql數(shù)據(jù)庫，客戶端采用近年比較火熱的強大跨平臺引擎Unity3D（2D，C）并且使用Sqlite作為嵌入式數(shù)據(jù)庫。即時制戰(zhàn)斗系統(tǒng)側(cè)重于刺激、反應、操作性，戰(zhàn)斗節(jié)奏快。本人也是熱衷于回合制戰(zhàn)斗系統(tǒng)的玩家之一，可縱觀近年來國內(nèi)回合制游戲的發(fā)展，國內(nèi)回合制游戲一直止步不前，《軒轅劍》系列、《仙劍奇?zhèn)b傳》系列、《古劍奇譚》銷量下降，MMORPG《夢幻西游》也有降溫跡象，甚至國內(nèi)大多回合制網(wǎng)游只是復制在《夢幻西游》或“換皮”，缺少創(chuàng)新和突破。項目將在2017年6月開源，開源地址 By 江正覬 第1章 緒論 回合制游戲簡介 廣義上的回合制游戲凡“我方與敵方在單個回合內(nèi)輪流行動，只有輪到我方（自己）的回合或者是新的回合開始時，才可進行行動”的游戲，都可歸類為廣義上的回合制游戲，而且絕大大多數(shù)情況下，單個回合內(nèi)敵我雙方行動次數(shù)相同。 實踐項目《PKer》簡介《PKer》是一個以回合制競技和社交為賣點的PC和移動端跨平臺網(wǎng)絡游戲，是游戲與社交APP的融合體。更強的裝備和稀有的寵物通過合成、付費租用等渠道獲得。當協(xié)程創(chuàng)建后，主線程中創(chuàng)建協(xié)程的語句后面的代碼塊會“掛起”，直到協(xié)同程序結(jié)束后，才會繼續(xù)執(zhí)行創(chuàng)建協(xié)程語句后面的代碼。 Unity協(xié)同程序的運用協(xié)程廣泛地運用在計時、延遲、控制物體運動、等待物體狀態(tài)的改變、有順序地讓物體執(zhí)行一系列動作等方面上。協(xié)同程序Move方法public IEnumerator Move(Vector3 destPos){ while ( != destPos) { = (, destPos, * )。直到while不滿足循環(huán)條件（ == destPos），則協(xié)程能夠完成使命執(zhí)行完成并返回。只有通過類的一個靜態(tài)方法可以創(chuàng)建或獲取有且只有唯一一個的對象實例。 private static Socket _socket。 private byte[] _buf=new byte[1024]。 } return _client_socket。由于粘包現(xiàn)象的存在，如果不進行分包，接收方可能只能讀取到粘包數(shù)據(jù)的頭一個消息，后面的消息將會丟失，甚至影響后續(xù)接收的消息，嚴重影響程序的運行。下面是環(huán)形緩沖區(qū)（CricularBuffer）類的UML類圖（C++）：圖 21 環(huán)形緩沖區(qū)UML類圖說明：buf：指向緩沖區(qū)的指針front：緩沖區(qū)的數(shù)據(jù)的起始位置rear：緩沖區(qū)的數(shù)據(jù)的尾部位