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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2 現(xiàn)狀
以stan經(jīng)歷過的工作室里三款游戲為例：微連、微胖和微塔。

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

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

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

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

（2）運維部署代價較高

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

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

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

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

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

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

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

為此，我們在實現(xiàn)需要遵行的一些原則有:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

進一步分析，該方案分為兩種情況：

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

圖1  阻塞同步序列圖

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

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

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

圖2  幀同步序列圖

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

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

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

圖3  弱同步序列圖

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

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

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

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

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

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

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

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

增量修改方案
實現(xiàn)要點是gamesvr修改玩家數(shù)據(jù)時，只提交修改的相對值，各個gamesvr的修改數(shù)據(jù)請求匯總至一臺中心服務(wù)器（熱點服務(wù)器）進行，因為只有一個地方修改，故修改數(shù)據(jù)自然會保持隊列同步。

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

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

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

（三）Compare And Swap

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

碰撞情形1：玩家A在P1點請求要去P2點時，玩家B也有可能在P3點請求要到P2點，但最終只能有一個人到P2的位置，如何避免拉扯呢。

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

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

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

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

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

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

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

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

如下圖所示：

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

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

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

優(yōu)點
保證了游戲操作手感，避免了本機操作延時。

缺點
運算邏輯存放在客戶端，會帶來較大的外掛風(fēng)險。

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

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

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

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

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

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

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

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

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

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

（一）協(xié)議通信

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

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

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

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

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

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

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

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

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

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

（四）DB存儲模型的選擇

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

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

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

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

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

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

（六）IDC部署

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

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

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

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

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

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

（一）

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

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

（二）

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

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

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

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

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

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

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

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

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

（8）特別小心：在作技能效果計算時，盡量避免有輪循的處理，因為，這個這個很耗CPU；

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

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

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

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

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