為什麼Unity3D能夠產生如此多的插件(中間件)?

Cocos2d-x,OGRE,Unreal都沒能成功構建自己的中間件生態鏈,這當然和遊戲軟體難以模塊化有關,但是為什麼Unity3D能夠能夠產生如此多的插件?國內的自研引擎開發商可以從中學習到社么?希望從技術和商業多方做解答。


不請自來。利益相關:Unity 插件開發者,Fireball 引擎開發者。

先回答第一個問題,Unity 插件咋這麼多捏?

  • Unity將插件開發的門檻降低到了極致,體現在:
    • 編輯器和引擎 API 風格相似,甚至連 UI 繪製方式也差不多,只要會做遊戲就能試著開發插件。
    • 插件直接就能在項目里新建腳本,隨意修改,自動載入……
    • 插件使用 C# 開發,配合 Unity 的跨平台 API,可以同時兼容不同操作系統。
    • Unity提供了 ScriptableObject,能夠很簡單的生成數據。
  • Unity 的插件能夠無縫的嵌入到工作流裡面,並且提供了無數的 API,能應對資源生產、版本管理、場景輔助、引擎擴展、自定義渲染、甚至調試腳本等各類需求。
  • 在 Unity 中使用插件非常方便,AssetStore直接下載,即插即用,而且基本都附帶了各種 Demo、Prefab、文檔,簡直不要太好用。
  • 在此基礎上,Unity 又打造了 AssetStore 這個恐怖的生態圈…… 好處就不啰嗦了想想 AppStore。

================== 我是誠聘廈門JavaScript開發者的分割線 =================

下面回答第二個問題。其實 Unity 的插件體系也不是完美的,Fireball 做為一款初出茅廬的自研產品,也總結了一些自己經驗,下面談談和插件有關的部分:

  • Unity 的插件體系是在編輯器的基礎上逆向開發出來的,導致雖然入門容易,想要做出比較複雜的插件難度卻很高:
    • 需要進行複雜的 UI 繪製時,那套立即式的 UI 系統簡直要人命…… 還是 Fireball 的聲明式 UI 來得好用。
    • Unity 對插件開發者的需求其實並不是特別了解,在親兒子 uGUI 推出之前 Unity 才惡補了一下插件體系。
  • Fireball 的解決方案是正向開發。插件體系一開始就是編輯器和引擎的核心內容,並且使用和編輯器一樣的 Html5 技術來開發。
    • 我們使用插件來實現整個編輯器的大部分功能,因此我們提供的框架本身就能支持各種比較複雜的需求。我認為需求能用合理的步驟實現後才應該考慮如何盡量降低學習曲線,而不是像 Unity 一樣一開始給一些很簡單的 API,結果要做複雜插件的時候卻再也簡單不起來了……
    • Fireball 的開發本身也是驗證插件系統的過程,編輯器內置的插件又是開源的,插件作者就有了很多天然的範例可以學習,不容易踩到坑。
  • Fireball 提供了基於包的資源管理方案,不但能從 AssetStore 下載插件,還能對插件進行版本管理。
  • Unity 的 ScriptableObject 只能用來儲存解析過的數據,但缺少了和資源之間的關聯性。當資源從外部更新之後,插件讀取到的 ScriptableObject 仍然是陳舊的,還是要用戶手工操作來強制刷新插件數據。
    • Fireball 則是更進一步開放了整個 Assets 資源庫的 API,用戶可以自由定義任意資源的導入配置、導入後的持久化方式,這樣插件的資源可以和內置資源一樣體驗到一樣的工作流。
  • Unity 的 Assets 資源庫使用的是一對一的資源導入方式,每份導入後的資源只能有一份原始文件。這樣一來如果我們要做一個 Texture Packer 那樣的功能,希望文件夾下的任一貼圖改變時,都能自動觸發整張 Atlas 大圖重新 Packing 時,就做不到了!
    • Fireball 則是提供了基於文件夾的資源導入機制,可以將文件夾下的所有資源都映射到一份導入文件中,很直觀地解決了以上問題。
  • 另外,Unity 使用後綴名來識別資源類型,那些常用的 .txt .json .plist .xml 格式簡直就沒辦法識別了,會造成多個插件爭搶同一個後綴名的現象。
    • Fireball 因為支持上面說的文件夾導入機制,所以可以給文件夾增加後綴名來規避這個問題。這樣一來那些類似 BitmapFont, Atlas, Spine 等沒有統一後綴名的數據,也能很好的通過文件夾的後綴名(.fnt .atlas .spine) 進行識別。

最後是廣告時間,目前 Fireball 引擎還在內測,官網是 http://fireball-x.com/ 求關注謝謝!


組件式開發, 耦合低到難以想像

再輔以微軟的C#大法, 那味道那叫一個酸爽

重要的是, 寫純代碼終於可以掙錢了!


因為Unity3D插件可以賣啊


「國內的自研引擎開發商可以從中學習到社么?希望從技術和商業多方做解答 ,」如果國內有哪怕一個引擎開發商,請你站出來告訴大家,asset store,相當於app store,也沒什麼好解答了吧,

說點技術問題,據說UNITY3D一開始只是想做成個特效編輯器,結果現在整個開發框架,連我這個架構師都汗顏,VISUAL STUDIO, ECLIPSE, SUBlime都沒有達到的高度,unity3d editor兼顧到教學推广部分那都是小兒科,國內那些「引擎開發商」一開始也是從做工具開始吸引一些人氣,也真有一開始就做引擎核心的,結果連一點人氣都沒有,連工具都不如,之前提到那幾個工具,如VISUAL STUDIO,無不想做成平台的,反而成了工具(微軟CEO水平如此),但是人家UNITY一開始只是想做工具的,卻成了平台


在於無縫的平台 asset store。

其實插件數量增加並不是什麼困難的事

有大把的閑得無聊的人想貢獻代碼和汗水

苦於沒有平台,只能自己搞

在github這類平台級的開源網站出現之前,開源團體是個什麼量級?現在呢?是個鬼都能做個開源工作者。

即使平台可能除了雲空間沒有任何功能。

聚集需求最相近的所有用戶是平台的最大價值。

unity插件一樣,這就好像appstore一樣,產銷一條龍,你插件的目標用戶全部在這個平台下活動,你開發好了就可以提交賣錢,不要太爽。


推薦閱讀:

unity5.X的場景烘培速度慢到令人髮指是什麼原因?有什麼提高速度的優化方案?
Unity3d 拖拽賦值組件與通過Find賦值組件的優點與缺點?

TAG:Unity遊戲引擎 |