Unity3d個人覺得網頁游戲，手機游戲，對于各個平臺支持都很好。并且支持flash，網頁運行再也不用安裝瀏覽器插件。這塊做的不錯。開發人員起點比較低。基本的資料文檔都很豐富了。缺點就是畫面不給力。燈光、畫面各方面在這三個引擎里都是最差的，并且對于美術人員來說，做開發不是很好上手。很簡單的一個材質。都要去寫shader。。

　　UNITY3D現在已經成為了眾多團隊的首選3D引擎。 并且，隨著Unity3D 4.3的發布，原生的2D支持也讓人大開眼界。雖然Unity3d的原生2D功能還有很長的路要走，但也阻擋不了它稱霸當下。

　　2011年中，公司的引擎項目停止之后，我的目光便轉到了U3D的身上，經過幾番掙扎后，終于對基于組件式的對象模型有了新的認識。 而如今，這種模式，成為了我最推崇的模式。 因為它能解決我在設計引擎對象時的糾結。 而這些糾結，是我在先前的引擎開發中，一直不能優雅地解決的。

　　首先，我們來說說U3D的好處。可能總結得不夠完善，如果有不足的地方，就表示我自己沒有體驗到。

　　一、可定制的IDE環境

　　U3D這種ALL IN ONE的設計思路，我在一個叫神咒的代碼中見到過。 集所有編輯器于一身。 雖然神咒的編輯器不能自由擴展，但由于是公司內部的引擎，所以，它的使用，也很方便。 比如，在場景中突然想要對一個模型的材質進行編輯，則選中此模型，右鍵，彈出材質編輯器即可。 U3D的組件式思路，將這種關系變得更加緊密。 你都感覺不到自己在使用一個材質編輯器。 你會覺得，你是在操作這個模型本身。 它的材質，它的碰撞器，它的對象結構等等。

　　回想一開始進入游戲行業的時候，天天啃著代碼。 當時覺得代碼就是一切，各種認為很牛X的代碼，都忍不住讀上一番。 而隨著時間的推移，特別是經過項目的洗禮后。 突然發現編輯器是多么的重要。 就我做的第一個頁游來說，起手前兩個星期，我們就做了動畫編輯器，場景編輯器。而最終證明，因為這兩個簡陋的編輯器，使我們后面的工作變得更加容易。

　　因此，一個好的引擎，必定得先有一個功能完備的編輯器。

　　二、基于Mono的開發腳本

　　C/C++無疑是圖形界的寵兒，也沒有人想過用另一種語言來替代它。即使是U3D，亦是如此。 但是，早期使用C/C++編寫的引擎，都理所當然地使用C/C++來作為上層邏輯的開發。 又有一些，采用了純腳本的模式。比如Python,LUA。 腳本的好處在于更低的編碼成本(經過仔細研究，我發現，這是由于寫腳本語言的心態和寫C++的心態導致的。 寫C++的時候，總是想著代碼的復用度，而在腳本的時候，很多時間會認為，這個腳本，就是為這個對象服務的，那我就按照策劃需求來寫就可以了。 我想，這也是許多時候，腳本語言存在的意義。特別是早期引擎中，使用腳本來處理一些關鍵的事件響應)。 而大家熟知的虛幻引擎以及有一個名不見經轉的Torque，則自己整了一套開發語言。 我想，它們的目的，就是為了使大家能夠以一種更安全的方式來編程， C++一不小心，則會帶來內存和效率問題。 它的使用成本，人員成本其實是高于其它語言的。 Mono C# JS,BOO的出現，再一次讓大家的眼睛一亮，原來，引擎可以這樣整。

　　Mono的橋接，使得高效的C++圖形引擎與帶GC的內存安全語言進行結合。不僅減少了安全隱患，也使得大家編寫跨平臺代碼時更佳容易。 同時，這類語言的反射機制，更適合做編輯器。而比起先前的一些DIY語言和像LUA這樣的小巧型語言，Mono使腳本編程可以進行DEBUG，而不單純的靠PRINT輸出。

　　這里就順帶說一下三個語言的區別

　　C# 這是我見過的大型項目中使用得最多的語言，也是我比較喜歡的語言。 因為它和C++很像，同時嚴格的類型和語法檢查。

　　JS 在幫一些朋友做小東西的時候，使用過這個語言，由于mono自帶的提示功能，寫起來還是挺順手。 但總給我一種摸不著頭腦的感覺。 并且U3D給的JS，不是嚴格的JS，有些語法不支持，而有些語法又很特別。

　　BOO 完全沒有使用過，貌似也很少有人使用。

　　三、基于組件的對象系統

　　這是一個我最喜歡的系統，我也使用irrlicht引擎山寨過，山寨的過程中，幾乎看完了它的組件參考手冊，使我對U3D引擎的組件系統又有了新的認識。 同時，目前公司自主研發的引擎，也是這樣的思想。 不管我是在工作中，還是業余搗鼓都受組件系統的影響。 慢慢的，喜歡上了這種對象模式。

　　之前在做一個RTS游戲項目的時候，參考了著名開源項目 0.A.D的代碼。 當時只是為了去尋找LOS和多單位協同尋路的方案。 但在參考其代碼的時候，發現了它整個系統，都是基于組件式的。又一次，對組件式有了好感。 而經過仔細思索后。 回到了我一直堅持的子系統劃分法的游戲框架。 當我不禁感嘆，原來，自己也一直是在組件式。 只不過，我的組件式，是MANAGER方式，MANANGER內部進行對應的實體管理、。 比如，背包系統，則只負責玩家背包數據，背包使用，背包相關的功能。 不管是數據存儲，還是與前端通信，都是背包系統自己在負責，其它模塊完全不需要干涉。 而U3D中的組件系統，則將這個粒度劃得更仔細了……。 這對于早期的像OGRE的entity系統。僅僅是認為對象可以由子對象構成，可以說是一個質的變化。

　　早期的引擎，基本上都是繼承優先的設計方案，更多時候考慮的是編碼的便利性，且引擎的走向都具有針對性。 而當面對一些復雜情況的時候，繼承式的編碼是十分麻煩的。 并且，對于JAVA,C#這樣的語言，并沒有提供多繼承能力。 因此，繼承式的編程，在面對越來越廣泛的游戲需求的時候。顯得無能為力。 組件式則是一種聚合優先的編碼方式，它的復用度和伸縮度，都遠遠大于繼承。 唯一讓一些C++程序員覺得不太順眼的，可能就是過多的變量和虛函數調用開銷吧。 但這些，在當下來說，都不是問題。 影響大眾步伐的，早已不是那種語言特性本身導致的開銷。更多的，是如何使我們高效率，高質量地完成一個游戲。 因此組件模式已經成為必然。 從新版的UE4的變革，以及暢游的G3D，國外一個開源的godot引擎，就可以看出來，大家對組件模式，已經有了深深的好感和接受度。

　　四、所見即所得

　　這可以說是許多人最喜歡的特性，這也是G3D群里，問的人最多的特性，三天兩頭就有人問，G3D能不能像U3D一樣在編輯器里預覽游戲效果呀。

　　U3D除了編輯后立即運行，還能在運行過程中時實編輯，查看效果。當然，運行過程中編輯對象的數據，會在停止后失效。(注意，對文件屬性的修改，不會失效)

　　五、代碼驅動的開發模式

　　這種模式，可以使我們快速地構建一個原型。 對于U3D中的MonoBehaviour來說，它扮演的，就是如何驅動它的目標對象。 因此，你可以將你的對象的各種能力分配到不同的腳本組件中，然后根據對象的需求來掛接。

　　六、多平臺發布

　　U3D支持的平臺，無疑是當下較為流行的平臺。 滿足絕大部分項目需求。 早期的引擎，多以PC和CONSOLE為主。 支持WINDOWS,XBOX,PS2已經是很不錯了。 U3D便利的多平臺發布特性，也使得它成為了當前性價比最高的引擎的原因之一。

　　也有許多公司正在自主研發引擎，或者是將先前的PC引擎修改為多平臺(IOS+ANDROID居多)。 但這也檔不了U3D的步伐。

　　七、良好的生態圈

　　在使用公司引擎的時候，我就發現，若我遇上一個問題，只能問公司的老員工們，或者找其它引擎TEAM尋求幫助。而U3D這種生態圈，不是一天兩天能形成的。GOOGLE,百度，各種論壇，都能很容易找到自己想要解決的問題。 而對于一些經驗上的問題，也有不少人總結。 這使得后來者，可以快速上手引擎。

　　而AssetStore的出現，不僅使U3D的生態圈更加穩固，同時也提供了許多機會。 你可以制作插件放網上賣，賺取一些利益，也可以購買別人的插件，作為使用或者參考也好。 有時候，購買一些插件，可以讓你快速脫離當前的困境。 一個是解決進度問題，一個是解決思路問題。 這是之前其它引擎不具備的。