https://store.steampowered.com/app/1274830/Autopanic/
先快速置入行銷一下開發兩年的遊戲終於快做完了，好累。
總之這篇是半開玩笑稱為：「『我全都要』系 Unity 學習心得、資源總整理」
但因為標題太長所以砍短的文章。
這篇會是一篇綜合過去兩年從零學習 Unity 期間，個人認為幫助相當大的資源總整理，也
因此文章篇幅超級無敵長，建議自行搜尋取用有興趣的部分：
－整體遊戲設計方針
－程序性產生（關卡）
－程序性動畫
－工具開發
－著色器（Shader）
－遊戲機制實作思考
－酷點子
－泛用程式撰寫概念
－泛用 Unity 開發知識
－雜項工具
畢竟才開始兩年，很有可能有個人錯誤認知，如果有的話也還請不吝指正。
由於這些資源對我的幫助極大，有大半原因跟我的背景、想做的遊戲有關，所以先提我的
背景。
個人背景與學習過程參考
我的主要背景是程式相關。由於知道未來的遊戲創作時人力很容易是瓶頸，尤其對素材的
創作這件事情來說，傳統流程基本上人力等同於一切。所以我在學習 Unity 的兩年之中
相對重視的是「泛用性」或者與之有些關聯的「效率」。
我的學習主題非常混亂，講簡單點就是一個「我全都要」的概念。一方面一人分飾多職對
於少人數的獨立遊戲工作室來說很常見，所以我的學習主題基本上朝著全方向發展。而同
時我也重視品質的展現，我希望能做出的成果並不會是傳統獨立遊戲常見的「玩法 / 畫
面」二選一情境，而是以玩法為基礎的同時，還是可以有相當等級的畫面表現。
我認為過去兩年的 Unity 學習經驗中，比起學習 Unity 可以做到些什麼，更準確地來說
是逐漸了解有什麼 Unity 不適合做的事情。
這點其實比想像得困難，因為在我嘗試使用過的各類工具、API 之中，Unity 的文件不只
缺乏協助測試的資訊，經常缺乏程式範例，更重要的是文件描述的準確性、實用性都有很
匱乏的問題。也因此使得測試 Unity 功能性的範疇變成一個在 Unity 學習過程中真正困
難也最有價值的一環。
藉由反覆地測試持續整理出自己知道一定適用的設計、流程，將之發展下去。
總之以下就開始流水帳介紹。
一、整體遊戲設計方針
[Adam Gryu](https://twitter.com/adamgryu ) -
[Crafting A Tiny Open World: A Short Hike Postmortem]
(https://youtu.be/ZW8gWgpptI8 )
（IGDS 的[中文翻譯](https://igdshare.org/content/a_short_hike_postmortem )）
前年三月底看到 Adam Gryu 的這部演講對我來說是整個遊戲開發方針上最具啟蒙價值的
影片。甚至可以說是啟蒙我動手開發遊戲的主因。
演講中提到《A Short Hike》的設計要素有兩個部分特別讓我感到具備價值：
－設計上要在三個月完成
－能省力盡量省
第一點對於現在遊戲不分大小開發週期都以年在計算來說可以說是個重大的衝擊，他的遊
戲想要做到精細的時辰、功能規劃，確保遊戲重要可玩的部分能在三個月內完成。
也就當然必須要第二點的輔助，作者也很明確地提到了很多以限制為優勢的關鍵字成為我
未來拓展研究的基礎：
刻意降低畫面解析度，也因而容易展現獨特美術：
－模型可以相對簡單而不顯單調
－重視色彩配置呈現出的視覺效果
－重視後製效果的使用
善用工具發揮效率，如：
－使用 Unity 第三方套件 Incontrol 管理多種裝置的操作
－使用 Unity 內建套件 Cinemachine 自動管理鏡頭
在開發流程中也重視效率：
－反覆利用自己的多個遊戲專案中使用的程式腳本，而不是一直重寫新的
－直接用 Unity 內建的地形工具
－使用 Triplanar Shader 自動對不同傾角的地形產生對應的外觀
－在極度有必要的時候也不排除自行撰寫工具處理（這裡舉例可以產生河流的工具）
同時也提到說玩家對於獨立遊戲的寬容度是很高的，不會對遊玩影響的 Bug 就不要鑽牛
角尖非得修好不可。後面另外還有一些更泛用的關卡設計、行銷方針討論都相當實用，不
過畢竟就跟 Unity 開發沒有直接關連性，這裡就不多提。
在看完演講後才實際遊玩《A Short Hike》也確實發現：這是一款雖然時長最多只有三個
小時的遊戲，但是提供的遊戲體驗相當圓滿，甚至帶來遠超過各種高 CP 值大量內容的開
放世界遊戲能給我的快樂。
二、程序性產生（關卡）
[Oskar Stålberg](https://twitter.com/OskSta )－
[Wave Function Collapse in Bad North](https://youtu.be/0bcZb-SsnrA )
（之前我也在板上寫過兩篇相關介紹，有興趣可以查我的 ID）
程序性產生（關卡）有很多種，特別受到 Oskar Stålberg 影響而持續使用 Wave
Function Collapse（WFC）的主因在於可控制性：WFC 的基本實作就是隨機找到符合條件
的板塊接上去場地，就像卡卡頌一樣，也因此可用板塊是事先產生的，視覺表現、功能性
都可以被預先限制住。
而程序性產生（關卡）對於戰鬥為主的遊戲也很有幫助，最主要的原因幾乎可以說是：因
為任何產生出來的地形，基本上都會自動變成對玩家某種形式的有效考驗。可以說是偷懶
地省了不少關卡設計的難處，也依然可以寫一些準則避免破壞遊戲體驗的關卡產生。也反
過來對於解謎、無戰鬥遊戲可能就比較難發揮有效作用。
而使用 WFC 進行程序性產生（關卡），也就發揮到了以極少成本製作大量關卡的效果。
三、程序性動畫
[Jakob Wahlberg](https://twitter.com/Jakob_Wahlberg )
（我之前也在板上寫過一篇相關雜談）
老實說程序性動畫，尤其我關注的完全交給程式控制而不仰賴動畫師的部分，可以說是還
在緩慢發展中沒有一個統一的大招或慣例。可能也是因為這樣的設計基本上就是在用程式
模擬真的情境下這些動畫是根據怎樣的物理性質去行動的。
也因此這部分給我最多靈感的莫過於 Jakob Wahlberg 實作出來的各種短片。相較於網路
上一些實用度比較還好的教學，多看在這方面嘗試的人有什麼成果去加以模仿更實際。
當然如果想要比較手把手的教學就可以參考 Codeer 的十步驟製作程序性動畫：
https://www.youtube.com/watch?v=e6Gjhr1IP6w
四、工具開發
[Freya Holmér](https://twitter.com/FreyaHolmer )－
[Tool Dev For Game Devs]
(https://www.youtube.com/playlist?list=PLImQaTpSAdsBKEkUvKxw6p0tpwl7ylw0d )
很長、很扎實的 Unity 工具開發教學。
雖然影片中主要只會設計一組「隨機放置」工具，但是可以藉由這部影片來了解要怎樣寫
出工具介面，將你可以控制的程式範圍擴張到包含 Unity 編輯器本身。
設計正確的工具更可以對遊戲開發過程帶來莫大的影響，可以幫助產生內容、避免錯誤發
生或者只是單純的效率增進。
Freya Holmér 還有製作一系列遊戲數學相關影片，但因為都是我學過的範疇所以沒有看
過。
只知道在國外有人形容 Freya Holmér 是「以一人之姿拯救遊戲界的數學知識」XD
五、著色器（Shader）
Freya Holmér－[Shaders for Game Devs]
(https://www.youtube.com/playlist?list=PLImQaTpSAdsCnJon-Eir92SZMl7tPBS4Z )
[Tomas Sala](https://twitter.com/falconeerdev )－
[與 Unity 合作的詳細訪談](https://youtu.be/5d8tx6K6hkk )
Shader 是個強大的視覺工具。使用得當的話，單靠 Shader 就可以設計出強大的視覺，
甚至可以完全不仰賴美術素材。但當然兩者的結合、配合更能發揮最大效果。
目前我對領域還只是研究階段，還遠遠不是可以在商業遊戲使用的程度。但有限的實驗中
都可以感受到無限的可能性。肯定會在未來至少嘗試一款大幅仰賴自行撰寫 Shader 的作
品。
六、遊戲機制實作思考
[André Cardoso](https://twitter.com/andre_mc )－
[Mix and Jam YouTube 頻道](https://www.youtube.com/c/MixandJam )
以及同一個人與 Unity 合作的 [Prototype 系列]
(https://www.youtube.com/playlist?list=PLX2vGYjWbI0SwlTX_RLSD0JmzUeS0f1OK )
André Cardoso 的影片系列基本上都是選一個遊戲機制，然後完整呈現出實作過程。
除了可以拿來幫助訓練思辨以外，他的專案全都開放下載研究，對於比較能從別人的實作
中學習的人來說，是非常不可多得的資源。
七、酷點子
[Sebastian Lague](https://twitter.com/SebastianLague )－
[YouTube 頻道](https://www.youtube.com/c/SebastianLague )
Sebastian Lague 雖然相對早期有很多實用級教學影片，但是他近期的系列影片我認為價
值比那些更高 XD
他近期的點子大多都是想到一個單純很酷的點子，或是隨機產生一個點子並且嘗試實作出
來。
雖然對於遊戲設計大多沒有直接的幫助，但通常都是非常有趣的議題。對於太長期只在乎
「有用的」遊戲設計概念時，能夠用完全不同的切入角度看待這個工具是很有價值的。
八、泛用程式撰寫概念
[CJ 貓，周明倫](https://twitter.com/theallenchou )－
[遊戲程式系列](http://allenchou.net/game-programming-series/ )
其實不用我介紹吧各位 XDDDD
總之程式系列，其中在我過去兩年反覆發揮效益的就是 Early-Out 式寫法。只能說不是普
通的受益無窮。
而長期維持比較好閱讀、比較好除錯的習慣撰寫程式，也就可以避免大型專案中容易讓程
式碼亂成一團而最終難以處理。
九、泛用 Unity 開發知識
[Game Dev Guide](https://twitter.com/GameDevGuideYT )－
[YouTube 頻道](https://www.youtube.com/channel/UCR35rzd4LLomtQout93gi0w )
Game Dev Guide 在製作主題上雖然比較多在使用者介面、工具開發上，但是觸及主題算
是相當全方面。對於想要了解各式各樣的 Unity 知識的人來說恰到好處。
同時在使用的深度上也大多比較實用級，對我來說跟大量介紹知識但是相對淺的
Brackeys 正好相對。
十、雜項工具
以下列出的工具是在我開發過程中大幅協助到我的工具：
[Shapes](https://acegikmo.com/shapes/ )（$100 但是偶爾會打五折）
一個繪製基本向量圖形的套件，我的遊戲中基本上所有東西都是用 Shapes 繪製的，希望
這樣足以展現出 Shapes 能有多強大 XD 這個套件也是 Freya Holmér 開發的，是個全
方面很 Nice 的人。
[DOTween](http://dotween.demigiant.com/ )（有基本版免費）
由 [Daniele Giardini](https://twitter.com/demigiant ) 製作的 DOTween 是個可以處
理任何「漸進」表現的強大工具。
由於現實世界物理不可能存在速度或加速度恆定的狀態，所以善用漸進函數庫就可以輕易
處理出視覺上宜人的各方面遊戲畫面。
使用 DOTween 只是因為 Mix and Jam 的教學也都使用 DOTween 而已，沒有特別研究過
與其他同類型工具的比較。
[ExposeMethodInEditor](https://gist.github.com/bcatcho/8889240ba154d99169fd )
（免費的程式碼）
一個可以加上 [ExposeMethodInEditor] 標示就自動實作按鈕在腳本上可以執行特定函數
的工具。
對於懶得幫自己的腳本寫編輯器工具的人來說是個非常實用的工具。
但是只在 Play Mode 可以用，而且不能用在有參數需求的函數上。
另外我最近才知道有個叫做
[ContextMenu](https://docs.unity3d.com/ScriptReference/ContextMenu.html )
的標示可以達到類似的效果。
[Array2D](https://github.com/Eldoir/Array2DEditor )（免費的程式碼）
一個可以在編輯器畫面顯示二維矩陣的工具。
老實說......我是用這個設計敵人外觀跟關卡的。
[ReadOnly]
(https://gist.github.com/LotteMakesStuff/c0a3b404524be57574ffa5f8270268ea)
（免費的程式碼）
可以標示 ReadOnly 就讓該變數沒有辦法在編輯器修改的工具。
對於想要讓自己可以直接在腳本上看到除錯用的參數，又怕自己動到的情境下很好用。
[ReorderableListUtility]
(https://github.com/twsiyuan/unity-ReorderableListUtility)
（免費的程式碼）
主要功能有兩個：
自動產生可以重新排序的編輯介面
自動將 Struct 裡面的變數分欄顯示
由於 Unity 2020 引進了將所有 List 都用 Reorderable List 顯示的功能，現在只剩第
二個功能得以發揮。但無論如何對於自動產生有效的編輯器介面來說還是很實用。
[Mesh Combine Wizard]
(https://github.com/sirgru/MeshCombineWizard )
（免費的程式碼）
快速合併模型的工具。
[Noisy Nodes](https://github.com/JimmyCushnie/Noisy-Nodes)（免費的程式碼）
這個套件實作了 Shader Graph 用的 3D 雜訊，拿來做假造的體積雲很方便。
新增一個小參考，大概學完上述的所有東西之後可以帶來的差異是這樣（？
https://imgur.com/wPRT4u6 （影片）
但當然要記得我無論機制還是視覺幾乎都自己寫的程式而已，所以如果有能力善用套件應
該是可以有一些事半功倍的效果啦 XD