2017年8月20日 星期日

Unity告別UnityScript,未來將只支援C#

作者:Richard Fine 原文
潤稿:Kelvin Lo


UnityScript(Unity中客製的JavaScript),從Unity 1.0開始一直伴隨著我們至今。正所謂天下無不散之宴席,終於要向它告別。我們已經開始逐步棄用UnityScript,未來只會保留C#作為Unity程式語言。

目前只有3.6%的Unity專案使用UnityScript進行開發,代表維護UnityScript將會影響Unity對新程式語言功能的支援進度,所以我們決定將棄用UnityScript。


棄用UnityScript的原因

每次Unity決定放棄支援一些功能,都會先瞭解這些決定可能會為開發者帶來的不便。所以我們必須確保這些決定有其進行的理由,這對我們很重要。Unity腳本程式設計正在經歷重大升級,其中一些重要功能包括:
  • 核心執行版本升級,支援使用.NET 4.6與C# 6
  • JobSystem,支援編寫多執行緒程式,且避免互相競爭與鎖死
  • NativeArray類型,支援建立及使用大型陣列,它們擁有原生程式控制的存儲區域,以便於對記憶體分配擁有更多控制權,不必再擔心GC回收機制
  • 支援控制腳本編譯,以便自訂將哪些腳本整合進程式集

這些只是一小部分,我們還將繼續支援一些新功能,並計畫開啟一些腳本專案。除了這些專案之外,我們也正利用最為合適的語言結構,來開放更多引擎底層API。

目前UnityScript與C#在功能與效能不相上下,當然C#可以實現的內容UnityScript也能達到同樣的效果。但說到開發生態,顯然C#是贏家,不僅僅是因為C#教學與範例網路上到處都是,C#語言也有豐富的工具,例如Visual Studio提供的代碼重構與智慧提示。或許你會質疑Unity Script可以用就好了,也不需要那麼多花俏的工具。

技術永遠是不斷發展的,隨著我們升級執行核心支援最新的C#版本時,就會出現一些C#簡單實現但UnityScript無法輕易實現或者不支援的功能。比如說目前UnityScript就不支援為方法參數(method parameters)提供預設值,並且C#語言支援的功能越來越多,例如ref return等都會造成同樣問題。目前我們暫未在API中使用這些功能,但出於效能與API結構設計考慮,我們也希望趕快讓這些新功能上線。

或者我們也可以選擇花時間來彌補UnityScript所欠缺的功能,但時間成本昂貴,把時間花在維護UnityScript就代表無法進行其它工作,好比加新功能或修Bug等。這還不包括在執行核心中支援UnityScript需要的工作,以及文件製作更新工作等等。

所以我們換了個方向思考,如果棄用UnityScript,會有多少開發者被影響呢?我們統計結果如下:

  • 截止目前使用Unity 5.6的專案中,包含至少一個.js檔的專案占14.6%。這個比例看起來相當高,但進一步分析資料,看看各專案中.js檔案與總檔案數(.js檔案 + .cs檔案)占比,會有新發現。
  • 也就是說,85.4%的Unity專案完全使用C#語言,根本不包含任何UnityScript腳本。
  • 9.5%的Unity專案大量使用C#語言,其中也包含一些UnityScript腳本,但腳本數量占腳本總數不足10%。還有1.5%的Unity專案所包含的UnityScript腳本占專案腳本總數在10~20%之間。
  • 3.6%的Unity專案使用UnityScript語言的腳本占腳本總數20%以上。
  • 僅有0.8%的Unity專案完全使用UnityScript。

這些資料顯示,大多數的Unity開發者都不是UnityScript的重度使用者。甚至專案所包含的UnityScript也並非實際使用的腳本,可能只是Asset Store某個套件的範例程式,對實際專案並無影響。所以我們棄用UnityScript計畫的第一步,就是從Asset Store開發者著手,先移除所有發佈套件裡的UnityScript腳本。

對於那3.6%使用較多UnityScript的Unity專案,以及那0.8%完全使用UnityScript的專案,我們表達深切的歉意。我們明白這樣的決定會對你產生影響,我們正製作一些轉換措施來嘗試讓整個轉換過程更加流暢,也希望大家能夠理解並支持我們所做出的決定。

棄用計畫

當然我們會一步一步捨棄UnityScript,而不是一刀切斷。主要計畫步驟如下:

首先,從6月開始我們已經修訂了Asset Store的套件審核條款,拒絕接受程式有包含UnityScript代碼的套件。所有新送審的套件都必須使用C#程式(在執行此項規定前我們已與開發者有過許多討論與溝通)。很快我們將會對Asset Store現有的套件進行檢查,如果有UnityScript則會通知發行商將程式碼轉為C#。如果一段時間後程式沒轉換為C#,套件將會從Asset Store下架。

再來,可能你已經注意到了,Unity 2017.2測試版的Create Assets選單下已經找不到Javascript(即UnityScript)。目前我們只移除了功能表上的建立功能,Unity編輯器仍然支援UnityScript,您仍然可以從編輯器之外創建UnityScript檔(例如MonoDevelop)。這麼做的原因是想確保新手開發者不會選用UnityScript,以免浪費學習成本。

另外,我們正在開發UnityScript自動轉換為C#的工具。目前該工具已有些成果,但還沒到我們滿意的地步。我們也還沒決定是否將工具整合到Unity編輯器或單獨開源提供。無論以何種方式,這個工具都會在今年年底Unity 2017.2正式發佈時提供大家使用。後續也會單獨介紹這個工具,請大家保持關注。

最後,我們也會繼續分析資料,我們希望能看到Unity專案都可以儘快切換至C#,尤其是那些UnityScript腳本數量少於10%的那些專案,因為需要移植的程式相對較少。但如果分析結果轉換未達預期,我們會暫停計畫並調查原因。在徹底棄用UnityScript之前,我們將確保不遺漏任何重要資訊。

一旦確認UnityScript使用率到一個低點之後,我們就會剝離UnityScript編譯器,不再將.js檔識別為腳本。也會從文檔中移除UnityScript程式範例,腳本更新器也將不再支援UnityScript。

如果有單獨需求,開發者仍可從Unity的GitHub中下載UnityScript編譯器,我們不會接受任何推送請求,但您可以建立自己的分支實現你的需求。


關於Boo

在歷史紀錄上Unity曾在2014年宣佈放棄支援Boo語言。但Boo編譯器仍存在現在的編輯器中,只因為UnityScript會用到了Boo的執行庫,並且UnityScript編譯器本身就是用Boo語言編寫的。所以雖然我們沒提但你仍可在Unity專案中使用.boo文件。

但是剝離UnityScript支援之後,就代表Boo編譯器也會被移除。目前所有使用Unity 5.6的專案中僅有0.2%的專案包含了.boo檔,僅有0.006%的專案擁有3個以上.boo檔案。


結論

希望本篇文章有清楚解釋了棄用UnityScript將會為大家帶來的影響,我們會依照流程:通知大家我們的計畫->推動Asset Store套件與編輯器UI更新,最後依照實際使用率的分析資料來決定是否執行。

放棄某個功能看起來像是退步,但這也是提高Unity開發效率的必經之路。我們希望集中精力為大家儘快修復現有的問題並製作新功能,也希望大家能夠理解並支持我們的決定。

沒有留言:

張貼留言

著作人