前文
事情没有一帆风顺，一直做准备，一直没准备好，有些新路需要探索，有些新坑需要填补。就好比
努力了不一定会成功，但是不努力一定会很舒服。
所以无论如何风雨也终将至，机会留给有准备的人。正所谓
磨刀不误砍柴工 | 工欲善其事，必先利其器 | 有备无患 |
一个道理
最基本的
良好的网络和硬件你得有吧，开发IOS苹果电脑得有一台吧。硬件配置尽量买中高端以上，这些无须多作解释。
软件篇
单刀直入，我聊聊我准备的软件
必须用到的开发软件，没有就做不了的那种
| 名字 | 用途 |
|---|---|
| Unity | 游戏引擎，现在使用Unity Hub进行多版本管理 |
| SourceTree | 项目管理软件，不是平台，也可以选择其它软件替代 |
| Visual Studio | 代码编程，没有VS表示会很难受的那种 |
| Sublime Text | 文本文档，很多时候用到 |
| Affinity Designer | 矢量图像，替代AI的软件 |
| Excel | 图表，我的游戏里面已经离不开了 |
| Snipaste | 截图软件，开机启动的那种 |
| GoldWave | 简单的音效处理 |
| Acrobat DC | PDF 阅读器 |
| ShadowSocks | 你懂的 |
| v2ray | 你也懂的 |
| Chrome | 浏览器，书签已有百，分文件夹整理，浏览器插件能单独写篇文章 |
需要一说的是 SourceTree的安装体验对国内用户不友好，翻墙是其一，帐户注册是其二，但是使用体验我感觉比其它的都好。 项目管理的平台有很多：GitHub、国内的码云、腾讯开发开台（前Coding）选一个就OK。
我经常用到的一些软件
| 软件名 | 用途 |
|---|---|
| Affinity Photo | 像素图像，替代PS的绝佳软件 |
| Dukto | 用于Mac与Win的文件传输 |
| Everything | Window的文件快速浏览与Http共享 |
| 微信与QQ | 很多时候你可以和其它人聊聊人生 |
| 网易云音乐 | 有的时候你需要听听音乐 |
| 百度网盘 | 有时候你需要找一些素材 |
| Beyond Compare | 对比工具，文件夹、文件对比 |
| Word | 写文档 |
| 逍遥模拟器 | 后期上线截图，做视频神器，windows only，Mac上没有好的模拟器 |
| Zoom | 远程会议工具 |
| TeamViewer | 远程协助工具 |
这些软件算是比较常用的，
也聊一下不常用的但在 其它地方还是比较有名的
| 软件名 | 用途 |
|---|---|
| Xmind | 思维导图，随着开发的深入，发现后面几乎都不用了，个人感觉适合多人协作 |
| AxureRP | UE设计，前面还试着使用，后面有了同上软件差不多的感觉，就闲置了 |
| Q-Dir | Windows下的文件资源浏览器，由于自身良好的文件整理习惯，用得也很少 |
| 向日葵 | 接外包的时候用了一下，现在没用了 |
正所谓萝卜青菜各有所爱，看各自爱好和习惯来选择罗~
其它扩展
| 软件名 | 用途 |
|---|---|
| MagicaVoxel | 轻量级体素建立软件 |
| Blender | 是个游戏引擎，我用来做模型动画，好感度随着版本的更新在不断在湮灭 |
| SecureCRT | 连服务器用的命令行工具 |
| SecureFX | 连服务器用的可视化工具 |
手机端
| 软件名 | 用途 |
|---|---|
| TestFlight | Ios测试用 |
| Kitsunebi | 用它看世界 |
| ShadowSock | 之前用它看世界 |
有了这些软件，游戏开发者 的样子就出来了，但是光有这些不行啊，犹如不能上大街裸奔一个道理
为你的开发添砖加瓦，为你添衣加褂
引用业界名言：
不要重复的造轮子
所以开发中，有一些东西是必不可少的，它能提高你的开发效率。
还是从Git项目出发，经常地，我们开发过程中是少不了一些素材的支持的，为了高效的开发，我们应当主动的避免在每一个游戏开始的时候从0开始你的项目，而是你已经积累了一些素材或者工具，直接导入进来用：
资源篇
Unity项目，一套素材有对应Demo场景，且适用性大，使用Git管理，分成多种类，大小最好不要超过10G，不然导入慢
很多资源在Unity商店上都可以进行购买，其它的来源也很多，当你遇到有用的资源时，一定一定要记得：
收集 – 整理 – 上传Git
| 项目名 | 用途 |
|---|---|
| UI资源 | 里面只有UI相关的素材 |
| FX资源 | 即粒子资源 |
| SFX资源 | 即音效资源 |
| 2D资源 | 里面只有2D图片的素材，指角色、场景等 |
| 3D资源 | 里面为3D资源 |
这是比较粗略的分类，我自己的还有细节，比如3D Poly 风格的资源，也就是说按风格来分类。 使用方式简单，把你想要的资源，选择之后，Export UnityPackage，然后在你的项目中Import就OK
此时有了这些，就好比已经拥有 衣柜 的 游戏开发者 了，你可以任意挑选你的 服装 进行组合！
工具篇
指的是你的开发工具或者是Unity的插件。
我把这一块分成了三块，难度积累从低到高 依次为：
- 商店插件
- （自己的）游戏工具
- 游戏系统
商店插件
自己的轮子是轮子，别人的轮子同样也是轮子，跟据地形的情况，选择不同的轮子上路 不要重复造轮子的名言在这里发挥得淋漓尽致，下面列举一些实用的插件：
| 插件名 | 介绍 |
|---|---|
| PlayMaker | 状态机的应用，非常适用于单个UI系统上的表现 |
| iTween | 运动学专用，类似的插件也很多，可根据需求去定制 |
| QHierarchy | 编辑器层级应用插件，在后期我摸索出编辑的写法后，自己开发了类似的插件以替代 |
| A* | 早年间用过的寻路插件，现在仍然在更新，寻路应当好好了解这个 |
| Behavior Designer | 这个拿来写AI比较靠谱 |
等等太多了，我看过太多的用户（知乎的、博客的）说某某插件不好用什么地，其实很大部分是误用，哪些插件适合哪些场合，有讲究，有规律，别乱套。
就像拿PlayMaker写数据结构，跟叫美术去写程序差不多道理，可能能写出来，但是何必呢？
同样的，插件可能会存在生命周期，因为大环境在升级，时代的洪流会冲走经不足考验的插件：
| 插件名 | 介绍 |
|---|---|
| NGUI | NGUI依然在更新，曾经也是业界制作UI系统的主要参考标杆，干掉了不思进取的EZGUI，作者甚至加入了Unity并参与UGUI的制作，后来又离职出来继续更新NGUI，依然有比UGUI更强大的表现相关的组件，但是UGUI已经够方便了，在之后的开发中我可能不会考虑NGUI |
| 2dToolKit | 不得不说这真是一个好插件，分类、使用便捷性、性能处理上都无可替代，可惜的是只支持到Unity2018，我的第1个Unity项目（2012年）正是使用此插件开发，很多超前的（例如现在Unity的TileMap）设计在当时都是其它同类插件望尘莫及的 |
我买了很多插件，有的已经过时，但是他们依然值得我去花那一笔钱，因为在那个时候，这些插件为我节省的工作量远远超过买他们的价值，并且我从中也学习到了很多。
游戏工具
工具非常非常非常重要，如果你想看到自己有所成长，就必须有自己的工具，工具最好单独使用Git项目管理。 单个工具的特征：单个文件夹，有Demo演示场景或者是文档，上手极快，使用简单，在项目中不断迭代优化
我在我的每一个游戏开发完成之后，都会花时间把游戏中哪怕能复用的一点点的代码都 zai（解耦） 出来，并且加工优化，制作成单独的工具，以便日后二次使用
举一些我做的工具的例子：
- ExcelParser – 直接把Excel导出脚本，直接使用
- GlobalParams – 全局静态调用参数，实时修改参数实时生效（Unity Play时），可视化编辑
- LocalData – 本地持久化数据管理，要求可以像GM一样编辑器修改所有数据、静态调用
- Popup UI – UI管理器，要求不写代码，直接通过引用实现所有UI的交互功能
- WayPoint – 路点编辑，要求支持贝赛尔曲线
好的工具有以下几个循环：
在游戏项目（或需求）中产生 – 解耦后自成一体 – 放在下一项目中再次更新迭代
工具为了命名冲突，用单独的命名空间给你的工具分类。
工具的产生太重要了，是程序员的价值体现，也可以作为技术入股的对象，必须集成！！
在这里提一嘴，我的工具代码量，已经超过我任何一款游戏的代码量了。
游戏系统
有一些游戏系统也是需要集成的，这些游戏系统的解耦难度相当的大，由于游戏系统对游戏主体产生直接的关联，所以有的地方需要用到强大的代码设计模式来减少耦合度。
在这里举个例从代码设计角度聊聊签到系统：
- 签到奖励与签到系统无关，签到单向解耦奖励，签到系统只负责：今天是否签到、是否连续签到、连续了几天、以及表现逻辑接口。
- 签到系统需要游戏主体来调用，调用时自动初始化，游戏主体还应当包括签到奖励相关的逻辑。
- 由于签到奖励的解耦，签到页面上的奖励表现只能由游戏主体（或者签到奖励系统）进行设置。
- 玩家响应签到后，签到系统只发起已签到的方法委托，所以游戏主体在签到之前注册签到成功的回调事件！
此设计同时也作用其它游戏系统，当然作为游戏策划的人只能提出需求，需求的解析解构，以及代码设计、逻辑实现是另外一回事。
设计是代码里面非常重要的一环，与其直接对应逻辑简单粗暴地去实现，少数几个脚本应付了事，还不如花费一些用时在设计上，至少说扩展性、可读性、对自身的成长有益无害，也能避免后期一小改让整个代码楼层松动甚至垮塌。
当你在以后的游戏中遇到同样系统时，直接借鉴或者复用一部分，你会发现比从零开始节省了很大部分时间
游戏系统应该：单个系统单个文件夹，一个示例的Demo，Demo里有相应的UI，用的时候可以复制修改的那种。
还是举例一些超级常见的：
- 签到系统
- 成就系统
- 排行榜系统
- 任务系统
- IAP购买系统
游戏系统肯定会依赖于工具，但是系统最好也用单独的Git项目。
有了工具，你会发现你已经有了 武器 ，路途漫长且坎坷，你的武器让你一往无前，披荆斩棘最终到达终点！
总结
总结很重要，在你的一款游戏结束之后，最好马上进行总结（提取有用的资源与代码），因为时间一长，你会忘记那些细节，难度也会拉长。 保持这种习惯非常重要，即使游戏结束之后会产生认知上的疲惫期，克服它，你会感谢你自己。