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