| 導購 | 订阅 | 在线投稿
分享
 
 
 

基于OGRE所實現的高層遊戲引擎框架(2)

來源:互聯網  2008-05-19 00:44:14  評論

第一部分 遊戲引擎技術簡介

第一部分所需所有圖片

王朝网络

引擎概述

曾經有一段時期,遊戲開發者關心的只是如何盡量多地開發出新的遊戲並把它們推銷給玩家。盡管那時的遊戲大多簡單粗糙,但每款遊戲的平均開發周期也要達到8到10個月以上,這一方面是由于技術的原因,另一方面則是因爲幾乎每款遊戲都要從頭編寫代碼,造成了大量的重複勞動。漸漸地,一些有經驗的開發者摸索出了一條偷懶的方法,他們借用上一款類似題材的遊戲中的部分代碼作爲新遊戲的基本框架,以節省開發時間和開發費用。于是就慢慢産生了遊戲引擎。人對于遊戲引擎的概念是逐步深入理解的,這個過程類似于其他技術的進步過程――畢竟遊戲引擎也是一個程序。這個理解所立足的就是對「封裝性」的理解。實際上在引擎這個概念下面更多的是每個人對引擎各自不同的理解:遊戲引擎只是一個說法,至今爲止沒有一個公認的定義。

近幾年一部分初學者所理解的引擎是「對底層功能的簡單封裝」,這個底層功能包括平台API、渲染API、音頻API、流媒體API等,這樣的引擎往往是一種C語言時代的思路,其劃分是來自于各個不同部分之間的「功能」關系,而非「邏輯」關系。經典概念包括:渲染核心、內存管理、骨骼動畫、幀動畫、文件操作、物理庫、網絡庫等等。這個在廣爲傳誦的網文《遊戲引擎剖析》(參考4)裏面有最爲明確的體系劃分:

1、「渲染和構造3D世界,3D環境的光照和紋理」。渲染永遠是引擎最具有技術含量的部分,就不說那動辄千百塊錢的圖形卡了,單是圖形渲染相關技術的進步速率,就已經足以讓人瞠目結舌了。「什麽是渲染器,爲什麽它又這麽重要呢?好吧,如果沒有它,你將什麽也看不到。它讓遊戲場景可視化,讓玩家/觀衆可以看見場景,從而讓玩家能夠根據屏幕上所看到的東西作出適當的決斷。」渲染所需的主要底層功能就是來支持OpenGL和DirectX的最新技術。由于這些技術不斷更改,導致渲染器的更新換代也相當明顯。好在OGRE本身就是一個很巧妙的渲染器,它爲我們隱藏了很多渲染器的複雜性,讓我們可以用近乎自然語言的方式來進行圖形處理。

2、「內存使用,特效和API」。圖形研究到高層次就不得不考慮到芯片的一些特性:例如顯存和內存管理、Shader和其它重要的參數。這也是屬于引擎必須染指的內容。

3、「模型與動畫,細節級別LOD」。遊戲引擎應該支持常見的模型文件格式並很好地渲染他們,如果遊戲引擎需要用到自己的數據格式,那麽它需要爲幾個主要的模型文件格式做導出插件,以滿足美工的需要。

4、「物理,運動,效果」。物理系統可以讓遊戲盡可能地逼真。「作爲遊戲開發者來說,無論我們做什麽,我們需要能夠檢測牆壁,檢測地板,在世界中處理和其他對象的碰撞。這些是現代遊戲引擎的必備。」先進的物理系統如ODE,可以在保證效率的前提下精確處理物理和運動學理論和公式,其中甚至包括流體力學。

5、「聲音系統,音頻APIs」。耳朵也是人的一個重要的感覺和信息獲得器官,這一點應該很好理解。

6、「網絡和連線遊戲環境」。網絡遊戲必備。如今大多數真正有長久生命力的遊戲都至少有一些連線成分。「最純粹的單人遊戲容易玩一次,也許兩次,或者甚至三次如果它是非常好的遊戲,但一旦遊戲結束,就被束之高閣了。如果你想要有任何長久生命力,那麽多人連線遊戲就是形勢的核心所在。」

7、「腳本系統」。你可以把遊戲腳本認爲是電影腳本,它們兩者實質上是相同的。

8、「人工智能和導航」。

當按照這個思路建立了自己的引擎後,我們的引擎只是一個功能引擎,它沒有任何邏輯關系。包括場景、地圖、物件、規則等一系列遊戲邏輯所直接相關的東西,它都沒法直接提供。這個時候我們所具有的引擎大約是如同下圖所示:

圖1-1 基本的的底層引擎核心結構

一種可怕的平鋪性的結構,互相之間沒有關聯或很少關聯。也就是說,它基本什麽邏輯都沒有實現,每一個遊戲你可以重用這些底層功能,除此之外,你需要重新寫所有邏輯,即便兩個遊戲在基本邏輯上基本相同。國外的遊戲引擎已經可以讓你脫離代碼,只用腳本和編輯器就可以做遊戲了(這種開發手段叫做MOD),這種簡單的平鋪結構,沒有縱深,根本無法架起這樣一棟充斥了邏輯的大樓!

高層引擎概述

我們拿2D地圖來做一個例子,在這樣的引擎思路下,地圖只是諸多圖元的拼接、Blt(發音Blit,位圖位塊傳輸)和互相遮擋。這個思路確實反映出來了地圖的本質,但是對于遊戲邏輯來說,它太細了。因爲遊戲邏輯是不需要管你地圖圖元如何拼接、Blt和遮擋的。下圖左就是針對這種設計思路的,而下圖右則是提供了高層引擎的設計思路。通過對比可以發現,右邊的設計思路更符合OO的封裝原則,而左邊的主要是比較古老的過程式填鴨。

圖1-2 左邊是直接在應用程序裏硬編碼底層功能,右邊是在應用程序和底層引擎之間建立一個抽象層,有這個抽象層劃分和承擔遊戲的基本邏輯。在OO大行其道的今天,你會用哪一種方法?

而在這裏我們理解的引擎除了功能元素之外,同時包括一些邏輯意義的部分,即部分開發者交流中所說的「遊戲層引擎」或「高層引擎」,爲何會存在這部分引擎呢?答案是爲了方便我們表達遊戲的上層邏輯。底層遊戲引擎所立足的都是平台API,是與API嚴格相關的。目的就是爲了要讓外界看不見API,專心做外界的邏輯部分,但底層引擎只完成了一個目的就是通過封裝API來完成一定功能,封裝好的API是否就表明一定適應上層邏輯的要求呢?這根本不可能,因爲它不是爲了這個目的而存在的,例如骨骼動畫和上層邏輯有什麽關系呢?因此人們又提出了高層引擎的概念。這就回答了剛剛的問題,骨骼動畫是應當包含在物件邏輯內部實現的,對外部應該是透明的。如果遊戲邏輯需要細化到「誰誰誰,按照骨骼動作『Walk2』來行走」,那就太麻煩了,這種情況下,比較普遍的做法是我們由來實現一個物件,然後爲其設置一種狀態叫做STATE_WALK2,在物件自己的邏輯裏面當發現物件是處于這種狀態的時候就開始引發「Walk2」動作,這樣,最後的遊戲邏輯只用簡化到說「那個誰,向前方走一步」就可以了。實際的處理是,引擎層獲取到了這個消息以後,向物件「誰」發送一個TranslateState(「走」)的消息,而物件「誰」獲得這個消息後,根據當前狀態自動進行狀態機的切換。對于邏輯的開發者來說,這一切都是封裝好的,透明的,他們只需要知道「當我說『A向前走』,A就會向前走」就可以了,這樣的引擎就不再簡簡單單是功能平鋪的平房,而是具有一定邏輯保障的大廈了。STATE_WALK2到Walk2的對應關系在不同遊戲引擎裏面可以通過不同方式實現,最初也是最簡單的方法是硬編碼(Hard-Code),這種方法速度快,然而犧牲了程序的維護性,會給測試帶來很大麻煩。現在,大部分的遊戲引擎可以通過配置文件甚至是編輯器來解決此問題,以及與此類似的問題,這種數據驅動的方式使編碼邏輯更加簡單,同時也使設計者和導演工作更加方便。

下圖是我們使用一款外國引擎的編輯器時的場面,在這個編輯器裏面,既有物件編輯器,也有場景編輯器,同時也包括腳本――這個編輯器裏用它來實現我們所說的規則――的編輯器:

圖1-4 看著很像3DMax的一款遊戲編輯器,中國目前大部分遊戲

工作室還沒有自己的實力開發這種高度集成的編輯器

把話題引回來,對比前面我們得出的結論,做一個遊戲,實際上就是在做場景(地圖+物件)、規則系統、GUI系統和I/O控制系統。那麽我們該怎麽做呢?構建一個過于集中的,把所有功能都實現了的高層系統,只會降低高層引擎的可適應性,因此屬于高層引擎更多的是對它們提供支持,這些支持包括:基本數據結構和組織方式(例如物件鏈表及查詢操作、特殊的文件數據)、工具集等。通過這一層的存在,最高層邏輯只需要寫:在場景中放置幾只飛鳥,按照Sin函數路線飛行。至于飛鳥飛行中是怎麽振翅,怎麽偏航,這是在物件系統的具體物件類――這裏是飛鳥――裏可以決定的。爲了最終産品的邏輯需要,我們迫不及待的需要一個「高層遊戲引擎」,這是源自于一個很重要的思想,同時也是軟件工程的基礎思想:「軟件産生于需求」。底層引擎層次的劃分完全來自于平台和API的限制,因爲畢竟我們要做的遊戲必須跟某一個平台相關。而高層次的引擎結構則是跟需要達到的目的嚴格相關的,因爲這是它的存在動機。

實際上現在大部分引擎都是或多或少地包括了高層引擎部分的,然而高層引擎的劃分卻並不容易,大部分引擎所面向的還是FPS這種遊戲類型,做一款普遍適應的引擎是難上加難,因爲不同遊戲所需要的高層不一樣。

我們這篇文章的基本目的,就是試驗當擁有一個現有的底層引擎的時候,如何構建一個高層引擎,以及如何讓這個高層引擎具有更強的適應性。

現在我們具有的引擎構造大抵如下:

王朝网络

圖1-4 按照現在的劃分誕生的高層引擎層的基本框架

第二部分 OGRE圖形引擎的基本構成

第二部分所需所有圖片

王朝网络

OGRE(Object-oriented Graphics Rendering Engine,面向對象的圖形渲染引擎),是國際上比較知名的開源圖形渲染引擎。OGRE是用C++開發的面向對象且使用靈活的3D引擎。它的目的是讓開發者能更方便和直接地開發基于3D硬件設備的應用程序或遊戲。引擎中的類庫對更底層的系統庫(如:Direct3D和OpenGL)的全部使用細節進行了抽象,並提供了基于現實世界對象的接口和其它類。

OGRE系統主要包括:Render系統和Render插件、Material系統和M

  第一部分 遊戲引擎技術簡介   第一部分所需所有圖片   [url=/bbs/detail_1440298.html][img]http://images.wangchao.net.cn/images/upload/images/lsdn/1211129052211.jpg[/img][/url]   引擎概述   曾經有一段時期,遊戲開發者關心的只是如何盡量多地開發出新的遊戲並把它們推銷給玩家。盡管那時的遊戲大多簡單粗糙,但每款遊戲的平均開發周期也要達到8到10個月以上,這一方面是由于技術的原因,另一方面則是因爲幾乎每款遊戲都要從頭編寫代碼,造成了大量的重複勞動。漸漸地,一些有經驗的開發者摸索出了一條偷懶的方法,他們借用上一款類似題材的遊戲中的部分代碼作爲新遊戲的基本框架,以節省開發時間和開發費用。于是就慢慢産生了遊戲引擎。人對于遊戲引擎的概念是逐步深入理解的,這個過程類似于其他技術的進步過程――畢竟遊戲引擎也是一個程序。這個理解所立足的就是對「封裝性」的理解。實際上在引擎這個概念下面更多的是每個人對引擎各自不同的理解:遊戲引擎只是一個說法,至今爲止沒有一個公認的定義。   近幾年一部分初學者所理解的引擎是「對底層功能的簡單封裝」,這個底層功能包括平台API、渲染API、音頻API、流媒體API等,這樣的引擎往往是一種C語言時代的思路,其劃分是來自于各個不同部分之間的「功能」關系,而非「邏輯」關系。經典概念包括:渲染核心、內存管理、骨骼動畫、幀動畫、文件操作、物理庫、網絡庫等等。這個在廣爲傳誦的網文《遊戲引擎剖析》(參考4)裏面有最爲明確的體系劃分:   1、「渲染和構造3D世界,3D環境的光照和紋理」。渲染永遠是引擎最具有技術含量的部分,就不說那動辄千百塊錢的圖形卡了,單是圖形渲染相關技術的進步速率,就已經足以讓人瞠目結舌了。「什麽是渲染器,爲什麽它又這麽重要呢?好吧,如果沒有它,你將什麽也看不到。它讓遊戲場景可視化,讓玩家/觀衆可以看見場景,從而讓玩家能夠根據屏幕上所看到的東西作出適當的決斷。」渲染所需的主要底層功能就是來支持OpenGL和DirectX的最新技術。由于這些技術不斷更改,導致渲染器的更新換代也相當明顯。好在OGRE本身就是一個很巧妙的渲染器,它爲我們隱藏了很多渲染器的複雜性,讓我們可以用近乎自然語言的方式來進行圖形處理。   2、「內存使用,特效和API」。圖形研究到高層次就不得不考慮到芯片的一些特性:例如顯存和內存管理、Shader和其它重要的參數。這也是屬于引擎必須染指的內容。   3、「模型與動畫,細節級別LOD」。遊戲引擎應該支持常見的模型文件格式並很好地渲染他們,如果遊戲引擎需要用到自己的數據格式,那麽它需要爲幾個主要的模型文件格式做導出插件,以滿足美工的需要。   4、「物理,運動,效果」。物理系統可以讓遊戲盡可能地逼真。「作爲遊戲開發者來說,無論我們做什麽,我們需要能夠檢測牆壁,檢測地板,在世界中處理和其他對象的碰撞。這些是現代遊戲引擎的必備。」先進的物理系統如ODE,可以在保證效率的前提下精確處理物理和運動學理論和公式,其中甚至包括流體力學。   5、「聲音系統,音頻APIs」。耳朵也是人的一個重要的感覺和信息獲得器官,這一點應該很好理解。   6、「網絡和連線遊戲環境」。網絡遊戲必備。如今大多數真正有長久生命力的遊戲都至少有一些連線成分。「最純粹的單人遊戲容易玩一次,也許兩次,或者甚至三次如果它是非常好的遊戲,但一旦遊戲結束,就被束之高閣了。如果你想要有任何長久生命力,那麽多人連線遊戲就是形勢的核心所在。」   7、「腳本系統」。你可以把遊戲腳本認爲是電影腳本,它們兩者實質上是相同的。   8、「人工智能和導航」。   當按照這個思路建立了自己的引擎後,我們的引擎只是一個功能引擎,它沒有任何邏輯關系。包括場景、地圖、物件、規則等一系列遊戲邏輯所直接相關的東西,它都沒法直接提供。這個時候我們所具有的引擎大約是如同下圖所示:   圖1-1 基本的的底層引擎核心結構   一種可怕的平鋪性的結構,互相之間沒有關聯或很少關聯。也就是說,它基本什麽邏輯都沒有實現,每一個遊戲你可以重用這些底層功能,除此之外,你需要重新寫所有邏輯,即便兩個遊戲在基本邏輯上基本相同。國外的遊戲引擎已經可以讓你脫離代碼,只用腳本和編輯器就可以做遊戲了(這種開發手段叫做MOD),這種簡單的平鋪結構,沒有縱深,根本無法架起這樣一棟充斥了邏輯的大樓!   高層引擎概述   我們拿2D地圖來做一個例子,在這樣的引擎思路下,地圖只是諸多圖元的拼接、Blt(發音Blit,位圖位塊傳輸)和互相遮擋。這個思路確實反映出來了地圖的本質,但是對于遊戲邏輯來說,它太細了。因爲遊戲邏輯是不需要管你地圖圖元如何拼接、Blt和遮擋的。下圖左就是針對這種設計思路的,而下圖右則是提供了高層引擎的設計思路。通過對比可以發現,右邊的設計思路更符合OO的封裝原則,而左邊的主要是比較古老的過程式填鴨。   圖1-2 左邊是直接在應用程序裏硬編碼底層功能,右邊是在應用程序和底層引擎之間建立一個抽象層,有這個抽象層劃分和承擔遊戲的基本邏輯。在OO大行其道的今天,你會用哪一種方法?   而在這裏我們理解的引擎除了功能元素之外,同時包括一些邏輯意義的部分,即部分開發者交流中所說的「遊戲層引擎」或「高層引擎」,爲何會存在這部分引擎呢?答案是爲了方便我們表達遊戲的上層邏輯。底層遊戲引擎所立足的都是平台API,是與API嚴格相關的。目的就是爲了要讓外界看不見API,專心做外界的邏輯部分,但底層引擎只完成了一個目的就是通過封裝API來完成一定功能,封裝好的API是否就表明一定適應上層邏輯的要求呢?這根本不可能,因爲它不是爲了這個目的而存在的,例如骨骼動畫和上層邏輯有什麽關系呢?因此人們又提出了高層引擎的概念。這就回答了剛剛的問題,骨骼動畫是應當包含在物件邏輯內部實現的,對外部應該是透明的。如果遊戲邏輯需要細化到「誰誰誰,按照骨骼動作『Walk2』來行走」,那就太麻煩了,這種情況下,比較普遍的做法是我們由來實現一個物件,然後爲其設置一種狀態叫做STATE_WALK2,在物件自己的邏輯裏面當發現物件是處于這種狀態的時候就開始引發「Walk2」動作,這樣,最後的遊戲邏輯只用簡化到說「那個誰,向前方走一步」就可以了。實際的處理是,引擎層獲取到了這個消息以後,向物件「誰」發送一個TranslateState(「走」)的消息,而物件「誰」獲得這個消息後,根據當前狀態自動進行狀態機的切換。對于邏輯的開發者來說,這一切都是封裝好的,透明的,他們只需要知道「當我說『A向前走』,A就會向前走」就可以了,這樣的引擎就不再簡簡單單是功能平鋪的平房,而是具有一定邏輯保障的大廈了。STATE_WALK2到Walk2的對應關系在不同遊戲引擎裏面可以通過不同方式實現,最初也是最簡單的方法是硬編碼(Hard-Code),這種方法速度快,然而犧牲了程序的維護性,會給測試帶來很大麻煩。現在,大部分的遊戲引擎可以通過配置文件甚至是編輯器來解決此問題,以及與此類似的問題,這種數據驅動的方式使編碼邏輯更加簡單,同時也使設計者和導演工作更加方便。   下圖是我們使用一款外國引擎的編輯器時的場面,在這個編輯器裏面,既有物件編輯器,也有場景編輯器,同時也包括腳本――這個編輯器裏用它來實現我們所說的規則――的編輯器:   圖1-4 看著很像3DMax的一款遊戲編輯器,中國目前大部分遊戲   工作室還沒有自己的實力開發這種高度集成的編輯器   把話題引回來,對比前面我們得出的結論,做一個遊戲,實際上就是在做場景(地圖+物件)、規則系統、GUI系統和I/O控制系統。那麽我們該怎麽做呢?構建一個過于集中的,把所有功能都實現了的高層系統,只會降低高層引擎的可適應性,因此屬于高層引擎更多的是對它們提供支持,這些支持包括:基本數據結構和組織方式(例如物件鏈表及查詢操作、特殊的文件數據)、工具集等。通過這一層的存在,最高層邏輯只需要寫:在場景中放置幾只飛鳥,按照Sin函數路線飛行。至于飛鳥飛行中是怎麽振翅,怎麽偏航,這是在物件系統的具體物件類――這裏是飛鳥――裏可以決定的。爲了最終産品的邏輯需要,我們迫不及待的需要一個「高層遊戲引擎」,這是源自于一個很重要的思想,同時也是軟件工程的基礎思想:「軟件産生于需求」。底層引擎層次的劃分完全來自于平台和API的限制,因爲畢竟我們要做的遊戲必須跟某一個平台相關。而高層次的引擎結構則是跟需要達到的目的嚴格相關的,因爲這是它的存在動機。   實際上現在大部分引擎都是或多或少地包括了高層引擎部分的,然而高層引擎的劃分卻並不容易,大部分引擎所面向的還是FPS這種遊戲類型,做一款普遍適應的引擎是難上加難,因爲不同遊戲所需要的高層不一樣。   我們這篇文章的基本目的,就是試驗當擁有一個現有的底層引擎的時候,如何構建一個高層引擎,以及如何讓這個高層引擎具有更強的適應性。   現在我們具有的引擎構造大抵如下:   [url=/bbs/detail_1440298.html][img]http://images.wangchao.net.cn/images/upload/images/lsdn/1211129053914.jpg[/img][/url]   圖1-4 按照現在的劃分誕生的高層引擎層的基本框架   第二部分 OGRE圖形引擎的基本構成   第二部分所需所有圖片   [url=/bbs/detail_1440298.html][img]http://images.wangchao.net.cn/images/upload/images/lsdn/1211129054227.jpg[/img][/url]   OGRE(Object-oriented Graphics Rendering Engine,面向對象的圖形渲染引擎),是國際上比較知名的開源圖形渲染引擎。OGRE是用C++開發的面向對象且使用靈活的3D引擎。它的目的是讓開發者能更方便和直接地開發基于3D硬件設備的應用程序或遊戲。引擎中的類庫對更底層的系統庫(如:Direct3D和OpenGL)的全部使用細節進行了抽象,並提供了基于現實世界對象的接口和其它類。   OGRE系統主要包括:Render系統和Render插件、Material系統和M
󰈣󰈤
王朝萬家燈火計劃
期待原創作者加盟
 
 
 
>>返回首頁<<
 
 
 
 
 熱帖排行
 
 
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有