《以XML资料驱动为基础之分散式网路》由会员分享，可在线阅读，更多相关《以XML资料驱动为基础之分散式网路（15页珍藏版）》请在金锄头文库上搜索。
1、以XML資料驅動爲基礎之分散式網路3D遊戲引擎架構鄭武堯世新大學資訊管理管理系wychen gcc.shu. edu. t w劉治廷世新大學資訊管理管理系mail.bow:鄭創予世新大學資訊管理管理系createinfinite.tw摘要目前對於大部分3D遊戲引擎的硏究多半著重在圖學、成像技術或是效能這 幾方面，鮮少針對3D遊戲引擎的易用性以及彈性做探討。目前最熱門的遊戲類 型莫過於3D線上遊戲，但3D線上遊戲的開發難度又比單機遊戲複雜的許多， 但對於網路部份的探討更是少。冇鑑於上述問題，本硏究目標爲簡化線上遊戲的 製作。本硏究主耍延續之前硏究之基礎繼續發展，以XML資料驅j(Data-Dri
2、ven) 爲基礎，並搭配3D遊戲引擎及網路部份的元件化。在單機部份，使用者可藉由 XML資料驅動定義3D場景的描述以及事件驅動，降低了 3D遊戲開發的難度； 在網路部份，使用者可藉XML資料驅動方式自行定義網路傳輸機制、頻道的切 割、封包傳遞的格式以及同步的處理，使用者也可自行撰寫程式碼，降低線上遊 戲開發的困難，增加引擎的易用性。而在整體部份，本硏究藉由資料驅動的 獨立性增加本引擎之再用性，並使用統架構，讓單機與線上遊戲使用相同 架構，讓開發者不用花費大量時間針對架構設計。使遊戲開發的門檻降低，並將 更多的精神花費在提升其內容的豐富性。關鍵字：3D遊戲引擎、資料驅動、同步處理、XML壹、引言
3、電腦的發展速度已不如以前那麼地快速，目前大部分電腦硬體對於處理一般 的文書作業已經非常足夠，所以市場轉向對硬體需求量高的新應用，而3D數位 內容成了新應用的主要舞台。3D數位內容大部分都需要強大的硬體效能爲後 盾5例如：線上數位學習(Online e-leaming)。而遊戲當然也是如此 3D線上遊 戲(3D Online Game, OLG)是目前最熱門的3D數位內容之一(MIC, 2005)。也因爲3D線上遊戲是數位內容中最具發展性的應用之一，許多大廠紛紛加 入線上遊戲製作的行列。但3D遊戲的製作比起2D平面遊戲來的困難度增加許 多，因爲3D遊戲有許多複雜的運算以及處理，不易學習，使得整體
4、門檻變高。 爲了降低製作難度，有許多大廠如Id Software、Unreal紛紛推出遊戲引擎，將複 雜的運算以及相關3D處理包覆其中，遊戲開發者只需使用遊戲引擎內部的函式 庫(Library)便可進行開發，口這些遊戲弓摩也授權於其他公司(Balazs, 2001)。雖然使用遊戲引擎雖然比一般從底層製作來的容易，但仍有許多困難存在。 目前市面上的遊戲引擎往往伴隨著昂貴的授權金，一般企業根本無法負擔；且目 前遊戲引擎往往都是使用複雜的API或函式庫，但函式庫的使用對一般程式人員 來說複雜度還是過高，增加了開發困難度。雖有部份引擎使用Script進行資料驅 動降低難度，但Script不易學習、除錯
5、困難、效率不彰口往往與引擎的耦合性過 高，使得這些內容不具備再用性。冇鑑於上述問題，本硏究延續著前人硏究之兩項成果：遊戲引擎架構及網路 簡化架構，提出整合兩者之3D線上遊戲引擎；透過XML資料驅動爲基礎架構， 使用者可藉由資料描述達到3D內容的製作、網路頻道的切割及傳輸封包格式的 設定，降低整體遊戲開發的困難度；並將資料騙動內容與弓I擎獨立，增加再用性。貳、文獻探討因爲本硏究目標爲開發3D線上遊戲引擎架構，所以針對以上目標而探討遊 戲引擎的架構、資料驅動、頻道切割機制等文獻。一、遊戲引擎架構遊戲引擎中主要包含的元件有事件處理(Event Handler) 遊戲規則(Game Logic)及遊戲
6、資料(Game Data)，整體架構圖如圖一所示(Bishop, 1998)。事件處理：主要是接收外來訊息並進行處理，如網路傳遞的訊息、使用者鍵 盤、滑鼠輸入的控制等。遊戲規則：主要是負責接收經過事件處理篩選過後的訊息，依照不同的遊戲 特性及遊戲規則處理，並且更新目前遊戲現有的資料。遊戲資料：其中包含了遊戲中角色的資訊、遊戲中圖形成像的資訊以及遊戲 相關設定的資訊。遊戲引擎不僅包含遊戲主耍的元件，亦包含輸入控制、音效以及圖形的部 份。且遊戲弓I擎捉供的功能應儘可能的與遊戲內容分離，遊戲發展方能更多樣性。圖一 Bishop遊戲引擎架構圖而Andrew(1999)架構分的更爲詳細，其中包括了事件處
7、理、物理引擎、規 則引擎、圖形引擎、音效引擎、選單、設定資訊以及遊戲資料等。且Andrew將 遊戲整體分爲兩大部份，分別爲硬體層及軟體層。硬體部份主要爲輸入、圖形顯 示、音效輸出等。軟體的部份主要分爲事件處理、物理引擎、邏輯引擎、音效引擎、繪圖引擎。Andrew的遊戲引擎架構圖如圖二所示。圖二 Andrew遊戲弓擎架構圖二、資料驅動將資料驅動運用在軟體的應用上已經非常普遍了，透過資料來改變商業軟體 的處理流程，可以增加應用程式的彈性。Michael(2003)提出資料驅動改變處理流 程是對於API以及應用程式影響最小的方式，可在程式執行時期(Run-Time)在決 定軟體的處理流程。Scott
8、 B.(2002)，提出關於資料驅動的一些槪念：爲了達到種需求，物件可使 用多重繼承的方式，但系統的架構會變的更複雜難以維護且失去彈性。所以藉由 資料驅動建立一致性的Skirt元件附加於物件中，可大幅增加系統的一致性以及 彈性。而Jeremy(2003)提出透過資料驅動可提高系統的一致性，如圖三所示。但 必需捉供友善的工具讓使用者進行資料驅動的編嘉。|A|I上 I圖三(A)爲物件繼承方式示意圖；(B)爲元件透過資料驅動的示意圖使用資料驅動在3D遊戲中越來越常見，因爲資料驅動的彈性對於遊戲這類 高度動態的流程具有相當人的助益，可讓遊戲製作時非程式人員可進行遊戲內容 設定。目前市面引擎多半使用Sc
9、ript及資料設定的方式進行資料驅動。例如開發 AOM(Age of Mythology)的Rob(2002)在開發AOM時，使用了 INI檔來設定環境 變數，也用到XML描述場景，利用Script進行遊戲流程及人工智慧的設計。Scott S.(2002)將遊戲分爲兩個部份，分別爲硬體與軟體。硬體部份由程式碼 撰寫及定義；軟體部分使用資料驅動。他建議遊戲整體流程由資料驅動進行，以 元件替代物件繼承，以增加彈性。資料驅動的優點就在於彈性；但缺點在於工具發展時間比較長。且自訂的 Script相容性較差、不易學習、執行效能不佳。資料驅動在學習及建置工具仍有 待改善0三、頻道切割機制學者 Ashwin
10、(2002)、Sergio(2002)、Stefan(2002)基於 Publisher-Subscriber 的 模型來設計線上遊戲的架構 Publisher-Subscriber模型是Consumer-Producer導 向，基礎槪念是所有使用者都可參與發布訊息的平台，接收端解析訊息後即可獲 得資訊。此模型不同於傳統Client-Server的一對一的通訊方式，其重心擺在傳遞 的內容而非參與者，內容產生者並不在乎誰接收訊息；以角色扮演遊戲爲例，其 他玩家移動的訊息,移動者不需要知道訊息傳遞給哪些參與者，使用Client-Server 架構，則每位線上遊戲參與者必須得和伺服器確認此訊息是否需
11、耍接收，將會耗 費大量時間。線上遊戲需要一對多或是多對多的傳輸架構，所以使用 Consumer-Producer模型的資訊散佈較冇優勢(Stenfan, 2002) 但以往純內容導向的傳輸模式缺乏效率，目前解決此問題的方法是利用通訊 空間(Communication Space)的切割讓Consumer接收必須的訊息，切割的區域只 有篩選過的資訊，這些區域稱爲頻道(Chanel)。Producer 其所屬的頻道發布 訊息，而Consumer只接收其所訂閱的頻逍的訊息。此通訊模型架構定義了三個 軟體規則：發布者(Publisher) 訂閱者(Subscriber)以及事件頻道。發布者，專門產生傳
12、遞的事件，依架構設計來描述事件的優先權。訂閱者， 負責接收事件，並且定義接收事件的優先權。事件頻道，主要是接收發布者傳出 的事件及訊息，並將這些事件過濾、轉送給訂閱者，同時還負責服務質量(Quality of Service, Qos)及錯誤管理。每一個頻道可以擁有像是訊息頻率(Message Rate)、Qos Guarantees、訊息優先權(Prioritized Message Transport)或是訊息底限(Message Deadlines) (Kaiser, 1999; Rajkumar, 1995)。在大型線上遊戲中的地圖非常大並且其中有許多的玩家，Stefan(2002)提
13、出 將通訊頻道以六角形切割成小區塊，並讓多台機器運算以提供資源。玩家在某一 地圖進行遊戲時，即是在該地圖所對應的虛擬網路中，而這網路便是玩家需要訂 閱的頻道。玩家所訂閱的虛擬網路包含了兩種類型的頻道，一爲變動較少的環境 頻道(Environment Channel)；二爲經常變動的互動(Interactive Channel)，而玩 家周圍的六角形僅須接收環境頻道的環境資訊。如此，玩家在地圖上移動時只需 要重複訂閱周圍區域的環境以及互動頻道，並取消超出範圍的頻道，請下圖四。environment & interactionen vironment onlyno Ion ger relevant
14、not relevant圖四環境頻道與互動頻道示意圖圖111灰色六角形分爲三種以及白色區域，最深的灰色六角形區域表示玩家必 須訂閱環境頻道以及互動頻道；而111等灰色的六角形區域表示玩家只需訂閱環境 頻道；顏色最淡的灰色表示即將與玩家無關，準備取消訂閱的頻道；而白色的六 角形表示跟玩家無關。參、硏究架構本硏究基本架構是採用前人所硏究之架構(鄭武堯、陳志傑、郭聰儒，2003 ； 鄭武堯、劉仲強，2005)。在原有之硏究部分，前項的硏究成果也是以XML資料 驅動爲主並以Multi-Scene Graph爲架構，但缺乏網路部份；並且在架構上並不 支援遊戲的多場景載入以及共冋資源的控管。而後項原有硏究
15、成果是朝網路互動 架構以及頻道切割機制的簡化爲硏究主軸，但缺乏與前項硏究之整合。本硏究主題便是將兩者整合，並且改變整體架構，本硏究將規則引擎(Rule Engine)整合進流程控制中?並新增了控制整體架構的架構層(Fnimework)且 在架構層中新增共同資源的管理，並將後項原有硏究成果之網路互動架構的簡化 整合進本架構中，架構圖如圖五所示，爲了使整體解釋更爲完整，以下詳述部份 會引用到先前硏究部分的內容：(-)事件驅動(Trigger) 以XML文件中紀錄遊戲物件的控制及場景中受控制的 物件，再透過XML對應至流程控制(Proxy)的動作(Action)，藉此弓廢互動， 流程控制的部份下一點
16、會做進一步的解說。事件驅動的類型冇使用者輸入控 制的相關事件，如鍵盤、滑鼠的事件；時間事件的處理，時間事件應用於逐 漸改變的行爲或狀態，如攝影機走訪場景、光影或特效變化等；碰撞事件的 處理，例如：彳i頭去向玻璃發出聲音，Y i頭物件與坡璃物件發生碰撞事件， 驅動聲音物件A播放聲音。這些事件會依不同的物件類型進行不同的處理。(-)流程控制(Proxy)，於XML中紀錄動作(Action)的運作流程，也就是在事件 驅動時所使用的動作，並且對應至相對的規則函式(Rule Function)，透過巢 狀的流程定義，以透過規則函式不同的回傳値決定運作的流程。規則函式即 爲遊戲規則(即Game Logical、Behavior)。使用者可直接在Proxy.xml編寫 簡
