write by 九天雁翎(JTianLing) -- blog.csdn.net/vagrxie

討論新聞組及文件

為什么我們要從現(xiàn)成的游戲引擎學習開始

很多人問過我類似的問題，學習程序該從什么入手？怎么樣開始編寫一個游戲？實際上的游戲開發(fā)都是從OpenGL開始的嗎？學了OpenGL后怎么開始做游戲？
這些問題可能很難有什么標準答案，不過個人認為，在學習一門編程語言后，開始真正的做一些東西是很重要的，并且，這些東西要上一定的規(guī)模，那種玩具式的開發(fā)雖然也能學到一些東西，但是因為其過于簡單，會掩蓋很多隨著規(guī)模變大而碰到的問題，這樣也就會讓你無法獲得真實開發(fā)中獲得的經驗及教訓。經驗，那是作為一個程序員最為寶貴的財富。
游戲的開發(fā)，很少有公司/個人會真的從零開始開發(fā)，得益于開源運動的努力，現(xiàn)在已經有很多開源的游戲引擎可以使用，從3D中最為著名的OGRE，irrlicht，2D的HGE。都是其中的佼佼者，從這些引擎的基礎上開始自己的工作，會讓你事半功倍，就像站在巨人的肩膀上，能看的更高，更遠，更加專注于自己關心的游戲邏輯模塊。誠然，假如需要真的對一款游戲引擎了解透徹，并掌握自己開發(fā)游戲引擎的技術，從零開發(fā)的經驗是很重要的，但是對于大多數(shù)人來講，即使是學習，先采取從上之下的學習方式，（即先學會使用一款引擎，然后再深入了解這個引擎的原理）也會輕松愉快很多。有了一定的對引擎的經驗后，再去嘗試開發(fā)自己的引擎，那會使你受益匪淺。假如一開始就做太大規(guī)模的嘗試，很可能使得你有太強的挫敗感，畢竟，這是游戲編寫最難的部分，人都是需要先學會走路然后才學會跑的。
另外，我選擇從2D引擎Orx開始，也是出于這樣的考慮，雖然事實上，也許我對Irrlicht的使用經驗比對orx的使用經驗還要多。

Orx介紹（http://orx-project.org/）

Orx的LOGO，有點像我們常提及的orz。。。。。

Orx不是世界上最優(yōu)秀的2D游戲引擎，也不是最流行的一個，事實上,Orx還有太多不成熟的地方，我也常常對這些地方感覺非常郁悶，由于Orx的小知名度，所以周邊的模塊開發(fā)，文檔等也非常少，這樣極大的限制了其傳播，并且極大的限制了其發(fā)展。
但是，我還是很喜歡Orx,因為它很有特點。

Orx以配置為基礎

以配置為基礎，所以使得Orx非常的靈活，可以進行快速的開發(fā)，快速的實驗，快速的調整，并且因為配置文件模塊寫的比較強大，你也很容易添加進自己的配置，這點我非常喜歡，我一直很喜歡一句話，lua之父說：只有當配置的使用足夠的簡單，人們才會樂于使用它。雖然此話是針對lua的，但是對于任何配置的使用都適用，Orx就有這樣的特質。這也是Orx最大的特點。
雖然在初期，對于太多配置的理解會比對于一些代碼的理解更加困難，但是掌握后的好處是無窮無盡的。

Orx是跨平臺的

目前Orx直接支持的平臺包含了所有流行的平臺，包括了Windows,MacOS,Linux，還有IPhone,IPad。事實上，我當年就是在尋找一個合適的跨平臺IPhone引擎時發(fā)現(xiàn)Orx的。（我前段時間的工作就是在IPhone平臺上，所以比較關注）當然，即使對于IPhone平臺來說，最優(yōu)秀的2D引擎毋庸置疑的是Cocos2D for Iphone，Cocos2D for Iphone是我見過的支持特性最多的2D引擎，不僅僅針對IPhone平臺，在所有的開源2D引擎中，它支持的特性都是堪稱最多的，得益于IPhone開發(fā)的熱門，其周邊的工具也是非常的豐富，實際建立在Cocos2D for Iphone引擎上的游戲也是數(shù)以十計。但是，Cocos2D for IPhone是僅限Iphone平臺的，并且使用的是Objective C語言開發(fā)。這是它的強項，也是其弱項。我希望有個跨平臺的引擎，這樣才能看到更多，并且易于協(xié)作，（在公司也是這樣）在Windows下開發(fā)，然后在其他平臺運行，這是很重要的，別的不說，就說Macos獨霸的XCode，根本沒有辦法與在Windows下經歷過多次殘酷競爭并且勝出的Visual studio相比，再加上Visual assist和ViEmu兩個插件，VS絕對是夢幻級的平臺！
并且，雖然我也可以使用Objective C來開發(fā)，但是我更加熟悉的還是C++，所以我希望使用C++來開發(fā)，這樣對于我來說，效率會更加高。
跨平臺，對于很多只關注Windows平臺的人來說是完全不考慮的，但是，其實，優(yōu)勢有太多太多。

Orx的協(xié)議非常自由

在外企的工作經驗使我對協(xié)議非常敏感，不再像在國內企業(yè)時那樣，只要是世界上最強大的，拿來就用，Orx的新版本（1.2)會使用Zlib協(xié)議，這是一個非常非常自由的協(xié)議，支持進行商業(yè)閉源的開發(fā)，并且也完全可以對Orx進行任何的閉源的修改。

Orx支持的特性比較多

Orx不是最強大的，但是支持的特性已經足夠多了，可以很方便的做一些簡單的游戲，其內嵌物理引擎Box2D，內嵌聲音引擎，有很多有用的圖形特效，比如縮放，翻轉，移動，alpha值變化等，事實也提供了對addcolor和普通透明混合效果的支持。

Orx使用較為簡單

Orx的使用很簡單，不僅僅其以配置為基礎（事實上我感覺這點在初期還比較麻煩），Orx的作者對Orx的定位是一款完整的游戲引擎，而不僅僅是一個圖形引擎，在Orx中所有的東西都抽象成了Object，擁有統(tǒng)一的接口，并且可以方便的通過配置/代碼來更改屬性及效果。并且最最重要的是，Orx對于物理引擎的支持不是簡單的外掛（如Cocos2D for Iphone)，而是內嵌，直接將Box2D與其Object綁定在一起，可以直接通過配置的設置，不用知道任何Box2D的東西，就能直接使用物理引擎。當然，事實上，知道其相關的物理概念還是很重要的，不然怎么知道配置什么啊？但是起碼可以不使用任何Box2D的API。（目前僅提供一些基礎的支持，不支持Joint這樣稍微復雜一點的特性）目前個人使用感覺是，用Orx做物理相關的東西，那是非常的簡單。但是，由于Orx對于圖形動畫的支持較弱，而且也沒有一款動畫編輯器支持，所以用來做復雜的動畫（其實即使是簡單的動畫）會比較麻煩，需要非常多的手動配置。我正考慮為Orx做一款以Json為基礎的動畫編輯器以簡化此過程。

Orx的開發(fā)者有豐富的經驗，并且極為熱心

我在Orx的論壇上，以及私下與Orx的開發(fā)者（目前Orx核心主要由iarwain開發(fā)）有很多的交流，他有著15年以上的程序編寫經驗，10年以上的游戲開發(fā)經驗，并且一直是從事底層開發(fā)，現(xiàn)在任職于Ubisoft的加拿大蒙特利爾工作室，他的工作經驗，使得Orx有著堅實的基礎，良好的架構，特別值得一提的是其編碼風格，注釋詳盡到幾乎每行都有，我曾經詢問過這個問題，因為通常來講，推薦的注釋的作用為解釋代碼的運行原理和作用（即Why？How？），而不是具體干了什么(what)，但是他認為，整個代碼他就是分為兩部分，一部分為邏輯，一部分為實現(xiàn)，邏輯由注釋描述，實現(xiàn)由代碼描述，方便他在不看代碼的情況下就能方便的了解邏輯，進行全面的了解或者深入的調試。并且其提出，在他那里，有很多編程經驗豐富的人嘗試用這種風格來編碼，從來沒有人說這種風格不好的，最后都堅持使用了這種風格。當然，這僅是一家之言，他的個人看法，但是對比現(xiàn)在我工作中的幾乎沒有注釋的代碼，我還是感慨良多。
他經驗豐富，最難得的是他非常熱心，在論壇中，他知無不答，答無不盡，糾正了很多我對游戲開發(fā)的一些不對看法，也解釋了很多Orx的設計，運行原理和思想，我受益良多。在私下的用steam的交流中，他也是給了我很多提示和解答，對我的幫助非常多。

最后

推薦有興趣的人都去其網站看看，并了解了解，希望你也能像我一樣喜歡上Orx,網址是http://orx-project.org/，在WIKI上有兩個 教程 ，講的還算比較詳細，但是也有很多我認為遺漏的地方， API Doc 得益于iarwain的詳盡注釋風格，非常詳細。事實上，我準備按照我的學習經驗，自己組織一系列關于Orx的教程，并且，以開發(fā)一款完整的游戲為脈絡，而不是以特性介紹為原則。會以Windows為平時的開發(fā)平臺。

-----------------------------------------------------------------------------------------------------------------------------

關于極端詳細的注釋風格，我問過iarwain，這樣的風格豈不是很影響開發(fā)效率？畢竟寫代碼時寫那么詳盡的注釋總是個負擔，但是他說他和他的朋友們都說從來沒有這樣的感覺，注釋總是讓他 們在調試時，在過了很久再回頭來看時，可以忽略很多代碼，而直達問題的關鍵。后來，我想了想，也許和他的工作內容有關吧，他常常進行的是底層的開發(fā)工作（如他所 言，low-level），所以可能相對來說代碼量比較小，改動也比較小的，更多的時間是用于思考，而不是敲代碼，而且，因為穩(wěn)定，有可能需要回頭看用過了很久的代碼，所以這樣的注釋風格才適合他吧。呵呵，對于我這樣的coder,常常敲無厘頭，沒難度，不用思考的邏輯代碼，最多一周幾千行C++代碼的工作量，要是按那個規(guī)模注釋，估計很難達到老板要求的速度了。

-----------------------------------------------------------------------------------------------------------------------------

這里貼一段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.

原創(chuàng)文章作者保留版權 轉載請注明原作者 并給出鏈接

write by 九天雁翎(JTianLing) -- blog.csdn.net/vagrxie

站在巨人的肩膀上開發(fā)游戲(1) -- orx 庫簡單介紹