【Norly 開發日記】場景雛形、GPU instance、Assembly Definition、單元測試

有了地圖規劃後，很快的拉了場景，讓小人跑一遍看看。

偷偷打廣告一下，這有使用我之前做的場景流程管理工具，先把每個場景的模型與預計的出入口放好，刷新一下工具介面就會出現出入口對應的port。

port會以相對距離的方式顯示在圖形介面上，例如中間那個水塔的出入口比較多，除了出入口物件名稱外，也能從大概位置推估誰是誰的門口。

(Unity stylesheet文獻太少QQ 懶得寫介面css)

玩家觸發門之後轉換場景，透過場景載入事件(callback)自動將玩家物件移動至指定門口位置，省去繁複判斷，也達到「左門進右門出」這種場景之間相對位置的感覺。

不過我這次擔任美術，這個工具是在我私下驗證地圖的時候使用的，主專案使用的辦法還是看程式那邊的規劃。( •̀ ω •́ )✧

場景的設定是在地下廢墟，會希望有點水滴流動的效果，也出於個人私心小小的研究了GPU

instance和compute shader。 (´▽`ʃ♡ƪ)

起初是想把這個小研究當成數獨之類的遊戲來殺時間，所以給自己一周的時間，沒有查流體相關演算法，用自己的想像去假設個方法做出來的。 目前是用深度去判斷Metaball能往哪個方向移動，就比較吃攝影機架設的角度了。

我猜是因為線性深度只是估計值，導致前後深度不好被測量，所以看起來像平面的水。

我試著用2個角度的相機提供深度圖，是可以看到粒子被遮擋了，但各角度移動的閥值可能還要再設定一下，不然大多粒子偏向往前移動。

不過一周的時間也差不多到了，接下來該認真找流體相關的做法了( •̀ ω •́ )✧

更動C#後再回到Unity，是否發現Unity每次都要重新編譯Assembly檔，讓讀取時間越來越久?  在我們沒有手動分組譯區塊的時候，Unity會把整個專案都跑一遍。我們可以手動在資料夾新增Assembly Definition檔案去做區隔。

(圖源 https://docs.unity3d.com/Manual/ScriptCompilationAssemblyDefinitionFiles.html )

以我上述的場景管理工具(levelfow)為例，目前結構如下：

先在最外層創立Assembly definition

Editor資料夾下的腳本不常更動，所以創個Assembly definition去分區，此時若腳本內容有被外部使用到則會出現namespace not found的error，需將呼叫方法所在的Assembly definition檔包含近來 (這裡則是外層Manager)。 是可以再細分，但工具基本上不常更動，分個大項即可。

以前只接觸過軟體開發的TDD(測試驅動)，也就是「先寫驗證碼，再寫主要程式」。TDD能降低錯誤的風險，且搭配如AWS自動部屬服務，在推新版本的時候會自動跑測試程式碼，通過才會替換版本檔案。

Unity也提供測試驗證功能，應該不多人發現General下的Test Runner介面。

分為PlayMode和EditMode，若在PlayMode下執行，則會自動產生一個場景，依序依照測試程式碼執行，由最終Assert函數返回是否通過測試。

官方範例：https://docs.unity3d.com/2018.3/Documentation/Manual/PlaymodeTestFramework.html

• 下周整周都在台北研習，剛好明天可以去台北地下街看巴哈的二手攤!!!  (希望有原神周邊)

• 不知道是不是還沒上美術的關係，做雛形的時候多少會替2D與3D結合捏把冷汗，是有幾個先例可以循，加上之前做的demo看來，3D能玩的視覺效果會更多，總能找到辦法的，先別畫地自限吧！( •̀ ω •́ )✧

• 暑假原本還有報名Ais3營，雖然正取，但想參加的那兩個項目爆滿了，只能棄權了。