摘要
需要說明的是，本人也不確定跨場景開發這個詞是會出現怎樣的歧義。簡單的說，就是多人合作的升級，不再是多個人在一個Project目錄下各負責某個模塊，而是一部分人負責某一個工程。將工程分爲不同的類型，以便於程序的擴展和維護。有些時候調整其中一個工程就可以實現變化，這樣的劃分的意義將凸顯。設想有如下的場景：你有一個邏輯完善的程序框架，其中部分資源經常需要調整，或則是這部分資源調整就可以實現完全不同的關卡。而你只需要通過加載不同的配製信息，不改變任何邏輯就可以滿足需求。此時，你應該會意識到，部分資源不應該放在邏輯程序中，而應該封閉起來，需要的時候加載出來。這樣不僅維護了資源配製的安全性，還體現了程序的可擴展能力。
目錄
也許本文的解決方案不是最好的，但確實已經在項目開發中使用，在這裏介紹給有相同需求的同仁，希望對其有所啓發。下面是關鍵的幾個點：
1.好好利用unity3d自身的優勢
2.資源自動關聯是本方案的核心
3.共享內嵌同步版本
4.資源發佈及資源加載方案
一、好好利用unity3d自身的優勢
unity3d是一個基本腳本的引擎，其中一個腳本開發的好，可以用在多個對象上，只需要修改部分參數就可以實現不同的顯示和邏輯等效果。正是因爲這樣，資源和代碼的關係並不是傳統遊戲那個分離。有很多文章建議回到傳統的開發方案上一，將資源和代碼分離，用到的時候在加載資源。但這樣明顯是十分困難的，畢竟遊戲引擎就應該讓問題變得簡單而不是讓人煩惱。爲此還是需要堅定對prefab的信念，提升使用prefab的能力。而prefab的加載中的三種方案只有一種可以滿足跨工程，那就是AssetBundle。
二、資源自動關聯是本方案的核心
Assetbundle的打包後，可以利用WWW腳本加載出來，但腳本卻不好處理。實際上邏輯需要改變的程序，可以加載lua腳本來實現，或直接使用反射來實現腳本動態。本文不做熱更新任何說明，因爲這個解決方案不涉及腳本的更新，且適用所有的平臺。在一個工程中配製好之後憑什麼可以在另一個有相同腳本的工程中自動進行關聯？那就是GUID,每一個導入到unity3d 的Asset目錄下的文件都會生成一個.meta文件，除非你設置了隱藏。這個.meta文件就記錄了資源的關聯信息。如果你希望在資源自動關聯，那麼請確保兩個工程中的.meta文件是相同的。
三、共享內嵌同步版本
預製體和腳本的關聯，非和腳本的名字進行關聯。都是和.meta中的GUID進行關聯，你需要做的僅僅是將需要保存信息和配製的腳本放置到一個版本庫中，在資源工程和邏輯工程中進行共享。那麼.meta就自動可以同步了。值得注意的是unity的控制檯有沒有提示guid重複的黃色警告，如果有，就要小心.meta被重寫和資源關聯丟失的問題了。共享版本的最大問題當然不是這個，而是你的資源工程應該儘量刪除不直接需要的庫引用，而沒有這些庫或是代碼，共享的代碼必然要報錯！此時，不要驚慌，因爲在資源項目中並不需要執行這些代碼。所以註釋掉就好了，但註釋也有講究，不是//也不是/**/，而是利用宏定義，確保在你的邏輯工程中，這些代碼並沒有被註釋。
四、資源發佈及資源加載方案
以上的三個點理解了就可以做你自己的跨場景開發了，但實際上使用不同工程的資源包還需要一個資源加載的工具，這個工具可以在unity AssetStore 上下載免費或付費的，但目前應該沒有一個和本方案貼切的加載及發佈工具。所以爲實現這樣的一套流程，本人也有常規的資源打包器和資源加載器上進行了一定的修改，可見github。主要的功能就是可以定義多個長期保存的發佈規則，每個規則中需要打包的資源不盡相同。具體打包那些資源就看你的用戶需要了。
五、後續
1.動態添加資源包設想
由於以上的方案中是直接在從資源路徑加載，所以只需要修改配製就可以實現不同的關卡加載。如果你能把用戶需要的資源製作成一個壓縮包如zip，那麼程序就可以實現從這個資源包中解壓後更新到你的程序中。而你的邏輯工程沒有進行任何改變，這樣你的程序也不需要進行任何打包，用戶只需要到你的商店購買相應的資源就可以進行其他效果的體驗。
2.如果需要選擇性打包,可以參考這個工程：CrossProject
