《以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編寫 簡