最近與朋友討論了如何在 Unity 切換場景完的瞬間，立刻執行某些特定工作。嘗試了幾個方式後，發現基本上是不可能的。不過如果要在Awake 之後， Start 之前進行某些工作，則可以利用 Unity SceneManager 類別底下預設的幾個事件 (Event) 來達成。
不過 Unity 官方文件對於 SceneManager 預設事件的說明可以說是沒有，所以還是得自行測試過才能確定功能。
正好前陣子測試了 MonoBehaviour 時，在轉換場景的部分沒有測試完全，便趁這機會與 Unity SceneManager 一並做些測試，確定在切換場景的過程中所有流程 (Flow)，未來依據不同需求便可以在不同階段安插希望執行的工作了。
Attribute 是 C# 的一個功能，更是在 Unity 中很方便的一個部分，可以用於強化 C# script 腳本與 Unity Editor 場景編輯器的互動。
善用 Attribute 可以讓 Editor 更方便的改動 Component 參數 (更加客製化的改動介面)、避開錯誤的參數設定 (超出數值範圍、不該改動的數值等)，或者添加全新的功能在 Editor 中等。
本文紀錄許多我常用的、方便的 Attribute，皆是 Unity 內建，直接可以使用。
比較三種將類別實體化 (Create Instance) 的方法之效能差異：
因為曾經看過反射機制 (Reflection) 需要大量消耗效能，但是在開發中為了便利與維護，C# 的反射機制 (Reflection) 是相當有用處的。
所以到底該不該使用反射機制 (Reflection) 在 Unity 的實際開發中呢？如果是要開發手機遊戲是否應該避開？於是做了次實際測試來確認。
State pattern 是我使用次數最多的設計模式，在 Unity 遊戲的開發中被我用於程式流程的控制、規則的彈性編輯、簡易 AI 的撰寫、腳色控制器的設計等，是應用相當廣泛的模式。
因為次數太多了，索性事先設計好基本的類別，當需要的時候便可以隨時隨地使用 State pattern，本文便是藉機介紹了 State pattern 及我的通用作法。
Git 是一個被廣泛使用的 版本控制系統(Version Control Systems)，雖然現在有許多圖形化的介面可以使用，但要完全發揮 Git 的各個功能細節，使用 Command 進行操作依舊是相當重要的。 本文重新整理了當初在學習 Git 時所寫的筆記，並另外加入一些新的補充，紀錄了大部分 Git 中常用的 Commit、Branch、Remote 相關指令，做為學習的參考或使用上的備忘錄。
在使用 Unity 開發遊戲的時候，為了實現各種功能，往往會不斷衍伸出一個又一個的系統，分別執掌不同的任務，可能是為了管理 UI 介面，也可能是為了建立連線，又或者是為了管理存檔。一個個的系統往往又為了方便而採用 Singleton pattern，或者互相注入，最後的結果就是系統之間的關係複雜，程式碼不易維護及重複使用。
於是乎我就一直思考著如何將一個巨大的系統架構，拆分成一個個獨立且靈活的小系統，就像電腦與周邊設備可以用 USB 輕易連接與斷開，我也希望我所開發的一個個系統，可以自由自在地安置在不同的開發專案之中。
如今這是我的初步成果，一套用於拆分以及管理各個子系統的架構：
接觸設計模式的時間說長不長說短不短，但自從接觸了之後，才發現不管網路或者開發者社群，時不時都會有人提出如何學習設計模式的疑問。對於只是聽聞設計模式這個名稱，並被灌輸這個很重要，必須去學的想法的人，設計模式可能就像神祕學一般難易入門。
其實設計模式沒有這麼神奇與強大，只要累積一定的程式開發經驗之後，設計模式的想法基礎自然會逐漸被你聽聞或者吸收 (頓悟)。所謂的學習設計模式，只不過是強行頓悟的一個過程，像是打坐或冥想一般。 這篇文章是我接觸設計模式後的想法彙整，且提到了些關於學習過程的想法，希望可以幫到想接觸的人。
最近嘗試使用了日本亞馬遜 (Amazon jp) 進行購物，真是太方便啦！
對於技術開發者來說，stack overflow 這個網站一定不陌生，它是一個絕佳的技術問答環境，我遭遇過的開發問題有一半以上在這邊找得到相關討論。不過在 stack overflow 上面提問不是件隨便的事，一個不良的問題或回答會有相當高的機率被管理者刪除，在管理者的努力下，維護出了一個相當 “秩序” 的交流風氣，這個秩序造就了知識可以在最短的時間內抵達疑問者的眼前，十分美妙。
近期我在許多討論區看到初學的開發者湧入，這是件好事，但同時也引發了一些問與答的混亂，於是我有了疑問：stack overflow 是如何規範與建立起良好的問答風氣？事實上，在它的網站就有許多關於提問方式的宣導，我將其中的一些內容轉錄過來，藉機學習一下如何提問。
周末參加了 2016 HackNTU，相比於去年，今年的參與感變得相當深刻。 去年的我對於專案開發的經驗不足，只是作為一個遭遇問題與需求後，加以解決的程序作業員，無法對整個活動有所掌握與體會。今年雖然沒有甚麼突出的結果，卻不再有蜻蜓點水、像是去參觀般的感覺，而是對於每個環節都有更多的想法，也算是種進步吧！ 以下會提到對於 2016 HackNTU 這個活動的感受，以及我認為 Hackathon 活動中所能學習並自我檢視的部分。