【轉】網絡即時戰略遊戲軟件開發 結構體系分析

文檔下載地址：http://download.csdn.net/detail/wanggan768q/4388056

 

網絡即時戰略遊戲軟件開發

結構體系分析

 

前言

本人對網絡遊戲的技術問題一直比較感興趣，我認爲網絡遊戲的開發在不遠的未來是一個很是龐大的產業。這段時間有空，特意玩了幾天網絡遊戲「破碎銀行系」，並分析了一下其中體系結構，有些體會，結合本身多年的軟件開發經驗，就如何開發一個相似於「破碎銀行系」的網絡即時戰略遊戲撰文以下，但願能拋磚引玉，對從事遊戲開發的人有所幫助。

網絡遊戲是咱們的機會

單人遊戲的開發國外廠商已經積累了豐富的技術基礎，各類遊戲模式已經基本定型，新款遊戲只能在視、聽覺的效果上大作文章，主要的競爭領域是3D技術和美工，在這些方面，咱們要一會兒遇上國外的技術水平還有必定難度。

而網絡遊戲，其吸引人的地方是多人的交互性和協做性，視聽覺效果的做用已經退到次要的位置，例如「破碎銀行系」，玩家所但願的是在上面打一場玩家緊密配合，最後成功打敗對方的「國戰」，沒人關注它是2D仍是3D的。

網絡遊戲，須要引入新的技術，如數據庫、通訊和服務器端軟件的開發，這些技術在國內其它領域（如金融和電信）已經獲得至關成熟的應用，並不存在任何技術問題，加上2D遊戲的開發，國內成功案例較多，所以，只要把國內的資源有效地組織起來，就能開發一個富有市場前景的網絡遊戲。

許多人會認爲網絡遊戲的開發是一件技術難度很是高的工做，固然，遊戲的開發，其它技術含量要比一個信息管理系統高，但並非遙不可及，我更願意用「開發網絡遊戲是一個系統工程」這樣的觀點形容網絡遊戲的開發。

本文的主要內容之一即是分析如何把一個功能複雜的網絡即時戰略遊戲，劃分爲多個儘可能孤立的子系統，並逐一分析每一個子系統的技術特色和難點。

遊戲功能模塊分析

在「破碎銀行系」中，可把它的功能劃分爲如下幾類：

1、 交流或做戰狀態的地圖漫遊；

2、 屬性設定；

3、 聊天；

在地圖漫遊功能，又分爲如下幾類：

² 交流狀態，多人在線的地圖漫遊；

² 戰鬥狀態，多人在線，人與人之間的戰鬥，如「國戰」、「競技場」等；

² 戰鬥狀態，多人在線，人與計算機之間的戰鬥，如「異形戰爭」；

² 戰鬥狀態，單人遊戲，人與計算機之間的戰鬥，如「訓練場」；

每一個多人在線的地圖，都須要一臺服務器管理，咱們把臺服務器稱之爲地圖服務器。

在「破碎銀行系」中，同一交流狀態地圖能夠同時容納128名在線用戶，而戰鬥狀態地圖則能夠同時容納64名在線用戶。

許多功能，如註冊、登陸、購買武器、修復武器、武器升級、武器物品裝備、加入軍團、選舉領主、拜師和系統內信件等，其實均可以納入屬性設定一類的功能，其實質很簡單，都是查詢或修改數據庫中，關於玩家的某些記錄。例如拜師，其實就是修改玩家眷性數據庫中，其上級的字段。

在Internet環境下，客戶端（即玩家使用的PC，如下稱爲遊戲端）不可能直接訪問數據庫服務器，必須經過聯機交易這種方式實現。

聯機交易首先在金融等行業獲得應用，如今全部的核心金融應用系統，都基於聯機交易，並且，聯機交易已經普遍地應用於其它各個領域中。

聯機交易是指客戶端根據實際功能的須要，按照規定的格式填寫一個數據結構（稱之爲交易請求報文），而後經過計算機通訊發給交易服務器；

交易服務器收收交易請求報文後，執行相應的數據處理工做，多爲數據庫操做，並把處理結果按照規定的格式填寫響應數據結構（稱之爲交易響應報文），而後發給客戶端，通知客戶端處理結果。

在遊戲軟件中，一個屬性設定功能，就是一個聯機交易，只不過是把操做界面圖形化、遊戲化而。

這裏咱們把交易服務器端稱爲屬性服務器。

若是玩家常用系統內信件的功能，則有必要讓系統內信件功能單獨使用一臺服務器。

聊天的實現與ICQ相似，也須要一臺服務器（至少邏輯上），我把這臺服務器稱之聊天服務器。

有一種考慮，就是把聊天服務器合併在地圖服務器上，這是由於聊天的對象通常都是同一個地圖上的人，但某些狀況例如，如領主和軍團長能夠經過「大喊」功能跨地圖，把指令發佈到整個星球，而上下級之間的聊天也能夠跨地圖。

所以，同一地圖的聊天可在地圖服務器中增長一個聊天模塊處理，整個遊戲分區還應設立一臺專用的聊天服務器，處理跨地圖的聊天功能。

服務器組織

    毫無疑問，遊戲端使用Windows平臺，使用Wins32 API，服務器則最好使用Linux操做系統。

系統服務器分爲兩類，數據庫服務器和通訊數據報文處理服務器。

數據庫服務器從穩定性、價格和性能出發，最好選擇Oracle，版本不限。Oracle的穩定性和性能自不用多說，而其For Linux的版本，最低價格不到8000元（從分銷商那出貨），也是很是便宜的。

在「破碎銀行系」中，一個遊戲分區能夠由多個星球，每一個昨星球有多張地圖，所以，其服務器組的結構能夠是這樣：

每個星球大概有100張地圖，能夠經過動態分配、一臺物理服務器運行多個交流地圖服務器等方式，減小真正須要的服務器。

由於地圖服務器能夠動態增長，所以一個分區同支持的用戶數取決於屬性服務器和聊天服務器。

其實屬性服務器的主要操做是數據庫操做，其性能又取決於數據庫服務器，根據個人經驗，一臺較好的數據庫服務器，每秒種能夠處理100筆以上的聯機交易，也就是說每秒種能夠處理100次屬性設定請求，根據我玩「破碎銀行系」的經驗，屬性設定的執行頻率不到10分鐘每次，那麼一個分區能夠同時支持60000個在線用戶。

由於跨地圖聊天的執行頻率很低，所以聊天服務器不會成爲系統的性能瓶頸。

    系統須要的服務器總數取決地圖服務器，一臺地圖服務器同時支持64至128在線用戶，但不可能老是滿員，因些，若是須要同時支持5000在線用戶，可能須要100臺左右地圖服務器。

戰鬥地圖漫遊遊戲引擎的設計

多人在線的戰鬥地圖漫遊是整個遊戲開發的難點，其它類型的地圖漫遊均可以視做這種漫遊的的簡化。在這裏，我提出一個戰鬥地圖漫遊遊戲引擎的設計方案，其要點是：

1、 參照面向對象開發語言的特色，採用數據驅動的程序結構，首先定義一系列全局的數據結構，這個數據結構能夠表達整個遊戲的狀態，包括地圖的形態、武器的狀態、當前玩家的操做等，其它全部模塊都圍繞這些數據結構實現。下面把這個數據結構稱之爲核心結構。

這種程序結構與面向對象的類類似，這裏沒有采用面向對象的緣由是：核心結構是全局的，引擎的模塊都圍繞核結構開發，跨度很是大：在遊戲端，核心結構必須以全局變量方式實現，供多個線索同時訪問；在地圖服務器端，核心結構必須放在共享內存中，供不一樣的進程同時訪問。

這樣，面向對象的開發模式很難知足這樣的需求，此外，這裏也沒有必要使用使用繼承、重載等面向對象開發模式獨有的特性，因些沒有必要使用面向對象的開發方式（注：這裏只是說核心結構及其操做模塊沒有對象化，並非說其它地方限制面向對象方式的使用）；

2、 按照模塊的功能分類，不一樣的模塊儘量單獨在一個線索（遊戲端）或進程（服務器端）運行，這些模塊包括：

² 操縱；

² 通訊；

² 核心結構計算；

² 音效表達；

² 視覺效果表示；

² 聊天；

3、 由服務器發出統一節拍（每一節拍大概從0.5秒到1秒之間），全部在線遊戲端都按照這個節拍運行。

整個引擎結構以下：

流程分析以下：

1、 遊戲端控制線索把最新的操做指令寫入本人操做指令的變量中；

2、 遊戲端核心計算線索計算結束後，向同步通訊線索發出通訊指令（經過互拆對象實現）；

3、 同步通訊線索收到通訊指令後，把節拍ID、核心數據結構校驗碼、本人的操做指令以通訊報文（下稱上行同步包）方式發給圖形服務器；

4、 服務器的同步通訊進程收到來自不一樣遊戲端的上行同步包後，首先檢查節拍ID、核心數據結構校驗碼是否與服務器中的數據一致，不然通知遊戲端出現同步問題，是則把各遊戲端上傳的上行同步包中的操做指令記入操做指令數組中，操做指令數組聚集全部線用戶在同一節拍的操做指令；

5、 節拍時間到了以後，服務器核心計算進程向同步通訊進程發出停止接收上行同步包的指令；

6、 若是同步通訊進程收到停止指令後收到上行同步包，則通知對方通訊出現同步問題，並不把指令記入核心結構中；

7、 服務器核心計算線索計算核心結構，生成一個校驗碼，向同步通訊進程發出計算結束指令；

8、 同步通訊進程收到計算結束指令後，則把下一節拍ID、操縱隊列結構數組、校驗碼（這組數據下面稱之爲下行同步包）發給全部的遊戲端，；

9、 遊戲端同步通訊線索收到下行同步包，把操做指令數組記入核心結構，通知核心計算線索計算核心結構；

10、 核心計算線索以操做指令數組爲輸入，從新計算核心結構和校驗碼，並和服務器計算校驗碼比較，若是不一致，出現認爲計算同步問題，啓動同步恢復過程，若是一致，則通知通訊線索上傳數據，執行下一節拍；

11、 音效和視覺效果表達線索能夠以核心結構爲輸入，按照本身的節拍運行。

12、 聊天時，非跨地圖的信息發送至地圖服務器的聊天通訊服務進程，並記入聊天即時信息記錄，若是是跨地圖信息，則直接發至專用的聊天服務器；

十3、 服務器中運行一個跨地圖聊天信息獲取進程，專門從專用聊天服務器取出發至本地圖的跨地圖聊天信息，而後記入聊天即時信息記錄中。

十4、 不管是否跨地圖，遊戲端接收的信息都來自地圖服務順的聊天服務程序。這樣的設計目的是減輕專用聊天服務器的負擔。聊天沒有同步要求。

經過以上流程，整個系統，包括服務器和全部的遊戲端，都按照統一的節拍運行，並保證其核心結構是一致的。若是遊戲中，玩家的遊戲端出現同步問題，首先同步回覆過程嘗試恢復同步，若是恢復失敗，則必須做掉線處理。

因爲核心結構的信息量很大，在每一個節拍中傳遞整個核心結構確定是不可行的。在「破碎銀行系」中，無論玩家的網速是多少，正常狀況下游戲的響應速度都很好，但當一個新的玩家加入時，整個系統會停頓下來，有時時間很長，多達1分鐘之久，玩家稱之爲「卡」。

產生「卡」的緣由很簡單，就是全部的玩家的操做必須停下來，得到一份一致的核心結構，而後把核心結構傳遞給新加入的玩家的遊戲端。

「卡」的現象很值得分析，「卡」的時候，玩家能夠正常聊天，大地圖和縮小地圖滾動正常，說明「破碎銀行系」也採起了聊天、視覺表達系統與核心結構的同步系統相分離的設計方法。

視聽覺表達系統與核心結構相分離，按照本身的節拍運行，可能會致使不一樣的遊戲端的顯示和音響不一樣，但這不會影響遊戲的運行，致使不一致的遊戲結果。

節拍間距和最大在線用戶分析

在一個節拍的間距中，整個系統必須完成的任務有：

1、 遊戲端向服務器傳遞一個上行同步包；

2、 服務器向遊戲端傳遞一個下行同步包；

3、 遊戲端和服務器各執行一次核心計算。

節拍間距的調整是個很是關鍵的問題，太長的間距影響遊戲的流暢性，過短致使了某些網速慢的遊戲端的同步困難。

在「破碎銀行系」中，若是快速操做，1秒種能夠執行2個以上的操做，能夠看到除第1個操做獲得執行外，其他操做被忽略，也就是說，「破碎銀行系」的節拍間距是1秒左右。

在玩「破碎銀行系」的過程當中，我以爲操做不是太順暢，若是把節拍設爲0.5秒會好一點。至於更短的值可能沒有必要，由於人的操做頻率通常不會每秒2個。

同一個地圖在線用戶的增長，從兩個方面影響性能：

1、 核心結構信息量增長，致使計算量的增長；

2、 下行同步包必須包含操做指令數組信息量更大。

通常認爲，運算速度不會成爲系統的性能瓶勁，下行同步包確定要大於上行同步包（只有一個操做指令），一張地圖支持的最大用戶數取決於下行同步包的大小和通訊速度。

下行同步包中，每一個操做指令的信息量大概爲：

² 操做涉及的武器，1個武器1Bit，每1位表示該序號的武器是否被選中。「破碎銀行系」每一個玩家最多隻能操縱6件武器參戰，也就說須要1個字節。

² 指令類型，1個字節；

² 指令參數（如移動指令的目標，鼠標點在地圖上的位置）兩個整形，4個字節；

也就是說每增長1個在線用戶，下行同步包須要增長6個字節的通訊量。

若是下行同步包中其它信息爲32個，最大在線用戶數爲128，那麼每一個下行同步包的報文長度爲32+6*128=800字節。

遊戲中，人不可能不停地發出指令，大部分時間應該處於空閒狀態，這時候可用一個字節0表示空操做指令，0表示沒有選中武器，沒有選擇武器沒是沒有操做。經過上述壓縮方法，把下行同步包數據通訊報文限制在576字節如下應該沒有問題。576字節是128K如下的PPP協議（即撥號上網）的最大包的字節數。數據在網絡中傳遞所須要的時間是按照包來計算的，更低的值沒有意義。

遊戲端使用56K 的撥號上網，通訊有效率爲50%，那麼每秒可傳遞3500字節。例如撥號上網下載文件時，下載速度通常是3K至4K。說明節拍間距0.5秒、128個同時在線用戶的性能參數還必定的挖掘空間。

除下行同步包外，遊戲端還必須向服務器傳遞一個上行同步包，因爲網絡有一個「雙工」，即同時雙向會傳輸的特性，加上信息確定小於下行同步包，系統主要仍是受下行同步包的影響。

玩家進入交流地圖時，並不會出現「卡」的現象，這是由於交流地圖的核心結構很小，只須要記錄在線用戶的用戶名、圖標號和在地圖的座標便可。能夠經過一些壓縮算法，實現「無等待加入地圖」。

聊天模塊的實現

    聊天模塊包括幾個子模塊，包括：

² 跨地圖聊天服務器

² 聊天數據發送線索

² 聊天服務進程

² 跨地圖聊天信息獲取進程

此外還有部分功能混集在其它模塊中，整個聊天模塊的流程爲：

1、 在遊戲端，「操縱控制線索」收到發出聊天信息命令，把數據寫入「待發聊天信息」的數據結構中，向「聊天數據發送線索」發出一個Windows消息；

2、 「聊天數據發送線索」收到Windows消息後，檢查待發聊天信息，若是發出的信息是跨地圖，則創建一個與「跨地圖聊天服務器」 （服務器地址在登陸時獲取，使用約定的端口號）的TCP鏈接，若是發出的信息是本地圖，則鏈接地圖服務器，鏈接成功後發送數據，而後關閉鏈接，回到接收消息的狀態；

3、 聊天數據發送線索可以使用阻塞機制發送聊天數據，使用阻塞機制時，必須從新安裝一個阻塞處理的鉤子函數，控制通訊超時時間；

4、 在地圖服務器啓動一個聊天服務進程，負責接收來自遊戲端的數據，收到後寫入「聊天信息記錄」，須要在地圖服務器開闢一塊共享內存的空間，專門記錄「聊天信息記錄」；

5、 在地圖服務器啓動一個「跨地圖聊天信息獲取進程」，進程大概每隔1秒鐘從「跨地圖聊天服務器」接收目標地址是本服務器的聊天信息，收到後寫入「聊天信息記錄」中；

6、 「同步通訊進程」向遊戲端發送下行同步包時，還須要實現一個「額外」的功能，就是檢查「聊天信息記錄」，有須要發到遊戲端的通訊數據，附帶在下行同步包中發給遊戲端；

7、 遊戲端的同步通訊線索收到下行同步包中附帶聊天數據後，把聊天數據寫入「接收聊天信息」中；

8、 聊天信息的顯示由「視覺效果表達線索」處理。

    這樣處理的優勢是：

1、 整體來講，實現比較簡單，與其它模塊之間的關係比較清淅，相互干涉少；

2、 實現了遊戲端的按需傳輸，象地圖服務器的跨地圖聊天信息獲取進程從服務器獲取數據時，必須採用輪詢的方式定時從服務器，產生大量的無用通訊，固然，這在帶寬比較高的服務器之間並沒關係，但對網速較低的遊戲端來講是必需的；

3、 沒有大量的遊戲端向聊天服務器輪詢數據，減輕了聊天服務器的壓力。

同步通訊模塊

同步通訊應該使用TCP長鏈接，長鏈接的意思是指在遊戲端進入地圖（服務器）以前，就創建一個與服務器的TCP鏈接（會話），該鏈接一直保留直至退出該地圖，在此期間，遊戲端和地圖服務器之間全部通訊都過該鏈接進行。這點和發送聊天數據是不一樣的，發送聊天數據時，遊戲端須要動態創建一個TCP鏈接，發送結束後，馬上關閉該鏈接。

TCP通訊通常是是C/S結構，當遊戲端進入地圖時，遊戲端主動呼叫地圖服務器某個端口（系統約定），試圖創建一個TCP鏈接。

鏈接創建成功後，遊戲端須要建立兩個線索，分別是「同步通訊發送線索」和「同步通訊接收線索」。

在客戶端，TCP的通訊使用Winsock 提供的「異步消息機制」，這點與聊天通訊發送線索使用的「阻塞機制」不一樣。同步通訊線索與核心計算線索之間的同步應該使用互拆對象，使用互拆對象要比消息更爲可靠，這是由於消息會放在一個系統級的隊列中排隊，若是其它線索沒有及時取走本身的消息，就會堵塞後面的消息的傳送。下面是客戶端的同步通訊處理過程：

1、 創建兩個互拆對象，一個稱爲發送互拆對象，一個爲計算互拆對象；

2、 核心計算線索計算結束後，釋放發送互拆對象；

3、 同步通訊發送線索運行，從核心結構取出須要發送的數據，生成上行同步包發送，釋放發送互拆對象，核心計算線索從新運行，檢查計算互拆對象；

4、 此時，同步通訊接收線索正處於接收消息狀態；

5、 當系統收到地圖服務器的下行同步包後，系統會向同步通訊線索發送一個消息（Winsock的異步消息機制）；

6、 同步通訊接收線索收到下行同步包後，寫入核心結構，而後釋放計算互拆對象；

7、 核心計算線索繼續運行，釋放計算互拆對象，進行核心計算；

8、 核心計算線索釋放計算互拆對象後，同步通訊接收線索也繼續運行，回到接收消息的狀態。

服務器端須要處理的關鍵問題是必須處理多個遊戲端的鏈接，服務器端可以使用：多進程、異步I/O複用和多線索等機制處理，三種機制都各有優缺點，但都能知足系統的需求。因爲Linux下的通訊實現比較簡單，下面再也不詳述。

服務器通訊同步進程可採用信號燈機制實現和核心計算進程之間的同步。

同步的創建和恢復

在網絡遊戲中，爲了維護遊戲的一致性，必須在每個節拍中，保證核心結構的一致性，這就同步。在本文同步的方案是，首先讓服務器和全部的遊戲端得到一份一致的核心結構數據，而後經過地圖服務器收集全部遊戲端的操做指令（上行同步包），而後經過下行同步包分發這些指令，這些指令造成增量數據，而後服務器和遊戲端都根據同一算法，從新計算出下一節拍的核心結構數據來。

當一臺新的遊戲端進入地圖時，服務器停止接受節拍的運行，中止接收新的操做指令，而後出遊戲端傳遞一份初始的核心結構，這段時間稱之卡。下面估算一下卡的時間。

核心結構中，地圖的信息較大，但這部分信息不須要傳遞，須要傳遞的主要信息是武器屬性數組。假設這個數組1000條記錄（128個在線遊戲端，每一個遊戲端7.8個，「破碎銀河系」爲6個），每條記錄100個字節，也就是說合計100K字節，假設遊戲端使用56K撥號上網，每秒接收3K字節的數據，「卡」的時間大概爲33秒，這個估算和「破碎銀河系統」的狀況大體吻合。

簡單採用直接傳送核心結構的辦法，一方面會致使使人討厭的「卡」現象，另外一方面，出現同步被破壞後，沒法恢復，只能掉線處理。

同步被破壞的緣由有兩種：

² 核心結構從新計算後，計算結果不一致，稱之爲計算同步破壞；

² 遊戲端由於通訊或其它問題，未能及時上傳上行同步包，稱之爲通訊同步破壞。

下面提出一種方案，試圖解決「卡」和同步恢復的問題，這種方法依賴於服務器大量備份歷史核心結構和操做指令序列數據：

1． 當地圖服務器順利完成一個同步的節拍後，服務器服務備份核心結構，同時備份該節拍以後全部的操做指令序列數組。

2． 新的遊戲端向服務器發出請求，請求加入地圖，或請求同步恢復；

3． 服務器下傳備份的核心結構；

4． 服務器接二連三地向遊戲端下傳備份操做指令序列數組的歷史記錄；

5． 遊戲端收到備份的核心結構和操做指令序列數組後，不斷的調用核心計算模塊，直至遇上服務器最新的節拍；

6． 在追趕的過程當中，遊戲端執行玩家的操做指令。

下面估算一下追趕須要經歷的時間。

計算條件：

節拍間距：0.5秒；

核心結構大小：100K；

下行同步包大小：小於576字節；

每秒下傳數據量：採用56K撥號上秒，每秒6個包，即3456字節；

其它（如核心計算時間）忽略不計。

追趕時間：S

那麼：

S * 3456 =  S / 0.5 * 576 + 100000

即

S = 100000/ （3456 – 0.5/576）= 32秒。

爲了保持戰略的均勢，「破碎銀河系」有一個設計，當玩家提出進入某個地圖做戰的請求後，必須等待一段時間才能進入，這段時間跟據玩家與做戰地圖的距離（戰略地圖）而定，大概從幾秒到120秒不等，能夠利用這段時間追趕同步。

核心結構和計算

核心結構是多個結構數組的集合，包括：

² 操做指令數組：每條記錄記錄一個用戶的指做指令；

² 地圖形態結構數組：

每條記錄描述地圖一個最小區域的屬性，在「破碎銀河系中」，地圖的屬性比較簡單，只須要表達該區域陸軍是否可進入便可，至於其豐富的地貌，如樹木、山脈、建築物、湖泊等，只需另外畫一張與地圖形態數組一致的圖便可，地圖形態數據沒必要記錄這些信息，那是屬於表達模塊處理的問題；

² 玩家狀態結構數組

每條記錄描述一個用戶的屬性，必須的數據成員有：

ID；

所屬國；

等級；

² 武器狀態結構數組：

每條記錄描述一件武器的的屬性，主要數據成員有：

武器種類；

所屬國；

主人在玩家狀態結構數組的序號；

等級；

生命值；

能源值；

裝備；

座標；

當前狀態；

被攻擊的類型；

² 特殊物體數組，特殊物體數組可用來表達佈雷等形態，主要的數據成員有：

種類；

所屬國；

主人在玩家狀態結構數組的序號；

座標等

² 校驗碼：利用校驗算法，對核心結構中可變的部分進行計算出來的校驗碼，用來防止計算同步破壞、做弊等；

² 節拍ID

核心計算能夠按照幾個步驟來進行：

1、 計算各武器的最新狀態；

2、 計算各武器的最新座標；

3、 計算各武器對其它武器的攻擊效果；

4、 計算特殊物對其它武器的攻擊效果並刪除記錄；

5、 刪除生命值爲0的記錄；

核心計算注意事項：

1、 爲了保證計算同步，全部計算數據只參使用整形，不能使用浮點數；

2、 爲了增長計算精度，應該對計算表達式進行變換，變換成除法是最後一個運算步驟；

3、 注意整形數據的超值（大於2的32次方）；

4、 爲了保持武器系統的平衡，避免出現「超級武器」，削弱遊戲的可玩性，不管是武器的速度、攻擊效果等數據都應該參數化，保存在文件中，方便在遊戲測試、營運時調整。

屬性設定模塊

     屬性設定模塊的實質就是聯機交易服務器，運行於Linux服務器上，通常採用C語言開發，與數據庫的接口是Embedding C預編譯器，若是數據庫爲Oracle，預編譯器的產品名稱爲Proc C。

    因爲這方面技術很是成熟，就再也不一一禪實。

視聽覺表達模塊

核心結構給視聽覺表達模塊一個接口，表達模塊只需圍繞這個接口按照生成畫面和音響便可，不須關心遊戲的其它部分，功能至關獨立，這是本文接出的結構的最大特色。

筆者沒有開發同類程序的經驗，就再也不獻醜了。

操做控制模塊

操做控制模塊接收用戶的按鍵和鼠標操做，若是發聊天操做，把發出的聊天數據寫入待發聊天數據的內存變量便可。

若是是武器操做，還必須把按鍵和鼠標操做翻譯爲對武器的操做，再寫入本人操做指令的數據結構中。

分工和工做量估算

上面所描述的遊戲引擎，有一個很大的優勢就充分考慮瞭如何分工合做，各模塊互相干涉較少。

遊戲開發的核開發小組可能須要成員包括：

² 項目經理2人；

² 遊戲端總控1人；

² 服務器端總控1人；

² 聊天功能的開發1人；

² 操做數據的交換（即遊戲端通訊線索和服務器端進程的開發）1人；

² 核心計算1人；

² 新玩家加入，創建初始狀態的通訊模塊1人；

² 音效表達線索1人；

² 視覺表達線索須要3人左右的小組一個；

² 屬性設定服務器1人；

² 屬性設定界面開發2人；

² 美工3人左右；

² 測試2人；

² 系統安裝管理1人；

² 質量配置管理員1人。

時間的安排爲：

² 腳本編寫1個月

² 整體設計和詳細設計2個月

² 編碼2個月；

² 測試3個月；

² 後期製做2個；

整個工期大根據爲12個月，每一個階段不必定須要全部人蔘與。

以上安排是按照比較寬裕、規範的方針按排，有很大的壓縮空間。

後記

因爲筆者並未開發過任何遊戲軟件，若是某些猜想與現實不符，敬請見諒。在可見的未來，筆者從事的工做雖然和遊戲無關，但出於興趣撰寫了本文，筆者更很是但願能和其它對遊戲開發感興趣的同行增進交流，相互學習。筆者信箱：chenchongfen@21cn.com或chenchongfen@163.com。