轉(zhuǎn)載請(qǐng)自覺標(biāo)明原創(chuàng)出處
原文鏈接：http://gameislife.info/archives/category/游戲開發(fā)
 
游戲服務(wù)器開發(fā)技術(shù)小結(jié)
1 概述
本文從開發(fā)者的視角，淺析游戲服務(wù)器開發(fā)涉及到的幾個(gè)技術(shù)層面，并說明這幾個(gè)層面我們可以選擇的解決方案。

一般地，會(huì)把游戲服務(wù)器的架構(gòu)劃分如下三層：網(wǎng)絡(luò)接入層、游戲邏輯層、數(shù)據(jù)存儲(chǔ)層，這樣劃分的主要目的是：

將底層通信與業(yè)務(wù)邏輯處理解耦合；
將業(yè)務(wù)邏輯處理與數(shù)據(jù)存儲(chǔ)解耦合；
有利于運(yùn)營部署與擴(kuò)展；
游戲服務(wù)器開發(fā)框架整體視圖，如下所示：

2 網(wǎng)絡(luò)接入層
網(wǎng)絡(luò)接入層主要任務(wù)是解決來自客戶端大量并發(fā)請(qǐng)求和負(fù)載均衡的處理，考量該層的主要性能指標(biāo)是：高吞吐、低延遲、均負(fù)載，即既能同一時(shí)刻處理大批量的客戶端請(qǐng)求（每秒至少1萬個(gè)請(qǐng)求以上），又能快速響應(yīng)，并且均負(fù)載的分布處理這些請(qǐng)求。

本層的基本技術(shù)要點(diǎn)如下圖所示：

2.1 高并發(fā)處理
2.1.1 http接入
（1）優(yōu)點(diǎn)

低成本：有成熟的開源webserver；
快速開發(fā)的效率：一請(qǐng)求一應(yīng)答的協(xié)議通訊，使用游戲邏輯處理相當(dāng)簡單；
低門檻：基于web的應(yīng)用，玩家無需下載客戶端，也不用擔(dān)心防火墻等問題；
（2）不足

難以處理服務(wù)器廣播事件；
文本協(xié)議會(huì)占用較大流量；
2.1.2 socket接入
（1）優(yōu)點(diǎn)

功能強(qiáng)大：能靈活處理服務(wù)器廣播事件；
高效通信：二進(jìn)制協(xié)議較文本協(xié)議能大幅度節(jié)省帶寬，并且通信包可做組播等處理，以有效降低流量；
（2）不足

實(shí)現(xiàn)成本較高，開發(fā)難度較大；
可能會(huì)遭遇部分辦公室玩家的機(jī)器通訊端口被屏蔽，無法穿透防火墻等問題；
2.2 IP路由與負(fù)載均衡
這塊跟服務(wù)器集群和IDC部署密切相關(guān)，主要是為了讓整個(gè)服務(wù)器集群能最大化其處理能力，尤其是在業(yè)務(wù)高峰時(shí)期，整個(gè)服務(wù)器集群能均衡平滑的應(yīng)對(duì)客戶端請(qǐng)求，不至于出現(xiàn)某個(gè)單點(diǎn)服務(wù)器出現(xiàn)很高負(fù)載時(shí)，其它同層服務(wù)器較空閑的情況。

目前，這塊公司和開源界都有很成熟的解決方案，故在此不多贅述。

2.3 應(yīng)用場(chǎng)景
目前市面上絕大多數(shù)的Social Game和SLG類的WebGame均采用http通訊；
RPG類的WebGame和有源客戶端網(wǎng)游均采用socket通訊；
3游戲邏輯層
游戲邏輯層主要是處理游戲的具體業(yè)務(wù)邏輯，根據(jù)游戲類型和部署的不同，它會(huì)由一個(gè)或多個(gè)進(jìn)程組成。其主要組成可由下圖說明

3.1 基礎(chǔ)系統(tǒng)
基礎(chǔ)系統(tǒng)包含的內(nèi)容基本上為各個(gè)游戲業(yè)務(wù)邏輯所公有的東西。

游戲?qū)ο髢?nèi)存管理：這是業(yè)務(wù)系統(tǒng)中最基本也是最重要的系統(tǒng)之一，目前，我們采用基于共享內(nèi)存的預(yù)分配機(jī)制，來管理游戲中各個(gè)對(duì)象所需內(nèi)存的分配與回收。這樣的好處是，當(dāng)游戲服務(wù)器進(jìn)程Crash時(shí)，配合運(yùn)營的實(shí)時(shí)監(jiān)測(cè)機(jī)制，系統(tǒng)自動(dòng)拉取Crash進(jìn)程后，在線玩家的狀態(tài)數(shù)據(jù)可以無損恢復(fù)，并且在線玩家不會(huì)感覺到服務(wù)器宕機(jī)；
消息分發(fā)管理：集中處理CS消息和SS消息，設(shè)計(jì)時(shí)重點(diǎn)考慮程序的可擴(kuò)展性；
系統(tǒng)與運(yùn)營日志管理：分別用來監(jiān)控服務(wù)器狀態(tài)和玩家的各種行為；
游戲商城管理：對(duì)付費(fèi)物品的上架、扣除、計(jì)費(fèi)等處理；
玩家登錄管理：玩家登錄游戲時(shí)的流程統(tǒng)一處理；
3.2 業(yè)務(wù)系統(tǒng)
業(yè)務(wù)系統(tǒng)主要是說明游戲的主體內(nèi)容是由哪些子模塊組成，這跟具體的游戲類型關(guān)系較大，這里抽取出大部分游戲應(yīng)用的業(yè)務(wù)模塊。

地圖與副本管理：游戲各公共場(chǎng)景和玩家獨(dú)自的副本地圖的處理，包括Npc與怪物分布、傳送點(diǎn)分布、地圖阻擋數(shù)據(jù)等的解析，以及地圖實(shí)例和副本實(shí)例的抽象等；
移動(dòng)管理：主要是實(shí)現(xiàn)游戲?qū)ο螅ㄍ婕医巧⒐治锏龋┑牡貓D尋路、障礙物檢測(cè)，以及動(dòng)態(tài)碰撞處理等功能。
裝備與道具管理：主要包括裝備的合成、拆分、打造、鑲嵌、升星等，以及道具的獲取、交易、使用等功能；
任務(wù)與事件管理：主要包括任務(wù)的領(lǐng)取、任務(wù)節(jié)點(diǎn)的更新、任務(wù)的完成和失敗處理等，以及系統(tǒng)隨機(jī)事件的產(chǎn)生等內(nèi)容；
游戲世界狀態(tài)管理：可將整個(gè)游戲世界各游戲?qū)ο蟮臓顟B(tài)分成幾大類與幾小類，如：玩家角色的狀態(tài)、技能Buff的狀態(tài)等，然后對(duì)各狀態(tài)之間關(guān)系進(jìn)行統(tǒng)一管理；
戰(zhàn)斗與技能管理：處理PVE、PVE戰(zhàn)斗流程、傷害計(jì)算，以及各個(gè)技能、Buff、Debuff的業(yè)務(wù)規(guī)則處理；
Npc與怪物AI管理：包括Npc在場(chǎng)景中的分布規(guī)則和本身的功能處理，以及怪物的分布、刷新、各類AI行為的處理；
視野管理：包括玩家的視野、Npc和怪物的視野等，設(shè)計(jì)時(shí)需要特別注意考慮各個(gè)不同場(chǎng)景中玩家的視野大小和視野搜索網(wǎng)格大小這兩個(gè)重要參數(shù)，因?yàn)椋鼈儗?duì)服務(wù)器的性能（CPU和流量）影響很大；
寵物與坐騎管理：包括寵物和坐騎的養(yǎng)成、交易、附帶技能和裝備等功能；
社會(huì)關(guān)系管理：包括玩家組隊(duì)、玩家好友、玩家交易、家族、公會(huì)、陣營、國家等社會(huì)關(guān)系功能的處理；
郵件管理：通過郵件可實(shí)現(xiàn)發(fā)送系統(tǒng)消息、發(fā)放系統(tǒng)道具，玩家道具交易等功能；
聊天管理：包括玩家點(diǎn)對(duì)點(diǎn)聊天、群聊等功能；
 

4 數(shù)據(jù)存儲(chǔ)層
數(shù)據(jù)存儲(chǔ)層是整個(gè)服務(wù)器的關(guān)鍵基礎(chǔ)系統(tǒng)之一，因?yàn)橛螒蚍?wù)器的核心功能之一就是存取玩家數(shù)據(jù)。游戲類型不同，對(duì)數(shù)據(jù)的存取需求也不一樣，對(duì)于傳統(tǒng)客戶端MMORPG而言，一般采用Mysql作數(shù)據(jù)持久化，然后在Mysql與GameSvr中間實(shí)現(xiàn)一個(gè)ORM的服務(wù)提供數(shù)據(jù)的代理或緩存即可。而新興的Social Game和強(qiáng)交互的WebGame，則選擇用NoSql來替代Mysql，以滿足其超大規(guī)模IO并發(fā)的需求。如下圖所示：

4.1 ORM
ORM即為對(duì)象關(guān)系映射，可以這樣來簡單的理解：我們平時(shí)操作關(guān)系型數(shù)據(jù)庫，需要業(yè)務(wù)自己編寫許多數(shù)據(jù)訪問的代碼，這樣會(huì)把許多SQL語句直接暴露在業(yè)務(wù)代碼里，十分不利于維護(hù)。利用ORM技術(shù)，可以避免這個(gè)問題，即業(yè)務(wù)邏輯不會(huì)直接對(duì)DB進(jìn)行操作，而改由ORM來完成，業(yè)務(wù)邏輯與ORM服務(wù)之間約定相關(guān)協(xié)議和API接口，來完成對(duì)數(shù)據(jù)的增、刪、改、查等功能。

4.2 NoSql
NoSql，指的是非關(guān)系型的數(shù)據(jù)庫，它可以滿足對(duì)數(shù)據(jù)庫的高并發(fā)讀寫、對(duì)海量數(shù)據(jù)的高效率存儲(chǔ)和訪問，以及對(duì)數(shù)據(jù)庫的高可擴(kuò)展性和高可用性等需求，它是隨著SNS和Web2.0的興起而產(chǎn)生的新興存儲(chǔ)技術(shù)。對(duì)于游戲而言，目前它主要應(yīng)用于Social Game和強(qiáng)交互的WebGame中。

5 通用組件庫
通用組件庫是指那些與具體業(yè)務(wù)無關(guān)的，能應(yīng)用于所有服務(wù)器開發(fā)的組件庫。目前，我們所積累的可歸納如下圖所示：

5.1 后臺(tái)服務(wù)應(yīng)用框架
后臺(tái)服務(wù)應(yīng)用框架規(guī)范了進(jìn)程的起停方式、信號(hào)處理、命令行參數(shù)等操作，框架本身實(shí)現(xiàn)了一個(gè)daemon服務(wù)所必備的消息主循環(huán)、reload機(jī)制，以及定時(shí)器處理等功能。

5.2 日志組件
日志是服務(wù)器調(diào)試和定位Bug的主要手段之一，日志組件一般需要實(shí)現(xiàn)日志分級(jí)、異步寫磁盤、以及按日期時(shí)間分類等功能。

5.3 進(jìn)程間通訊組件
進(jìn)程間的通訊也是服務(wù)器的核心基礎(chǔ)功能之一，高效的進(jìn)程間通訊是服務(wù)器性能的基本保障，進(jìn)程間通訊組件需要實(shí)現(xiàn)同機(jī)器與跨機(jī)器的進(jìn)程高效通訊。

5.4 消息打包組件
在許多通信程序中，需要定義一套網(wǎng)絡(luò)協(xié)議，并需要根據(jù)網(wǎng)絡(luò)協(xié)議對(duì)協(xié)議數(shù)據(jù)單元（PDU）進(jìn)行Pack/Unpack，以實(shí)現(xiàn)可移植性和網(wǎng)絡(luò)傳輸?shù)目煽啃约靶省５菍?duì)協(xié)議數(shù)據(jù)單元進(jìn)行Pack/Unpack是一個(gè)重復(fù)性很強(qiáng)的操作，繁瑣而且容易出錯(cuò)（Pack和Unpack容易不匹配）。而消息打包組件則簡化了網(wǎng)絡(luò)協(xié)議的制定，使得業(yè)務(wù)應(yīng)用不用關(guān)心協(xié)議的Pack/Unpack操作，并且支持良好的數(shù)據(jù)擴(kuò)展和協(xié)議版本兼容。

發(fā)布于
手游游戲服務(wù)器邏輯框架
1 背景
首先，要回答一個(gè)問題：

我們?yōu)槭裁匆獙ｉT為手機(jī)游戲?qū)ｉT定制設(shè)計(jì)一個(gè)游戲服務(wù)器邏輯框架？

坦白地說，公司自研游戲做了這么多年，事實(shí)上互娛已經(jīng)沉淀了一批相當(dāng)成熟的組件，如：解決底層網(wǎng)絡(luò)通信的Tconnd、解決進(jìn)程間通信Tbus、解決協(xié)議加解包的Tdr等等，但我們發(fā)現(xiàn)，這些組件絕大多數(shù)都是與業(yè)務(wù)無關(guān)的基礎(chǔ)組件、服務(wù)和庫。而與游戲業(yè)務(wù)緊密相關(guān)的邏輯框架，可能每個(gè)項(xiàng)目組都有自己的一套，這一方面源于，不同游戲業(yè)務(wù)，的確需求本身有較大的差別，很難用一套可復(fù)用性很強(qiáng)的邏輯框架包打天下；另一方面，也可能受限于項(xiàng)目本身的開發(fā)進(jìn)度壓力，端游有相對(duì)充裕的開發(fā)時(shí)間，但由于游戲系統(tǒng)繁多，平攤下來，每個(gè)系統(tǒng)的開發(fā)時(shí)間也不多，而頁游和手游的開發(fā)進(jìn)度就更緊一些，邏輯框架這塊也沒太多時(shí)間來作整理了。

2 現(xiàn)狀
以stan經(jīng)歷過的工作室里三款游戲?yàn)槔何⑦B、微胖和微塔。

三款游戲在業(yè)務(wù)邏輯處理上，均各自使用不同的一套框架，風(fēng)格迥異。如果要說相同點(diǎn)，則是均使用C/C++來作業(yè)務(wù)邏輯的實(shí)現(xiàn)。微連和微胖均以tapp作基礎(chǔ)來搭建框架，而微塔則是完全自行做的一套后臺(tái)框架。

考慮到手游開發(fā)周期短，迭代速度快，發(fā)布頻率高等特點(diǎn)，如果延用目前的邏輯框架，無論是上述三款游戲的哪一種，均難以解決如下幾個(gè)問題：

（1）開發(fā)復(fù)雜度較高

這里的復(fù)雜度包括語言本身的復(fù)雜度、開發(fā)效率、代碼可讀/可維護(hù)性等。

（2）運(yùn)維部署代價(jià)較高

從代碼編譯到上線部署，整個(gè)周期都比較長，雖然目前的邏輯框架基本上都采用了共享內(nèi)存保存玩家核心數(shù)據(jù)，以便于進(jìn)程重啟后數(shù)據(jù)即時(shí)恢復(fù)的機(jī)制，用來實(shí)現(xiàn)“熱更新”的效果，但這實(shí)際上是以犧牲開發(fā)復(fù)雜度來作代價(jià)的。

（3）系統(tǒng)可靠性

實(shí)事求是地說，要寫出可靠性的代碼，根本上還是取決于寫代碼的“人”。但由于C/C++本身是屬于偏底層的語言，對(duì)開發(fā)者的要求客觀上要更高一些。但即使經(jīng)驗(yàn)豐富的開發(fā)者，也難免不犯內(nèi)存越界、內(nèi)存泄漏、堆棧溢出等諸多令人抓狂的錯(cuò)誤。

有鑒于此，結(jié)合業(yè)內(nèi)同行朋友成熟項(xiàng)目的經(jīng)驗(yàn)，我們選擇用Lua與C/C++混合編程的方式來實(shí)現(xiàn)游戲業(yè)務(wù)邏輯。

3 新的解決方案
新改進(jìn)的邏輯框架基本可以解決上述提到的三個(gè)問題，至于為什么選擇用Lua，這個(gè)業(yè)內(nèi)基本上已有了一些共識(shí)，可以看這里，互娛魔方工作室也有項(xiàng)目已經(jīng)在應(yīng)用 ，看這里。故這個(gè)問題在此不再贅述。

接下來，我們探討一下解決方案的具體實(shí)現(xiàn)方法。

3.1 邊界
混合編程面臨的一個(gè)問題是：如何界定不同語言之間的處理邊界。對(duì)于我們來說就是，Lua能干什么，該干什么？C/C++需要做什么？

為此，我們?cè)趯?shí)現(xiàn)需要遵行的一些原則有:

網(wǎng)絡(luò)消息的收發(fā)、加解包、DB讀寫、日志讀寫、玩家對(duì)象池管理等涉及到有一定CPU開銷或底層處理的操作均由C/C++來承擔(dān)；
有復(fù)雜交互流程的邏輯，由Lua來實(shí)現(xiàn)，如：一個(gè)業(yè)務(wù)協(xié)議流程涉及到多個(gè)SS交互；
有單一重復(fù)邏輯的需求，由Lua來實(shí)現(xiàn)，如：任務(wù)、關(guān)卡、副本等；
系統(tǒng)配置文件由Lua來實(shí)現(xiàn)；
其它比較模糊的業(yè)務(wù)系統(tǒng)，我們會(huì)根據(jù)如下幾個(gè)因素來綜合權(quán)衡：開發(fā)效率、性能、兩種語言的交互調(diào)用頻率等；
3.2 框架外貌
（1）GAMESVR加載Lua配置文件進(jìn)行進(jìn)程參數(shù)以及業(yè)務(wù)邏輯參數(shù)配置；

（2）GAMESVR加載Lua邏輯腳本，根據(jù)CS請(qǐng)求，運(yùn)行不同的邏輯腳本；

（3）GAMESVR可以通過修改Lua邏輯腳本進(jìn)行熱更新；

3.3 框架處理流程

3.4 Lua配置文件處理思路
Lua的一種重要用途是作為配置語言

XML層次分明，寫起來太復(fù)雜；ini配置不夠靈活；其他配置需要自己開發(fā)

Lua作為配置文件編寫起來簡單，解析也方便，更重要的是在Lua協(xié)程框架中，很多情況是Lua協(xié)程讀取配置文件，而不需要其他接口便可直接讀取，天然的結(jié)合，使用起來非常方便。

遇到的問題：

（1）一份配置文件，C++中需要調(diào)用并且Lua業(yè)務(wù)邏輯腳本中也需要調(diào)用如何處理？

在GAMESVR中，建立一個(gè)ConfModule，ConfModule加載Lua配置文件到本模塊中的Lua虛擬機(jī)，并把配置文件需要的字段解析到本模塊的成員變量中，對(duì)外提供GET接口進(jìn)行訪問，對(duì)于LuaTaskMgrModule也同樣加載該lua配置文件，方便Lua業(yè)務(wù)邏輯腳本中的調(diào)用。

（2）lua配置文件便捷的解析方式

采用lua_dostring方式，將需要的參數(shù)按lua語句方式復(fù)制給一個(gè)變量，然后通過lua_tostring、lua_tointeger、lua_tonumber將其解析出來，lua_dostring方式速度較慢，但該模塊只是在GAMESVR初始化時(shí)候解析一次，并將解析出來的數(shù)據(jù)存入模塊的成員變量中，后續(xù)數(shù)據(jù)訪問通過提供的GET接口，解析完后關(guān)閉lua虛擬機(jī)，我們認(rèn)為該方式在解析速度上可接收。

3.5 C++網(wǎng)絡(luò)收發(fā)包處理思路
目前GAMESVR中存在三個(gè)異步回調(diào)點(diǎn)：

TBUS
TCAPLUS
LIBCURL
lua協(xié)程框架需要將task_id存入異步交互數(shù)據(jù)中，并且需要在響應(yīng)包中能夠原封不動(dòng)的帶回該task_id；
TBUS可以將task_id放入包頭的seq_id字段；
TCAPLUS可以通過TcaplusService::TcaplusServiceRequest中的SetAsyncID將task_id存入，并在響應(yīng)包時(shí)，通過TcaplusService::TcaplusServiceResponse的GetAsynID獲取task_id
LIBCURL需要封裝，使得CurlClient支持緩存task_id的機(jī)制；

4 寫在后面的話
目前用新的邏輯框架，重寫了好友關(guān)系鏈Server和GameSvr賬號(hào)登錄驗(yàn)證模塊，可以用微塔老客戶端完成賬號(hào)登錄全流程。

雖然新設(shè)計(jì)的邏輯框架還有諸多可完善的地方，但初次嘗試應(yīng)用，我們已感受到它帶來的變化，比如：重寫的好友關(guān)系鏈Server代碼量比原來縮減了近三分之一，代碼量減少的很明顯的好處就是：代碼更簡潔，可讀性更高（客觀說，微塔原來的代碼也寫得不錯(cuò)，可讀性也比較好）。

在后續(xù)項(xiàng)目的開發(fā)實(shí)踐過程中，我們還需不斷優(yōu)化、完善新設(shè)計(jì)的邏輯框架，讓其可用性更高、可復(fù)用性更強(qiáng)，相信經(jīng)歷咱們新項(xiàng)目的洗禮，新的邏輯框架能成為咱們產(chǎn)品中心游戲服務(wù)器開發(fā)的一把利器。

發(fā)布于
手游對(duì)戰(zhàn)設(shè)計(jì)方案
1       術(shù)語
1.1    術(shù)語和定義
術(shù)語 解釋
硬直時(shí)間 客戶端連續(xù)作移動(dòng)消除時(shí)的累積時(shí)間
   

2       需求說明
2.1    實(shí)時(shí)對(duì)戰(zhàn)
下面論述以《女巫之戰(zhàn)》為例進(jìn)行。

系統(tǒng)從當(dāng)前在線玩家中，匹配出合適對(duì)手來。當(dāng)進(jìn)入挑戰(zhàn)場(chǎng)景時(shí)，對(duì)戰(zhàn)兩方玩家在同一屏顯示，雙方的每一次游戲操作帶來的變化，如：消除效果，都能實(shí)時(shí)同步到屏幕上。

如下圖：來自《女巫之戰(zhàn)》截圖，即游戲?qū)?zhàn)界面會(huì)顯示兩個(gè)棋盤，左邊為玩家自己的，右上角為對(duì)手的，游戲過程中，會(huì)同步顯示血條和棋盤的變化。

2.2    離線對(duì)戰(zhàn)
離線對(duì)戰(zhàn)模式，在SNS游戲中是比較常見的一種PVP玩法。玩家可以隨時(shí)對(duì)自己的關(guān)系鏈好友發(fā)起挑戰(zhàn)，即玩家A可以對(duì)好友玩家B發(fā)起的挑戰(zhàn)，不關(guān)心其玩家B是否在線。挑戰(zhàn)完成后，若玩家B在線，則即時(shí)通知其被挑戰(zhàn)的信息，若玩家B離線，則待其上線時(shí)，再通知被挑戰(zhàn)詳細(xì)信息。

2.3    半實(shí)時(shí)對(duì)戰(zhàn)
同實(shí)時(shí)對(duì)戰(zhàn)類似，系統(tǒng)也是先從當(dāng)前在線玩家中，匹配出合適對(duì)手來。但是當(dāng)進(jìn)入挑戰(zhàn)場(chǎng)景時(shí)，屏幕只顯示玩家自己，不顯示對(duì)手游戲界面。待這局游戲結(jié)束后，在結(jié)算界面一起顯示對(duì)戰(zhàn)結(jié)果。

還有另一個(gè)版本是，對(duì)戰(zhàn)雙方都是帶角色的，游戲過程中可以顯示對(duì)手玩家的角色I(xiàn)con，對(duì)戰(zhàn)過程中發(fā)生的變化，如：分?jǐn)?shù)等，是實(shí)時(shí)廣播給雙方的。

3       設(shè)計(jì)實(shí)現(xiàn)
3.1    實(shí)時(shí)對(duì)戰(zhàn)
實(shí)時(shí)對(duì)戰(zhàn)的設(shè)計(jì)實(shí)現(xiàn)，總的來說，可分為兩類，一類是服務(wù)器強(qiáng)同步，一類是服務(wù)器弱同步，下面詳細(xì)描述之。

3.1.1     服務(wù)器強(qiáng)同步方案
在這個(gè)方案中，游戲邏輯的判定均放在服務(wù)端進(jìn)行，無論是棋盤的初始化操作，還是游戲過程中的消除、新棋子生成等邏輯均由服務(wù)器運(yùn)算，即將消除的算法放在服務(wù)器端，客戶端主要作相應(yīng)消除效果的表現(xiàn)。

進(jìn)一步分析，該方案分為兩種情況：

阻塞同步
阻塞同步的特征是：玩家每次移動(dòng)棋子作消除操作時(shí)，需要等本次操作產(chǎn)生的效果全部完成后（如：播放消除特效、已有棋子下落，新棋子填充等），才能作下一次移動(dòng)棋子的操作。基本流程如下圖所示：

圖1  阻塞同步序列圖

（0）客戶端發(fā)起PVP匹配，服務(wù)器根據(jù)相關(guān)規(guī)則，在同一臺(tái)gamesvr上匹配出對(duì)手玩家，并向兩者廣播一致的初始化棋盤信息；

客戶端A和B分別發(fā)起棋子移動(dòng)請(qǐng)求，在收到服務(wù)器的響應(yīng)包之前，客戶端阻塞不允許移動(dòng)；
服務(wù)器分別判定兩者的移動(dòng)是否合法，若非法，客戶端收到移動(dòng)失敗響應(yīng)包后，讓棋子置位；若合法，先響應(yīng)客戶端移動(dòng)成功消息。然后，服務(wù)器進(jìn)一步計(jì)算本次移動(dòng)影響的待下落棋子和新生成待填充的棋子，以及新生成棋子中可能引發(fā)的combo棋子，計(jì)算完畢后，則一起打包分別向客戶端A與B廣播棋子下落消息，同時(shí)處理業(yè)務(wù)對(duì)應(yīng)的邏輯，如：扣對(duì)手玩家的HP、累加自己的分?jǐn)?shù)等；
客戶端收到服務(wù)器的響應(yīng)移動(dòng)結(jié)果包后，若檢查通過，則處理棋子移動(dòng)，并播放棋子消除特效等，若不通過，則重置棋子歸位；
客戶端收到服務(wù)器的棋子下落和新棋子填充廣播包后，分別處理A和B兩個(gè)棋盤的棋子下落效果；
進(jìn)入下一輪棋子請(qǐng)求處理；
 

幀同步
幀同步允許玩家在一定時(shí)間內(nèi)（硬直時(shí)間），即時(shí)移動(dòng)消除，即時(shí)反饋移動(dòng)消除結(jié)果。當(dāng)硬直時(shí)間到達(dá)時(shí)，客戶端A和客戶端B分別提交其在硬直時(shí)間內(nèi)累積的所有移動(dòng)請(qǐng)求，同時(shí)鎖定棋盤，并等待服務(wù)器的處理結(jié)果。這種情況下，客戶端和服務(wù)器都需要作消除邏輯的計(jì)算，并且兩者的算法要保持一致。基本流程圖如下所示：

圖2  幀同步序列圖

（0）客戶端發(fā)起PVP匹配，服務(wù)器根據(jù)相關(guān)規(guī)則，在同一臺(tái)gamesvr上匹配出對(duì)手玩家，并向兩者廣播一致的初始化棋盤信息；

在硬直時(shí)間內(nèi)，客戶端A和B各自處理玩家的移動(dòng)消除操作，此時(shí)只處理移動(dòng)效果和消除爆炸效果，而棋子下落和新棋子填充不處理。硬直時(shí)間到達(dá)時(shí)，分別向服務(wù)器提前期間所有的請(qǐng)求移動(dòng)信息；
服務(wù)器分別判定兩者的移動(dòng)是否合法，若非法，客戶端收到移動(dòng)失敗響應(yīng)包后，讓棋子置位；若合法，先響應(yīng)客戶端移動(dòng)成功消息。然后，服務(wù)器進(jìn)一步計(jì)算本次移動(dòng)影響的待下落棋子和新生成待填充的棋子，以及新生成棋子中可能引發(fā)的combo棋子，計(jì)算完畢后，則一起打包分別向客戶端A與B廣播棋子下落消息，同時(shí)處理業(yè)務(wù)對(duì)應(yīng)的邏輯，如：扣對(duì)手玩家的HP、累加自己的分?jǐn)?shù)等；
客戶端收到服務(wù)器的棋子下落和新棋子填充廣播包后，分別處理A和B兩個(gè)棋盤的棋子下落效果；
進(jìn)入下一輪處理；
 

3.1.2     服務(wù)器弱同步方案
在該方案中，游戲消除邏輯主要放在客戶端進(jìn)行，即棋盤初始生成算法、消除檢查算法、棋子下落與新棋子生成算法等均由客戶端來控制，而服務(wù)器主要作消息轉(zhuǎn)發(fā)與一些簡單的判定，如：對(duì)局結(jié)束的條件等，基本流程圖如下所示：

圖3  弱同步序列圖

（0）客戶端發(fā)起PVP匹配，服務(wù)器根據(jù)相關(guān)規(guī)則，在同一臺(tái)gamesvr上匹配出對(duì)手玩家，并向兩者廣播約定的對(duì)局開始時(shí)間，如：播放開場(chǎng)動(dòng)畫（3s）后開始；

客戶端各自判定玩家的移動(dòng)棋子操作，判定能過，則表現(xiàn)相應(yīng)的消除效果、棋子下落與新棋子填充過程，同時(shí)將本次消除信息打包發(fā)至服務(wù)器；
服務(wù)器收到客戶端的消除信息后，分別轉(zhuǎn)發(fā)至其對(duì)應(yīng)的玩家，同時(shí)處理業(yè)務(wù)對(duì)應(yīng)的邏輯，如：扣對(duì)手玩家的HP、累加自己的分?jǐn)?shù)等；
客戶端收到對(duì)手玩家轉(zhuǎn)發(fā)來的消除信息后，在其對(duì)手棋盤上表現(xiàn)相應(yīng)的消除過程與效果；
如此循環(huán)往復(fù)，直至對(duì)局條件達(dá)到，如：某一方玩家HP<=0，或游戲?qū)謺r(shí)間到等；
3.1.3     小結(jié)
對(duì)比以上兩類實(shí)時(shí)對(duì)戰(zhàn)的實(shí)現(xiàn)方案，可以得出如下結(jié)論：

強(qiáng)同步方案一般適用于需要服務(wù)器作嚴(yán)格檢查判定的場(chǎng)合，即游戲業(yè)務(wù)上，需要嚴(yán)防玩家作弊的情形。其中，阻塞同步方案在MMORPG中應(yīng)用較多，如：戰(zhàn)斗技能系統(tǒng)等；幀同步方案在ACT中經(jīng)常使用，如：雙人格斗游戲中的動(dòng)作同步等；
與強(qiáng)同步方案有所不同，弱同步方案所應(yīng)用的游戲，往往更關(guān)心玩家的單機(jī)體驗(yàn)手感，而不是數(shù)值本身，因此，對(duì)于數(shù)據(jù)校驗(yàn)的要求也會(huì)低一些，如：Puzzle類休閑游戲；
強(qiáng)同步方案的實(shí)現(xiàn)成本一般要高于弱同步方案，并且，由于強(qiáng)同步方案往往需要服務(wù)器實(shí)現(xiàn)比較復(fù)雜的邏輯運(yùn)算，因此，其服務(wù)器的性能開銷要較弱同步方案的大一些，相應(yīng)地，服務(wù)器的承載能力就會(huì)較弱同步方案的低；
3.2    離線對(duì)戰(zhàn)
離線對(duì)戰(zhàn)在實(shí)現(xiàn)層面需要關(guān)注點(diǎn)是多點(diǎn)數(shù)據(jù)的修改問題。即同一時(shí)刻，某個(gè)玩家可能會(huì)被他的多個(gè)好友同時(shí)發(fā)起挑戰(zhàn)，而在挑戰(zhàn)過程中，可能會(huì)同時(shí)修改對(duì)戰(zhàn)雙方的玩家數(shù)據(jù)。

多點(diǎn)數(shù)據(jù)的修改問題，目前都有比較成熟的解決方案，具體方案需要根據(jù)業(yè)務(wù)需求實(shí)際來選擇：

全局邏輯鎖方案
實(shí)現(xiàn)要點(diǎn)是用一個(gè)單獨(dú)的locksvr來保持?jǐn)?shù)據(jù)修改時(shí)的同步。即玩家A發(fā)起對(duì)玩家B挑戰(zhàn)，gamesvr在get玩家A和玩家B數(shù)據(jù)的同時(shí)，會(huì)lock這兩者的數(shù)據(jù)。此時(shí)，若還有其他玩家需要get這兩個(gè)玩家數(shù)據(jù)時(shí)，就會(huì)get失敗，即鎖沖突。這樣就保證了，每次修改只會(huì)有一個(gè)玩家在操作。

該方案的優(yōu)點(diǎn)：

好處在于單獨(dú)的locksvr可以設(shè)計(jì)得比較通用，多個(gè)項(xiàng)目可以復(fù)用，一定程度上可以提高開發(fā)效率；
locksvr邏輯上比較清晰，部署也比較方便。目前微連等項(xiàng)目就是采用的架構(gòu)組提供的locksvr組件；
不足的地方：

當(dāng)交互比較頻繁時(shí)，locksvr的機(jī)制可能會(huì)導(dǎo)致比較多的沖突，從而會(huì)影響玩家的游戲體驗(yàn)。這個(gè)問題在webgame中，玩家可能不會(huì)太敏感，這跟玩家的操作習(xí)慣有關(guān)，當(dāng)沖突發(fā)生時(shí)，玩家一般刷新一下頁面操作即可恢復(fù)正常。而在手機(jī)游戲中，需要根據(jù)具體游戲業(yè)務(wù)來評(píng)估；
 

增量修改方案
實(shí)現(xiàn)要點(diǎn)是gamesvr修改玩家數(shù)據(jù)時(shí)，只提交修改的相對(duì)值，各個(gè)gamesvr的修改數(shù)據(jù)請(qǐng)求匯總至一臺(tái)中心服務(wù)器（熱點(diǎn)服務(wù)器）進(jìn)行，因?yàn)橹挥幸粋€(gè)地方修改，故修改數(shù)據(jù)自然會(huì)保持隊(duì)列同步。

該方案的優(yōu)點(diǎn)：

最大的好處是不會(huì)產(chǎn)生修改引發(fā)的沖突問題；
Gamesvr為無狀態(tài)服務(wù)器，邏輯會(huì)比較簡單；
不足的地方：

要求修改的數(shù)據(jù)結(jié)構(gòu)比較簡單且單一，否則會(huì)導(dǎo)致中心服務(wù)器的邏輯處理復(fù)雜度成倍增加；
由于所有數(shù)據(jù)的修改均在中心服務(wù)器進(jìn)行，故其有單點(diǎn)風(fēng)險(xiǎn)；
 

（三）Compare And Swap

實(shí)現(xiàn)要點(diǎn)保證每次提交的操作，只有一個(gè)是成功的。即gamesvr修改玩家數(shù)據(jù)前，先獲取該玩家的cas值，并在修改數(shù)據(jù)時(shí)把cas值帶上。數(shù)據(jù)到達(dá)DBSvr時(shí)，會(huì)檢查cas值的合法性，檢查通過，則允許修改數(shù)據(jù)，同時(shí)將當(dāng)前cas值加1。此時(shí)，若有其它gamesvr提交同一玩家的修改請(qǐng)求時(shí)，會(huì)發(fā)現(xiàn)cas值與當(dāng)前的不匹配，則拒絕此次修改，同時(shí)，返回一個(gè)錯(cuò)誤給這個(gè)gamesvr的請(qǐng)求。

該方案的優(yōu)點(diǎn)：

它其實(shí)是前兩種方案的一個(gè)折衷方案，相對(duì)于全局鎖的強(qiáng)鎖定（get數(shù)據(jù)就會(huì)鎖定），它只會(huì)在set數(shù)據(jù)時(shí)判定數(shù)據(jù)是否沖突，即有玩家A修改玩家B數(shù)據(jù)時(shí)，玩家C依然可以get玩家B或玩家A的數(shù)據(jù)，不會(huì)引發(fā)沖突問題；
該方案同樣可以做到通用；
不足的地方：

依然有強(qiáng)交互時(shí)，可能有比較多的沖突問題；
需要有DBsvr支持該CAS機(jī)制；
注：目前公司的CMem組件支持CAS機(jī)制；

3.3    半實(shí)時(shí)對(duì)戰(zhàn)
半實(shí)時(shí)對(duì)戰(zhàn)本質(zhì)上還是在線玩家之間的PK，只是客戶端在表現(xiàn)手法上，與實(shí)時(shí)對(duì)戰(zhàn)有所區(qū)別。以《女巫之戰(zhàn)》為例，若換成半實(shí)時(shí)對(duì)戰(zhàn)，則對(duì)戰(zhàn)開始后，對(duì)戰(zhàn)界面只顯示玩家自己一個(gè)人的棋盤，對(duì)手玩家只顯示一個(gè)Avatar Icon和血條。

半實(shí)時(shí)對(duì)戰(zhàn)的實(shí)現(xiàn)方案可參考實(shí)時(shí)對(duì)戰(zhàn)中的弱同步方案。

4       我們的選擇
上面討論了三類對(duì)戰(zhàn)需求，在實(shí)現(xiàn)層面上，可供選擇的設(shè)計(jì)方案。并且分析了每種設(shè)計(jì)方案的優(yōu)缺點(diǎn)和適用場(chǎng)合。咱們微項(xiàng)目具體選擇哪種實(shí)現(xiàn)方案，需要根據(jù)特定的業(yè)務(wù)需求來決定。選擇原則是：方案滿足需求，實(shí)現(xiàn)代價(jià)最小。

發(fā)布于
WebGame游戲開發(fā)現(xiàn)狀淺析
（一）產(chǎn)品設(shè)計(jì)

    1）新手設(shè)計(jì)無腦化、傻瓜化
        1. UI操作簡單、直觀、便捷；
        2. 短時(shí)間使玩家角色獲得快速成長；
    2）針對(duì)付費(fèi)的設(shè)計(jì)
        1. 第一時(shí)間讓玩家產(chǎn)生付費(fèi)的沖動(dòng)；
        2. 付費(fèi)點(diǎn)遍及游戲各個(gè)系統(tǒng)；
    3）內(nèi)掛設(shè)計(jì)，減少外掛影響
        1. 自動(dòng)尋路、自動(dòng)拾取物品、自動(dòng)戰(zhàn)斗、自動(dòng)補(bǔ)充HP/MP等；
        2. 自動(dòng)換裝（或者提示玩家換更強(qiáng)的裝備）；
    4）提供玩家最大的滿足感和爽快感
        1. 更好的游戲代入：游戲題材的選擇，游戲世界觀的設(shè)計(jì)等
        2. 深挖數(shù)值，但又不能使游戲系統(tǒng)過于復(fù)雜，即玩家能快速理解游戲玩法內(nèi)容；
（二）技術(shù)研發(fā)

    1）提供跨服PK的功能，即不同大區(qū)的玩家能夠同場(chǎng)競(jìng)技；
        技術(shù)關(guān)注點(diǎn)：不同大區(qū)的服務(wù)器是否部署在同一IDC？存儲(chǔ)服務(wù)器數(shù)據(jù)分區(qū)部署 or 全Cluster共享？
    2）支持一機(jī)多服部署
        即同一臺(tái)物理機(jī)器部署多個(gè)游戲世界
    3）形成一套核心研發(fā)機(jī)制和穩(wěn)定的開發(fā)框架、基礎(chǔ)庫，保障核心功能快速復(fù)制
（三）運(yùn)營推廣

    1）快速開服，滿足玩家“滾服”需求：《龍將》和《神仙道》做到了1天1服或1天2服，所謂“滾服”，即玩家會(huì)在不同服務(wù)器體驗(yàn)，目的是爭取在新的服務(wù)器更高的排名和更大的滿足感；
    2）開服第一周的收入是該服最主要的收入，也決定了運(yùn)營商是否加大推廣的力度；
    3）流量就是金錢，一般運(yùn)營商的成本是每個(gè)人1-2元每人的流量成本；
    4）運(yùn)營商可以提供機(jī)器，也可能讓開發(fā)者自己租用機(jī)器和帶寬，它只提供一個(gè)域名；
（四）其它

    1）核心玩家群特征：低粘性、高ARP值，即純粹互聯(lián)網(wǎng)用戶，游戲只是其網(wǎng)絡(luò)生活的一種典型應(yīng)用；
    2）3–6個(gè)月完成一款RPG類webgame的全部開發(fā)，即正式付款公測(cè)；
發(fā)布于
WebGame游戲服務(wù)器技術(shù)要點(diǎn)
（一）服務(wù)器技術(shù)實(shí)現(xiàn)方案選擇的問題？
（1）選擇標(biāo)準(zhǔn)WebServer+CGI開發(fā)（偏輕）
【優(yōu)點(diǎn)】
    1）快速開發(fā)：WebServer都是現(xiàn)成的，如：Nginx和Apache；CGI程序能也快速編程；
    2）靈活開發(fā)：整個(gè)后臺(tái)服務(wù)可由多個(gè)CGI程序組成，一個(gè)CGI程序可以對(duì)應(yīng)一項(xiàng)或多項(xiàng)業(yè)務(wù)功能，增加新功能時(shí)則增加新的CGI程序即可；
    3）不停機(jī)更新：部署新的CGI程序，不影響已運(yùn)行的CGI程序；
    4）可適合處理SNS類玩家異步（離線）交互數(shù)據(jù)的情形；
【不足】
    1）CGI程序如果過多，可能會(huì)加大維護(hù)的難度；
    2）業(yè)務(wù)需求如果要涉及到多個(gè)CGI程序之間的通信，即有狀態(tài)的關(guān)聯(lián)依賴，可能會(huì)有較復(fù)雜的邏輯和可能的性能瓶；
（2）選擇自定義通信服務(wù)器+GameSvr開發(fā)（偏重）
【優(yōu)點(diǎn)】
    1）可應(yīng)對(duì)復(fù)雜業(yè)務(wù)邏輯的處理，如：業(yè)務(wù)需求之間的關(guān)聯(lián)依賴較深等；
    2）可輕松處理玩家之間同步數(shù)據(jù)的需求；
【不足】
    1）開發(fā)復(fù)雜度較大，需要較多的開發(fā)資源；
（二）游戲服務(wù)器Cache設(shè)計(jì)方案
【背景】
    1）游戲服務(wù)器cache數(shù)據(jù)可大大緩解數(shù)據(jù)存取時(shí)壓力；
    2）多臺(tái)分布式游戲服務(wù)器作Cache，可有效利用硬件資源；
【實(shí)現(xiàn)方案】
    1）基于共享內(nèi)存的對(duì)象池設(shè)計(jì)；
【注意事項(xiàng)】
    1）數(shù)據(jù)一致性：對(duì)于SNS強(qiáng)交互類游戲，需要作多玩家修改同一數(shù)據(jù)的設(shè)計(jì)；
    2）數(shù)據(jù)同步的時(shí)機(jī)：根據(jù)業(yè)務(wù)數(shù)據(jù)的重要程度，分級(jí)設(shè)計(jì)同步時(shí)間，越重要的數(shù)據(jù)，同步時(shí)間越短；
（三）游戲服務(wù)器數(shù)據(jù)分類設(shè)計(jì)方案
【基本思想】
    把業(yè)務(wù)數(shù)據(jù)按重要程度進(jìn)行分類，每類數(shù)據(jù)采用不同的存儲(chǔ)和邏輯處理策略；
 
【應(yīng)用說明】
    SNS類游戲需要重點(diǎn)考慮
（四）游戲服務(wù)器全局鎖的設(shè)計(jì)
【背景】
    1）同一玩家數(shù)據(jù)會(huì)被多玩家修改；
    2）某一Cache數(shù)據(jù)會(huì)被多個(gè)應(yīng)用修改；
【方案一】：熱點(diǎn)數(shù)據(jù)分布在各個(gè)游戲服務(wù)器的Cache中
    1）數(shù)據(jù)被修改點(diǎn)（熱點(diǎn)數(shù)據(jù)）設(shè)置一個(gè)全局Seq，如：玩家數(shù)據(jù)修改，則在玩家身上設(shè)置一個(gè)Seq；
    2）當(dāng)Client讀熱點(diǎn)數(shù)據(jù)時(shí)，則直接返回?cái)?shù)據(jù)給Client，并將Seq一齊帶上；
    3）當(dāng)Client寫熱點(diǎn)數(shù)據(jù)時(shí)，會(huì)在寫數(shù)據(jù)請(qǐng)求里帶上上次請(qǐng)求獲得的該熱點(diǎn)數(shù)據(jù)的Seq，熱點(diǎn)數(shù)據(jù)的處理邏輯先比較寫數(shù)據(jù)請(qǐng)求的Seq，是否與當(dāng)前熱點(diǎn)數(shù)據(jù)的Seq一致，若不一致（該請(qǐng)求來之前已被其它Client修改過），則有如下兩種異步處理方案：
        1. 直接報(bào)錯(cuò)給請(qǐng)求Client，此時(shí)Client可能需要提示玩家重新刷新瀏覽器；
        2. 返回當(dāng)前最新熱點(diǎn)數(shù)據(jù)給請(qǐng)求Client，Client需要重新處理一遍之前的業(yè)務(wù)邏輯，再提交寫數(shù)據(jù)請(qǐng)求；
    4）每次寫熱點(diǎn)數(shù)據(jù)成功后，熱點(diǎn)數(shù)據(jù)本身的Seq加1；
    5）數(shù)據(jù)修改的邏輯統(tǒng)一在熱點(diǎn)數(shù)據(jù)所在的游戲服務(wù)器處理；
【方案二】：熱點(diǎn)數(shù)據(jù)集中在一個(gè)全局公共服務(wù)器的Cache中
    實(shí)現(xiàn)方法與【方案一】類似
【兩個(gè)方案的比較】
    1）【方案一】：Cache分布在每臺(tái)游戲服務(wù)器中，可以有效利用硬件資源，但SS交互邏輯復(fù)雜一些；
    2）【方案二】：可以減少一些SS協(xié)議的交互，但需要單獨(dú)的全局Cache服務(wù)器；
【注意事項(xiàng)】
    1）需要分別考慮玩家在線和離線數(shù)據(jù)的修改；
 （五）如何有效利用機(jī)器的多核CPU
1）多個(gè)通信服務(wù)器+1個(gè)游戲服務(wù)器；

    2）多個(gè)通信服務(wù)器+多個(gè)游戲服務(wù)器；
 
（六）如何評(píng)估網(wǎng)絡(luò)I/O的瓶頸
    1）網(wǎng)卡（1000M bit/100M bit）本身的極限處理能力：理論處理包的數(shù)量：網(wǎng)卡帶寬[1000M bit]/（最小包大小[64Byte] * 8）；
    2）游戲業(yè)務(wù)對(duì)包的數(shù)量較包的大小更敏感，因?yàn)槊總€(gè)網(wǎng)絡(luò)包在CPU處理時(shí)，會(huì)產(chǎn)生IO中斷，因此，常用的策略是，合并多個(gè)請(qǐng)求包為一個(gè)包，提高帶個(gè)包的信息量；
 
（七）深入了解MySQL的存儲(chǔ)性能
    1）Mysql5.5+InnoDB1.1；
    2）Mysql的Cache解決方案；
【聲明：若有摘錄，請(qǐng)注明來自http://gameislife.info/archives/109】
發(fā)布于
動(dòng)作類網(wǎng)游技術(shù)難點(diǎn)分析
1 背景
動(dòng)作類游戲（ACT）在百度百科上的定義是：由玩家所控制的人物根據(jù)周圍環(huán)境的變化，利用鍵盤或者手柄、鼠標(biāo)的按鍵做出一定的動(dòng)作，如移動(dòng)、跳躍、攻擊、躲避、防守等，來達(dá)到游戲要求的相應(yīng)目標(biāo)。單機(jī)代表作有：《波斯王子》、《鬼泣》、《真三國無雙》、《戰(zhàn)神》等，而網(wǎng)游代表作有：《DNF》、《龍之谷》、《怪物獵人OL》等。

從技術(shù)層面來說，與傳統(tǒng)MMORPG不同的是，動(dòng)作類網(wǎng)游對(duì)于操作響應(yīng)的網(wǎng)絡(luò)時(shí)延要求極高，要保證較好的體驗(yàn)效果的話，一般要求時(shí)延小于150ms。如果網(wǎng)絡(luò)時(shí)延較大的話，會(huì)帶來對(duì)戰(zhàn)雙方（或多方）數(shù)據(jù)不一致的問題，即所謂的數(shù)據(jù)同步問題。因此，數(shù)據(jù)同步問題是動(dòng)作類網(wǎng)游的首要問題，也是最大的問題。

下面將先描述數(shù)據(jù)同步問題的具體表現(xiàn)，再嘗試分析目前業(yè)界常用的解決辦法，最后簡要講述公司兩個(gè)自研項(xiàng)目的實(shí)施方案。

2 問題聚焦
下面列舉的這些同步問題，也是大部分網(wǎng)絡(luò)游戲共有的一些典型問題，如果處理不好，又會(huì)在動(dòng)作類網(wǎng)游中進(jìn)一步放大，從而極大的影響玩家體驗(yàn)。

2.1 位置不同步
比如在T1時(shí)間，第三世界的玩家B看第一世界的玩家A在射程內(nèi)并發(fā)起攻擊，但此時(shí)玩家A正在跑出射程，當(dāng)服務(wù)器收到玩家B的攻擊請(qǐng)求，會(huì)判斷玩家A已經(jīng)在射程外了，如果服務(wù)器拒絕B的攻擊，則會(huì)讓B覺得很困惑，為什么明明在攻擊范圍內(nèi)，卻攻擊不到呢？

2.2 動(dòng)態(tài)阻擋
所謂動(dòng)態(tài)阻擋是指角色、怪物和建筑這些實(shí)體不可重疊。動(dòng)態(tài)阻擋讓玩家感覺更具有真實(shí)性，并且在多人PK中，可以利用動(dòng)態(tài)阻擋進(jìn)行卡位，制造人墻，豐富游戲的玩法。

動(dòng)態(tài)阻擋本身就會(huì)有很多碰撞問題，再加上網(wǎng)絡(luò)延遲，會(huì)有各種各樣的問題產(chǎn)生。

碰撞情形1：玩家A在P1點(diǎn)請(qǐng)求要去P2點(diǎn)時(shí)，玩家B也有可能在P3點(diǎn)請(qǐng)求要到P2點(diǎn)，但最終只能有一個(gè)人到P2的位置，如何避免拉扯呢。

碰撞情形2：玩家A在P1點(diǎn)請(qǐng)求要去P2點(diǎn)，玩家B在P3點(diǎn)請(qǐng)求要去P4點(diǎn)，路徑有交叉，要讓他們碰還是不碰呢？

碰撞情形3：玩家A在P1點(diǎn)請(qǐng)求要去P2點(diǎn)，玩家B在P3點(diǎn)要去P4點(diǎn)，這種情形也會(huì)有碰撞發(fā)生。

碰撞情形4：玩家A要通過一個(gè)只能容納一個(gè)人的關(guān)隘，玩家B要阻止玩家A通過，但是由于網(wǎng)絡(luò)延遲，當(dāng)A通過時(shí)，并沒有發(fā)現(xiàn)B已經(jīng)在卡住關(guān)隘，服務(wù)器是相信A，允許通過呢，還是相信服務(wù)器自己，要拖拽A呢？

碰撞情形5:玩家A要通過城門，但是由于網(wǎng)絡(luò)延遲，當(dāng)A通過時(shí)，并沒有發(fā)現(xiàn)城門已經(jīng)關(guān)閉了，服務(wù)器是相信A，允許通過呢，還是要拖拽A呢?

2.3 技能事件
考慮冰凍情形，在T1時(shí)間，玩家A對(duì)玩家B施放冰凍，在T2時(shí)間，服務(wù)器收到報(bào)文，并下發(fā)冰凍確認(rèn)，玩家B在T3時(shí)刻才收到自己被冰凍的消息，

如果在T3時(shí)間前，B沒有收到被冰凍消息，進(jìn)行移動(dòng)，而移動(dòng)報(bào)文又在T2時(shí)刻到達(dá)服務(wù)器，如果按照邏輯，服務(wù)器拒絕處理B的移動(dòng)請(qǐng)求，那么就會(huì)產(chǎn)生B在第一視角的位置和服務(wù)器的位置不一致的現(xiàn)象，就會(huì)產(chǎn)生拖拽，如何避免拖拽呢？

其他諸如擊暈，減速，恐懼，死亡等等，都類似冰凍情形，不再贅述

3解決方案
3.1 幀同步
原理
玩家在發(fā)起戰(zhàn)斗后，每隔一定時(shí)間在玩家的戰(zhàn)斗動(dòng)作序列中設(shè)置一個(gè)邏輯關(guān)鍵幀，在關(guān)鍵幀這個(gè)點(diǎn)，本機(jī)必須收到來自所有參與者反饋后才可繼續(xù)執(zhí)行其余的動(dòng)作序列，否則，就進(jìn)行鎖幀、等待。這樣就通過頻繁對(duì)時(shí)（即在每一個(gè)關(guān)鍵幀節(jié)點(diǎn)上對(duì)齊），便可以像編寫串行單機(jī)指令一樣來進(jìn)行多個(gè)客戶端的事件指令同步了。

如下圖所示：

優(yōu)點(diǎn)
簡單易實(shí)現(xiàn)，不會(huì)出現(xiàn)任何的不一致性。在延遲小(< 100ms)且穩(wěn)定的環(huán)境下非常合適。此外，在實(shí)時(shí)性要求不高的玩法(比如回合制玩法)中也非常合適。

缺點(diǎn)
游戲節(jié)奏受最慢的那個(gè)玩家客戶端影響巨大。一人卡機(jī)，所有人受影響。惡意玩家可以用偽造大延遲的方式來獲得好處，從而破壞游戲公平性。

3.2 客戶端承擔(dān)消耗運(yùn)算
原理
游戲比較消耗CPU的運(yùn)算均放在玩家本地客戶端執(zhí)行，如：角色移動(dòng)物理判定、戰(zhàn)斗物理判定、AI邏輯判定等等。服務(wù)器只對(duì)影響玩家利益的關(guān)鍵信息作驗(yàn)證。

優(yōu)點(diǎn)
保證了游戲操作手感，避免了本機(jī)操作延時(shí)。

缺點(diǎn)
運(yùn)算邏輯存放在客戶端，會(huì)帶來較大的外掛風(fēng)險(xiǎn)。

3.3 游戲策劃上的優(yōu)化
原理
在游戲設(shè)計(jì)層面，來隱藏玩家的延遲感。比如：延長出招/收招動(dòng)作時(shí)間、降低動(dòng)作判定精度、給技能加公共CD、避免戰(zhàn)斗受擊時(shí)發(fā)生位移等等。

優(yōu)點(diǎn)
無任何技術(shù)風(fēng)險(xiǎn)，綠色、環(huán)保、安全，代價(jià)最小。

缺點(diǎn)
可能會(huì)影響戰(zhàn)斗的爽快感。

4 公司內(nèi)項(xiàng)目的一些做法
《QQ堂》和《炫斗之王》都是公司自研的動(dòng)作休閑類游戲，在與其相關(guān)負(fù)責(zé)同事作了一些簡要交流后，將他們的做法小結(jié)如下：

客戶端之間采用P2P通信
這對(duì)于在同一局域網(wǎng)內(nèi)（如：網(wǎng)吧）的玩家，網(wǎng)絡(luò)延遲很小。只有當(dāng)兩個(gè)Peer連結(jié)不同時(shí)，消息包才通過服務(wù)器中轉(zhuǎn)；

客戶端先表現(xiàn)，服務(wù)器后檢驗(yàn)
玩家角色在移動(dòng)、戰(zhàn)斗出招等操作時(shí)，客戶端在發(fā)出請(qǐng)求包的同時(shí)，先自行在本機(jī)表現(xiàn)，繼續(xù)后面的游戲邏輯，而無需等到服務(wù)器驗(yàn)證通過后才開始。

客戶端的校驗(yàn)邏輯同時(shí)在服務(wù)器再運(yùn)行一遍
這也是慣用做法，即所謂的服務(wù)器強(qiáng)校驗(yàn)。

做好客戶端反外掛
由于采用P2P通信，有些邏輯難免會(huì)放在客戶端，這與上述的一些解決方案的做法也是類似的。附上QQ堂對(duì)于反外掛處理的一個(gè)分享文檔

5 小結(jié)
綜上所述，動(dòng)作類網(wǎng)游在技術(shù)實(shí)施層面上，較傳統(tǒng)MMORPG主要是在數(shù)據(jù)同步（多個(gè)Peer間、C/S間）上要求更加苛刻，當(dāng)然，這目前在客戶端平臺(tái)上，也已經(jīng)有了較為成熟的技術(shù)解決方案。但具體到頁游平臺(tái)，雖然從Flash10和Adobe AIR1.5開始，已經(jīng)支持P2P通信，Adobe也在官方提供相應(yīng) 的P2P服務(wù)，即代號(hào)為Cirrus，但目前尚未看到其在商業(yè)運(yùn)營的頁游項(xiàng)目里有成熟的應(yīng)用。因此，在頁游平臺(tái)的P2P應(yīng)用，還需要更進(jìn)一步的探索和挖掘。

發(fā)布于
Social Game與MMORPG在服務(wù)器架構(gòu)上的差異
最近在作公司的一個(gè)Social Game的項(xiàng)目服務(wù)器架構(gòu)設(shè)計(jì)，與之前做過的MMORPG（簡稱RPG）相比，差別還是較為明顯的，現(xiàn)總結(jié)一二，以供分享！

（一）協(xié)議通信

1）Socail Game為了快速開發(fā)，在通信協(xié)議的選擇上均會(huì)選擇http作為底層通信協(xié)議，這樣選擇的好處大致有：

1、方便客戶端編程：http為一應(yīng)一答的同步模型；

2、可以選擇成熟的開源http服務(wù)器，如：apache、nginx；

2）RPG選擇的是基于socket的TCP通信，這是由游戲本身的特點(diǎn)所決定的，如：聊天、多人視野、服務(wù)器主動(dòng)通知事件等需求

（二）游戲邏輯服務(wù)器的承受能力

1）RPG的游戲邏輯服務(wù)器（地圖服務(wù)器）所能承載的最高在線（PCU）是在3000-5000不等；

2）Social Game由于沒有RPG復(fù)雜的移動(dòng)、戰(zhàn)斗、視野管理等需求，邏輯服務(wù)器承受的在線一般都是比較高的，如：10000-30000不等

（三）游戲邏輯服務(wù)器的Cache和回寫機(jī)制

1）RPG的游戲邏輯服務(wù)器一般都需要Cache玩家數(shù)據(jù)，并且采取定時(shí)回寫的策略，如根據(jù)數(shù)據(jù)重要程度分別作5min-15min不等的定時(shí)回寫；

2）Social Game的游戲邏輯服務(wù)器一般都無需Cache玩家數(shù)據(jù)，玩家的每次請(qǐng)求都是即時(shí)讀即時(shí)寫（這樣會(huì)涉及到另外一個(gè)問題，即DB讀寫的性能問題，見下一條）；

（四）DB存儲(chǔ)模型的選擇

1）RPG存儲(chǔ)服務(wù)器常用的還是MySQL+innodb，中間還由業(yè)務(wù)自己寫一個(gè)Cache代理服務(wù)器，以Cache熱點(diǎn)數(shù)據(jù)；

2）Social Game則會(huì)選用TC、MemCached等所謂Key-Value全內(nèi)存數(shù)據(jù)存儲(chǔ)，有實(shí)力的公司會(huì)自己實(shí)現(xiàn)一個(gè)類似這種機(jī)制的存儲(chǔ)系統(tǒng)，它可以無源，也可以是有源，并且還可以選擇用MySQL作數(shù)據(jù)落地，畢竟MySQL作為互聯(lián)網(wǎng)業(yè)務(wù)DB的成熟解決方案，已毋庸置疑；

（注：我們公司是選擇自己開發(fā)基于key-value機(jī)制的全內(nèi)存DB，現(xiàn)網(wǎng)測(cè)試的數(shù)據(jù)是平均1KB的數(shù)據(jù)可以分別達(dá)到5w左右的讀/寫，還是很牛X的了）

（五）交互數(shù)據(jù)的一致性

1）在SNS Game中，會(huì)經(jīng)常出現(xiàn)同一個(gè)玩家在某一個(gè)時(shí)刻同時(shí)被多個(gè)好友訪問和修改數(shù)據(jù)的情況，這時(shí)就需要保證，每次數(shù)據(jù)的更新都是正常有序進(jìn)行的，而不能被寫臟數(shù)據(jù)。一般地，都會(huì)使用一個(gè)類似全局鎖服務(wù)的設(shè)計(jì)來解決這個(gè)問題；

2）RPG不會(huì)存在這樣的問題，類似的需求是：玩家可能會(huì)跨地圖服務(wù)器，即所謂的跳線或跨服，這個(gè)問題的通常解決方案是服務(wù)器重新作一次下線、重登錄的處理，當(dāng)然，玩家是感覺不到的；

（六）IDC部署

1）RPG一般是分區(qū)分服部署；

2）Social Game則是全區(qū)全服部署；

呵，先寫這些多，后面再慢慢補(bǔ)充，也歡迎同行朋友拍磚！：）

發(fā)布于
關(guān)于游戲服務(wù)器性能問題的幾點(diǎn)思考（2）
工作中對(duì)項(xiàng)目壓力測(cè)試的一些心得，先自我作一個(gè)小結(jié)吧！

（一）宏觀與微觀相結(jié)合
  （1）宏觀層面
       即系統(tǒng)的一些關(guān)鍵性能指標(biāo)，如：各進(jìn)程所占CPU的百分比、內(nèi)存消耗、網(wǎng)絡(luò)包量、磁盤IO等等，詳細(xì)指標(biāo)列舉如下：
名稱 描述 參考值
CPU useage CPU 的使用時(shí)間百分比。 平均值小于70%
Process virtual memery size 進(jìn)程使用的內(nèi)存空間總量，包括物理內(nèi)存和swap內(nèi)存 進(jìn)程長時(shí)間運(yùn)行后該值不能大幅度的改變，否則是內(nèi)存泄露
Disk rate 磁盤傳輸速率 一般少于2M/s, 日志級(jí)別太低時(shí)硬盤io會(huì)是瓶頸。
Bytes trans rate 網(wǎng)絡(luò)發(fā)送速率 少于200Mbps
Bytes receive rate 網(wǎng)絡(luò)接收速率 少于200Mbps
Pages swap in 每秒鐘讀入到物理內(nèi)存中的頁數(shù) 長期大于0表示物理內(nèi)存不足
Pages swap out 每秒鐘寫入頁面文件頁數(shù) 參考上面
Context switches rate 每秒鐘在進(jìn)程或線程之間的切換率。 少于5000*cpu個(gè)數(shù)
Interrupt rate 每秒內(nèi)的設(shè)備中斷數(shù)。該指標(biāo)代表了本地向CPU引起的本地中斷，例如IO端口引起中斷，系統(tǒng)時(shí)鐘引起中斷。 一個(gè)巨大的中斷值，同時(shí)伴隨著緩慢的系統(tǒng)性能表現(xiàn)，指示存在硬件問題。
  

    測(cè)試工具：nmon
  （2）微觀層面
       這里是指具體到Server程序的邏輯功能模塊，包括函數(shù)消耗CPU周期、函數(shù)調(diào)用次數(shù)等資源占用情況，以及系統(tǒng)內(nèi)核哪一部分最忙等。
       測(cè)試工具：oprofile、gprof
 
（二）黑盒與白盒相結(jié)合
  （1）黑盒測(cè)試
       我們目前的壓力測(cè)試程序，其實(shí)是歸于黑盒測(cè)試范疇的，它模擬玩家的一些行為，應(yīng)用具體項(xiàng)目的實(shí)際協(xié)議與被測(cè)游戲Server通訊，通過同時(shí)產(chǎn)生大規(guī)模機(jī)器人，來模擬與實(shí)際運(yùn)營中相似的場(chǎng)景。這里編寫的測(cè)試用例，其功能就是要盡可能真實(shí)地模擬client的功能，并能方便的配置化和部署client行為；
  （2）白盒測(cè)試
       我理解的白盒測(cè)試包括兩部分，一是單元測(cè)試，它能有效地解決BUG回歸測(cè)試的問題，二是代碼覆蓋率檢查，它能有效檢查到每個(gè)函數(shù)分支的執(zhí)行情況。前者可借助業(yè)界成熟的自動(dòng)化測(cè)試框架，如：cppunit、gtest；后者也有許多第三方工具，比較方便的有GNU自帶的gcov，只要在編譯程序時(shí)，加入-fprofile-arcs -ftest-coverage編譯選項(xiàng)即可。
   如果要用一句話來概括兩者的話，那就是：
  白盒測(cè)試能極大的保障程序邏輯功能層面的正確性（正常與異常流程均能檢測(cè)到），而黑盒測(cè)試則能有效保障程序運(yùn)行的穩(wěn)定性。
發(fā)布于
MMORPG游戲在技能戰(zhàn)斗中的位置同步問題
這里列舉在技能戰(zhàn)斗系統(tǒng)開發(fā)中，碰到的兩個(gè)與位置同步相關(guān)的問題

（一）

在MMORPG游戲中，對(duì)于那些同時(shí)擁有近攻和遠(yuǎn)程系等多種職業(yè)的游戲，策劃一般都會(huì)對(duì)近攻類的職業(yè)，加上沖鋒類的技能，以便平衡遠(yuǎn)程類職業(yè)在攻擊距離上的優(yōu)勢(shì)。在client看到的效果，是玩家邊播放沖鋒動(dòng)作，然后快速接近目標(biāo)，并對(duì)目標(biāo)一個(gè)傷害，而對(duì)server而言，該技能與其它技能在處理的不同之處在于，施法玩家在施法的同時(shí)，也作一個(gè)位置的變更。一般server的處理流程是，先檢查沖鋒直線路徑是否合法（有無阻擋）和其它施法條件，若通過，則告訴client可以施法，并同時(shí)設(shè)置當(dāng)前玩家坐標(biāo)為沖鋒后的坐標(biāo)（該坐標(biāo)由client帶上來）。

由于server移動(dòng)系統(tǒng)在對(duì)client發(fā)過來的移動(dòng)數(shù)據(jù)作檢驗(yàn)時(shí)，需要檢查本次移動(dòng)的起步點(diǎn)，是否為上次移動(dòng)的結(jié)束點(diǎn)，即作線段端點(diǎn)合法檢查，而沖鋒到達(dá)的目標(biāo)點(diǎn)并未在上次移動(dòng)的路徑棧信息中，所以，server技能系統(tǒng)在設(shè)置沖鋒位置時(shí)，需要先清除原路徑棧信息（如調(diào)用MoveStop接口），以便確認(rèn)本次沖鋒為一次全新的移動(dòng)。

（二）

兩個(gè)玩家同時(shí)使用沖鋒技能時(shí)（目前client在做技能時(shí)，采用先表現(xiàn)的方式），出現(xiàn)一個(gè)玩家（沖鋒目標(biāo)client）停在沖鋒途中的現(xiàn)象，原因?yàn)閟erver廣播技能施法時(shí)，沒有帶目標(biāo)主動(dòng)位移的信息（client在處理沖鋒位置時(shí)，對(duì)于使用沖鋒技能的client，因?yàn)樗罌_鋒到達(dá)的位置，所以它的處理沒有問題，而另一個(gè)沖鋒目標(biāo)client，由于它不知道對(duì)方要沖到哪里，則client處理時(shí)就是選擇沖鋒路徑上的一點(diǎn)，這樣就會(huì)看到停在沖鋒途中了）所致。解決辦法是，要么在協(xié)議中下發(fā)目標(biāo)位移信息，要么在策劃規(guī)則上，只允許同一時(shí)刻一個(gè)玩家沖鋒，如：沖鋒加暈眩debug等；

發(fā)布于
MMORPG中技能戰(zhàn)斗系統(tǒng)的技術(shù)分享
今天下午參加了公司兄弟項(xiàng)目組的一個(gè)技術(shù)分享會(huì)，主題是關(guān)于MMORPG游戲中的技能系統(tǒng)設(shè)計(jì)的，有幾點(diǎn)體會(huì)和思考，先記錄下來了！

（1）技能施法時(shí)，client只有一個(gè)上行的請(qǐng)求施法包，后續(xù)施法的過程全由server來驅(qū)動(dòng)下發(fā)施法各階段的結(jié)果信息，如吟唱、效果傷害、命中信息等等；

（2）彈道類技能是由server計(jì)算飛行時(shí)間，并不考慮飛行后的軌跡，若此時(shí)目標(biāo)有移動(dòng)，則client會(huì)做目標(biāo)跟隨的處理；

（3）技能學(xué)習(xí)：由秘籍來獲得技能，一本秘籍包含多個(gè)技能，被動(dòng)技能不影響主動(dòng)技能的屬性；

（4）Buff系統(tǒng)與技能系統(tǒng)是相互獨(dú)立的，相互之間有接口各自的進(jìn)行訪問；

（5）玩家施法作群攻目標(biāo)選定時(shí)，也是由server來完成，這時(shí)是從玩家自己的視野里搜索，而無需再搜一次動(dòng)態(tài)區(qū)域（格子32*32）；

（6）技能效果由一個(gè)主效果+N個(gè)Buff效果組成；

（7）Buff對(duì)象區(qū)分玩家和怪物，其存儲(chǔ)結(jié)構(gòu)獨(dú)立出來放在內(nèi)存池中，在施法者需要時(shí)再根據(jù)目標(biāo)類型來添加；

（8）特別小心：在作技能效果計(jì)算時(shí)，盡量避免有輪循的處理，因?yàn)椋@個(gè)這個(gè)很耗CPU；

思考題：關(guān)于技能引發(fā)的位置同步問題

（1）對(duì)于改變目標(biāo)（玩家）移動(dòng)速度的技能，可能會(huì)帶來位置不同步的問題，即server下發(fā)速度改變的包時(shí)，目標(biāo)玩家可能正在移動(dòng)，從而導(dǎo)致server和client的位置不一致？

答：對(duì)于這個(gè)問題，一般是通過移動(dòng)系統(tǒng)自身的位置同步策略來解決的，即移動(dòng)系統(tǒng)發(fā)現(xiàn)client和server位置不一致時(shí)，通過一定的策略來補(bǔ)償速度慢的一方，從而在目標(biāo)玩家在接來的一定時(shí)間內(nèi)達(dá)到位置平衡。

（2）類似性質(zhì)的問題還有給目標(biāo)加冰凍、定身等Buff，也可能帶來位置不同步的問題？

答：這個(gè)問題暫也還沒有好的解決方案，目前的做法是當(dāng)目標(biāo)中定身Buff時(shí)，client立即表現(xiàn)定身，即定在原地，并將此時(shí)的位置信息帶給server，server檢驗(yàn)合法后設(shè)置這個(gè)位置，解凍后client為繼續(xù)玩家移動(dòng)（若玩家是移動(dòng)中被定身住的話）。