游戲引擎不僅是代碼，更多的是完善的工具 - geniusalex－IT工程師數位筆記本

文章出處

從洗腦開始

記得若干年前，在做公司引擎研發的時候，時常會念到的一句話：引擎不僅是代碼，更多的是完善的工具。當時只是用這句話還激勵自己，找準引擎開發的原則和位置。而實際上，對這句話的理解甚少。時隔多年，這句話油然在耳，伴隨我左右

親身體會

后來，引擎項目砍掉了，進入了頁游產品的開發。在這個產品開發的第一周，我們就面臨著動畫和場景編輯問題，在腦海中第一時間浮現出的，依然是這句話。于是，我們花了兩個星期來做了一個簡單的動畫編輯器和場景編輯器。動畫編輯器只有簡單的圖片導入，和錨點設置功能（因為怪物大小不一樣）。而場景編輯器，則只有圖片導入，怪物擺放功能……。但正是這兩個簡陋的編輯器，使我們的項目能夠讓策劃在沒有程序的幫助下快速進行關卡相關的內容設計。這也是第一次，讓我感受到，工具能夠給項目帶來的意義，絕非那兩句話可以概括的。

擴展與定制

換了一家公司，是做和帝國時代差不多的開發。這家公司的理念和我是一致的，就是先要開發編輯器，然后再做游戲。這家公司開發了sprite editor,ai editor,level editor 一切的愿望都是美好的，而唯一讓我覺得神奇的，是ai editor和level editor，消耗了大量的時間。同時，內置的許多東西，使得每一次需求變更，都要程序維護相應的editor版本才能達到對應的功能支持。現來回想起來，如果當初使用配置文件來做一些和需求相關的東西，豈不是更好

上層開發語言

我曾經一度認為，這輩子就靠C++吃飯了。C++這么好的語言，圖形和引擎底層都是用C++寫的，上層邏輯自然應該用C++寫。并且腳本語言的效率，完全是C++沒法比的。

這只是當時的想法，據我所知，成都的逸海情天，在很早的時候，就已經使用 C++底層+JAVA邏輯的開發模式了。曾經我還笑過這種方案，覺得是一堆不會C++的奇葩貨弄出來的玩意兒。當我接觸到UNITY3D后，我才發現，C++ + JAVA的模式，是多么的高大上啊。 C++高效率的特性用在底層無疑是不二之選，但好東西都是一把雙刃劍，C++邏輯開發中遇上的各種問題，不是一己之力能夠杜絕的。

現在在手機平臺上，將腳本作為上層開發語言就更是比比皆是了。原因就是那讓人神往的IOS。為了游戲能夠在游戲中進行更新，不得不采用腳本作為邏輯開發。這也使得引擎使用C++底層+腳本邏輯走上了正軌。而實際上，早期的許多公司或者引擎也是這樣做的。比如torque,unreal等

發布與布署

在端游的時代，發布和布署可能并沒有受到在大的重視，只要編譯好，放到適合的位置就可以了。

而隨著頁游聯運的興起，發布和布署的成本就隨之提升了，因為會針對不同的運營商做一些功能定制，若為每個運營商開發一分支，維護起來成本就更高了。因此我們選擇在同分支下做處理，而將運營商相關的東西做一些標志，根據不同運行商進行加載。這都還不是終點，在一定程度上，我們可以解決問題。

隨著手游的興起，先不說雜七雜八的國內ANDROID平臺，首先面對IOS和ANDROID系統，我們的引擎就需要針對性地做一些優化處理。拿圖片處理為例，在IOS上，通常使用PVRTC 4bp格式，而在ANDROID上，則使用ETC。如果兩個版本做不同分支，就更不科學了。因此，我們需要做一些腳本化的東西，使我們的資源可以在發布前，打包或者轉化為目標平臺可識別的資源。因此，在這個地方，SHELL工具，又變得不可缺少了，而不僅僅是給策劃和美術使用的編輯器

Shell與python

很多時候，我們使用shell就可以搞定許多問題，但是，python作為一個強大的腳本語言，它提供的各種工具庫不是shell能比擬的，比如文件搜索，MD5生成，圖片處理等等。更讓shell不能比的是，python是跨平臺的，這就讓我們在MAC，LINUX和WINDOWS上，可以復用我們寫好的工具。而shell則只需要做一些簡單的平臺權限相關的操作。如果使用python能夠搞定的，我們盡量使用它。因為手機游戲的開發，很多時候MAC與windows都有需求。

Unity3D

雖然從來沒有使用過這貨開發項目，但自從2011引擎項目砍掉后，我就一直關注它，研究它。一開始，我對它的做法是很不接受的，覺得將一個引擎與工具綁定得如此緊密，導致我在調試程序的時候，還要啟動UNITY3D的IDE，是一件很不爽的事情。很有早期使用FLASH CS來開發FLASH游戲的感覺。一直期待UNITY3D能夠像FLASH BUILDER一樣，出一個純代碼的開發環境。但后來發現，UNITY3D之所以強大，正是因為它的編輯器，而不是他那高端的組件化設計。一個純組件化設計的引擎，如果沒有一個好的工具配合，是很難發揮效果的，甚至會多寫許多代碼。而組件式這種巧妙的設計，居然能夠將編輯器與項目需求解耦。也讓我刷新了引擎架構方面的認知－－－－－引擎除了工具和渲染，良好的上層結構依然重要。

Mono平臺的引入，雖然使UNITY3D發出的包略大，同時在CPU較低的機型上很吃力以外，沒有任何不好的地方。許多人吐槽這東西，但我覺得，大家應該承認時代的變遷。

Unity3d的2D支持引入雖然過晚，但充分說明Unity3d對2D方面的勢頭，雖然重型的MONO平臺使得即使是2D游戲，也帶來一定的開銷，但我覺得，在保證產品穩定，快速迭代等前提下，少兼容一定量的低端設備，也是允許的。

Cocos2d-x

要說影響中國游戲開發界的開源引擎，除了早期名噪一時的OGRE，如今就只有它了。許多人說它的架構很2，許多人說他其實就是一個山寨貨，許多人說他自己花點時間就能寫出來。這些人的對與錯我們不討論了，我們來看市場占有率。或許這樣你會說很俗。但一個東西存在即是合理的。一個引擎，能夠滿足你的項目開發需求，同時為你省下大把時間，你有多少理由不使用它？而非要自己去DIY一個蹩腳的引擎，你覺得你寫出來的東西，坑就一定比別人少嗎？

3.x版本的cocos2d-x已經與往日不同了，我很高興能夠看到cocos2d-x在代碼結構方面的革新。（不僅僅是去掉了CC前綴）

cocostudio雖然還是一個半殘品，但不得不說，觸控官方出力開發一個商業級的編輯器，這在開源項目中還是很少見的。大家應該給它時間成長。而在成長期間，還是用最適合的方案來構建自己的項目吧。試想，在cocostudio出現之前，也有無數的成功案例。

Irrlicht

這是我曾經最喜歡的引擎，它伴隨著我渡過了大學生活，我在寢室里，時常閱讀它的代碼和注釋，雖然沒有特別的收獲（因為完全看不明白），卻使我保持了對引擎的熱情。

Nicko為這個引擎開發了一個irrEdit，但隨時時間的推移，這個東西已經不更新了，因為nicko發現，irrlicht沒啥意思，irrEdit和irrKlang收益又不多。于是轉而投入一superCube的開發。supercube賣得還挺貴的，支持flash,html5,android app,ios app,windows exe等發布。功能和特性都挺NB，但是界面和實際的功能，真的好像小朋友做的。有興趣的朋友可以試試

OGRE

這是我接觸的第二個引擎，它的龐大使我望而怯步。有幸在研發過程中，研究過天龍八部的代碼，以及它的材質系統。整個東西都挺OK的，而美中不足的是它就像一個倉庫，什么都往里塞，而很多東西，也是停留在學術層次，如果想投入項目，還得自己改造一番。cocos2dx可以說是很直接的了（有人說是因為2D很簡單，但我覺得，是因為cocos2dx定位很明確，或者說，是因為cocos2d的定位很明確）。 OGRE也沒有附帶編輯器。而早期的項目，都不是基于UNITY3D那種解耦方式，許多都是為特定類型的游戲定制編輯器。我研究過大唐，神咒，天機，以及剛剛說的天龍八部的代碼和編輯器，都是為MMORPG定制的，且直接關聯游戲內容。這或許就是當時的引擎發展層次吧。

Glitch

這是一個由Irrlicht發展而來的引擎，核心部分雖然有較多擴展，性能和特性也是Irrlicht不可同日而語的，但核心部分依然保持了IRRLICHT的風格。唯一不同的是，上層邏輯開發的模式，與UNITY3D如出一轍，這也是讓我想到了，任何引擎，都可以慢慢的向UNITY3D的邏輯開發方式靠齊，包括cocos2dx,更甚至是ogre。glitch由于是內部使用引擎，工具也是自家定制的，但工具的設計思路，也和unity3d頗為相似。這一點可以說是讓我十分欣賞。