網絡即時戰略遊戲軟體開發 結構體系分析
文檔下載下傳位址：http://download.csdn.net/detail/wanggan768q/4388056
網絡即時戰略遊戲軟體開發
結構體系分析
前言
本人對網絡遊戲的技術問題一直比較感興趣，我認為網絡遊戲的開發在不遠的将來是一個非常龐大的産業。這段時間有空，特地玩了幾天網絡遊戲“破碎銀行系”，并分析了一下其中體系結構，有些體會，結合自己多年的軟體開發經驗，就如何開發一個類似于“破碎銀行系”的網絡即時戰略遊戲撰文如下，希望能抛磚引玉，對從事遊戲開發的人有所幫助。
網絡遊戲是我們的機會
單人遊戲的開發國外廠商已經積累了豐富的技術基礎，各種遊戲模式已經基本定型，新款遊戲隻能在視、聽覺的效果上大做文章，主要的競争領域是3D技術和美工，在這些方面，我們要一下子趕上國外的技術水準還有一定難度。
而網絡遊戲，其吸引人的地方是多人的互動性和協作性，視聽覺效果的作用已經退到次要的位置，例如“破碎銀行系”，玩家所希望的是在上面打一場玩家緊密配合，最後成功戰勝對方的“國戰”，沒人關注它是2D還是3D的。
網絡遊戲，需要引入新的技術，如資料庫、通信和伺服器端軟體的開發，這些技術在國内其它領域（如金融和電信）已經得到相當成熟的應用，并不存在任何技術問題，加上2D遊戲的開發，國内成功案例較多，是以，隻要把國内的資源有效地組織起來，就能開發一個富有市場前景的網絡遊戲。
許多人會認為網絡遊戲的開發是一件技術難度非常高的工作，當然，遊戲的開發，其它技術含量要比一個資訊管理系統高，但并不是高不可攀，我更願意用“開發網絡遊戲是一個系統工程”這樣的觀點形容網絡遊戲的開發。
本文的主要内容之一便是分析如何把一個功能複雜的網絡即時戰略遊戲，劃分為多個盡量孤立的子系統，并逐一分析每個子系統的技術特點和難點。
遊戲功能子產品分析
在“破碎銀行系”中，可把它的功能劃分為以下幾類：
一、 交流或作戰狀态的地圖漫遊；
二、 屬性設定；
三、 聊天；
在地圖漫遊功能，又分為以下幾類：
² 交流狀态，多人線上的地圖漫遊；
² 戰鬥狀态，多人線上，人與人之間的戰鬥，如“國戰”、“競技場”等；
² 戰鬥狀态，多人線上，人與計算機之間的戰鬥，如“異形戰争”；
² 戰鬥狀态，單人遊戲，人與計算機之間的戰鬥，如“訓練場”；
每個多人線上的地圖，都需要一台伺服器管理，我們把台伺服器稱之為地圖伺服器。
在“破碎銀行系”中，同一交流狀态地圖可以同時容納128名線上使用者，而戰鬥狀态地圖則可以同時容納64名線上使用者。
許多功能，如注冊、登入、購買武器、修複武器、武器更新、武器物品裝備、加入軍團、選舉領主、拜師和系統内信件等，其實都可以歸入屬性設定一類的功能，其實質很簡單，都是查詢或修改資料庫中，關于玩家的某些記錄。例如拜師，其實就是修改玩家屬性資料庫中，其上級的字段。
在Internet環境下，用戶端（即玩家使用的PC，以下稱為遊戲端）不可能直接通路資料庫伺服器，必須通過聯機交易這種方式實作。
聯機交易首先在金融等行業得到應用，現在所有的核心金融應用系統，都基于聯機交易，而且，聯機交易已經廣泛地應用于其它各個領域中。
聯機交易是指用戶端根據實際功能的需要，按照規定的格式填寫一個資料結構（稱之為交易請求封包），然後通過計算機通信發給交易伺服器；
交易伺服器收收交易請求封包後，執行相應的資料處理工作，多為資料庫操作，并把處理結果按照規定的格式填寫響應資料結構（稱之為交易響應封包），然後發給用戶端，通知用戶端處理結果。
在遊戲軟體中，一個屬性設定功能，就是一個聯機交易，隻不過是把操作界面圖形化、遊戲化而。
這裡我們把交易伺服器端稱為屬性伺服器。
如果玩家經常使用系統内信件的功能，則有必要讓系統内信件功能單獨使用一台伺服器。
聊天的實作與ICQ類似，也需要一台伺服器（至少邏輯上），我把這台伺服器稱之聊天伺服器。
有一種考慮，就是把聊天伺服器合并在地圖伺服器上，這是因為聊天的對象一般都是同一個地圖上的人，但某些情況例如，如領主和軍團長可以通過“大喊”功能跨地圖，把指令釋出到整個星球，而上下級之間的聊天也可以跨地圖。
是以，同一地圖的聊天可在地圖伺服器中增加一個聊天子產品處理，整個遊戲分區還應設立一台專用的聊天伺服器，處理跨地圖的聊天功能。
伺服器組織
毫無疑問，遊戲端使用Windows平台，使用Wins32 API，伺服器則最好使用Linux作業系統。
系統伺服器分為兩類，資料庫伺服器和通信資料封包處理伺服器。
資料庫伺服器從穩定性、價格和性能出發，最好選擇Oracle，版本不限。Oracle的穩定性和性能自不用多說，而其For Linux的版本，最低價格不到8000元（從分銷商那出貨），也是非常便宜的。
在“破碎銀行系”中，一個遊戲分區可以由多個星球，每個昨星球有多張地圖，是以，其伺服器組的結構可以是這樣：
每一個星球大概有100張地圖，可以通過動态配置設定、一台實體伺服器運作多個交流地圖伺服器等方式，減少真正需要的伺服器。
因為地圖伺服器可以動态增加，是以一個分區同支援的使用者數取決于屬性伺服器和聊天伺服器。
其實屬性伺服器的主要操作是資料庫操作，其性能又取決于資料庫伺服器，根據我的經驗，一台較好的資料庫伺服器，每秒種可以處理100筆以上的聯機交易，也就是說每秒種可以處理100次屬性設定請求，根據我玩“破碎銀行系”的經驗，屬性設定的執行頻率不到10分鐘每次，那麼一個分區可以同時支援60000個線上使用者。
因為跨地圖聊天的執行頻率很低，是以聊天伺服器不會成為系統的性能瓶頸。
系統需要的伺服器總數取決地圖伺服器，一台地圖伺服器同時支援64至128線上使用者，但不可能總是滿員，因些，如果需要同時支援5000線上使用者，可能需要100台左右地圖伺服器。
戰鬥地圖漫遊遊戲引擎的設計
多人線上的戰鬥地圖漫遊是整個遊戲開發的難點，其它類型的地圖漫遊都可以視作這種漫遊的的簡化。在這裡，我提出一個戰鬥地圖漫遊遊戲引擎的設計方案，其要點是：
一、 參照面向對象開發語言的特點，采用資料驅動的程式結構，首先定義一系列全局的資料結構，這個資料結構可以表達整個遊戲的狀态，包括地圖的形态、武器的狀态、目前玩家的操作等，其它所有子產品都圍繞這些資料結構實作。下面把這個資料結構稱之為核心結構。
這種程式結構與面向對象的類相似，這裡沒有采用面向對象的原因是：核心結構是全局的，引擎的子產品都圍繞核結構開發，跨度非常大：在遊戲端，核心結構必須以全局變量方式實作，供多個線索同時通路；在地圖伺服器端，核心結構必須放在共享記憶體中，供不同的程序同時通路。
這樣，面向對象的開發模式很難滿足這樣的需求，此外，這裡也沒有必要使用使用繼承、重載等面向對象開發模式獨有的特性，因些沒有必要使用面向對象的開發方式（注：這裡隻是說核心結構及其操作子產品沒有對象化，并不是說其它地方限制面向對象方式的使用）；
二、 按照子產品的功能分類，不同的子產品盡可能單獨在一個線索（遊戲端）或程序（伺服器端）運作，這些子產品包括：
² 操縱；
² 通信；
² 核心結構計算；
² 音效表達；
² 視覺效果表示；
² 聊天；
三、 由伺服器發出統一節拍（每一節拍大概從0.5秒到1秒之間），所有線上遊戲端都按照這個節拍運作。
整個引擎結構如下：
流程分析如下：
一、 遊戲端控制線索把最新的操作指令寫入本人操作指令的變量中；
二、 遊戲端核心計算線索計算結束後，向同步通信線索發出通信指令（通過互拆對象實作）；
三、 同步通信線索收到通信指令後，把節拍ID、核心資料結構校驗碼、本人的操作指令以通信封包（下稱上行同步包）方式發給圖形伺服器；
四、 伺服器的同步通信程序收到來自不同遊戲端的上行同步包後，首先檢查節拍ID、核心資料結構校驗碼是否與伺服器中的資料一緻，否則通知遊戲端出現同步問題，是則把各遊戲端上傳的上行同步包中的操作指令記入操作指令數組中，操作指令數組彙集所有線使用者在同一節拍的操作指令；
五、 節拍時間到了之後，伺服器核心計算程序向同步通信程序發出中止接收上行同步包的指令；
六、 如果同步通信程序收到中止指令後收到上行同步包，則通知對方通信出現同步問題，并不把指令記入核心結構中；
七、 伺服器核心計算線索計算核心結構，生成一個校驗碼，向同步通信程序發出計算結束指令；
八、 同步通信程序收到計算結束指令後，則把下一節拍ID、操縱隊列結構數組、校驗碼（這組資料下面稱之為下行同步包）發給所有的遊戲端，；
九、 遊戲端同步通信線索收到下行同步包，把操作指令數組記入核心結構，通知核心計算線索計算核心結構；
十、 核心計算線索以操作指令數組為輸入，重新計算核心結構和校驗碼，并和伺服器計算校驗碼比較，如果不一緻，出現認為計算同步問題，啟動同步恢複過程，如果一緻，則通知通信線索上傳資料，執行下一節拍；
十一、 音效和視覺效果表達線索可以以核心結構為輸入，按照自己的節拍運作。
十二、 聊天時，非跨地圖的資訊發送至地圖伺服器的聊天通信服務程序，并記入聊天即時資訊記錄，如果是跨地圖資訊，則直接發至專用的聊天伺服器；
十三、 伺服器中運作一個跨地圖聊天資訊擷取程序，專門從專用聊天伺服器取出發至本地圖的跨地圖聊天資訊，然後記入聊天即時資訊記錄中。
十四、 不論是否跨地圖，遊戲端接收的資訊都來自地圖服務順的聊天服務程式。這樣的設計目的是減輕專用聊天伺服器的負擔。聊天沒有同步要求。
通過以上流程，整個系統，包括伺服器和所有的遊戲端，都按照統一的節拍運作，并保證其核心結構是一緻的。如果遊戲中，玩家的遊戲端出現同步問題，首先同步回複過程嘗試恢複同步，如果恢複失敗，則必須作掉線處理。
由于核心結構的資訊量很大，在每個節拍中傳遞整個核心結構肯定是不可行的。在“破碎銀行系”中，不管玩家的網速是多少，正常情況下遊戲的響應速度都很好，但當一個新的玩家加入時，整個系統會停頓下來，有時時間很長，多達1分鐘之久，玩家稱之為“卡”。
産生“卡”的原因很簡單，就是所有的玩家的操作必須停下來，獲得一份一緻的核心結構，然後把核心結構傳遞給新加入的玩家的遊戲端。
“卡”的現象很值得分析，“卡”的時候，玩家可以正常聊天，大地圖和縮小地圖滾動正常，說明“破碎銀行系”也采取了聊天、視覺表達系統與核心結構的同步系統相分離的設計方法。
視聽覺表達系統與核心結構相分離，按照自己的節拍運作，可能會導緻不同的遊戲端的顯示和音響不同，但這不會影響遊戲的運作，導緻不一緻的遊戲結果。
節拍間距和最大線上使用者分析
在一個節拍的間距中，整個系統必須完成的任務有：
一、 遊戲端向伺服器傳遞一個上行同步包；
二、 伺服器向遊戲端傳遞一個下行同步包；
三、 遊戲端和伺服器各執行一次核心計算。
節拍間距的調整是個非常關鍵的問題，太長的間距影響遊戲的流暢性，太短導緻了某些網速慢的遊戲端的同步困難。
在“破碎銀行系”中，如果快速操作，1秒種可以執行2個以上的操作，可以看到除第1個操作得到執行外，其餘操作被忽略，也就是說，“破碎銀行系”的節拍間距是1秒左右。
在玩“破碎銀行系”的過程中，我覺得操作不是太順暢，如果把節拍設為0.5秒會好一點。至于更短的值可能沒有必要，因為人的操作頻率一般不會每秒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個同時線上使用者的性能參數還一定的挖掘空間。
除下行同步包外，遊戲端還必須向伺服器傳遞一個上行同步包，由于網絡有一個“雙工”，即同時雙向會傳輸的特性，加上資訊肯定小于下行同步包，系統主要還是受下行同步包的影響。
玩家進入交流地圖時，并不會出現“卡”的現象，這是因為交流地圖的核心結構很小，隻需要記錄線上使用者的使用者名、圖示号和在地圖的座标即可。可以通過一些壓縮算法，實作“無等待加入地圖”。
聊天子產品的實作
聊天子產品包括幾個子子產品，包括：
² 跨地圖聊天伺服器
² 聊天資料發送線索
² 聊天服務程序
² 跨地圖聊天資訊擷取程序
此外還有部分功能混集在其它子產品中，整個聊天子產品的流程為：
一、 在遊戲端，“操縱控制線索”收到發出聊天資訊指令，把資料寫入“待發聊天資訊”的資料結構中，向“聊天資料發送線索”發出一個Windows消息；
二、 “聊天資料發送線索”收到Windows消息後，檢查待發聊天資訊，如果發出的資訊是跨地圖，則建立一個與“跨地圖聊天伺服器” （伺服器位址在登入時擷取，使用約定的端口号）的TCP連接配接，如果發出的資訊是本地圖，則連接配接地圖伺服器，連接配接成功後發送資料，然後關閉連接配接，回到接收消息的狀态；
三、 聊天資料發送線索可使用阻塞機制發送聊天資料，使用阻塞機制時，必須重新安裝一個阻塞處理的鈎子函數，控制通信逾時時間；
四、 在地圖伺服器啟動一個聊天服務程序，負責接收來自遊戲端的資料，收到後寫入“聊天資訊記錄”，需要在地圖伺服器開辟一塊共享記憶體的空間，專門記錄“聊天資訊記錄”；
五、 在地圖伺服器啟動一個“跨地圖聊天資訊擷取程序”，程序大概每隔1秒鐘從“跨地圖聊天伺服器”接收目标位址是本伺服器的聊天資訊，收到後寫入“聊天資訊記錄”中；
六、 “同步通信程序”向遊戲端發送下行同步包時，還需要實作一個“額外”的功能，就是檢查“聊天資訊記錄”，有需要發到遊戲端的通信資料，附帶在下行同步包中發給遊戲端；
七、 遊戲端的同步通信線索收到下行同步包中附帶聊天資料後，把聊天資料寫入“接收聊天資訊”中；
八、 聊天資訊的顯示由“視覺效果表達線索”處理。
這樣處理的優點是：
一、 總體來說，實作比較簡單，與其它子產品之間的關系比較清淅，互相幹涉少；
二、 實作了遊戲端的按需傳輸，象地圖伺服器的跨地圖聊天資訊擷取程序從伺服器擷取資料時，必須采用輪詢的方式定時從伺服器，産生大量的無用通信，當然，這在帶寬比較高的伺服器之間并不要緊，但對網速較低的遊戲端來說是必需的；
三、 沒有大量的遊戲端向聊天伺服器輪詢資料，減輕了聊天伺服器的壓力。
同步通信子產品
同步通信應該使用TCP長連接配接，長連接配接的意思是指在遊戲端進入地圖（伺服器）之前，就建立一個與伺服器的TCP連接配接（會話），該連接配接一直保留直至退出該地圖，在此期間，遊戲端和地圖伺服器之間所有通信都過該連接配接進行。這點和發送聊天資料是不同的，發送聊天資料時，遊戲端需要動态建立一個TCP連接配接，發送結束後，立刻關閉該連接配接。
TCP通信一般是是C/S結構，當遊戲端進入地圖時，遊戲端主動呼叫地圖伺服器某個端口（系統約定），試圖建立一個TCP連接配接。
連接配接建立成功後，遊戲端需要建立兩個線索，分别是“同步通信發送線索”和“同步通信接收線索”。
在用戶端，TCP的通信使用Winsock 提供的“異步消息機制”，這點與聊天通信發送線索使用的“阻塞機制”不同。同步通信線索與核心計算線索之間的同步應該使用互拆對象，使用互拆對象要比消息更為可靠，這是因為消息會放在一個系統級的隊列中排隊，如果其它線索沒有及時取走自己的消息，就會堵塞後面的消息的傳送。下面是用戶端的同步通信處理過程：
一、 建立兩個互拆對象，一個稱為發送互拆對象，一個為計算互拆對象；
二、 核心計算線索計算結束後，釋放發送互拆對象；
三、 同步通信發送線索運作，從核心結構取出需要發送的資料，生成上行同步包發送，釋放發送互拆對象，核心計算線索重新運作，檢查計算互拆對象；
四、 此時，同步通信接收線索正處于接收消息狀态；
五、 當系統收到地圖伺服器的下行同步包後，系統會向同步通信線索發送一個消息（Winsock的異步消息機制）；
六、 同步通信接收線索收到下行同步包後，寫入核心結構，然後釋放計算互拆對象；
七、 核心計算線索繼續運作，釋放計算互拆對象，進行核心計算；
八、 核心計算線索釋放計算互拆對象後，同步通信接收線索也繼續運作，回到接收消息的狀态。
伺服器端需要處理的關鍵問題是必須處理多個遊戲端的連接配接，伺服器端可使用：多程序、異步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
核心計算可以按照幾個步驟來進行：
一、 計算各武器的最新狀态；
二、 計算各武器的最新座标；
三、 計算各武器對其它武器的攻擊效果；
四、 計算特殊物對其它武器的攻擊效果并删除記錄；
五、 删除生命值為0的記錄；
核心計算注意事項：
一、 為了保證計算同步，所有計算資料隻參使用整形，不能使用浮點數；
二、 為了增加計算精度，應該對計算表達式進行變換，變換成除法是最後一個運算步驟；
三、 注意整形資料的超值（大于2的32次方）；
四、 為了保持武器系統的平衡，避免出現“超級武器”，削弱遊戲的可玩性，無論是武器的速度、攻擊效果等資料都應該參數化，儲存在檔案中，友善在遊戲測試、營運時調整。
屬性設定子產品
屬性設定子產品的實質就是聯機交易伺服器，運作于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個月，每個階段不一定需要所有人參與。
以上安排是按照比較寬裕、規範的方針按排，有很大的壓縮空間。
後記
由于筆者并未開發過任何遊戲軟體，如果某些猜測與現實不符，敬請見諒。在可見的将來，筆者從事的工作雖然和遊戲無關，但出于興趣撰寫了本文，筆者更非常希望能和其它對遊戲開發感興趣的同行增進交流，互相學習。筆者信箱：[email protected]或[email protected]。