視窗背後訊息處理的模式

玩家對滑鼠操作的不同，會產生不一樣的訊息，每種訊息在其背 後會有一組相對應的連串處理程序，這樣的處理程序又可分為兩種，

一種是與伺服端有關的，而另一種則是無關的。

簡易3D多人線上遊戲系統

一、與伺服端相關之處理程序

主要的有交易、升級、技能增加…等之點選，這些動作會影響到 遊戲相關資料，需要由伺服端來計算更新。圖 5-72 則為玩家點選商 品購買之活動圖，由圖中可以清楚看出整個過程是如何處理。

圖 5-72 玩家點選商品購買之活動圖

二、與伺服端無關之處理程序

主要的有按鈕及拖曳視窗等之點選，這些動作不會影響到遊戲相 關資料，只會改變視窗的呈現。

5.10 網路連線系統

網路連線系統，是用 DirectPlay 架構出來的，而 DirectPlay 是 以 COM 的方式開發出來，所以要先使用 CoCreateInstance 取得 DirectPlay API 介面，之後列舉出所有網路設備，選擇一個適合設 備，這樣就完成第一步的準備工作。

最後，最重要的工作就是要如何設計編輯訊息封包，及管理訊息 封包。訊息的設計方面，每個訊息封包會有一個標頭結構，這樣就很 容易分配封包種類，如圖 5-73 所示。

圖 5-73 封包標頭

網路封包的傳送接收是由另一個執行緒平行處理，如圖 5-74 所 示，當接收到封包的時後，就將封包都放入佇列，以先進先出的方式 處理每一個封包，運用 Header 指標和 Tail 指標控制資料儲存位置，

資料寫入佇列時，Header 指標加一，如果超過最大值就回到 0；讀取 資料的時後，Tail 減一，如果小於 0 就到最大值，當 Header 和 Tail 差距愈大的時後，表示尚未處理資料愈多，所以 Header+1=Tail 的情 況發生的時後就是 full，而 Header=Tail 的時後，就是 empty。

簡易3D多人線上遊戲系統

圖 5-74 封包佇列說明圖

在處理傳送過程中並不需要佇列，直接由低層的網路協定處理。

另一面傳送封包的時後，指定傳送對象在用戶端跟伺服端上有一些不 同的地方如圖 5-75 所示，用戶端傳送封包的對象只有伺服端一方，

而伺服端要溝通的是所有的用戶端，但是有些訊息並不需要傳送給每 一個用戶端，反而只要傳送給某些族群的用戶端就夠了，如移動封包 和攻擊封包只要傳給同一個地圖上的玩家就行了，在這方面可以運用 DirectPlay 內 CreateGroup 的功能，把同地圖的玩家設為同一個族 群，所以傳送封包的時後，對象只要指定 Group 的 ID，就會自動把 訊息傳送給這族群的所有玩家，這樣就可以減少無謂的封包。

圖 5-75 不同地圖 Group 示意圖

簡易3D多人線上遊戲系統

5.11 劇情創造系統

提供給主程式一個介面，讓它可以建立、觸發劇情。使遊戲內有 劇情的變化。讓遊戲有更豐富的內容來展現出遊戲的深度，如此一來 就能吸引更多的玩家。

5.11.1 基本概念

為了讓遊戲開發者容易設計不一樣的劇情，且又不希望劇情寫死 在程式裡，因此提供一套機制，讓遊戲開發者易於編寫、修改、及擴 充劇情。圖 5-76 為此機制的主要組成元件。

圖 5-76 劇情系統組成元件

一、劇情原始檔