來用F#開發遊戲

F#這個語言已出來10年左右了，雖然在Unity的生態中因為Mono版本的關係一直都處於弱勢，但隨著2017版本漸漸的被開發者接受後，F#逐漸的受到關注。

從歷史的角度來看，從Unity 2.x版開始，官方就讓開發者可以選擇用JavaScript（後更名為UnityScript）或是C#的語法進行程式規則面的撰寫。而在3.x版時更又加入了Boo（python的變體），雖然隨後又於4.x版後不再支援Boo，一直到5.x版和即將要推出的2017版，也至少維持了二種語法可供開發者選擇。

而從熱門程度的觀點來看，原先的UnityScript是大宗，但到了2012年開始，越來越多具有程式背景的開發者加入後，開始有了些變化，很多的範例和外掛都慢慢地改成了以C#的方式做撰寫，而如今（2017年）已鮮少有範例或是外掛用UnityScript了。

以這個趨勢來看，會不會官方做移除UnityScript的調整？這是未知數，只是這就很明確的點出Unity不是只能用C#開發的。其實只要是建構在.Net框架上的語言，都可以用開發Unity，也就是說不論是Visual Basic（VB）、IronRuby等，理論上都可行。在Unity的社群中，就有Arcadia開源專案，讓開發者可以在Unity中使用Clojure（Scheme）的語法開發。而從2012年開始，陸續也都有文章記錄著如何用F#開發Unity的遊戲。

Unity所給予的Editor中，若是用官方支持的語言-UnityScript或是C#，則每當程式碼有所變動時，Unity會自動做編譯和建置的動作，所以每當有所變化時，最後都會被建置成Library/ScriptAssemblies目錄中的dll檔，而後再被引用。但這個編譯的動作除了自行撰寫的程式碼會被納入考量，連引用的外掛或其它的函式庫等都一併會進來，因此，每當引用的外掛過多時，整個編譯的時間就會增加。

網路上有談論到怎麼最佳化編譯時間的文章。簡單來說有二種方法：

• 將外掛放到Plugins或是Standard Assets目錄裡
• 額外建置Dll後引用

也就是說藉由建置成Dll的方式再讓Unity引用是可行，而且是很不錯的最佳化方式之一。

一但建置成Dll，則原先是用什麼語言寫的都不重要了，在.Net的框加下，建置成的Dll簡單來說就是一連串.Net特有的組合語言（IL, Intermediate Language）。因此用C#也好、VB也好，或是目標語言-F#也好，都沒有太大的問題。

從這個想法來看，用F#開發是可行的，但不要說在Unity的社群中使用者不多，連一般的商用開發上，也是這一、二年才開始展露頭角。2012年到現今有關於用F#開發Unity遊戲的文章雖有，但和為數眾多的Unity文章比起來，真的是不算什麼，感覺起來上不來枱面。

撇開它是否熱門，用F#開發其實是可行的，也是一種選擇。F#自身有其特有的優勢是C#無法比擬的，但其實語言用多了用久了，也就知道不論如何，語言本身並不會影響到產品，不論什麼樣的語言做開發的基石，都是可行。但自接觸到F#、Scala等語言後，慢慢地被其直覺的函式導向所吸引，也越來越投入在Unity中用函式導向進行開發的嘗試。因此，希望能藉由記錄用F#開發的想法、過程，將不一樣的開發方式分享給有興趣的開發者。

在探索的過程當中，體驗到一下子從物件導向切換到純函式導向是困難的，且開發像是遊戲這樣規模複雜專案時想純以函式導向解決也不是很實際的想法。但在一步步整理到目前已找到的方式前，先試著用直譯式的方法，將一個小規模由C#為主體的專案改成以F#的語法做撰寫，讓其它想接觸F#的開發者有個具體的專案可評量是否想要採取F#當做開發語言的一個標準。

這樣的範例規模不能太大，最好是適合初學者可以了解Unity運作的範疇，而在Unity自身多數的教學範例中，Roll-a-ball就是大小、難度適中的一個選擇。接下來會介紹怎麼將此專案改成用F#做開發。