鴨子開發日記

《Unity shader 入門精要》的讀書筆記，一到四章。

第一章為書本簡介，二到四章為螢幕渲染的基本知識、數學原理。

Singleton 是個充滿爭論的設計模式，從某些角度來看，Singleton 並不完全符合物件導向設計原則的所有理念，但是 Singleton 又某種程度上的不易被取代。所以一般來說的建議是：少用、小心地用。

過去我曾設計兩套實作方式，企圖用集合管理的方式，完全取代單一 Singleton 的使用：

• [Unity] 應用 Singleton pattern 及 Unity Component 做系統拆分與管理 – Dividing your game system in unity
• [C#/Unity] 更多 Singleton – More Singleton in Unity

不過最近我又把單一 Singleton 撿回來使用了，並回顧了我所遭遇過的使用情境，對何時該用何種 Singleton 實作，立下一套主觀原則。

我在製作遊戲 UI，或者場景中有些會不斷在顯示、隱藏之間切換的物件時，會利用物件的 SetActive() 來進行操作；或者有其他原因，會在場景中佈置一些關閉的物件，之後再依據遊戲流程重新啟動。

在這樣的情境下，我常常發生一個失誤：在編輯場景時為了確認某個效果，而將應該關閉的物件啟動，或者將應該啟動的物件關閉，最後忘記復原就進行了儲存與遊戲建置，然後理所當然地出錯了。

但畢竟場景配置不像程式碼撰寫，會在失誤時提示錯誤。於是這次就嘗試建立一套機制，可以對場景配置進行自動檢查，來避免人為的失誤造成遊戲運行的錯誤。

一個沒有深入結論的小測試，所以標題是問號。先直接給結果：

• 測試版本：Unity 5.5.0f3，PC Editor 環境
• 測試的物件：Unity 內建的 Sphere
• 測試的數量：300 * 300 (即 90000 個)

Unity 在手機或掌機等效能有限的平台上，如果沒有進行優化，當遊戲複雜到一定的程度就無法保證幀數可以穩定，開始出現各種卡頓，影響玩家體驗。 一般出現卡頓，都可以依照原因對症下藥、進行優化，盡量增加玩家的優良體驗，以及減少對設備的負擔。因為在社群上參與了些討論，就想將 Coroutine 跟非同步這兩個在 Unity 中常用的運算優化手段做個紀錄。 **這篇文章是單純的想法心得與資料閱讀筆記，沒有舉出實作的驗證。

有點神奇的事情。

有時候在 clone git 專案時，會在 command line 或 windows bash 得到這種錯誤：

1

user@host> git clone http://github.com/douduck08/foo.git ... fatal: I don't handle protocol 'http' or fatal: I don't handle protocol 'https'

今天終於知道原因與解法了。

前陣子有注意到，大多數的書籍或網站資料在介紹 設計模式(Design Pattern) 時，往往所採用的實作方式都是以 C++ 或 JAVA 為實作基礎，甚至在 Unity 為主題的書籍上，也沒有針對 C# 做進一步說明。

事實上作為一個不斷擴充版本及功能的語言，.NET 的 C# 的使用上提供了更多樣化的類別或介面，可以用不太一樣的方式來實作設計模式，妥善的應用 C# 所帶來的便利。

最明顯的例子，就是利用 C# 的 delegate，可以更加方便的實作 觀察者模式(Observer pattern)，甚至讓應用上更加靈活。

在舊文章 [Unity] 應用 Singleton pattern 及 Unity Component 做系統拆分與管理 – Dividing your game system in unity 中，我開發了一套架構來作為單一 Singleton 的替代方案，用於統一管理會在整個 Unity 專案中使用到的遊戲功能系統。

該篇文章中的 GameSystemMono (即仿 Singlton 的組件) 繼承了 MonoBehaviour，來實現一些設計上的想法。不過帶來優點的同時也產生了一些限制，經過與他人的討論後，認為還是需要一個不依賴 MonoBehaviour 的 Singleton 組件方案，兩者互相補足，而這個想法終於在最近進行了實作。

踩雷了。決定還是好好搞清楚 event 這個關鍵字的效果，把過去以及剛剛所查過的資料統整筆記，這次還發現有對 IL 的分析，完全補足了官方文件對於這塊實作方式的說明。

怎麼 MSDN 上面的說明如此簡單然而不明確呢？

不久前才測試完了 Delegate 的 GC，雖然只是驗證了一個可以預期的結果。不過才過幾小時，我就想到類似的議題在 Unity Component 上，是否會因為 Component 特性而產生不太一樣的結果？

雖然本是要測試 Delegate，不過我同時也想驗證一下之前就發現的一個 Component 特性：自行移除相關參照 (Reference)。

結果竟然在測試過程中有了額外發現，間接造成 Delegate 的測試無法進行下去… 所以文章便直接停止在 Unity Component 的 GC 測試。