第一篇：游戲服務器架構(gòu)

星辰小屋004km.cn了，如果你要是想用自己的就把sa賬戶的密碼修改成自己的不過要修改五去文件

導入備份數(shù)據(jù)庫

星辰小屋004km.cn

星辰小屋004km.cn

星辰小屋004km.cn

星辰小屋004km.cn

再導入這個（方法和上面同樣）

星辰小屋004km.cn

多了兩個數(shù)據(jù)庫，這就是游戲的數(shù)據(jù)庫

星辰小屋004km.cn

現(xiàn)在數(shù)據(jù)庫完了，可以為自己注冊個賬號來測試了

服務器做好

了，現(xiàn)

在來

安

裝

客

戶

端

星辰小屋004km.cn

現(xiàn)在只要把服務器的服務開啟客戶端就可能進入游戲了

我沒有全部開啟因我只是做測試，一個人玩就開這么多就行了，要是多人玩就全開

星辰小屋004km.cn

開啟服務時在winows2003中正規(guī)服務器1線到3線可能開啟不了，解決方法：我的電腦-屬性-高級-設置

實驗結(jié)果：

星辰小屋004km.cn

在一臺機子上我用的兩個虛機太卡了所以我就不進入游戲了，有興趣的把郵箱留下我可以把服務器軟件發(fā)給你

第二篇：[zz]游戲服務器架構(gòu)探討(上)

[zz]游戲服務器架構(gòu)探討(上)2008-10-31 1116這里討論的游戲服務器架構(gòu)大概是目前國內(nèi)乃至世界上的網(wǎng)游通用的一種架構(gòu)了：

httpbbs.gameres.comshowthread.aspthreadid=93775 作者：qinglan

有段時間沒有研究技術(shù)了，這次正好看到了新版的mangos，較之以前我看的版本有了比較大的完善，于是再次瀏覽了下他的代碼，也借此機會整理下我在游戲服務器開發(fā)方面的一些心得，與大家探討。

另外由于為避免與公司引起一些不必要的糾紛，我所描述的全都是通過google能夠找到的資料，所以也可以認為我下面的內(nèi)容都是網(wǎng)上所找資料的整理合集。在平時的開發(fā)中我也搜索過相關(guān)的中文網(wǎng)頁，很少有講游戲服務器相關(guān)技術(shù)的，大家的討論主要還是集中在3D相關(guān)技術(shù)，所以也希望我將開始的這幾篇文章能夠起到拋磚引玉的作用，潛水的兄弟們也都上來透透氣。

要描述一項技術(shù)或是一個行業(yè)，一般都會從其最古老的歷史開始說起，我本也想按著這個套路走，無奈本人乃一八零后小輩，沒有經(jīng)歷過那些苦澀的卻令人羨慕的單機游戲開發(fā)，也沒有響當當?shù)哪玫某鍪值膬?yōu)秀作品，所以也就只能就我所了解的一些技術(shù)做些簡單的描述。一來算是敦促自己對知識做個梳理，二來與大家探討的過程也能夠找到我之前學習的不足和理解上的錯誤，最后呢，有可能的話也跟業(yè)內(nèi)的同行們混個臉熟，哪天要是想換個工作了也好有個人幫忙介紹下。最后的理由有些俗了。

關(guān)于游戲開發(fā)，正如云風在其blog上所說，游戲項目始終只是個小工程，另外開發(fā)時間還是個很重要的問題，所以軟件工程的思想及方法在大部分的游戲公司中并不怎么受歡迎。當然這也只是從我個人一些膚淺的了解所得，可能不夠充分。從游戲開發(fā)的程序團隊的人員構(gòu)成上也可看出來，基本只能算作是小開發(fā)團隊。有些工作室性質(zhì)的開發(fā)團隊，那就更簡單了。

我所了解的早些的開發(fā)團隊，其成員間沒有什么嚴格的分工，大家憑興趣自由選擇一些模塊來負責，完成了再去負責另一模塊，有其他同事的工作需要接手或協(xié)助的也會立即轉(zhuǎn)入。所以游戲開發(fā)人員基本都是多面手，從網(wǎng)絡到數(shù)據(jù)庫，從游戲邏輯到圖形圖象，每一項都有所了解，并能實際應用。或者說都具有非常強的學習能力，在接手一項新的任務后能在很短的時間內(nèi)對該領(lǐng)域的技術(shù)迅速掌握并消化，而且還能現(xiàn)炒現(xiàn)賣。當然，這也與早期2D游戲的技術(shù)要求相對比較簡單，游戲邏輯也沒有現(xiàn)在這般復雜有關(guān)。而更重要的可能是，都是被逼出來的吧！)

好了，閑話少說，下一篇，也就是第一篇了，主題為，服務器結(jié)構(gòu)探討。

服務器結(jié)構(gòu)探討--最簡單的結(jié)構(gòu)

所謂服務器結(jié)構(gòu)，也就是如何將服務器各部分合理地安排，以實現(xiàn)最初的功能需求。所以，結(jié)構(gòu)本無所謂正確與錯誤；當然，優(yōu)秀的結(jié)構(gòu)更有助于系統(tǒng)的搭建，對系統(tǒng)的可擴展性及可維護性也有更大的幫助。

好的結(jié)構(gòu)不是一蹴而就的，而且每個設計者心中的那把尺都不相同，所以這個優(yōu)秀結(jié)構(gòu)的定義也就沒有定論。在這里，我們不打算對現(xiàn)有游戲結(jié)構(gòu)做評價，而是試著從頭開始搭建一個我們需要的MMOG結(jié)構(gòu)。

對于一個最簡單的游戲服務器來說，它只需要能夠接受來自客戶端的連接請求，然后處理客戶端在游戲世界中的移動及交互，也即游戲邏輯處理即可。如果我們把這兩項功能集成到一個服務進程中，則最終的結(jié)構(gòu)很簡單：

client-----server

嗯，太簡單了點，這樣也敢叫服務器結(jié)構(gòu)？好吧，現(xiàn)在我們來往里面稍稍加點東西，讓它看起來更像是服務器結(jié)構(gòu)一些。

一般來說，我們在接入游戲服務器的時候都會要提供一個帳號和密碼，驗證通過后才能進入。關(guān)于為什么要提供用戶名和密碼才能進入的問題我們這里不打算做過多討論，云風曾對此也提出過類似的疑問，并給出了只用一個標識串就能進入的設想，有興趣的可以去看看他們的討論。但不管是采用何種方式進入，照目前看來我們的服務器起碼得提供一個帳號驗證的功能。

我們把觀察點先集中在一個大區(qū)內(nèi)。在大多數(shù)情況下，一個大區(qū)內(nèi)都會有多組游戲服，也就是多個游戲世界可供選擇。簡單點來實現(xiàn)，我們完全可以拋棄這個大區(qū)的概念，認為一個大區(qū)也就是放在同一個機房的多臺服務器組，各服務器組間沒有什么關(guān)系。這樣，我們可為每組服務器單獨配備一臺登錄服。最后的結(jié)構(gòu)圖應該像這樣：

loginServer gameServer client

該結(jié)構(gòu)下的玩家操作流程為，先選擇大區(qū)，再選擇大區(qū)下的某臺服務器，即某個游戲世界，點擊進入后開始帳號驗證過程，驗證成功則進入了該游戲世界。但是，如果玩家想要切換游戲世界，他只能先退出當前游戲世界，然后進入新的游戲世界重新進行帳號驗證。

早期的游戲大都采用的是這種結(jié)構(gòu)，有些游戲在實現(xiàn)時采用了一些技術(shù)手段使得在切換游戲服時不需要再次驗證帳號，但整體結(jié)構(gòu)還是未做改變。

該結(jié)構(gòu)存在一個服務器資源配置的問題。因為登錄服處理的邏輯相對來說比較簡單，就是將玩家提交的帳號和密碼送到數(shù)據(jù)庫進行驗證，和生成會話密鑰發(fā)送給游戲服和客戶端，操作完成后連接就會立即斷開，而且玩家在以后的游戲過程中不會再與登錄服打任何交道。這樣處理短連接的過程使得系統(tǒng)在大多數(shù)情況下都是比較空閑的，但是在某些時候，由于請求比較密集，比如開新服的時候，登錄服的負載又會比較大，甚至會處理不過來。

另外在實際的游戲運營中，有些游戲世界很火爆，而有些游戲世界卻非常冷清，甚至沒有多少人玩的情況也是很常見的。所以，我們能否更合理地配置登錄服資源，使得整個大區(qū)內(nèi)的登錄服可以共享就成了下一步改進的目標。

服務器結(jié)構(gòu)探討--登錄服的負載均衡

回想一下我們在玩wow時的操作流程：運行wow.exe進入游戲后，首先就會要求我們輸入用戶名和密碼進行驗證，驗證成功后才會出來游戲世界列表，之后是排隊進入游戲世界，開始游戲...可以看到跟前面的描述有個很明顯的不同，那就是要先驗證帳號再選擇游戲世界。這種結(jié)構(gòu)也就使得登錄服不是固定配備給個游戲世界，而是全區(qū)共有的。

我們可以試著從實際需求的角度來考慮一下這個問題。正如我們之前所描述過的那樣，登錄服在大多數(shù)情況下都是比較空閑的，也許我們的一個擁有20個游戲世界的大區(qū)僅僅使用10臺或更少的登錄服即可滿足需求。而當在開新區(qū)的時候，或許要配備40臺登錄服才能應付那如潮水般涌入的玩家登錄請求。所以，登錄服在設計上應該能滿足這種動態(tài)增刪的需求，我們可以在任何時候為大區(qū)增加或減少登錄服的部署。

當然，在這里也不會存在要求添加太多登錄服的情況。還是拿開新區(qū)的情況來說，即使新增加登錄服滿足了玩家登錄的請求，游戲世界服的承載能力依然有限，玩家一樣只能在排隊系統(tǒng)中等待，或者是進入到游戲世界中導致大家都卡。

另外，當我們在增加或移除登錄服的時候不應該需要對游戲世界服有所改動，也不會要求重啟世界服，當然也不應該要求客戶端有什么更新或者修改，一切都是在背后自動完成。

最后，有關(guān)數(shù)據(jù)持久化的問題也在這里考慮一下。一般來說，使用現(xiàn)有的商業(yè)數(shù)據(jù)庫系統(tǒng)比自己手工技術(shù)先進要明智得多。我們需要持久化的數(shù)據(jù)有玩家的帳號及密碼，玩家創(chuàng)建的角色相關(guān)信息，另外還有一些游戲世界全局共有數(shù)據(jù)也需要持久化。

好了，需求已經(jīng)提出來了，現(xiàn)在來考慮如何將其實現(xiàn)。

對于負載均衡來說，已有了成熟的解決方案。一般最常用，也最簡單部署的應該是基于DNS的負載均衡系統(tǒng)了，其通過在DNS中為一個域名配置多個IP地址來實現(xiàn)。最新的DNS服務已實現(xiàn)了根據(jù)服務器系統(tǒng)狀態(tài)來實現(xiàn)的動態(tài)負載均衡，也就是實現(xiàn)了真正意義上的負載均衡，這樣也就有效地解決了當某臺登錄服當機后，DNS服務器不能立即做出反應的問題。當然，如果找不到這樣的解決方案，自己從頭打造一個也并不難。而且，通過DNS來實現(xiàn)的負載均衡已經(jīng)包含了所做的修改對登錄服及客戶端的透明。

而對于數(shù)據(jù)庫的應用，在這種結(jié)構(gòu)下，登錄服及游戲世界服都會需要連接數(shù)據(jù)庫。從數(shù)據(jù)庫服務器的部署上來說，可以將帳號和角色數(shù)據(jù)都放在一個中心數(shù)據(jù)庫中，也可分為兩個不同的庫分別來處理，基到從物理上分到兩臺不同的服務器上去也行。

但是對于不同的游戲世界來說，其角色及游戲內(nèi)數(shù)據(jù)都是互相獨立的，所以一般情況下也就為每個游戲世界單獨配備一臺數(shù)據(jù)庫服務器，以減輕數(shù)據(jù)庫的壓力。所以，整體的服務器結(jié)構(gòu)應該是一個大區(qū)有一臺帳號數(shù)據(jù)庫服務器，所有的登錄服都連接到這里。而每個游戲世界都有自己的游戲數(shù)據(jù)庫服務器，只允許本游戲世界內(nèi)的服務器連接。

最后，我們的服務器結(jié)構(gòu)就像這樣：

大區(qū)服務器

登錄服1 登錄服2 世界服1 世界服2

帳號數(shù)據(jù)庫 DBS DBS

這里既然討論到了大區(qū)及帳號數(shù)據(jù)庫，所以順帶也說一下關(guān)于激活大區(qū)的概念。wow中一共有八個大區(qū)，我們想要進入某個大區(qū)游戲之前，必須到官網(wǎng)上激活這個區(qū)，這是為什么呢？

一般來說，在各個大區(qū)帳號數(shù)據(jù)庫之上還有一個總的帳號數(shù)據(jù)庫，我們可以稱它為中心數(shù)據(jù)庫。比如我們在官網(wǎng)上注冊了一個帳號，這時帳號數(shù)據(jù)是只保存在中心數(shù)據(jù)庫上的。而當我們要到一區(qū)去創(chuàng)建角色開始游戲的時候，在一區(qū)的帳號數(shù)據(jù)庫中并沒有我們的帳號數(shù)據(jù)，所以，我們必須先到官網(wǎng)上做一次激活操作。這個激活的過程也就是從中心庫上把我們的帳號數(shù)據(jù)拷貝到所要到的大區(qū)帳號數(shù)據(jù)庫中。

服務器結(jié)構(gòu)探討--簡單的世界服實現(xiàn)

討論了這么久我們一直都還沒有進入游戲世界服務器內(nèi)部，現(xiàn)在就讓我們來窺探一下里面的結(jié)構(gòu)吧。

對于現(xiàn)在大多數(shù)MMORPG來說，游戲服務器要處理的基本邏輯有移動、聊天、技能、物品、任務和生物等，另外還有地圖管理與消息廣播來對其他高級功能做支撐。如縱隊、好友、公會、戰(zhàn)場和副本等，這些都是通過基本邏輯功能組合或擴展而成。

在所有這些基礎邏輯中，與我們要討論的服務器結(jié)構(gòu)關(guān)系最緊密的當屬地圖管理方式。決定了地圖的管理方式也就決定了我們的服務器結(jié)構(gòu)，我們?nèi)匀幌葟淖詈唵蔚膶崿F(xiàn)方式開始說起。

回想一下我們曾戰(zhàn)斗過無數(shù)個夜晚的暗黑破壞神，整個暗黑的世界被分為了若干個獨立的小地圖，當我們在地圖間穿越時，一般都要經(jīng)過一個叫做傳送門的裝置。世界中有些地圖間雖然在地理上是直接相連的，但我們發(fā)現(xiàn)其游戲內(nèi)部的邏輯卻是完全隔離的?？梢赃@樣認為，一塊地圖就是一個獨立的數(shù)據(jù)處理單元。

既然如此，我們就把每塊地圖都當作是一臺獨立的服務器，他提供了在這塊地圖上游戲時的所有邏輯功能，至于內(nèi)部結(jié)構(gòu)如何劃分我們暫不理會，先把他當作一個黑盒子吧。

當兩個人合作做一件事時，我們可以以對等的關(guān)系相互協(xié)商著來做，而且一般也都不會有什么問題。當人數(shù)增加到三個時，我們對等的合作關(guān)系可能會有些復雜，因為我們每個人都同時要與另兩個人合作協(xié)商。正如俗語所說的那樣，三個和尚可能會碰到?jīng)]水喝的情況。當人數(shù)繼續(xù)增加，情況就變得不那么簡單了，我們得需要一個管理者來對我們的工作進行分工、協(xié)調(diào)。游戲的地圖服務器之間也是這么回事。

一般來說，我們的游戲世界不可能會只有一塊或者兩塊小地圖，那順理成章的，也就需要一個地圖管理者。先稱它為游戲世界的中心服務器吧，畢竟是管理者嘛，大家都以它為中心。

中心服務器主要維護一張地圖ID到地圖服務器地址的映射表。當我們要進入某張地圖時，會從中心服上取得該地圖的IP和port告訴客戶端，客戶端主動去連接，這樣進入他想要去的游戲地圖。在整個游戲過程中，客戶端始終只會與一臺地圖服務器保持連接，當要切換地圖的時候，在獲取到新地圖的地址后，會先與當前地圖斷開連接，再進入新的地圖，這樣保證玩家數(shù)據(jù)在服務器上只有一份。

我們來看看結(jié)構(gòu)圖是怎樣的：

中心服務器

登錄服 地圖1 地圖2 地圖n

客戶端

很簡單，不是嗎。但是簡單并不表示功能上會有什么損失，簡單也更不能表示游戲不能賺錢。早期不少游戲也確實采用的就是這種簡單結(jié)構(gòu)。

服務器結(jié)構(gòu)探討--繼續(xù)世界服

都已經(jīng)看出來了，這種每切換一次地圖就要重新連接服務器的方式實在是不夠優(yōu)雅，而且在實際游戲運營中也發(fā)現(xiàn)，地圖切換導致的卡號，復制裝備等問題非常多，這里完全就是一個事故多發(fā)地段，如何避免這種頻繁的連接操作呢？

最直接的方法就是把那個圖倒轉(zhuǎn)過來就行了?？蛻舳酥恍枰B接到中心服上，所有到地圖服務器的數(shù)據(jù)都由中心服來轉(zhuǎn)發(fā)。很完美的解決方案，不是嗎？

這種結(jié)構(gòu)在實際的部署中也遇到了一些挑戰(zhàn)。對于一般的MMORPG服務器來說，單臺服務器的承載量平均在2000左右，如果你的服務器很不幸地只能帶 1000人，沒關(guān)系，不少游戲都是如此；如果你的服務器上跑了3000多玩家依然比較流暢，那你可以自豪地告訴你的策劃，多設計些大量消耗服務器資源的玩法吧，比如大型國戰(zhàn)、公會戰(zhàn)爭等。

2000人，似乎我們的策劃朋友們不大愿意接受這個數(shù)字。我們將地圖服務器分開來原來也是想將負載分開，以多帶些客戶端，現(xiàn)在要所有的連接都從中心服上轉(zhuǎn)發(fā)，那連接數(shù)又遇到單臺服務器的可最大承載量的瓶頸了。這里有必要再解釋下這個數(shù)字。我知道，有人一定會說，才帶2000人，那是你水平不行，我隨便寫個TCP服務器都可帶個五六千連接。問題恰恰在于你是隨便寫的，而MMORPG的服務器是復雜設計的。如果一個演示socket API用的echo服務器就能滿足MMOG服務器的需求，那寫服務器該是件多么愜意的事啊。

但我們所遇到的事實是，服務器收到一個移動包后，要向周圍所有人廣播，而不是echo服務器那樣簡單的回應；服務器在收到一個連接斷開通知時要向很多人通知玩家退出事件，并將該玩家的資料寫入數(shù)據(jù)庫，而不是echo服務器那樣什么都不需要做；服務器在收到一個物品使用請求包后要做一系列的邏輯判斷以檢查玩家有沒有作弊；服務器上還啟動著很多定時器用來更新游戲世界的各種狀態(tài)......其實這么一比較，我們也看出資源消耗的所在了：服務器上大量的復雜的邏輯處理。再回過頭來看看我們想要實現(xiàn)的結(jié)構(gòu)，我們既想要有一個唯一的入口，使得客戶端不用頻繁改變連接，又希望這個唯一入口的負載不會太大，以致于接受不了多少連接。

仔細看一看這個需求，我們想要的僅僅只是一臺管理連接的服務器，并不打算讓他承擔太多的游戲邏輯。既然如此，那五六千個連接也還有滿足我們的要求。至少在現(xiàn)在來說，一個游戲世界內(nèi)，也就是一組服務器內(nèi)同時有五六千個在線的玩家還是件讓人很興奮的事。事實上，在大多數(shù)游戲的大部分時間里，這個數(shù)字也是很讓人眼紅的。

什么？你說夢幻、魔獸還有史先生的那個什么征途遠不止這么點人了！噢，我說的是大多數(shù)，是大多數(shù)，不包括那些明星。你知道大陸現(xiàn)在有多少游戲在運營嗎？或許你又該說，我們不該在一開始就把自己的目標定的太低！好吧，我們還是先不談這個。

繼續(xù)我們的結(jié)構(gòu)討論。一般來說，我們把這臺負責連接管理的服務器稱為網(wǎng)關(guān)服務器，因為內(nèi)部的數(shù)據(jù)都要通過這個網(wǎng)關(guān)才能出去，不過從這臺服務器提供的功能來看，稱其為反向代理服務器可能更合適。我們也不在這個名字上糾纏了，就按大家通用的叫法，還是稱他為網(wǎng)關(guān)服務器吧。

網(wǎng)關(guān)之后的結(jié)構(gòu)我們依然可以采用之前描述的方案，只是，似乎并沒有必要為每一個地圖都開一個獨立的監(jiān)聽端口了。我們可以試著對地圖進行一些劃分，由一個 Master Server來管理一些更小的Zone Server，玩家通過網(wǎng)關(guān)連接到Master Server上，而實際與地圖有關(guān)的邏輯是分派給更小的Zone Server去處理。

最后的結(jié)構(gòu)看起來大概是這樣的：

Zone Server Zone Server

Master Server Master Server

Gateway Server Center Server

Client

服務器結(jié)構(gòu)探討--最終的結(jié)構(gòu)

如果我們就此打住，可能馬上就會有人要嗤之以鼻了，就這點古董級的技術(shù)也敢出來現(xiàn)。好吧，我們還是把之前留下的問題拿出來解決掉吧。

一般來說，當某一部分能力達不到我們的要求時，最簡單的解決方法就是在此多投入一點資源。既然想要更多的連接數(shù)，那就再加一臺網(wǎng)關(guān)服務器吧。新增加了網(wǎng)關(guān)服后需要在大區(qū)服上做相應的支持，或者再簡單點，有一臺主要的網(wǎng)關(guān)服，當其負載較高時，主動將新到達的連接重定向到其他網(wǎng)關(guān)服上。

而對于游戲服來說，有一臺還是多臺網(wǎng)關(guān)服是沒有什么區(qū)別的。每個代表客戶端玩家的對象內(nèi)部都保留一個代表其連接的對象，消息廣播時要求每個玩家對象使用自己的連接對象發(fā)送數(shù)據(jù)即可，至于連接是在什么地方，那是完全透明的。當然，這只是一種簡單的實現(xiàn)，也是普通使用的一種方案，如果后期想對消息廣播做一些優(yōu)化的話，那可能才需要多考慮一下。

既然說到了優(yōu)化，我們也稍稍考慮一下現(xiàn)在結(jié)構(gòu)下可能采用的優(yōu)化方案。

首先是當前的Zone Server要做的事情太多了，以至于他都處理不了多少連接。這其中最消耗系統(tǒng)資源的當屬生物的AI處理了，尤其是那些復雜的尋路算法，所以我們可以考慮把這部分AI邏輯獨立出來，由一臺單獨的AI服務器來承擔。

然后，我們可以試著把一些與地圖數(shù)據(jù)無關(guān)的公共邏輯放到Master Server上去實現(xiàn)，這樣Zone Server上只保留了與地圖數(shù)據(jù)緊密相關(guān)的邏輯，如生物管理，玩家移動和狀態(tài)更新等。

還有聊天處理邏輯，這部分與游戲邏輯沒有任何關(guān)聯(lián)，我們也完全可以將其獨立出來，放到一臺單獨的聊天服務器上去實現(xiàn)。

最后是數(shù)據(jù)庫了，為了減輕數(shù)據(jù)庫的壓力，提高數(shù)據(jù)請求的響應速度，我們可以在數(shù)據(jù)庫之前建立一個數(shù)據(jù)庫緩存服務器，將一些常用數(shù)據(jù)緩存在此，服務器與數(shù)據(jù)庫的通信都要通過這臺服務器進行代理。緩存的數(shù)據(jù)會定時的寫入到后臺數(shù)據(jù)庫中。

好了，做完這些優(yōu)化我們的服務器結(jié)構(gòu)大體也就定的差不多了，暫且也不再繼續(xù)深入，更細化的內(nèi)容等到各個部分實現(xiàn)的時候再探討。

好比我們?nèi)タ匆粓鐾頃枧_上演員們按著預定的節(jié)目單有序地上演著，但這就是整場晚會的全部嗎？顯然不止，在幕后還有太多太多的人在忙碌著，甚至在晚會前和晚會后都有。我們的游戲服務器也如此。在之前描述的部分就如同舞臺上的演員，是我們能直接看到的，幕后的工作人員我們也來認識一下。

現(xiàn)實中有警察來維護秩序，游戲中也如此，這就是我們常說的GM。GM可以采用跟普通玩家一樣的拉入方式來進入游戲，當然權(quán)限會比普通玩家高一些，也可以提供一臺GM服務器專門用來處理GM命令，這樣可以有更高的安全性，GM服一般接在中心服務器上。

在以時間收費的游戲中，我們還需要一臺計費的服務器，這臺服務器一般接在網(wǎng)關(guān)服務器上，注冊玩家登錄和退出事件以記錄玩家的游戲時間。

任何為用戶提供服務的地方都會有日志記錄，游戲服務器當然也不例外。從記錄玩家登錄的時間，地址，機器信息到游戲過程中的每一項操作都可以作為日志記錄下來，以備查錯及數(shù)據(jù)挖掘用。至于搜集玩家機器資料所涉及到的法律問題不是我們該考慮的。

差不多就這么多了吧，接下來我們會按照這個大致的結(jié)構(gòu)來詳細討論各部分的實現(xiàn)。

服務器結(jié)構(gòu)探討--一點雜談

再強調(diào)一下，服務器結(jié)構(gòu)本無所謂好壞，只有是否適合自己。我們在前面探討了一些在現(xiàn)在的游戲中見到過的結(jié)構(gòu)，并盡我所知地分析了各自存在的一些問題和可以做的一些改進，希望其中沒有謬誤，如果能給大家也帶來些啟發(fā)那自然更好。

突然發(fā)現(xiàn)自己一旦羅嗦起來還真是沒完沒了。接下來先說說我在開發(fā)中遇到過的一些困惑和一基礎問題探討吧，這些問題可能有人與我一樣，也曾遇到過，或者正在被困擾中，而所要探討的這些基礎問題向來也是爭論比較多的，我們也不評價其中的好與壞，只做簡單的描述。

首先是服務器操作系統(tǒng)，linux與windows之爭隨處可見，其實在大多數(shù)情況下這不是我們所能決定的，似乎各大公司也基本都有了自己的傳統(tǒng)，如網(wǎng)易的freebsd，騰訊的linux等。如果真有權(quán)利去選擇的話，選自己最熟悉的吧。

決定了OS也就基本上確定了網(wǎng)絡IO模型，windows上的IOCP和linux下的epool，或者直接使用現(xiàn)有的網(wǎng)絡框架，如ACE和asio等，其他還有些商業(yè)的網(wǎng)絡庫在國內(nèi)的使用好像沒有見到，不符合中國國情嘛。)

然后是網(wǎng)絡協(xié)議的選擇，以前的選擇大多傾向于UDP，為了可靠傳輸一般自己都會在上面實現(xiàn)一層封裝，而現(xiàn)在更普通的是直接采用本身就很可靠的TCP，或者TCP與UDP的混用。早期選擇UDP的主要原因還是帶寬限制，現(xiàn)在寬帶普通的情況下TCP比UDP多出來的一點點開銷與開發(fā)的便利性相比已經(jīng)不算什么了。當然，如果已有了成熟的可靠UDP庫，那也可以繼續(xù)使用著。

還有消息包格式的定義，這個曾在云風的blog上展開過激烈的爭論。消息包格式定義包括三段，包長、消息碼和包體，爭論的焦點在于應該是消息碼在前還是包長在前，我們也把這個當作是信仰問題吧，有興趣的去云風的blog上看看，論論。另外早期有些游戲的包格式定義是以特殊字符作分隔的，這樣一個好處是其中某個包出現(xiàn)錯誤后我們的游戲還能繼續(xù)。但實際上，我覺得這是完全沒有必要的，真要出現(xiàn)這樣的錯誤，直接斷開這個客戶端的連接可能更安全。而且，以特殊字符做分隔的消息包定義還加大了一點點網(wǎng)絡數(shù)據(jù)量。

最后是一個純技術(shù)問題，有關(guān)socket連接數(shù)的最大限制。開始學習網(wǎng)絡編程的時候我犯過這樣的錯誤，以為port的定義為unsigned short，所以想當然的認為服務器的最大連接數(shù)為65535，這會是一個硬性的限制。而實際上，一個socket描述符在windows上的定義是 unsigned int，因此要有限制那也是四十多億，放心好了。

在服務器上port是監(jiān)聽用的，想象這樣一種情況，web server在80端口上監(jiān)聽，當一個連接到來時，系統(tǒng)會為這個連接分配一個socket句柄，同時與其在80端口上進行通訊；當另一個連接到來時，服務器仍然在80端口與之通信，只是分配的socket句柄不一樣。這個socket句柄才是描述每個連接的唯一標識。按windows網(wǎng)絡編程第二版上的說法，這個上限值配置影響。

好了，廢話說完了，下一篇，我們開始進入登錄服的設計吧。

第三篇：百萬用戶級游戲服務器架構(gòu)設計

百萬用戶級游戲服務器架構(gòu)設計

服務器結(jié)構(gòu)探討--最簡單的結(jié)構(gòu)

所謂服務器結(jié)構(gòu)，也就是如何將服務器各部分合理地安排，以實現(xiàn)最初的功能需求。所以，結(jié)構(gòu)本無所謂正確與錯誤；當然，優(yōu)秀的結(jié)構(gòu)更有助于系統(tǒng)的搭建，對系統(tǒng)的可擴展性及可維護性也有更大的幫助。

好的結(jié)構(gòu)不是一蹴而就的，而且每個設計者心中的那把尺都不相同，所以這個優(yōu)秀結(jié)構(gòu)的定義也就沒有定論。在這里，我們不打算對現(xiàn)有游戲結(jié)構(gòu)做評價，而是試著從頭開始搭建一個我們需要的MMOG結(jié)構(gòu)。

對于一個最簡單的游戲服務器來說，它只需要能夠接受來自客戶端的連接請求，然后處理客戶端在游戲世界中的移動及交互，也即游戲邏輯處理即可。如果我們把這兩項功能集成到一個服務進程中，則最終的結(jié)構(gòu)很簡單：

client-----server

嗯，太簡單了點，這樣也敢叫服務器結(jié)構(gòu)？好吧，現(xiàn)在我們來往里面稍稍加點東西，讓它看起來更像是服務器結(jié)構(gòu)一些。

一般來說，我們在接入游戲服務器的時候都會要提供一個帳號和密碼，驗證通過后才能進入。關(guān)于為什么要提供用戶名和密碼才能進入的問題我們這里不打算做過多討論，云風曾對此也提出過類似的疑問，并給出了只用一個標識串就能進入的設想，有興趣的可以去看看他們的討論。但不管是采用何種方式進入，照目前看來我們的服務器起碼得提供一個帳號驗證的功能。

我們把觀察點先集中在一個大區(qū)內(nèi)。在大多數(shù)情況下，一個大區(qū)內(nèi)都會有多組游戲服，也就是多個游戲世界可供選擇。簡單點來實現(xiàn)，我們完全可以拋棄這個大區(qū)的概念，認為一個大區(qū)也就是放在同一個機房的多臺服務器組，各服務器組間沒有什么關(guān)系。這樣，我們可為每組服務器單獨配備一臺登錄服。最后的結(jié)構(gòu)圖應該像這樣：

loginServer

gameServer

|

/

|

/

client

該結(jié)構(gòu)下的玩家操作流程為，先選擇大區(qū)，再選擇大區(qū)下的某臺服務器，即某個游戲世界，點擊進入后開始帳號驗證過程，驗證成功則進入了該游戲世界。但是，如果玩家想要切換游戲世界，他只能先退出當前游戲世界，然后進入新的游戲世界重新進行帳號驗證。

早期的游戲大都采用的是這種結(jié)構(gòu)，有些游戲在實現(xiàn)時采用了一些技術(shù)手段使得在切換游戲服時不需要再次驗證帳號，但整體結(jié)構(gòu)還是未做改變。

該結(jié)構(gòu)存在一個服務器資源配置的問題。因為登錄服處理的邏輯相對來說比較簡單，就是將玩家提交的帳號和密碼送到數(shù)據(jù)庫進行驗證，和生成會話密鑰發(fā)送給游戲服和客戶端，操作完成后連接就會立即斷開，而且玩家在以后的游戲過程中不會再與登錄服打任何交道。這樣處理短連接的過程使得系統(tǒng)在大多數(shù)情況下都是比較空閑的，但是在某些時候，由于請求比較密集，比如開新服的時候，登錄服的負載又會比較大，甚至會處理不過來。

另外在實際的游戲運營中，有些游戲世界很火爆，而有些游戲世界卻非常冷清，甚至沒有多少人玩的情況也是很常見的。所以，我們能否更合理地配置登錄服資源，使得整個大區(qū)內(nèi)的登錄服可以共享就成了下一步改進的目標。

服務器結(jié)構(gòu)探討--登錄服的負載均衡

回想一下我們在玩wow時的操作流程：運行wow.exe進入游戲后，首先就會要求我們輸入用戶名和密碼進行驗證，驗證成功后才會出來游戲世界列表，之后是排隊進入游戲世界，開始游戲...可以看到跟前面的描述有個很明顯的不同，那就是要先驗證帳號再選擇游戲世界。這種結(jié)構(gòu)也就使得登錄服不是固定配備給個游戲世界，而是全區(qū)共有的。

我們可以試著從實際需求的角度來考慮一下這個問題。正如我們之前所描述過的那樣，登錄服在大多數(shù)情況下都是比較空閑的，也許我們的一個擁有20個游戲世界的大區(qū)僅僅使用10臺或更少的登錄服即可滿足需求。而當在開新區(qū)的時候，或許要配備40臺登錄服才能應付那如潮水般涌入的玩家登錄請求。所以，登錄服在設計上應該能滿足這種動態(tài)增刪的需求，我們可以在任何時候為大區(qū)增加或減少登錄服的部署。

當然，在這里也不會存在要求添加太多登錄服的情況。還是拿開新區(qū)的情況來說，即使新增加登錄服滿足了玩家登錄的請求，游戲世界服的承載能力依然有限，玩家一樣只能在排隊系統(tǒng)中等待，或者是進入到游戲世界中導致大家都卡。

另外，當我們在增加或移除登錄服的時候不應該需要對游戲世界服有所改動，也不會要求重啟世界服，當然也不應該要求客戶端有什么更新或者修改，一切都是在背后自動完成。

最后，有關(guān)數(shù)據(jù)持久化的問題也在這里考慮一下。一般來說，使用現(xiàn)有的商業(yè)數(shù)據(jù)庫系統(tǒng)比自己手工技術(shù)先進要明智得多。我們需要持久化的數(shù)據(jù)有玩家的帳號及密碼，玩家創(chuàng)建的角色相關(guān)信息，另外還有一些游戲世界全局共有數(shù)據(jù)也需要持久化。

好了，需求已經(jīng)提出來了，現(xiàn)在來考慮如何將其實現(xiàn)。

對于負載均衡來說，已有了成熟的解決方案。一般最常用，也最簡單部署的應該是基于DNS的負載均衡系統(tǒng)了，其通過在DNS中為一個域名配置多個IP地址來實現(xiàn)。最新的DNS服務已實現(xiàn)了根據(jù)服務器系統(tǒng)狀態(tài)來實現(xiàn)的動態(tài)負載均衡，也就是實現(xiàn)了真正意義上的負載均衡，這樣也就有效地解決了當某臺登錄服當機后，DNS服務器不能立即做出反應的問題。當然，如果找不到這樣的解決方案，自己從頭打造一個也并不難。而且，通過DNS來實現(xiàn)的負載均衡已經(jīng)包含了所做的修改對登錄服及客戶端的透明。

而對于數(shù)據(jù)庫的應用，在這種結(jié)構(gòu)下，登錄服及游戲世界服都會需要連接數(shù)據(jù)庫。從數(shù)據(jù)庫服務器的部署上來說，可以將帳號和角色數(shù)據(jù)都放在一個中心數(shù)據(jù)庫中，也可分為兩個不同的庫分別來處理，基到從物理上分到兩臺不同的服務器上去也行。

但是對于不同的游戲世界來說，其角色及游戲內(nèi)數(shù)據(jù)都是互相獨立的，所以一般情況下也就為每個游戲世界單獨配備一臺數(shù)據(jù)庫服務器，以減輕數(shù)據(jù)庫的壓力。所以，整體的服務器結(jié)構(gòu)應該是一個大區(qū)有一臺帳號數(shù)據(jù)庫服務器，所有的登錄服都連接到這里。而每個游戲世界都有自己的游戲數(shù)據(jù)庫服務器，只允許本游戲世界內(nèi)的服務器連接。

最后，我們的服務器結(jié)構(gòu)就像這樣：

大區(qū)服務器

/

|

/

|

登錄服1

登錄服2

世界服1

世界服2

|

|

|

|

|

|

帳號數(shù)據(jù)庫

DBS

DBS

這里既然討論到了大區(qū)及帳號數(shù)據(jù)庫，所以順帶也說一下關(guān)于激活大區(qū)的概念。wow中一共有八個大區(qū)，我們想要進入某個大區(qū)游戲之前，必須到官網(wǎng)上激活這個區(qū)，這是為什么呢？

一般來說，在各個大區(qū)帳號數(shù)據(jù)庫之上還有一個總的帳號數(shù)據(jù)庫，我們可以稱它為中心數(shù)據(jù)庫。比如我們在官網(wǎng)上注冊了一個帳號，這時帳號數(shù)據(jù)是只保存在中心數(shù)據(jù)庫上的。而當我們要到一區(qū)去創(chuàng)建角色開始游戲的時候，在一區(qū)的帳號數(shù)據(jù)庫中并沒有我們的帳號數(shù)據(jù)，所以，我們必須先到官網(wǎng)上做一次激活操作。這個激活的過程也就是從中心庫上把我們的帳號數(shù)據(jù)拷貝到所要到的大區(qū)帳號數(shù)據(jù)庫中。

服務器結(jié)構(gòu)探討--簡單的世界服實現(xiàn)

討論了這么久我們一直都還沒有進入游戲世界服務器內(nèi)部，現(xiàn)在就讓我們來窺探一下里面的結(jié)構(gòu)吧。

對于現(xiàn)在大多數(shù)MMORPG來說，游戲服務器要處理的基本邏輯有移動、聊天、技能、物品、任務和生物等，另外還有地圖管理與消息廣播來對其他高級功能做支撐。如縱隊、好友、公會、戰(zhàn)場和副本等，這些都是通過基本邏輯功能組合或擴展而成。

在所有這些基礎邏輯中，與我們要討論的服務器結(jié)構(gòu)關(guān)系最緊密的當屬地圖管理方式。決定了地圖的管理方式也就決定了我們的服務器結(jié)構(gòu)，我們?nèi)匀幌葟淖詈唵蔚膶崿F(xiàn)方式開始說起。

回想一下我們曾戰(zhàn)斗過無數(shù)個夜晚的暗黑破壞神，整個暗黑的世界被分為了若干個獨立的小地圖，當我們在地圖間穿越時，一般都要經(jīng)過一個叫做傳送門的裝置。世界中有些地圖間雖然在地理上是直接相連的，但我們發(fā)現(xiàn)其游戲內(nèi)部的邏輯卻是完全隔離的?？梢赃@樣認為，一塊地圖就是一個獨立的數(shù)據(jù)處理單元。

既然如此，我們就把每塊地圖都當作是一臺獨立的服務器，他提供了在這塊地圖上游戲時的所有邏輯功能，至于內(nèi)部結(jié)構(gòu)如何劃分我們暫不理會，先把他當作一個黑盒子吧。

當兩個人合作做一件事時，我們可以以對等的關(guān)系相互協(xié)商著來做，而且一般也都不會有什么問題。當人數(shù)增加到三個時，我們對等的合作關(guān)系可能會有些復雜，因為我們每個人都同時要與另兩個人合作協(xié)商。正如俗語所說的那樣，三個和尚可能會碰到?jīng)]水喝的情況。當人數(shù)繼續(xù)增加，情況就變得不那么簡單了，我們得需要一個管理者來對我們的工作進行分工、協(xié)調(diào)。游戲的地圖服務器之間也是這么回事。

一般來說，我們的游戲世界不可能會只有一塊或者兩塊小地圖，那順理成章的，也就需要一個地圖管理者。先稱它為游戲世界的中心服務器吧，畢竟是管理者嘛，大家都以它為中心。

中心服務器主要維護一張地圖ID到地圖服務器地址的映射表。當我們要進入某張地圖時，會從中心服上取得該地圖的IP和port告訴客戶端，客戶端主動去連接，這樣進入他想要去的游戲地圖。在整個游戲過程中，客戶端始終只會與一臺地圖服務器保持連接，當要切換地圖的時候，在獲取到新地圖的地址后，會先與當前地圖斷開連接，再進入新的地圖，這樣保證玩家數(shù)據(jù)在服務器上只有一份。

我們來看看結(jié)構(gòu)圖是怎樣的：

中心服務器

/ / 登錄服 地圖1 地圖2 地圖n | / / | / /

客戶端

很簡單，不是嗎。但是簡單并不表示功能上會有什么損失，簡單也更不能表示游戲不能賺錢。早期不少游戲也確實采用的就是這種簡單結(jié)構(gòu)。

服務器結(jié)構(gòu)探討--繼續(xù)世界服

都已經(jīng)看出來了，這種每切換一次地圖就要重新連接服務器的方式實在是不夠優(yōu)雅，而且在實際游戲運營中也發(fā)現(xiàn)，地圖切換導致的卡號，復制裝備等問題非常多，這里完全就是一個事故多發(fā)地段，如何避免這種頻繁的連接操作呢？

最直接的方法就是把那個圖倒轉(zhuǎn)過來就行了?？蛻舳酥恍枰B接到中心服上，所有到地圖服務器的數(shù)據(jù)都由中心服來轉(zhuǎn)發(fā)。很完美的解決方案，不是嗎？

這種結(jié)構(gòu)在實際的部署中也遇到了一些挑戰(zhàn)。對于一般的MMORPG服務器來說，單臺服務器的承載量平均在2000左右，如果你的服務器很不幸地只能帶1000人，沒關(guān)系，不少游戲都是如此；如果你的服務器上跑了3000多玩家依然比較流暢，那你可以自豪地告訴你的策劃，多設計些大量消耗服務器資源的玩法吧，比如大型國戰(zhàn)、公會戰(zhàn)爭等。

2000人，似乎我們的策劃朋友們不大愿意接受這個數(shù)字。我們將地圖服務器分開來原來也是想將負載分開，以多帶些客戶端，現(xiàn)在要所有的連接都從中心服上轉(zhuǎn)發(fā)，那連接數(shù)又遇到單臺服務器的可最大承載量的瓶頸了。

這里有必要再解釋下這個數(shù)字。我知道，有人一定會說，才帶2000人，那是你水平不行，我隨便寫個TCP服務器都可帶個五六千連接。問題恰恰在于你是隨便寫的，而MMORPG的服務器是復雜設計的。如果一個演示socket API用的echo服務器就能滿足MMOG服務器的需求，那寫服務器該是件多么愜意的事啊。

但我們所遇到的事實是，服務器收到一個移動包后，要向周圍所有人廣播，而不是echo服務器那樣簡單的回應；服務器在收到一個連接斷開通知時要向很多人通知玩家退出事件，并將該玩家的資料寫入數(shù)據(jù)庫，而不是echo服務器那樣什么都不需要做；服務器在收到一個物品使用請求包后要做一系列的邏輯判斷以檢查玩家有沒有作弊；服務器上還啟動著很多定時器用來更新游戲世界的各種狀態(tài)......其實這么一比較，我們也看出資源消耗的所在了：服務器上大量的復雜的邏輯處理。再回過頭來看看我們想要實現(xiàn)的結(jié)構(gòu)，我們既想要有一個唯一的入口，使得客戶端不用頻繁改變連接，又希望這個唯一入口的負載不會太大，以致于接受不了多少連接。

仔細看一看這個需求，我們想要的僅僅只是一臺管理連接的服務器，并不打算讓他承擔太多的游戲邏輯。既然如此，那五六千個連接也還有滿足我們的要求。至少在現(xiàn)在來說，一個游戲世界內(nèi)，也就是一組服務器內(nèi)同時有五六千個在線的玩家還是件讓人很興奮的事。事實上，在大多數(shù)游戲的大部分時間里，這個數(shù)字也是很讓人眼紅的。

什么？你說夢幻、魔獸還有史先生的那個什么征途遠不止這么點人了！噢，我說的是大多數(shù)，是大多數(shù)，不包括那些明星。你知道大陸現(xiàn)在有多少游戲在運營嗎？或許你又該說，我們不該在一開始就把自己的目標定的太低！好吧，我們還是先不談這個。

繼續(xù)我們的結(jié)構(gòu)討論。一般來說，我們把這臺負責連接管理的服務器稱為網(wǎng)關(guān)服務器，因為內(nèi)部的數(shù)據(jù)都要通過這個網(wǎng)關(guān)才能出去，不過從這臺服務器提供的功能來看，稱其為反向代理服務器可能更合適。我們也不在這個名字上糾纏了，就按大家通用的叫法，還是稱他為網(wǎng)關(guān)服務器吧。

網(wǎng)關(guān)之后的結(jié)構(gòu)我們依然可以采用之前描述的方案，只是，似乎并沒有必要為每一個地圖都開一個獨立的監(jiān)聽端口了。我們可以試著對地圖進行一些劃分，由一個Master Server來管理一些更小的Zone Server，玩家通過網(wǎng)關(guān)連接到Master Server上，而實際與地圖有關(guān)的邏輯是分派給更小的Zone Server去處理。

最后的結(jié)構(gòu)看起來大概是這樣的：

Zone Server Zone Server / / Master Server Master Server / / / / Gateway Server / | / | / | Center Server | | Client

服務器結(jié)構(gòu)探討--最終的結(jié)構(gòu)

如果我們就此打住，可能馬上就會有人要嗤之以鼻了，就這點古董級的技術(shù)也敢出來現(xiàn)。好吧，我們還是把之前留下的問題拿出來解決掉吧。

一般來說，當某一部分能力達不到我們的要求時，最簡單的解決方法就是在此多投入一點資源。既然想要更多的連接數(shù)，那就再加一臺網(wǎng)關(guān)服務器吧。新增加了網(wǎng)關(guān)服后需要在大區(qū)服上做相應的支持，或者再簡單點，有一臺主要的網(wǎng)關(guān)服，當其負載較高時，主動將新到達的連接重定向到其他網(wǎng)關(guān)服上。

而對于游戲服來說，有一臺還是多臺網(wǎng)關(guān)服是沒有什么區(qū)別的。每個代表客戶端玩家的對象內(nèi)部都保留一個代表其連接的對象，消息廣播時要求每個玩家對象使用自己的連接對象發(fā)送數(shù)據(jù)即可，至于連接是在什么地方，那是完全透明的。當然，這只是一種簡單的實現(xiàn)，也是普通使用的一種方案，如果后期想對消息廣播做一些優(yōu)化的話，那可能才需要多考慮一下。

既然說到了優(yōu)化，我們也稍稍考慮一下現(xiàn)在結(jié)構(gòu)下可能采用的優(yōu)化方案。

首先是當前的Zone Server要做的事情太多了，以至于他都處理不了多少連接。這其中最消耗系統(tǒng)資源的當屬生物的AI處理了，尤其是那些復雜的尋路算法，所以我們可以考慮把這部分AI邏輯獨立出來，由一臺單獨的AI服務器來承擔。

然后，我們可以試著把一些與地圖數(shù)據(jù)無關(guān)的公共邏輯放到Master Server上去實現(xiàn)，這樣Zone Server上只保留了與地圖數(shù)據(jù)緊密相關(guān)的邏輯，如生物管理，玩家移動和狀態(tài)更新等。

還有聊天處理邏輯，這部分與游戲邏輯沒有任何關(guān)聯(lián)，我們也完全可以將其獨立出來，放到一臺單獨的聊天服務器上去實現(xiàn)。

最后是數(shù)據(jù)庫了，為了減輕數(shù)據(jù)庫的壓力，提高數(shù)據(jù)請求的響應速度，我們可以在數(shù)據(jù)庫之前建立一個數(shù)據(jù)庫緩存服務器，將一些常用數(shù)據(jù)緩存在此，服務器與數(shù)據(jù)庫的通信都要通過這臺服務器進行代理。緩存的數(shù)據(jù)會定時的寫入到后臺數(shù)據(jù)庫中。

好了，做完這些優(yōu)化我們的服務器結(jié)構(gòu)大體也就定的差不多了，暫且也不再繼續(xù)深入，更細化的內(nèi)容等到各個部分實現(xiàn)的時候再探討。

好比我們?nèi)タ匆粓鐾頃?，舞臺上演員們按著預定的節(jié)目單有序地上演著，但這就是整場晚會的全部嗎？顯然不止，在幕后還有太多太多的人在忙碌著，甚至在晚會前和晚會后都有。我們的游戲服務器也如此。

在之前描述的部分就如同舞臺上的演員，是我們能直接看到的，幕后的工作人員我們也來認識一下。

現(xiàn)實中有警察來維護秩序，游戲中也如此，這就是我們常說的GM。GM可以采用跟普通玩家一樣的拉入方式來進入游戲，當然權(quán)限會比普通玩家高一些，也可以提供一臺GM服務器專門用來處理GM命令，這樣可以有更高的安全性，GM服一般接在中心服務器上。

在以時間收費的游戲中，我們還需要一臺計費的服務器，這臺服務器一般接在網(wǎng)關(guān)服務器上，注冊玩家登錄和退出事件以記錄玩家的游戲時間。

任何為用戶提供服務的地方都會有日志記錄，游戲服務器當然也不例外。從記錄玩家登錄的時間，地址，機器信息到游戲過程中的每一項操作都可以作為日志記錄下來，以備查錯及數(shù)據(jù)挖掘用。至于搜集玩家機器資料所涉及到的法律問題不是我們該考慮的。

差不多就這么多了吧，接下來我們會按照這個大致的結(jié)構(gòu)來詳細討論各部分的實現(xiàn)。

服務器結(jié)構(gòu)探討--一點雜談

再強調(diào)一下，服務器結(jié)構(gòu)本無所謂好壞，只有是否適合自己。我們在前面探討了一些在現(xiàn)在的游戲中見到過的結(jié)構(gòu)，并盡我所知地分析了各自存在的一些問題和可以做的一些改進，希望其中沒有謬誤，如果能給大家也帶來些啟發(fā)那自然更好。

突然發(fā)現(xiàn)自己一旦羅嗦起來還真是沒完沒了。接下來先說說我在開發(fā)中遇到過的一些困惑和一基礎問題探討吧，這些問題可能有人與我一樣，也曾遇到過，或者正在被困擾中，而所要探討的這些基礎問題向來也是爭論比較多的，我們也不評價其中的好與壞，只做簡單的描述。

首先是服務器操作系統(tǒng)，linux與windows之爭隨處可見，其實在大多數(shù)情況下這不是我們所能決定的，似乎各大公司也基本都有了自己的傳統(tǒng)，如網(wǎng)易的freebsd，騰訊的linux等。如果真有權(quán)利去選擇的話，選自己最熟悉的吧。

決定了OS也就基本上確定了網(wǎng)絡IO模型，windows上的IOCP和linux下的epool，或者直接使用現(xiàn)有的網(wǎng)絡框架，如ACE和asio等，其他還有些商業(yè)的網(wǎng)絡庫在國內(nèi)的使用好像沒有見到，不符合中國國情嘛。:)

然后是網(wǎng)絡協(xié)議的選擇，以前的選擇大多傾向于UDP，為了可靠傳輸一般自己都會在上面實現(xiàn)一層封裝，而現(xiàn)在更普通的是直接采用本身就很可靠的TCP，或者TCP與UDP的混用。早期選擇UDP的主要原因還是帶寬限制，現(xiàn)在寬帶普通的情況下TCP比UDP多出來的一點點開銷與開發(fā)的便利性相比已經(jīng)不算什么了。當然，如果已有了成熟的可靠UDP庫，那也可以繼續(xù)使用著。

還有消息包格式的定義，這個曾在云風的blog上展開過激烈的爭論。消息包格式定義包括三段，包長、消息碼和包體，爭論的焦點在于應該是消息碼在前還是包長在前，我們也把這個當作是信仰問題吧，有興趣的去云風的blog上看看，論論。

另外早期有些游戲的包格式定義是以特殊字符作分隔的，這樣一個好處是其中某個包出現(xiàn)錯誤后我們的游戲還能繼續(xù)。但實際上，我覺得這是完全沒有必要的，真要出現(xiàn)這樣的錯誤，直接斷開這個客戶端的連接可能更安全。而且，以特殊字符做分隔的消息包定義還加大了一點點網(wǎng)絡數(shù)據(jù)量。

最后是一個純技術(shù)問題，有關(guān)socket連接數(shù)的最大限制。開始學習網(wǎng)絡編程的時候我犯過這樣的錯誤，以為port的定義為unsigned short，所以想當然的認為服務器的最大連接數(shù)為65535，這會是一個硬性的限制。而實際上，一個socket描述符在windows上的定義是unsigned int，因此要有限制那也是四十多億，放心好了。

在服務器上port是監(jiān)聽用的，想象這樣一種情況，web server在80端口上監(jiān)聽，當一個連接到來時，系統(tǒng)會為這個連接分配一個socket句柄，同時與其在80端口上進行通訊；當另一個連接到來時，服務器仍然在80端口與之通信，只是分配的socket句柄不一樣。這個socket句柄才是描述每個連接的唯一標識。按windows網(wǎng)絡編程第二版上的說法，這個上限值配置影響。

好了，廢話說完了，下一篇，我們開始進入登錄服的設計吧。

登錄服的設計--功能需求

正如我們在前面曾討論過的，登錄服要實現(xiàn)的功能相當簡單，就是帳號驗證。為了便于描述，我們暫不引入那些討論過的優(yōu)化手段，先以最簡單的方式實現(xiàn)，另外也將基本以mangos的代碼作為參考來進行描述。

想象一下帳號驗證的實現(xiàn)方法，最容易的那就是把用戶輸入的明文用帳號和密碼直接發(fā)給登錄服，服務器根據(jù)帳號從數(shù)據(jù)庫中取出密碼，與用戶輸入的密碼相比較。

這個方法存在的安全隱患實在太大，明文的密碼傳輸太容易被截獲了。那我們試著在傳輸之前先加一下密，為了服務器能進行密碼比較，我們應該采用一個可逆的加密算法，在服務器端把這個加密后的字串還原為原始的明文密碼，然后與數(shù)據(jù)庫密碼進行比較。既然是一個可逆的過程，那外掛制作者總有辦法知道我們的加密過程，所以，這個方法仍不夠安全。

哦，如果我們只是希望密碼不可能被還原出來，那還不容易嗎，使用一個不可逆的散列算法就行了。用戶在登錄時發(fā)送給服務器的是明文的帳號和經(jīng)散列后的不可逆密碼串，服務器取出密碼后也用同樣的算法進行散列后再進行比較。比如，我們就用使用最廣泛的md5算法吧。噢，不要管那個王小云的什么論文，如果我真有那么好的運氣，早中500w了，還用在這考慮該死的服務器設計嗎？

似乎是一個很完美的方案，外掛制作者再也偷不到我們的密碼了。慢著，外掛偷密碼的目的是什么？是為了能用我們的帳號進游戲！如果我們總是用一種固定的算法來對密碼做散列，那外掛只需要記住這個散列后的字串就行了，用這個做密碼就可以成功登錄。

嗯，這個問題好解決，我們不要用固定的算法進行散列就是了。只是，問題在于服務器與客戶端采用的散列算法得出的字串必須是相同的，或者是可驗證其是否匹配的。很幸運的是，偉大的數(shù)學字們早就為我們準備好了很多優(yōu)秀的這類算法，而且經(jīng)理論和實踐都證明他們也確實是足夠安全的。

這其中之一是一個叫做SRP的算法，全稱叫做Secure Remote Password，即安全遠程密碼。wow使用的是第6版，也就是SRP6算法。有關(guān)其中的數(shù)學證明，如果有人能向我解釋清楚，并能讓我真正弄明白的話，我將非常感激。不過其代碼實現(xiàn)步驟倒是并不復雜，mangos中的代碼也還算清晰，我們也不再贅述。

登錄服除了帳號驗證外還得提供另一項功能，就是在玩家的帳號驗證成功后返回給他一個服務器列表讓他去選擇。這個列表的狀態(tài)要定時刷新，可能有新的游戲世界開放了，也可能有些游戲世界非常不幸地停止運轉(zhuǎn)了，這些狀態(tài)的變化都要盡可能及時地讓玩家知道。不管發(fā)生了什么事，用戶都有權(quán)利知道，特別是對于付過費的用戶來說，我們不該藏著掖著，不是嗎？

這個游戲世界列表的功能將由大區(qū)服來提供，具體的結(jié)構(gòu)我們在之前也描述過，這里暫不做討論。登錄服將從大區(qū)服上獲取到的游戲世界列表發(fā)給已驗證通過的客戶端即可。好了，登錄服要實現(xiàn)的功能就這些，很簡單，是吧。

確實是太簡單了，不過簡單的結(jié)構(gòu)正好更適合我們來看一看游戲服務器內(nèi)部的模塊結(jié)構(gòu)，以及一些服務器共有組件的實現(xiàn)方法。這就留作下一篇吧。

服務器公共組件實現(xiàn)--mangos的游戲主循環(huán)

當閱讀一項工程的源碼時，我們大概會選擇從main函數(shù)開始，而當開始一項新的工程時，第一個寫下的函數(shù)大多也是main。那我們就先來看看，游戲服務器代碼實現(xiàn)中，main函數(shù)都做了些什么。

由于我在讀技術(shù)文章時最不喜看到的就是大段大段的代碼，特別是那些直接Ctrl+C再Ctrl+V后未做任何修改的代碼，用句時髦的話說，一點技術(shù)含量都沒有！所以在我們今后所要討論的內(nèi)容中，盡量會避免出現(xiàn)直接的代碼，在有些地方確實需要代碼來表述時，也將會選擇使用偽碼。

先從mangos的登錄服代碼開始。mangos的登錄服是一個單線程的結(jié)構(gòu)，雖然在數(shù)據(jù)庫連接中可以開啟一個獨立的線程，但這個線程也只是對無返回結(jié)果的執(zhí)行類SQL做緩沖，而對需要有返回結(jié)果的查詢類SQL還是在主邏輯線程中阻塞調(diào)用的。

登錄服中唯一的這一個線程，也就是主循環(huán)線程對監(jiān)聽的socket做select操作，為每個連接進來的客戶端讀取其上的數(shù)據(jù)并立即進行處理，直到服務器收到SIGABRT或SIGBREAK信號時結(jié)束。

所以，mangos登錄服主循環(huán)的邏輯，也包括后面游戲服的邏輯，主循環(huán)的關(guān)鍵代碼其實是在SocketHandler中，也就是那個Select函數(shù)中。檢查所有的連接，對新到來的連接調(diào)用OnAccept方法，有數(shù)據(jù)到來的連接則調(diào)用OnRead方法，然后socket處理器自己定義對接收到的數(shù)據(jù)如何處理。

很簡單的結(jié)構(gòu)，也比較容易理解。

只是，在對性能要求比較高的服務器上，select一般不會是最好的選擇。如果我們使用windows平臺，那IOCP將是首選；如果是linux，epool將是不二選擇。我們也不打算討論基于IOCP或是基于epool的服務器實現(xiàn)，如果僅僅只是要實現(xiàn)服務器功能，很簡單的幾個API調(diào)用即可，而且網(wǎng)上已有很多好的教程；如果是要做一個成熟的網(wǎng)絡服務器產(chǎn)品，不是我?guī)灼唵蔚募夹g(shù)介紹文章所能達到。

另外，在服務器實現(xiàn)上，網(wǎng)絡IO與邏輯處理一般會放在不同的線程中，以免耗時較長的IO過程阻塞住了需要立即反應的游戲邏輯。

數(shù)據(jù)庫的處理也類似，會使用異步的方式，也是避免耗時的查詢過程將游戲服務器主循環(huán)阻塞住。想象一下，因某個玩家上線而發(fā)起的一次數(shù)據(jù)庫查詢操作導致服務器內(nèi)所有在線玩家都卡住不動將是多么恐怖的一件事！

另外還有一些如事件、腳本、消息隊列、狀態(tài)機、日志和異常處理等公共組件，我們也會在接下來的時間里進行探討。

服務器公共組件實現(xiàn)--繼續(xù)來說主循環(huán)

前面我們只簡單了解了下mangos登錄服的程序結(jié)構(gòu)，也發(fā)現(xiàn)了一些不足之處，現(xiàn)在我們就來看看如何提供一個更好的方案。

正如我們曾討論過的，為了游戲主邏輯循環(huán)的流暢運行，所有比較耗時的IO操作都會分享到單獨的線程中去做，如網(wǎng)絡IO，數(shù)據(jù)庫IO和日志IO等。當然，也有把這些分享到單獨的進程中去做的。

另外對于大多數(shù)服務器程序來說，在運行時都是作為精靈進程或服務進程的，所以我們并不需要服務器能夠處理控制臺用戶輸入，我們所要處理的數(shù)據(jù)來源都來自網(wǎng)絡。

這樣，主邏輯循環(huán)所要做的就是不停要取消息包來處理，當然這些消息包不僅有來自客戶端的玩家操作數(shù)據(jù)包，也有來自GM服務器的管理命令，還包括來自數(shù)據(jù)庫查詢線程的返回結(jié)果消息包。這個循環(huán)將一直持續(xù)，直到收到一個通知服務器關(guān)閉的消息包。

主邏輯循環(huán)的結(jié)構(gòu)還是很簡單的，復雜的部分都在如何處理這些消息包的邏輯上。我們可以用一段簡單的偽碼來描述這個循環(huán)過程：

while(Message* msg = getMessage())

{

if(msg為服務器關(guān)閉消息)

break;

處理msg消息;

}

這里就有一個問題需要探討了，在getMessage()的時候，我們應該去哪里取消息？前面我們考慮過，至少會有三個消息來源，而我們還討論過，這些消息源的IO操作都是在獨立的線程中進行的，我們這里的主線程不應該直接去那幾處消息源進行阻塞式的IO操作。

很簡單，讓那些獨立的IO線程在接收完數(shù)據(jù)后自己送過來就是了。好比是，我這里提供了一個倉庫，有很多的供貨商，他們有貨要給我的時候只需要交到倉庫，然后我再到倉庫去取就是了，這個倉庫也就是消息隊列。消息隊列是一個普通的隊列實現(xiàn)，當然必須要提供多線程互斥訪問的安全性支持，其基本的接口定義大概類似這樣：

IMessageQueue

{

void putMessage(Message*);

Message* getMessage();

}

網(wǎng)絡IO，數(shù)據(jù)庫IO線程把整理好的消息包都加入到主邏輯循環(huán)線程的這個消息隊列中便返回。有關(guān)消息隊列的實現(xiàn)和線程間消息的傳遞在ACE中有比較完全的代碼實現(xiàn)及描述，還有一些使用示例，是個很好的參考。

這樣的話，我們的主循環(huán)就很清晰了，從主線程的消息隊列中取消息，處理消息，再取下一條消息......服務器公共組件實現(xiàn)--消息隊列

既然說到了消息隊列，那我們繼續(xù)來稍微多聊一點吧。

我們所能想到的最簡單的消息隊列可能就是使用stl的list來實現(xiàn)了，即消息隊列內(nèi)部維護一個list和一個互斥鎖，putMessage時將message加入到隊列尾，getMessage時從隊列頭取一個message返回，同時在getMessage和putMessage之前都要求先獲取鎖資源。

實現(xiàn)雖然簡單，但功能是絕對滿足需求的，只是性能上可能稍稍有些不盡如人意。其最大的問題在頻繁的鎖競爭上。

對于如何減少鎖競爭次數(shù)的優(yōu)化方案，Ghost Cheng提出了一種。提供一個隊列容器，里面有多個隊列，每個隊列都可固定存放一定數(shù)量的消息。網(wǎng)絡IO線程要給邏輯線程投遞消息時，會從隊列容器中取一個空隊列來使用，直到將該隊列填滿后再放回容器中換另一個空隊列。而邏輯線程取消息時是從隊列容器中取一個有消息的隊列來讀取，處理完后清空隊列再放回到容器中。

這樣便使得只有在對隊列容器進行操作時才需要加鎖，而IO線程和邏輯線程在操作自己當前使用的隊列時都不需要加鎖，所以鎖競爭的機會大大減少了。

這里為每個隊列設了個最大消息數(shù)，看來好像是打算只有當IO線程寫滿隊列時才會將其放回到容器中換另一個隊列。那這樣有時也會出現(xiàn)IO線程未寫滿一個隊列，而邏輯線程又沒有數(shù)據(jù)可處理的情況，特別是當數(shù)據(jù)量很少時可能會很容易出現(xiàn)。Ghost Cheng在他的描述中沒有講到如何解決這種問題，但我們可以先來看看另一個方案。

這個方案與上一個方案基本類似，只是不再提供隊列容器，因為在這個方案中只使用了兩個隊列，arthur在他的一封郵件中描述了這個方案的實現(xiàn)及部分代碼。兩個隊列，一個給邏輯線程讀，一個給IO線程用來寫，當邏輯線程讀完隊列后會將自己的隊列與IO線程的隊列相調(diào)換。所以，這種方案下加鎖的次數(shù)會比較多一些，IO線程每次寫隊列時都要加鎖，邏輯線程在調(diào)換隊列時也需要加鎖，但邏輯線程在讀隊列時是不需要加鎖的。

雖然看起來鎖的調(diào)用次數(shù)是比前一種方案要多很多，但實際上大部分鎖調(diào)用都是不會引起阻塞的，只有在邏輯線程調(diào)換隊列的那一瞬間可能會使得某個線程阻塞一下。另外對于鎖調(diào)用過程本身來說，其開銷是完全可以忽略的，我們所不能忍受的僅僅是因為鎖調(diào)用而引起的阻塞而已。

兩種方案都是很優(yōu)秀的優(yōu)化方案，但也都是有其適用范圍的。Ghost Cheng的方案因為提供了多個隊列，可以使得多個IO線程可以總工程師的，互不干擾的使用自己的隊列，只是還有一個遺留問題我們還不了解其解決方法。arthur的方案很好的解決了上一個方案遺留的問題，但因為只有一個寫隊列，所以當想要提供多個IO線程時，線程間互斥地寫入數(shù)據(jù)可能會增大競爭的機會，當然，如果只有一個IO線程那將是非常完美的。

服務器公共組件實現(xiàn)--環(huán)形緩沖區(qū)

消息隊列鎖調(diào)用太頻繁的問題算是解決了，另一個讓人有些苦惱的大概是這太多的內(nèi)存分配和釋放操作了。頻繁的內(nèi)存分配不但增加了系統(tǒng)開銷，更使得內(nèi)存碎片不斷增多，非常不利于我們的服務器長期穩(wěn)定運行。也許我們可以使用內(nèi)存池，比如SGI STL中附帶的小內(nèi)存分配器。但是對于這種按照嚴格的先進先出順序處理的，塊大小并不算小的，而且塊大小也并不統(tǒng)一的內(nèi)存分配情況來說，更多使用的是一種叫做環(huán)形緩沖區(qū)的方案，mangos的網(wǎng)絡代碼中也有這么一個東西，其原理也是比較簡單的。

就好比兩個人圍著一張圓形的桌子在追逐，跑的人被網(wǎng)絡IO線程所控制，當寫入數(shù)據(jù)時，這個人就往前跑；追的人就是邏輯線程，會一直往前追直到追上跑的人。如果追上了怎么辦？那就是沒有數(shù)據(jù)可讀了，先等會兒唄，等跑的人向前跑幾步了再追，總不能讓游戲沒得玩了吧。那要是追的人跑的太慢，跑的人轉(zhuǎn)了一圈過來反追上追的人了呢？那您也先歇會兒吧。要是一直這么反著追，估計您就只能換一個跑的更快的追逐者了，要不這游戲還真沒法玩下去。

前面我們特別強調(diào)了，按照嚴格的先進先出順序進行處理，這是環(huán)形緩沖區(qū)的使用必須遵守的一項要求。也就是，大家都得遵守規(guī)定，追的人不能從桌子上跨過去，跑的人當然也不允許反過來跑。至于為什么，不需要多做解釋了吧。

環(huán)形緩沖區(qū)是一項很好的技術(shù)，不用頻繁的分配內(nèi)存，而且在大多數(shù)情況下，內(nèi)存的反復使用也使得我們能用更少的內(nèi)存塊做更多的事。

在網(wǎng)絡IO線程中，我們會為每一個連接都準備一個環(huán)形緩沖區(qū)，用于臨時存放接收到的數(shù)據(jù)，以應付半包及粘包的情況。在解包及解密完成后，我們會將這個數(shù)據(jù)包復制到邏輯線程消息隊列中，如果我們只使用一個隊列，那這里也將會是個環(huán)形緩沖區(qū)，IO線程往里寫，邏輯線程在后面讀，互相追逐?？梢俏覀兪褂昧饲懊娼榻B的優(yōu)化方案后，可能這里便不再需要環(huán)形緩沖區(qū)了，至少我們并不再需要他們是環(huán)形的了。因為我們對同一個隊列不再會出現(xiàn)同時讀和寫的情況，每個隊列在寫滿后交給邏輯線程去讀，邏輯線程讀完后清空隊列再交給IO線程去寫，一段固定大小的緩沖區(qū)即可。沒關(guān)系，這么好的技術(shù)，在別的地方一定也會用到的。

服務器公共組件實現(xiàn)--發(fā)包的方式

前面一直都在說接收數(shù)據(jù)時的處理方法，我們應該用專門的IO線程，接收到完整的消息包后加入到主線程的消息隊列，但是主線程如何發(fā)送數(shù)據(jù)還沒有探討過。

一般來說最直接的方法就是邏輯線程什么時候想發(fā)數(shù)據(jù)了就直接調(diào)用相關(guān)的socket API發(fā)送，這要求服務器的玩家對象中保存其連接的socket句柄。但是直接send調(diào)用有時候有會存在一些問題，比如遇到系統(tǒng)的發(fā)送緩沖區(qū)滿而阻塞住的情況，或者只發(fā)送了一部分數(shù)據(jù)的情況也時有發(fā)生。我們可以將要發(fā)送的數(shù)據(jù)先緩存一下，這樣遇到未發(fā)送完的，在邏輯線程的下一次處理時可以接著再發(fā)送。

考慮數(shù)據(jù)緩存的話，那這里這可以有兩種實現(xiàn)方式了，一是為每個玩家準備一個緩沖區(qū)，另外就是只有一個全局的緩沖區(qū)，要發(fā)送的數(shù)據(jù)加入到全局緩沖區(qū)的時候同時要指明這個數(shù)據(jù)是發(fā)到哪個socket的。如果使用全局緩沖區(qū)的話，那我們可以再進一步，使用一個獨立的線程來處理數(shù)據(jù)發(fā)送，類似于邏輯線程對數(shù)據(jù)的處理方式，這個獨立發(fā)送線程也維護一個消息隊列，邏輯線程要發(fā)數(shù)據(jù)時也只是把數(shù)據(jù)加入到這個隊列中，發(fā)送線程循環(huán)取包來執(zhí)行send調(diào)用，這時的阻塞也就不會對邏輯線程有任何影響了。

采用第二種方式還可以附帶一個優(yōu)化方案。一般對于廣播消息而言，發(fā)送給周圍玩家的數(shù)據(jù)都是完全相同的，我們?nèi)绻捎媒o每個玩家一個緩沖隊列的方式，這個數(shù)據(jù)包將需要拷貝多份，而采用一個全局發(fā)送隊列時，我們只需要把這個消息入隊一次，同時指明該消息包是要發(fā)送給哪些socket的即可。有關(guān)該優(yōu)化的說明在云風描述其連接服務器實現(xiàn)的blog文章中也有講到，有興趣的可以去閱讀一下。

服務器公共組件實現(xiàn)--狀態(tài)機

有關(guān)State模式的設計意圖及實現(xiàn)就不從設計模式中摘抄了，我們只來看看游戲服務器編程中如何使用State設計模式。

首先還是從mangos的代碼開始看起，我們注意到登錄服在處理客戶端發(fā)來的消息時用到了這樣一個結(jié)構(gòu)體：

struct AuthHandler

{

eAuthCmd cmd;

uint32 status;

bool(AuthSocket::*handler)(void);

};

該結(jié)構(gòu)體定義了每個消息碼的處理函數(shù)及需要的狀態(tài)標識，只有當前狀態(tài)滿足要求時才會調(diào)用指定的處理函數(shù)，否則這個消息碼的出現(xiàn)是不合法的。這個status狀態(tài)標識的定義是一個宏，有兩種有效的標識，STATUS_CONNECTED和STATUS_AUTHED，也就是未認證通過和已認證通過。而這個狀態(tài)標識的改變是在運行時進行的，確切的說是在收到某個消息并正確處理完后改變的。

我們再來看看設計模式中對State模式的說明，其中關(guān)于State模式適用情況里有一條，當操作中含有龐大的多分支的條件語句，且這些分支依賴于該對象的狀態(tài)，這個狀態(tài)通常用一個或多個枚舉變量表示。

描述的情況與我們這里所要處理的情況是如此的相似，也許我們可以試一試。那再看看State模式提供的解決方案是怎樣的，State模式將每一個條件分支放入一個獨立的類中。

由于這里的兩個狀態(tài)標識只區(qū)分出了兩種狀態(tài)，所以，我們僅需要兩個獨立的類，用以表示兩種狀態(tài)即可。然后，按照State模式的描述，我們還需要一個Context類，也就是狀態(tài)機管理類，用以管理當前的狀態(tài)類。稍作整理，大概的代碼會類似這樣：

狀態(tài)基類接口：

StateBase

{

void Enter()= 0;

void Leave()= 0;

void Process(Message* msg)= 0;

};

狀態(tài)機基類接口：

MachineBase

{

void ChangeState(StateBase* state)= 0;

StateBase* m_curState;

};

我們的邏輯處理類會從MachineBase派生，當取出數(shù)據(jù)包后交給當前狀態(tài)處理，前面描述的兩個狀態(tài)類從StateBase派生，每個狀態(tài)類只處理該狀態(tài)標識下需要處理的消息。當要進行狀態(tài)轉(zhuǎn)換時，調(diào)用MachineBase的ChangeState()方法，顯示地告訴狀態(tài)機管理類自己要轉(zhuǎn)到哪一個狀態(tài)。所以，狀態(tài)類內(nèi)部需要保存狀態(tài)機管理類的指針，這個可以在狀態(tài)類初始化時傳入。具體的實現(xiàn)細節(jié)就不做過多描述了。

使用狀態(tài)機雖然避免了復雜的判斷語句，但也引入了新的麻煩。當我們在進行狀態(tài)轉(zhuǎn)換時，可能會需要將一些現(xiàn)場數(shù)據(jù)從老狀態(tài)對象轉(zhuǎn)移到新狀態(tài)對象，這需要在定義接口時做一下考慮。如果不希望執(zhí)行拷貝，那么這里公有的現(xiàn)場數(shù)據(jù)也可放到狀態(tài)機類中，只是這樣在使用時可能就不那么優(yōu)雅了。<

BR>

正如同在設計模式中所描述的，所有的模式都是已有問題的另一種解決方案，也就是說這并不是唯一的解決方案。放到我們今天討論的State模式中，就拿登錄服所處理的兩個狀態(tài)來說，也許用mangos所采用的遍歷處理函數(shù)的方法可能更簡單，但當系統(tǒng)中的狀態(tài)數(shù)量增多，狀態(tài)標識也變多的時候，State模式就顯得尤其重要了。

比如在游戲服務器上玩家的狀態(tài)管理，還有在實現(xiàn)NPC人工智能時的各種狀態(tài)管理，這些就留作以后的專題吧。

服務器公共組件--事件與信號

關(guān)于這一節(jié)，這幾天已經(jīng)打了好幾遍草稿，總覺得說不清楚，也不好組織這些內(nèi)容，但是打鐵要趁熱，為避免熱情消退，先整理一點東西放這，好繼續(xù)下面的主題，以后如果有機會再回來完善吧。本節(jié)內(nèi)容欠考慮，希望大家多給點意見。

有些類似于QT中的event與signal，我將一些動作請求消息定義為事件，而將狀態(tài)改變消息定義為信號。比如在QT應用程序中，用戶的一次鼠標點擊會產(chǎn)生一個鼠標點擊事件加入到事件隊列中，當處理此事件時可能會導致某個按鈕控件產(chǎn)生一個clicked()信號。

對應到我們的服務器上的一個例子，玩家登錄時會發(fā)給服務器一個請求登錄的數(shù)據(jù)包，服務器可將其當作一個用戶登錄事件，該事件處理完后可能會產(chǎn)生一個用戶已登錄信號。

這樣，與QT類似，對于事件我們可以重定義其處理方法，甚至過濾掉某些事件使其不被處理，但對于信號我們只是收到了一個通知，有些類似于Observe模式中的觀察者，當收到更新通知時，我們只能更新自己的狀態(tài)，對剛剛發(fā)生的事件我不已不能做任何影響。仔細來看，事件與信號其實并無多大差別，從我們對其需求上來說，都只要能注冊事件或信號響應函數(shù)，在事件或信號產(chǎn)生時能夠被通知到即可。但有一項區(qū)別在于，事件處理函數(shù)的返回值是有意義的，我們要根據(jù)這個返回值來確定是否還要繼續(xù)事件的處理，比如在QT中，事件處理函數(shù)如果返回true，則這個事件處理已完成，QApplication會接著處理下一個事件，而如果返回false，那么事件分派函數(shù)會繼續(xù)向上尋找下一個可以處理該事件的注冊方法。信號處理函數(shù)的返回值對信號分派器來說是無意義的。

簡單點說，就是我們可以為事件定義過濾器，使得事件可以被過濾。這一功能需求在游戲服務器上是到處存在的。

關(guān)于事件和信號機制的實現(xiàn)，網(wǎng)絡上的開源訓也比較多，比如FastDelegate，sigslot，boost::signal等，其中sigslot還被Google采用，在libjingle的代碼中我們可以看到他是如何被使用的。

在實現(xiàn)事件和信號機制時或許可以考慮用同一套實現(xiàn)，在前面我們就分析過，兩者唯一的區(qū)別僅在于返回值的處理上。

另外還有一個需要我們關(guān)注的問題是事件和信號處理時的優(yōu)先級問題。在QT中，事件因為都是與窗口相關(guān)的，所以事件回調(diào)時都是從當前窗口開始，一級一級向上派發(fā)，直到有一個窗口返回true，截斷了事件的處理為止。對于信號的處理則比較簡單，默認是沒有順序的，如果需要明確的順序，可以在信號注冊時顯示地指明槽的位置。

在我們的需求中，因為沒有窗口的概念，事件的處理也與信號類似，對注冊過的處理器要按某個順序依次回調(diào)，所以優(yōu)先級的設置功能是需要的。

最后需要我們考慮的是事件和信號的處理方式。在QT中，事件使用了一個事件隊列來維護，如果事件的處理中又產(chǎn)生了新的事件，那么新的事件會加入到隊列尾，直到當前事件處理完畢后，QApplication再去隊列頭取下一個事件來處理。而信號的處理方式有些不同，信號處理是立即回調(diào)的，也就是一個信號產(chǎn)生后，他上面所注冊的所有槽都會立即被回調(diào)。這樣就會產(chǎn)生一個遞歸調(diào)用的問題，比如某個信號處理器中又產(chǎn)生了一個信號，會使得信號的處理像一棵樹一樣的展開。我們需要注意的一個很重要的問題是會不會引起循環(huán)調(diào)用。

關(guān)于事件機制的考慮其實還很多，但都是一些不成熟的想法。在上面的文字中就同時出現(xiàn)了消息、事件和信號三個相近的概念，而在實際處理中，經(jīng)常發(fā)現(xiàn)三者不知道如何界定的情況，實際的情況比我在這里描述的要混亂的多。

這里也就當是挖下一個坑，希望能夠有所交流。

再談登錄服的實現(xiàn)

離我們的登錄服實現(xiàn)已經(jīng)太遠了，先拉回來一下。

關(guān)于登錄服、大區(qū)服及游戲世界服的結(jié)構(gòu)之前已做過探討，這里再把各自的職責和關(guān)系列一下。

GateWay/WorldServer GateWay/WodlServer LoginServer LoginServer DNSServer WorldServerMgr | | | | | | | | internet | clients

其中DNSServer負責帶負載均衡的域名解析服務，返回LoginServer的IP地址給客戶端。WorldServerMgr維護當前大區(qū)內(nèi)的世界服列表，LoginServer會從這里取世界列表發(fā)給客戶端。LoginServer處理玩家的登錄及世界服選擇請求。GateWay/WorldServer為各個獨立的世界服或者通過網(wǎng)關(guān)連接到后面的世界服。

在mangos的代碼中，我們注意到登錄服是從數(shù)據(jù)庫中取的世界列表，而在wow官方服務器中，我們卻會注意到，這個世界服列表并不是一開始就固定，而是動態(tài)生成的。當每周一次的維護完成之后，我們可以很明顯的看到這個列表生成的過程。剛開始時，世界列表是空的，慢慢的，世界服會一個個加入進來，而這里如果有世界服當機，他會顯示為離線，不會從列表中刪除。但是當下一次服務器再維護后，所有的世界服都不存在了，全部重新開始添加。

從上面的過程描述中，我們很容易想到利用一個臨時的列表來保存世界服信息，這也是我們增加WorldServerMgr服務器的目的所在。GateWay/WorldServer在啟動時會自動向WorldServerMgr注冊自己，這樣就把自己所代表的游戲世界添加到世界列表中了。類似的，如果DNSServer也可以讓LoginServer自己去注冊，這樣在臨時LoginServer時就不需要去改動DNSServer的配置文件了。

WorldServerMgr內(nèi)部的實現(xiàn)很簡單，監(jiān)聽一個固定的端口，接受來自WorldServer的主動連接，并檢測其狀態(tài)。這里可以用一個心跳包來實現(xiàn)其狀態(tài)的檢測，如果WorldServer的連接斷開或者在規(guī)定時間內(nèi)未收到心跳包，則將其狀態(tài)更新為離線。另外WorldServerMgr還處理來自LoginServer的列表請求。由于世界列表并不常變化，所以LoginServer沒有必要每次發(fā)送世界列表時都到WorldServerMgr上去取，LoginServer完全可以自己維護一個列表，當WorldServerMgr上的列表發(fā)生變化時，WorldServerMgr會主動通知所有的LoginServer也更新一下自己的列表。這個或許就可以用前面描述過的事件方式，或者就是觀察者模式了。

WorldServerMgr實現(xiàn)所要考慮的內(nèi)容就這些，我們再來看看LoginServer，這才是我們今天要重點討論的對象。前面探討一些服務器公共組件，那我們這里也應該試用一下，不能只是停留在理論上。先從狀態(tài)機開始，前面也說過了，登錄服上的連接會有兩種狀態(tài)，一是帳號密碼驗證狀態(tài)，一是服務器列表選擇狀態(tài)，其實還有另外一個狀態(tài)我們未曾討論過，因為它與我們的登錄過程并無多大關(guān)系，這就是升級包發(fā)送狀態(tài)。三個狀態(tài)的轉(zhuǎn)換流程大致為：

LogonState--驗證成功--版本檢查--版本低于最新值--轉(zhuǎn)到UpdateState |--版本等于最新值--轉(zhuǎn)到WorldState

這個版本檢查的和決定下一個狀態(tài)的過程是在LogonState中進行的，下一個狀態(tài)的選擇是由當前狀態(tài)來決定。密碼驗證的過程使用了SRP6協(xié)議，具體過程就不多做描述，每個游戲使用的方式也都不大一樣。而版本檢查的過程就更無值得探討的東西，一個if-else即可。

升級狀態(tài)其實就是文件傳輸過程，文件發(fā)送完畢后通知客戶端開始執(zhí)行升級文件并關(guān)閉連接。世界選擇狀態(tài)則提供了一個列表給客戶端，其中包括了所有游戲世界網(wǎng)關(guān)服務器的IP、PORT和當前負載情況。如果客戶端一直連接著，則該狀態(tài)會以每5秒一次的頻率不停刷新列表給客戶端，當然是否值得這樣做還是有待商榷。

整個過程似乎都沒有值得探討的內(nèi)容，但是，還沒有完。當客戶端選擇了一個世界之后該怎么辦？wow的做法是，當客戶端選擇一個游戲世界時，客戶端

會主動去連接該世界服的IP和PORT，然后進入這個游戲世界。與此同時，與登錄服的連接還沒有斷開，直到客戶端確實連接上了選定的世界服并且走完了排隊過程為止。這是一個很必要的設計，保證了我們在因意外情況連接不上世界服或者發(fā)現(xiàn)世界服正在排隊而想換另外一個試試時不會需要重新進行密碼驗證。

但是我們所要關(guān)注的還不是這些，而是客戶端去連接游戲世界的網(wǎng)關(guān)服時服務器該如何識別我們。打個比方，有個不自覺的玩家不遵守游戲規(guī)則，沒有去驗證帳號密碼就直接跑去連接世界服了，就如同一個不自覺的乘客沒有換登機牌就直接跑到登機口一樣。這時，乘務員會客氣地告訴你要先換登機牌，那登機牌又從哪來？檢票口換的，人家會先驗明你的身份，確認后才會發(fā)給你登機牌。一樣的處理過程，我們的登錄服在驗明客戶端身份后，也會發(fā)給客戶端一個登機牌，這個登機牌還有一個學名，叫做session key。

客戶端拿著這個session key去世界服網(wǎng)關(guān)處就可正確登錄了嗎？似乎還是有個疑問，他怎么知道我這個key是不是造假的？沒辦法，中國的假貨太多，我們不得不到處都考慮假貨的問題。方法很簡單，去找給他登機牌的那個檢票員問一下，這張牌是不是他發(fā)的不就得了?？墒牵敲炊嗟腖oginServer，要一個個問下來，這效率也太低了，后面排的長隊一定會開始叫喚了。那么，LoginServer將這個key存到數(shù)據(jù)庫中，讓網(wǎng)關(guān)服自己去數(shù)據(jù)庫驗證？似乎也是個可行的方案。

如果覺得這樣給數(shù)據(jù)庫帶來了太大的壓力的話，也可以考慮類似WorldServerMgr的做法，用一個臨時的列表來保存，甚至可以將這個列表就保存到WorldServerMgr上，他正好是全區(qū)唯一的。這兩種方案的本質(zhì)并無差別，只是看你愿意將負載放在哪里。而不管在哪里，這個查詢的壓力都是有點大的，想想，全區(qū)所有玩家呢。所以，我們也可以試著考慮一種新的方案，一種不需要去全區(qū)唯一一個入口查詢的方案。

那我們將這些session key分開存儲不就得了。一個可行的方案是，讓任意時刻只有一個地方保存一個客戶端的session key，這個地方可能是客戶端當前正連接著的服務器，也可以是它正要去連接的服務器。讓我們來詳細描述一下這個過程，客戶端在LoginServer上驗證通過時，LoginServer為其生成了本次會話的session key，但只是保存在當前的LoginServer上，不會存數(shù)據(jù)庫，也不會發(fā)送給WorldServerMgr。如果客戶端這時想要去某個游戲世界，那么他必須先通知當前連接的LoginServer要去的服務器地址，LoginServer將session key安全轉(zhuǎn)移給目標服務器，轉(zhuǎn)移的意思是要確保目標服務器收到了session key，本地保存的要刪除掉。轉(zhuǎn)移成功后LoginServer通知客戶端再去連接目標服務器，這時目標服務器在驗證session key合法性的時候就不需要去別處查詢了，只在本地保存的session key列表中查詢即可。

當然了，為了session key的安全，所有的服務器在收到一個新的session key后都會為其設一個有效期，在有效期過后還沒來認證的，則該session key會被自動刪除。同時，所有服務器上的session key在連接關(guān)閉后一定會被刪除，保證一個session key真正只為一次連接會話服務。

但是，很顯然的，wow并沒有采用這種方案，因為客戶端在選擇世界服時并沒有向服務器發(fā)送要求確認的消息。wow中的session key應該是保存在一個類似于WorldServerMgr的地方，或者如mangos一樣，就是保存在了數(shù)據(jù)庫中。不管是怎樣一種方式，了解了其過程，代碼實現(xiàn)都是比較簡單的，我們就不再贅述了

第四篇：游戲架構(gòu)設計

淺談游戲策劃的前期工作

班級：09數(shù)字媒體技術(shù)姓名：廖偉民學號：090804006

摘要：游戲制作所涉及的知識領(lǐng)域極其廣泛，其中就單其游戲策劃這一塊就涉及到三大內(nèi)容：前期的準備工作、中期的制作工作、后期的宣傳工作。因此作為個人沒時間也不可能對每一區(qū)域都了解。在這篇文章當中我將針對游戲策劃當中的前期準備進行說明，并發(fā)表自己的看法。

關(guān)鍵字：可行性、調(diào)研、工作計劃、草案

引言：不少人認為游戲策劃就是寫個精彩的故事出幾個好點子，如果事情如此簡單那不是每個人都可以做策劃?由于國內(nèi)的游戲制作業(yè)剛剛起步，既缺乏系統(tǒng)的專業(yè)理論指導，又缺乏實戰(zhàn)經(jīng)驗，以至大多數(shù)玩家甚至一些游戲制作公司在對待策劃這個問題上都明顯存在不少誤區(qū)[1]。其實每一個游戲的策劃都要經(jīng)歷很多步驟和過程，就游戲策劃的前期準備工作當中就包含了對技術(shù)、經(jīng)濟、人力資源這三點的可行性分析，市場調(diào)研，確定工作計劃以及撰寫策劃草案這四個步驟，下面我將對其一一經(jīng)行分析。

一、可行性分析

一個游戲從一個想法到成為產(chǎn)品需要經(jīng)歷太多的磨難，合格的策劃應該在一開始就知道這個想法能否行的通，在經(jīng)過了嚴格的論證并初步產(chǎn)生了產(chǎn)品的輪廓后，才能把自己的想法提出來。這也是一個游戲能否可行的一個自我論證過程，這其中包括以下幾個部分:

1、技術(shù)可行性分析:

從技術(shù)上來考慮，你的想法是否能夠?qū)崿F(xiàn)呢?一個想法產(chǎn)生后，你就要知道你要把它做成什么樣的游戲，大概需要哪些技術(shù)支持。這一般都會受項目組或者游戲開發(fā)公司自身的技術(shù)實力的影響，因為一個新的創(chuàng)意往往會牽扯到大量的技術(shù)性創(chuàng)新，如果你的想法按照現(xiàn)有的技術(shù)能力根本就無法達到或者會超出項目預算，那肯定會被槍斃的。只有那些在現(xiàn)有技術(shù)基礎上進行升級和發(fā)展，或者在現(xiàn)有條件下能夠進行技術(shù)突破而達到要求的創(chuàng)意才是符合要求的。比如，做一個網(wǎng)絡游戲，你要讓200個人能夠在一個屏幕內(nèi)同時PK就算是程序上能夠?qū)崿F(xiàn)，現(xiàn)有的網(wǎng)絡條件也不支持，所以這種想法就屬于技術(shù)上不可行的[2]。因為策劃受到技術(shù)本身的影響，所以要求游戲策劃對游戲中可能使用到的技術(shù)有個大致的了解。策劃必須及時和主程序溝通，并多接觸一些前沿的技術(shù)，這樣才可以跟上時代的潮流，并不斷提出符合拮術(shù)要求的創(chuàng)意來!

2、經(jīng)濟可行性分析:

一個游戲的實現(xiàn)，如果不考慮到要花多少費用，多少時間和多少人，不計算能夠回收多少資金就不是一個好的項目負責人。一個新想法如果不經(jīng)過項目負責人的決策是不可能立項的。所以，在進行游戲設計的過程中，一定要把項目的規(guī)模和市場效果考慮進去，否則也是會很容易被槍斃的。游戲再好，不適合市場的需要也是白搭，而且公司也有自己的市場戰(zhàn)略，所以大多數(shù)的策劃被槍斃都是這些原因所造成的。

什么樣的游戲可以引起玩家的興趣，哪些游戲可以掙到錢，這是所有的游戲制作者都在努力尋找的。也只有市場才可以決定那些游戲是成功的，對于策劃人

員來講，經(jīng)常注意游戲市場的動向和海內(nèi)外游戲的發(fā)展趨勢才是正確的道路[3]。如何選擇一個適合潮流的游戲點來展開想象是獲得一個有價值創(chuàng)意的關(guān)鍵[4]!

3、人力資源分析:

在進行了技術(shù)和經(jīng)濟上的考慮后，還要看你自己周圍的人力情況是否允許你這樣設計。因為資源并不是你想獲得就可以得到的，而資源中最重要的就是人。有經(jīng)驗的開發(fā)者本身就是一筆巨大的財富，如果你有一些很棒的同志一起來做開發(fā)，那么你的設計就可以很快被別人所接受，他們也可以給你很多建議來完善你的想法。甚至于你在產(chǎn)生了這個想法之后，馬上就要考慮誰可以完成這個工作，你有多少人可以完成這個工作。如果只有幾個剛畢業(yè)的有志青年，希望你開始不要去設計那些過于復雜的東西，就算你設計的再完善，最后因為人的原因而做不出來也是不管用的。

上面的三種情況是最容易被忽視的因素，還不是要考慮的全部。其實一個有經(jīng)驗的策劃在剛開始有想法的時候就應該把大部分可能發(fā)生的問題都預測到，這樣才可以保證這個項目有存在下去的必要和價值。而一個剛?cè)腴T或者準備入門的新手，也最容易忽略上面三個因素。可能由于自身條件的限制，你對技術(shù)并不是很熟悉甚至是門外漢，那么你就一定要找一個做程序或者有經(jīng)驗的策劃詢問一下你的想法是否可行。如果有了一個念頭就一頭扎進去，最后的結(jié)果很可能是浪費了精力和時間，卻一無所獲。

你可以把自己的可行性分析過程記錄并整理出來，這就是你的可行性設計文檔，也是整個策劃中一個很重要步驟。有了這份文檔，程序就知道這個東西要實現(xiàn)什么，自己要做什么樣的技術(shù)準備;部門負責人就可以估算大概需要多少費用來開發(fā)，開發(fā)周期大概有多長;人事部門就知道還要招聘什么樣的人才能滿足項目的需要。如果這些文檔根本經(jīng)不起推敲或者你自己都認為不可行，那就最好換個想法或者繼續(xù)修改。越早發(fā)現(xiàn)問題就能夠避免更大的損失，想成為一個策劃就要從全局的角度來看問題。如果只是想做一個執(zhí)行策劃或者腳本設計就可以忽略這部分，因為你要干的事情就只是聽從主策劃的任務分配并按時完成工作就可以了。而你想成為一名合格的主策劃或者項目管理者，那么可行性分析就是你要掌握的第一個重要步驟。

二、市場調(diào)研

如果將市場調(diào)研細分的話可以大致分為三個部分:

1對現(xiàn)有游戲作品的調(diào)研

2對用戶需求的調(diào)研

3對游戲產(chǎn)品時效性的調(diào)研

1、對現(xiàn)有游戲作品的調(diào)研

對現(xiàn)有作品的調(diào)研可避免新策劃的作品有”跟風”之嫌，特別是國內(nèi)的游戲產(chǎn)業(yè)，由于技術(shù)水準和國外相比還有比較大的差距，如果一味地跟著別人跑，沒有什么新的突破，那么這種作品想獲得玩家的認可是相當困難的，2、對用戶需求的調(diào)研

對游戲玩家的需求以及其游戲心理的分析使策劃人員可以了解當前游戲作品的流行趨勢，游戲玩家的興趣指向和游戲動機以避免策劃的盲目性.3、游戲產(chǎn)品時效性的調(diào)研

有一個很重要但又容易被忽視的問題，這就是游戲產(chǎn)品的時效性。一個游戲作品的制作周期比較長，短則一年半載，長則一年兩年。但一個游戲的銷售期卻

非常短，特別是在國內(nèi)，國內(nèi)一個游戲作品的銷售時間通常只有兩個月時間，很難突破三個月。也就是說，在這兩個多月的時間里你就可以得知你的人力、時間和資金的投入是否得到了回報。

所以，在開發(fā)一個新產(chǎn)品進行市場調(diào)研時一定要考慮一個提前量。首先確定自己的產(chǎn)品上市時間，然后根據(jù)調(diào)查研究的結(jié)果判斷自己的產(chǎn)品上市時是否會受到其它作品的沖擊，用戶群是否會因為技術(shù)的更新、新作品的上市而轉(zhuǎn)移，等等。

三、確定工作計劃

在看完上面的市場調(diào)研報告后，估計對游戲策劃有興趣的朋友對市場調(diào)研所要做的工作和涉及內(nèi)容應該有一定了解和認識。

策劃人員通過市場調(diào)研對當前游戲市場有一個充分認識后就要開始確定工作計劃的安排。工作計劃中的主要內(nèi)容是人員配備和工作日程表[5]。

根據(jù)游戲容量的大小確定參與制作的人員結(jié)構(gòu)，既要在預計的時間內(nèi)完成任務，又要在整個制作過程中沒有人員閑置，安排是否得當取決于策劃的經(jīng)驗和預測。

在不同的游戲種類中，制作組的各部門人員比例是不一樣的。如RPG游戲，美工工作量較大，文字工作量較大，那么就應該在美術(shù)方面多加人手，可以專門安排一個人做文字方面的工作;戰(zhàn)略類游戲美術(shù)工作量相對較小，但數(shù)據(jù)量大，結(jié)構(gòu)復雜，調(diào)整困難，靠策劃一個人難以勝任，那么就應該安排人員協(xié)助策劃做數(shù)據(jù)設定方面的工作。

由于在游戲制作的后期就要開始做宣傳、銷售方面的工作，所以工作日日程表一定要比較準確，誤差不能太大。日程安排過松，會導致工作效率降低，從而增加開發(fā)成本;日程安排過緊，在預定的時間內(nèi)不能完成制作，將使宣傳和銷售處于非常不利的境地，直接影響回報率。

工作計劃中至少應包括以下幾個部分:

1游戲的主要指標;

2各部門工作量預算;

3制作時間預算;

4資金預算;

5進度表。

在進行充分的市場調(diào)研后并確定了工作計劃的同時策劃人員就可以開始撰寫策劃草案。

四、撰寫策劃草案

策劃草案相當于工程師的藍圖，實際上就是策劃將大腦中的游戲雛形用文字表達出來，以書面形式轉(zhuǎn)告制作組的其它部門，作為其它部門在制作過程中的指導書。

策劃草案不要求很詳細，基本上不考慮細節(jié)方面的東西，但要求它很穩(wěn)定，一旦生成不得隨意修改，所以撰寫策劃書時一定要和其它部門溝通，以確保策劃案草案切實可行。特別是關(guān)于技術(shù)方面的，不能脫離技術(shù)人員的能力范圍之外，如果到時候技術(shù)方面不能達到策劃草案中的要求，后果很可能是整個制作組的人員在某一段時間內(nèi)的工作都白干了。

不同的游戲種類的策劃草案的撰寫會有一些差異，但下列項目是每一份策劃

草案中都必須明確規(guī)定的：

1、類型(結(jié)構(gòu));

2、解析度;

3、操作系統(tǒng);

4、故事背景;

5,容量(關(guān)數(shù));

6、游戲進程

7、預定發(fā)行的時間

8、適合什么樣的年齡層

9、游戲主要構(gòu)成畫面草圖.當然，隨著技術(shù)的發(fā)展，游戲的容量越來越大，內(nèi)涵越來越多，以至某些游戲己經(jīng)很難用某一種類型來定義它。如有些戰(zhàn)略游戲，卻包含有許多角色扮演的成分;許多角色扮演類游戲，卻又包含有養(yǎng)成的成分，等等.在這種情況下，要給一個尚未誕生的游戲確定一種現(xiàn)成的類型是比較困難的。通常我們可以提出一個大致方案，然后在這個方案之上構(gòu)思新的創(chuàng)意，最后形成一種新的模式，這種模式和現(xiàn)有的作品相比應該有所突破。所謂的游戲類型，可以看作是諸多模式的組合。

五、結(jié)束語

總之，游戲制作所涉及的知識領(lǐng)域極其廣泛，其中就單其游戲策劃這一塊就涉及到三大內(nèi)容：前期的準備工作、中期的制作工作、后期的宣傳工作。因此，游戲策劃并不是不少人認為的寫個精彩的故事出幾個好點子如此簡單，一個游戲從一個想法到成為產(chǎn)品需要經(jīng)歷太多的磨難，合格的策劃應該在一開始就知道這個想法能否行的通，在經(jīng)過了嚴格的論證并初步產(chǎn)生了產(chǎn)品的輪廓后，才能把自己的想法提出來。所以，游戲策劃的前期準備工作對于一個好的游戲來說是相當重要的。

參考文獻

[l]《游戲的劇情系統(tǒng)》作者:李蘭云西山居游戲工作室

[2]《腳本語言淺介》來源:標點工作室http://bj.netease.com.[3]《游戲引擎演化史》來源:http://

[4]《游戲引擎剖析》作者:Jake Simpson譯者:向海

[5]《游戲引擎基礎原理》作者:Dave Astle譯者:sunlxy

第五篇：垂直行業(yè)網(wǎng)站服務器架構(gòu)方案

服務器架構(gòu)

一、目前架構(gòu)：

114.113.229.66massterHadoop114.113.229.72V1web114.113.229.73V2webmysql主JobsHbase114.113.229.67slaveHadoopHadoop-data114.113.229.68tomcatV1 搜索tomcatSolrSolr Home索引搜索服務編輯后臺114.113.229.69slaveHadoopHadoop-data114.113.229.70slaveHadoopHadoop-dataMongoDBHbase114.113.229.71slaveHadoopHadoop-dataMongoDBHbase114.113.229.74slaveHadoopHadoop-dataMongoDBHbasemysql從 爬蟲使用6臺，其中3臺同時放了MongoDB服務，1臺同時放了搜索服務和編輯后臺服務，直接導致服務器不能專職使用互相影響，大部分服務器CPU一直在高負荷運作，67為我們的搜索服務器，其中編輯后臺和爬蟲服務會影響到搜索服務的運行，一旦cpu負荷到100%，那么搜索指令將不會被執(zhí)行，直接表現(xiàn)為搜索任何關(guān)鍵詞或分類都無結(jié)果。

缺點：服務器不能發(fā)揮出應用的性能。

二、基本架構(gòu)：需要9臺服務器

114.113.229.66massterHadoopJobsHbase114.113.229.71V2webmysqlMail114.113.229.67slaveHadoopHadoop-datatomcat編輯后臺114.113.229.69slaveHadoopHadoop-dataCPS/API114.113.229.72slaveHadoopHadoop-dataHbase114.113.229.73slaveHadoopHadoop-dataHbase114.113.229.74slaveHadoopHadoop-dataHbase114.113.229.68SolrSolr Home索引搜索服務114.113.229.70MongoDB

? 一臺WEB主機；支持500人同時在線，每天約百萬PV。? 一臺搜索SOLR主機；支持 400W 以下數(shù)據(jù)量。

? 爬蟲HADOOP共6臺；能做到全部商城數(shù)據(jù)更新2天更新一次，主流5個綜合商城每天更新一次（京東除外）

? CPS和API搭建在hadoop集群內(nèi)； ? 一臺獨立MongoDb；

以上架構(gòu)缺點：沒有容災性，宕機會丟失數(shù)據(jù)，尤其是WEB/MYSQL服務器、搜索服務器和MongoDB服務器這3臺機器是支撐我們前端服務的，一旦一臺主機宕機網(wǎng)站就無法正常使用。

三、最佳架構(gòu)：需要18臺服務器

114.113.229.73WEB主webmysqlMail114.113.229.72WEB從webmysqlMail114.113.229.74massterHadoopJobs114.113.229.*搜索SolrSolr Home114.113.229.*搜索SolrSolr HomeAPI114.113.229.*搜索主SolrSolr Home索引搜索服務114.113.229.67slaveHadoopHadoop-datatomcat編輯后臺114.113.229.69slaveHadoopHadoop-data114.113.229.*slaveHadoopHadoop-data114.113.229.*slaveHadoopHadoop-data搜索服務搜索服務114.113.229.66slaveHadoop114.113.229.70數(shù)據(jù)庫從MongoDB114.113.229.71數(shù)據(jù)庫從MongoDB114.113.229.68數(shù)據(jù)庫主MongoDBHadoop-data114.113.229.*slaveHadoopHadoop-data114.113.229.*slaveHadoopHadoop-data114.113.229.*slaveHadoopHadoop-data114.113.229.*CPSCPS

? 爬蟲服務器Hadoop：9臺（配置需求不高）架構(gòu)可以隨時擴容。滿足所有80家商城數(shù)據(jù)更新每天可以更新一次，部分綜合商城可以做到每天更新2次（京東除外）

? 數(shù)據(jù)庫服務器MongoDB：3臺主從（配置需求比較高）架構(gòu)可以隨時擴容。

? 搜索服務器SOLR/編輯后臺：3臺主從（配置需求比較高）架構(gòu)可以隨時擴容。搜索服務器Solr服務將支持 千萬級以上數(shù)據(jù)量，并可以隨時根據(jù)服務器壓力擴容。? CPS： 1臺，能滿足初期CPS接入流量，可以隨時擴容。? Web/Mysql：2臺主從（配置需求比較高）架構(gòu)可以隨時擴容。

以上架構(gòu)優(yōu)點：具有數(shù)據(jù)容災性，任意一個節(jié)點的服務器宕機，不影響在線服務。