我初次接觸 Unity 是在 2015 年 9 月左右，當時沒有任何做遊戲或互動媒體的經驗，一個基本只會 C++ 跟一點 Web 開發的畢業生加入了遊戲公司，從沒聽過 Unity 也沒寫過 C# 開始，一路學習到現在。
一路上依賴網路自學，拆解公司舊專案當參考，追趕新專案的需求，在去年 2016 的 4月前後，接觸了 Unity 相關的網路社群 (Unity 應用領域、You can make game)，開始了大量吸趴的一年。
如今又過了一年，雖然憑著兩年實作經驗可能還只能算隻小菜鴨，更多深入專精的遊戲開發技術也尚未掌握起來，而這篇文章是想寫下到目前為止，我學習 Unity 的過程與理解。
因為我是從已經有程式底子的情況來學習 Unity，所以這系列的內容會有較多的 程式視角，但我會盡量從沒基礎的角度進行補充，作為一個基本觀念的系列文章。
如果這系列文章，可以作為某人進入遊戲開發的敲門磚，我想便足矣。
前幾天用 Unity 的 uGUI 元件組合出了雷達圖效果，同時也能夠及時的修改數值，表現在圖表上，是個蠻有趣的嘗試。
如果要完整表達內容，可能要搭配大量的圖片，所以這次嘗試使用影片的方式來分享實作。
繼續閱讀 “[影片][Unity] 利用 UI 元件製作雷達圖 – Make Radar Chart with uGUI"
過去在《[C#/Unity] 更多 Singleton – More Singleton in Unity》這篇文章中，實作了一個名為 Singleton manager 的物件來做 Singleton 的註冊與使用。
但最近在研讀 相依性注入 (Dependency Injection) 相關文章時，才發現有個叫做 Service Locator 的設計模式，基本上就是我過去所實作的 Singleton manager。再加上一些關於抽象化的觀念又比當初更成熟了，因此便想趁機改善當初的設計，同時正名為 Service Locator。
(概念相似所以就直接借用舊圖片作為封面)
繼續閱讀 “[C#/Unity] 這不叫 Singleton，叫 Service Locator – Practice of Service Locator"
這是看 Unity 官方 Youtube 頻道的影片後，留下來的筆記。
相關連結：
過去在我的其他文章介紹過利用 狀態模式 / 狀態機 來控制遊戲程式的流程，是我相當喜歡且穩定的作法。在一般使用狀態機的情境下，所有的 UI 開關都由狀態機中的邏輯決定，UI 本身只是作為畫面表現的客體存在。
不過若用狀態機做為開發的專案核心，則代表會需要有一套是先架構的核心系統。如果是臨時的小型 prototype，或者在 game jam 環境展開的專案，引入一套架構並要新成員馬上建立起使用規範來利用這套系統，是有點不實際的。
所以是否有擺脫狀態機，甚至沒有一個集中式核心的小型替代方案可以用來管理流程跟 UI 切換呢？本文便是以此為出發點，所做的一個嘗試。
前天寫了篇文章《[Unity] 物件池的實現 – Practicing of Object Pool》討論 物件池 (Object Pool) 的使用目的，以及一個簡單的實作例子。
本文是要介紹另外一個新出爐的實作方式，考慮跟 Unity 機制做配合，以改善下面兩點：
繼續閱讀 “[Unity] 另一個物件池的實現 – Another Practicing of Object Pool"
物件池 (Object Pool)，是一個普遍用於遊戲的一個設計模式 (pattern)，目的是為了重複使用一些頻繁被取用的資源，減少 建立、銷毀 的運算消耗，在特定情況下是非常重要的優化手段。
我這邊會試著從硬體原理開始，說明物件池的使用。
《Unity のエディター拡張》後所留下的簡單筆記，第九到十一章。
介紹了 CustomEditor，也就是最常被使用的 自訂 Inspector 操作介面，這幾個章節內容很多，我覺得介紹依舊尚淺而有些不明白。
CustomEditor 真是博大精深的領域！
《Unity のエディター拡張》後所留下的簡單筆記，第六到八章。
前五章以介紹內建的 Editor 功能為主，六到八章開始進入了自訂 EditorGUI 的部分了，然後是 EditorWindow。
閱讀《Unity のエディター拡張》後所留下的簡單筆記，第一到五章。
這是日本 Unity 技術人員 安藤圭吾 針對 Unity Editor 所寫的一本電子書，可透過下方連結看到原文。
鴨仔開發日記 