站在巨人的肩膀上開發遊戲 1 -- orx 庫簡單介紹
分享一下我老師大神的人工智慧教程!零基礎,通俗易懂!http://blog.csdn.net/jiangjunshow
也歡迎大家轉載本篇文章。分享知識,造福人民,實現我們中華民族偉大復興!
write by 九天雁翎(JTianLing) -- blog.csdn.net/vagrxie
為什麼我們要從現成的遊戲引擎學習開始
很多人問過我類似的問題,學習程式該從什麼入手?怎麼樣開始編寫一個遊戲?實際上的遊戲開發都是從OpenGL開始的嗎?學了OpenGL後怎麼開始做遊戲?
這些問題可能很難有什麼標準答案,不過個人認為,在學習一門程式語言後,開始真正的做一些東西是很重要的,並且,這些東西要上一定的規模,那種玩具式的開發雖然也能學到一些東西,但是因為其過於簡單,會掩蓋很多隨著規模變大而碰到的問題,這樣也就會讓你無法獲得真實開發中獲得的經驗及教訓。經驗,那是作為一個程式設計師最為寶貴的財富。
遊戲的開發,很少有公司/個人會真的從零開始開發,得益於開源運動的努力,現在已經有很多開源的遊戲引擎可以使用,從3D中最為著名的OGRE,irrlicht,2D的HGE。都是其中的佼佼者,從這些引擎的基礎上開始自己的工作,會讓你事半功倍,就像站在巨人的肩膀上,能看的更高,更遠,更加專注於自己關心的遊戲邏輯模組。誠然,假如需要真的對一款遊戲引擎瞭解透徹,並掌握自己開發遊戲引擎的技術,從零開發的經驗是很重要的,但是對於大多數人來講,即使是學習,先採取從上之下的學習方式,(即先學會使用一款引擎,然後再深入瞭解這個引擎的原理)也會輕鬆愉快很多。有了一定的對引擎的經驗後,再去嘗試開發自己的引擎,那會使你受益匪淺。假如一開始就做太大規模的嘗試,很可能使得你有太強的挫敗感,畢竟,這是遊戲編寫最難的部分,人都是需要先學會走路然後才學會跑的。
另外,我選擇從2D引擎Orx開始,也是出於這樣的考慮,雖然事實上,也許我對Irrlicht的使用經驗比對orx的使用經驗還要多。
Orx介紹(http://orx-project.org/)
Orx的LOGO,有點像我們常提及的orz。。。。。
Orx不是世界上最優秀的2D遊戲引擎,也不是最流行的一個,事實上,Orx還有太多不成熟的地方,我也常常對這些地方感覺非常鬱悶,由於Orx的小知名度,所以周邊的模組開發,文件等也非常少,這樣極大的限制了其傳播,並且極大的限制了其發展。
但是,我還是很喜歡Orx,因為它很有特點。
Orx以配置為基礎
以配置為基礎,所以使得Orx非常的靈活,可以進行快速的開發,快速的實驗,快速的調整,並且因為配置檔案模組寫的比較強大,你也很容易新增進自己的配置,這點我非常喜歡,我一直很喜歡一句話,lua之父說:只有當配置的使用足夠的簡單,人們才會樂於使用它。雖然此話是針對lua的,但是對於任何配置的使用都適用,Orx就有這樣的特質。這也是Orx最大的特點。
雖然在初期,對於太多配置的理解會比對於一些程式碼的理解更加困難,但是掌握後的好處是無窮無盡的。
Orx是跨平臺的
目前Orx直接支援的平臺包含了所有流行的平臺,包括了Windows,MacOS,Linux,還有IPhone,IPad。事實上,我當年就是在尋找一個合適的跨平臺IPhone引擎時發現Orx的。(我前段時間的工作就是在IPhone平臺上,所以比較關注)當然,即使對於IPhone平臺來說,最優秀的2D引擎毋庸置疑的是Cocos2D for Iphone,Cocos2D for Iphone是我見過的支援特性最多的2D引擎,不僅僅針對IPhone平臺,在所有的開源2D引擎中,它支援的特性都是堪稱最多的,得益於IPhone開發的熱門,其周邊的工具也是非常的豐富,實際建立在Cocos2D for Iphone引擎上的遊戲也是數以十計。但是,Cocos2D for IPhone是僅限Iphone平臺的,並且使用的是Objective C語言開發。這是它的強項,也是其弱項。我希望有個跨平臺的引擎,這樣才能看到更多,並且易於協作,(在公司也是這樣)在Windows下開發,然後在其他平臺執行,這是很重要的,別的不說,就說Macos獨霸的XCode,根本沒有辦法與在Windows下經歷過多次殘酷競爭並且勝出的Visual studio相比,再加上Visual assist和ViEmu兩個外掛,VS絕對是夢幻級的平臺!
並且,雖然我也可以使用Objective C來開發,但是我更加熟悉的還是C++,所以我希望使用C++來開發,這樣對於我來說,效率會更加高。
跨平臺,對於很多隻關注Windows平臺的人來說是完全不考慮的,但是,其實,優勢有太多太多。
Orx的協議非常自由
在外企的工作經驗使我對協議非常敏感,不再像在國內企業時那樣,只要是世界上最強大的,拿來就用,Orx的新版本(1.2)會使用Zlib協議,這是一個非常非常自由的協議,支援進行商業閉源的開發,並且也完全可以對Orx進行任何的閉源的修改。
Orx支援的特性比較多
Orx不是最強大的,但是支援的特性已經足夠多了,可以很方便的做一些簡單的遊戲,其內嵌物理引擎Box2D,內嵌聲音引擎,有很多有用的圖形特效,比如縮放,翻轉,移動,alpha值變化等,事實也提供了對addcolor和普通透明混合效果的支援。
Orx使用較為簡單
Orx的使用很簡單,不僅僅其以配置為基礎(事實上我感覺這點在初期還比較麻煩),Orx的作者對Orx的定位是一款完整的遊戲引擎,而不僅僅是一個圖形引擎,在Orx中所有的東西都抽象成了Object,擁有統一的介面,並且可以方便的通過配置/程式碼來更改屬性及效果。並且最最重要的是,Orx對於物理引擎的支援不是簡單的外掛(如Cocos2D for Iphone),而是內嵌,直接將Box2D與其Object繫結在一起,可以直接通過配置的設定,不用知道任何Box2D的東西,就能直接使用物理引擎。當然,事實上,知道其相關的物理概念還是很重要的,不然怎麼知道配置什麼啊?但是起碼可以不使用任何Box2D的API。(目前僅提供一些基礎的支援,不支援Joint這樣稍微複雜一點的特性)目前個人使用感覺是,用Orx做物理相關的東西,那是非常的簡單。但是,由於Orx對於圖形動畫的支援較弱,而且也沒有一款動畫編輯器支援,所以用來做複雜的動畫(其實即使是簡單的動畫)會比較麻煩,需要非常多的手動配置。我正考慮為Orx做一款以Json為基礎的動畫編輯器以簡化此過程。
Orx的開發者有豐富的經驗,並且極為熱心
我在Orx的論壇上,以及私下與Orx的開發者(目前Orx核心主要由iarwain開發)有很多的交流,他有著15年以上的程式編寫經驗,10年以上的遊戲開發經驗,並且一直是從事底層開發,現在任職於Ubisoft的加拿大蒙特利爾工作室,他的工作經驗,使得Orx有著堅實的基礎,良好的架構,特別值得一提的是其編碼風格,註釋詳盡到幾乎每行都有,我曾經詢問過這個問題,因為通常來講,推薦的註釋的作用為解釋程式碼的執行原理和作用(即Why?How?),而不是具體幹了什麼(what),但是他認為,整個程式碼他就是分為兩部分,一部分為邏輯,一部分為實現,邏輯由註釋描述,實現由程式碼描述,方便他在不看程式碼的情況下就能方便的瞭解邏輯,進行全面的瞭解或者深入的除錯。並且其提出,在他那裡,有很多程式設計經驗豐富的人嘗試用這種風格來編碼,從來沒有人說這種風格不好的,最後都堅持使用了這種風格。當然,這僅是一家之言,他的個人看法,但是對比現在我工作中的幾乎沒有註釋的程式碼,我還是感慨良多。
他經驗豐富,最難得的是他非常熱心,在論壇中,他知無不答,答無不盡,糾正了很多我對遊戲開發的一些不對看法,也解釋了很多Orx的設計,執行原理和思想,我受益良多。在私下的用steam的交流中,他也是給了我很多提示和解答,對我的幫助非常多。
最後
推薦有興趣的人都去其網站看看,並瞭解瞭解,希望你也能像我一樣喜歡上Orx,網址是http://orx-project.org/,在WIKI上有兩個教程,講的還算比較詳細,但是也有很多我認為遺漏的地方,API Doc得益於iarwain的詳盡註釋風格,非常詳細。事實上,我準備按照我的學習經驗,自己組織一系列關於Orx的教程,並且,以開發一款完整的遊戲為脈絡,而不是以特性介紹為原則。會以Windows為平時的開發平臺。
-----------------------------------------------------------------------------------------------------------------------------
關於極端詳細的註釋風格,我問過iarwain,這樣的風格豈不是很影響開發效率?畢竟寫程式碼時寫那麼詳盡的註釋總是個負擔,但是他說他和他的朋友們都說從來沒有這樣的感覺,註釋總是讓他們在除錯時,在過了很久再回頭來看時,可以忽略很多程式碼,而直達問題的關鍵。後來,我想了想,也許和他的工作內容有關吧,他常常進行的是底層的開發工作(如他所言,low-level),所以可能相對來說程式碼量比較小,改動也比較小的,更多的時間是用於思考,而不是敲程式碼,而且,因為穩定,有可能需要回頭看用過了很久的程式碼,所以這樣的註釋風格才適合他吧。呵呵,對於我這樣的coder,常常敲無厘頭,沒難度,不用思考的邏輯程式碼,最多一週幾千行C++程式碼的工作量,要是按那個規模註釋,估計很難達到老闆要求的速度了。
-----------------------------------------------------------------------------------------------------------------------------
這裡貼一段iarwain自己的話來解釋一下LuckilyYu 的問題,以及iarwain自己對Orx的目標,也同時作為一個額外的參考材料。其實並不是所有的引擎都只關心圖形顯示的。
其中Irrlicht作者將其歸入Game Engines一類,個人對其有所瞭解,感覺應該在High level game libraries。其他還是比較贊同。
usually see 4 different kinds of game creation tools:
* Low level game libraries: Allegro, SDL, ClanLib, ...
* High level game libraries: IndieLib, Cocos2D, STK, ...
* Game engines: they're usually 3D ones: Panda3D, Irrlicht, Delta3D, ...
* Fully integrated game engines: Construct, Unreal, Unity, GameMaker, ...
I think orx is (or trying to be) part of the third list. You don't manage sprites, sound resources etc, in orx, you just have objects with properties and rules in a 3D world.
What it means in the end is that, as you said, there's a higher level of abstraction which usually leads to less low level control.
As everything is public in orx, and due to the plugin architecture, you could take control of the low level parts, even rendering if you needed 3D support.
Of course, it's not the philosophy of the engine and I'm trying hard to make things so that you wouldn't feel the need too much to do so.
Orx is the way it is because I don't like having to initialize in code a whole bunch of things and write 10 lines everytime I want to add a new sprite with a visual effect.
I'd rather just change some parameters in config and restart the program without changing a line of code, or even just reload the config file on-the-fly depending on the cases.
Of course, nothing's perfect and this aim isn't totally reached, but that's my current goal: having the least amount of code to write as possible.
原創文章作者保留版權 轉載請註明原作者 並給出連結
write by 九天雁翎(JTianLing) -- blog.csdn.net/vagrxie