游戲人生

Author: Fox

在MMORPG中，存在大量的數據文件和腳本文件，這些文件涉及很多變量，當玩家信息需要存取時（上線、下線、保存、服務器交互），即伴隨著大量的讀寫操作。隨著游戲中游戲任務的增加，每一個玩家對應的需要數據庫存取的腳本變量的數據量也隨之線性增長，隨著玩家數量的增加，在服務器保存玩家角色信息的時候，通信量的大小是相當可觀的，使用多線程讀寫，可以使服務器的處理能力大幅增強，但網絡和數據庫承受的壓力也會大幅增加。

當然現在有很多的腳本語言為我們設計任務系統提供了便利，像Lua、Python、Ruby這些動態語言的功能越來越強，而且可以肯定的是，會有越來越多的產品采用這些優秀的語言。但我今天要談的不是如何使用動態語言，也不是討論動態語言孰優孰劣的問題，而是對于大量的腳本變量的存取優化。說白了，這對于使用自定義腳本語言的游戲開發人員才更有參考價值。而且我要說的問題很小，小到我只是講一點點內容，只是我今天下午的一點活，總結下來更多只是為了讓自己記住，并不是教育別人。

假設在整個腳本系統中，存在500個與玩家相關而且需要數據庫存取的腳本變量，如果一個游戲世界中擁有3000個在線玩家，平均每個玩家的腳本變量大小為10KB，如果服務器同時保存這3000個玩家的數據（那可不僅僅是腳本變量，當然腳本變量所占的分量比較大就是了），3000×10KB，哦……與此同時，服務器還要進行其實正常的網絡通信和邏輯處理（雖然不可能是同一個線程），但服務器承受的壓力已經不小了吧，為了減少這種壓力，腳本變量成為了一種稀缺資源。
為了對腳本變量的存取進行優化，我想到了一個最容易實現的方法。通過對數據庫的觀察（其實想也想也想得到:)），我發現玩家數據中大量的腳本變量的值都是0或者空字符串，這就為優化提供了很大的一個空間。

服務器一般都保存有一個腳本變量的配置文件，在這個文件中列出了所有的腳本變量及其默認值。當玩家登錄時，服務器將為其依據這個文件為其建立一份拷貝，并從數據庫讀取這些變量的真實值填充之。因為大量的變量值都是默認值，所以在往數據庫保存的時候，是沒有必要全部保存的，而只需保存那些不同于默認值的變量名和變量值以及該變量對應的下標即可。下一次從數據庫讀入的時候根據下標確定哪些變量值需要從數據庫中讀取就可以了。

很簡單的一個操作，雖然做到了這一點優化，但是對于500個變量的線性讀取和其他操作，依然不是一個好的處理方法。

幾點改進的方向，目前只是有個想法：

1、將玩家與其腳本變量解耦

并不是所有的玩家都需要500個腳本變量的，不同等級的玩家可以參與的任務和活動是完全不同的，我們顯然沒有必要為每一個玩家從生到死都保持這500個變量。這樣考慮下來，估計一個玩家的腳本變量數可以減少300-400個，從而實現了“垃圾”回收再利用。OMG！

想法是非常具有誘惑力的，但這一優化同時涉及到腳本策劃和程序，而且稍有不慎（對某一變量重復使用），全盤皆輸，在“穩定壓倒一切”的大方針下，這樣的優化需要給出一個系統的策略，玩家等級、職業因素的影響都要考慮進去。

2、對玩家腳本變量實現壓縮存儲

未經壓縮的腳本變量，每個大概有幾十Bytes，如果采用一個好的壓縮算法，能不能減少到10Bytes呢？什么又是一個好的壓縮算法呢？壓縮解壓縮的成本和直接存取成本比起來哪個更高呢？想想這些的確也都是問題呢。

/*****************************************************************************
? 這只是我工作中的一個總結，問題很簡單，也很瑣碎，正如我前面所提的，僅僅是提供一個參考。
*****************************************************************************/

Author: Fox

一個MMORPG（Massively Multiplayer Online Role Playing Game）的架構包含客戶端和服務器兩部分。客戶端主要涉及計算機圖形學、物理學、多媒體技術等，服務器主要涉及網絡通信技術、數據庫技術，而人工智能、操作系統等計算機基礎學科知識的應用體現在MMORPG開發過程中的方方面面。

一、游戲世界的劃分

理想狀態的游戲世界僅由一個完整的場景組成，在《魔獸爭霸 III 》、《 CS 》這樣的單機游戲中，所有玩家位于該場景中，在理論上，位于該場景中的任意玩家都可以看到游戲中所有玩家并與之交互，出于公平性和游戲性（而不是技術上）的考慮，游戲中并不會這樣做。

然而，目前的 MMORPG 中，幾乎沒有任何一款可以做到整個游戲世界只包含一個場景，因為在一款 MMORPG 中，同時在線的玩家數量成百上千，甚至是數萬人同時在一個游戲世界中交互。以現在的網絡技術和計算機系統，還無法為這么多玩家的交互提供即時處理。因此， MMORPG 的游戲世界被劃分為大小不等、數量眾多的場景，游戲服務器對于這些場景的處理分為分區和無縫兩種。

在分區式服務器中，一個場景中的玩家無法看到另一個場景中的玩家，當玩家從一個場景到另外一個場景跨越時，都有一個數據轉移和加載的過程（尤其是從一個分區服務器跨越到另外一個服務器時），玩家都有一個等待的時間，在這段時間內，服務器的主要工作是實現跨越玩家數據的轉移和加載以及后一個場景中玩家、 NPC 等數據的傳輸，客戶端的主要工作是實現新場景資源的加載和服務器通信。主要時間的長短主要取決于后一個場景中資源數據的大小。分區式服務器的優點主要是各分區服務器保持相對獨立，缺點是游戲空間不夠大，而且，一旦某個分區服務器中止服務，位于該服務器上的所有玩家將失去連接。

所謂無縫服務器，玩家幾乎察覺不到場景之間的這種切換，在場景間沒有物理上的屏障，對于玩家而言，眾多場景構成了一個巨大的游戲世界。場景之間，甚至服務器之間“沒有了”明確的界線。因此，無縫服務器為玩家提供了更大的游戲空間和更友好的交互，實現了動態邊界的無縫服務器甚至可以在某個服務器中止服務時，按一定策略將負載動態分散到其他服務器。因此，無縫服務器在技術上要比分區服務器更加復雜。

目前國內上市的 MMORPG ，大多采用分區式服務器，做到無縫世界的主要有《完美世界》和《天下貳》等，國外的 MMORPG 中，像《魔獸世界》、《 EVE 》等，都實現了無縫世界。

無縫服務器與分區式服務器在技術上的主要區別是，當位于場景 S1 中的玩家 P1 處于兩個（甚至更多）場景 S1 、 S2 的邊界區域內時，要保證 P1 能夠看到場景 S2 中建筑、玩家、 NPC 等可感知對象。而且邊界區域的大小要大于等于 P1 可感知的范圍，否則就可能發生 S2 中的可感知對象突然閃現在 P1 視野中的異常。

無疑，無縫世界為玩家提供了更人性化和更具魅力的用戶體驗。

二、無縫世界游戲服務器的整體架構

MMORPG 的服務器架構從功能上主要劃分為三種：

1、 登錄服務器（ Login Server ）

登錄服務器用于玩家驗證登錄，并根據系統記錄玩家信息得到其所在節點服務器，并通過世界服務器為登錄玩家和對應節點服務器建立連接。

2、 世界服務器（ World Server ）

世界服務器將整個游戲世界劃分成不同場景，將所有場景按一定策略分配給節點服務器，并對節點服務器進行管理。世界服務器的另一功能是與登錄服務器交互。因此，世界服務器是登錄服務器、節點服務器的溝通橋梁，當然，一旦玩家登錄成功，世界服務器將主要處理節點服務器間的通信。因此，世界服務器對于玩家是透明的。

3、 節點服務器（ Node Server ）

節點服務器負責管理位于該節點的所有玩家、 NPC 的所有交互，在無縫世界游戲中，由于邊界區域的存在，一個節點服務器甚至要處理相鄰節點上位于邊界區域的玩家和 NPC 的信息。

在具體實現上，不同的 MMORPG 為了便于管理，可能還會具有 AI 服務器、日志服務器、數據庫緩存服務器、代理服務器等。

三、 無縫世界游戲服務器的主要技術需求

1、 編程語言（ C/C++ 、 SQL 、 Lua 、 Python ）

2、 圖形庫（ Direct 3D 、 OpenGL ）

3、 網絡通信（ WinSock 、 BSD Socket ，或者 ACE ）

4、 消息、事件、多線程、 GUI

5、 OS

三、無縫世界游戲服務器需要解決的主要問題

1、 資源管理

無論是服務器還是客戶端，都涉及到大量資源：玩家數據、 NPC 數據、戰斗公式、模型資源、通信資源等。當這些資源達到一定規模，其管理的難度不可忽視。而且，資源管理的好壞，直接關系到游戲的安全和生命。

2、 網絡安全

安全永遠是第一位的，我們無法指望所有的玩家及其所持的客戶端永遠是友好的。事實上，威脅到游戲的公平性和安全性的大多數問題，歸根結底，都是由于網絡通信中存在的欺騙和攻擊造成的，這些問題包含但不限于交易欺騙、物品復制。

3、 邏輯安全

邏輯安全按理說應該是游戲中最基本的考慮，覆蓋的范圍也最廣最雜。隨機數系統是一個非常值得重視的問題，隨機數不僅僅用于玩家可見的一些任務系統、戰斗公式、人工智能、物品得失等，還可用于網絡報文加密等。因此，隨機數系統本身的安全不容忽視。另外一個常見的邏輯安全是玩家的移動，最主要的就是防止加速齒輪這樣的變態操作。

4、 負載均衡

MMORPG 中的負載均衡包括客戶端及服務器資源管理和邏輯處理的負載均衡，其中最難預知的是網絡通信的負載均衡，正常情況下的網絡通信數量是可以在游戲設計時做出評估的，但因惡意攻擊造成的網絡負載是無法預測的。因此，負載均衡所要處理的主要是實時動態負載均衡和災難恢復。負載均衡需要解決的問題包括負載監控、負載分析、負載分發和災難恢復。

5、 錄像系統

錄像系統的構建，主要用于重現關鍵數據的輸入輸出，如玩家交易、玩家充值，或者當 bug 出現后，為邏輯服務器（泛指上文提到的所有類型服務器，主要是節點服務器）相應部分啟動錄像系統。待收集到足夠數據后，通過錄像系統重現 bug 。為了使邏輯服務器不受自身時間（如中斷調試等）的影響，還可以專門設計心跳服務器來控制數據傳輸。

四、總結

在 MMORPG 中，真正的 bug 永遠存在于將來。從這一點出發，關于 MMORPG 中游戲世界的構建，怎樣苛刻的思考都不為過。

參考資料：

1、 [美] Kim Pallister編, 孟憲武 等譯. 游戲編程精粹5, P467-474, P516. 人民郵電出版社, 2007年9月. 北京.
2、 [美] Thor Alexander編, 史曉明 譯. 大型多人在線游戲開發, P174-185. 人民郵電出版社, 2006年12月. 北京.
3、 [美] Dante Treglia編, 張磊 譯. 游戲編程精粹3, P117-122. 人民郵電出版社, 2003年7月. 北京.
4、 [美] Mark DeLoura編, 王淑禮 等譯. 游戲編程精粹1, P90-93. 人民郵電出版社, 2004年10月. 北京.
5、 [美] Douglas 等著, 於春景 譯. C++網絡編程 卷1. 中國電力出版社, 2004年11月. 北京.
6、 [美] Stephen D. Huston 等著, 馬維達 譯. ACE程序員指南. 中國電力出版社, 2004年11月. 北京.
7、 [美] Erich Gamma等著, 李英軍 等譯. 設計模式. 機械工業出版社, 2000年6月. 北京.
8、 游戲引擎全剖析. http://bbs.gameres.com/showthread.asp?threadid=101293.
9、 服務器結構探討：登錄服的負載均衡. http://gamedev.csdn.net/page/351491d0-05ad-48a4-85e1-77870bc1eef3.
10、服務器結構探討：最終的結構. http://gamedev.csdn.net/page/28695655-974c-4291-8ac4-2589c4e770d3.
11、談談網絡游戲服務器解決方案. http://www.beareyes.com.cn/2/lib/200411/08/20041108102.htm.
12、負載均衡——大型在線系統實現的關鍵(下篇)（服務器集群架構的設計與選擇）. http://blog.csdn.net/sodme/archive/2005/06/15/394576.aspx.
13、云風的BLOG. http://blog.codingnow.com/