[C#/Unity] 回顧所使用過的 Singleton 實作方式 – Difference of Four Singleton practicing

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

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

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

Read More »

主觀淺談《時空之門》與《Colorful Waves》遊戲性的相似失控

前幾天《時空之門》宣布停止營運的日程,作為曾經入過坑但也快速離坑的前玩家,我主觀的思考了《時空之門》核心玩法無法持續吸引玩家的問題,察覺其中或許與我在 2017 GGJ 製作的《Colorful Waves》有著相似的困境。

這篇文章便是寫下一些主觀的心得,也歡迎他人針對我的觀點提出意見與討論。

Read More »

[Unity] 設計可以在建置前自我檢查的場景 – Make GameObject Check Itself

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

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

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

Read More »

解決 Unity 的遊戲停頓或 lag 的可能方案 – some probable methods to prevent unity lagging

Unity 在手機或掌機等效能有限的平台上,如果沒有進行優化,當遊戲複雜到一定的程度就無法保證幀數可以穩定,開始出現各種卡頓,影響玩家體驗。

一般出現卡頓,都可以依照原因對症下藥、進行優化,盡量增加玩家的優良體驗,以及減少對設備的負擔。因為在社群上參與了些討論,就想將 Coroutine 跟非同步這兩個在 Unity 中常用的運算優化手段做個紀錄。

**這篇文章是單純的想法心得與資料閱讀筆記,沒有舉出實作的驗證。

Read More »