連結和引用外部擴充、外掛

原先Unity的預設開發方式是直接在Editor裡產生程式碼，藉由Mono可以直接編譯並建置成Dll的特性，達到開發中快速回饋的機制。這個方式立意非常的良好，但專案慢慢變大後，加入了不少第三方的外掛後，就開始變得有些複雜。其中影響最巨大的就是編譯建置的時間。但本篇並不探究原理，單純的從已知的解決方案往下提出有利於開發的作業環境。

解決第三方外掛過多導致每次編譯建置的時間增加，最有效的方式就是分析哪些外掛是需要的哪些不是這麼重要的，挪開不太需要的外掛，澸少外掛使用量。雖然這是最有效的方式，坦白說卻是最難實施的。因為複雜的專案中，就是沒有辦法澸少外掛的量。

也不考慮更換硬體到更快更強大的電腦，最簡單的方式就是按照官方提出的特殊目錄結構（Specical Folder）將第三方外掛置入到Plugins或是Standard Assets這二個目錄之下（擇一或是都用，看當時的考量）。雖然這是一個很棒的建議，但外掛開發者遵守的並不多，多數的外掛仍是散在Assets目錄之下。因此遊戲開發者能做的，就是手動的把這些外掛移到這二個目錄之下。

雖然想法上相單的簡單，但在Unity之前的版本若是單純的只把第三方外掛的根目錄直接拖到這二個目錄之下，當下次外掛更新時就會有路徑上的問題。還好，在新版的Unity中完全解決了這些問題，就算是外掛在更新時也可以正確的將拖移過的資料比對找到好進行正確的更新。

但在開發時，不是只有第三方的外掛會成外部參考資料被引入到Unity Editor中。遊戲開發者自己也有可能會撰寫模組、擴充（外掛），這時候仍需要好的方式引入到Editor裡。此時不可能打包成package放到Unity Asset Store（UAS）上，就算是免費的外掛，一來一回的審核也要花去一個星期以上。所以一定只能從本機的作業環境去進行。

若是自行撰寫的模組等是完完全全只會以Dll檔的方式出現，在任何IDE裡都可以編輯專案檔，讓輸出的Dll直接進入到Unity Editor的某個規劃好的目䤸。但實際有開發過擴充的開發者都知道，不會僅僅只有Dll檔產生，有時會有些資源圖檔、設定檔，但說實在的在某些情況下，仍是需要寫橋接於Unity環境的C#程式碼檔案，這些檔案無論如何都不能包成Dll檔。這時候就會產生目錄結構規劃上的爭奪戰。

比如說是在開發某個擴充，那所有相關於此擴充的檔案-被建置成Dll的程式碼、和Unity橋接的程式碼、圖檔等，是否被放在同一個目錄下？但這個目錄是否要放在Unity Editor的Assets目錄下（麻煩的是，要被建置成Dll的程式碼仍有可能會被Unity偵測到並自行拿去建置），還是要額外放置在完全沒有關聯到的位置？又或是分成一部份在Unity Editor下，一部份在沒有關聯的位置？

有鑒於擴充本體的完整性和控管需求，一定是放在一起最好。但這時候就會產生另一個問題，那要怎麼將需要的部份檔案置於到Unity Editor的Assets目錄下？方法異常的簡單，複製／貼上即可。但不要忘了在開發時檔案／目錄變動性高，這樣的做法有可能出錯，不過最大的問題在於繁鎖。因此比較好的方式是用Symlink代勞，配合Shellscript／Powerscript的撰寫，一勞永逸的解決。

從目錄結構上來看，可以看成Unity專案的目錄和開發擴充專案的目錄，將開發擴充專案目錄的子目錄Symlink到Unity專案目錄下。就可以解決一直複製／貼上的問題。若是有需要進行目錄增減，也只需要從script端著手，安全又有效率。

Unity中使用Symlink會看到被提示的警告，但目前用Symlink的經驗是沒有任合的問題。至於會不會有元件不見的問題，這和在做版本控管時，Unity有特別提出meta檔要被保留下來有關，也就是說用Symlink不會造成物件上的元件不見的問題，但沒有一起將meta檔Symlink過來，則會產生此問題。

提到版本控管，在Unity的專案目錄下，若是有進行版本控管，則應該要將由script負責Symlink的的目錄、檔案納入到ignore（Git、Perforce都有不被控管的設定檔）中，因為這些目錄可之後藉由script回復。因此，這些回復Symlink用的script是要被控管的。

而另一點和Symlink使用相關的是當該目錄被滙出成Package檔時，原先是Symlink的目錄、資料，都會被實體目錄、檔案取代。也就是說在現行的滙出機制下，是無法滙出Symlink，這其實是好的處理方式，畢竟滙出Symlink的意義不大，主要還是實體檔。

若是有自行開發模組、擴充的開發者可以參考看看，用Symlink的方法讓開發作業環境更順暢。