在 开发 或者 测试发布 游戏时，有时候会因为素材还没有准备就绪，但是需要进行 test play 的情况，这时候打开 dummy 文件功能，可以来避免资源卡住加载问题。
开启方法：
打开游戏场景，比如 Utage 示例的 Sample.scene。
在 Hierarchy 窗口展开定位到 Managers > FileManager。
在 Inspector 窗口中找到 AssetFileManager 组件，鼠标滚轮滑到 Dummy Files 部分。
勾选 Is Enable，设置好 Texture Sound Text Asset 的 dummy 文件。
Ctrl + S 保存场景，完成。
设置完毕后，点击 Play 按钮运行游戏，遇到缺素材文件的时候就不会弹出资源加载错误弹窗了，而是使用 dummy 文件来替代不存在的资源。
在使用 CaptureImage 指令和 RuleFadeOut 指令组合进行 Transition 的演出时，使用 Ctrl 来 skip 之后，多跑几遍就会内存上涨到爆炸。
详细汇报可看 谷歌论坛帖子地址
在 Report 给开发者之后，过了几小时就回复放出了补丁，效率还是很不错的。
以前的项目里很少用这个组合，目前开发的游戏使用了很多次这个指令在测试运行的时候发现了这个问题。（用 Utage3 的开发者还是少啊，都这么多年了，没人汇报 >_<，不过现在解决 了，可喜可贺，可喜可贺。）
用 Unity 来制作 GALGAME 的坑真不少，Unity 版本升级得踩坑，Asset 导入又慢管理又麻烦，Utage3 也用了这么久，整体来说还是很棒得，但是也有很多令人不爽的地方，但，GAL 开发没有银弹，游戏制作还得继续，踩着开发工具的版本更替，在制作的道路上越走越远。
Resolution
Default Screen Width: 1600
Default Screen Height: 900
Mac App Store Validation: True
Build 窗口里设置：
勾选 Create Xcode Project，导出一个 Xcode 项目包。
然后使用 Xcode 打开 build 之后的项目。
在 Project 栏选中项目，修改 Info 里的
Deployment Target 为 Unity 2019.4.18f1 支持的最低系统版本 10.12
切换到 Build Settings
Architectures:
Build Active Architecture Only 修改 NO 为 YES. （Unity 2019.4.18 不支持 ARM）
打开 Targets 的 Sign & Capabilities
Sign 方式 Automatic manage signing
新增 App Sandbox，勾选下面的权限
使用 Xcode Archive 功能 Build 发行包。
在 Distribute App 的时候，需要先在 App Store Connect 里建好 app 需要的 Identifiers 和 导出 App Store App 需要的 Profiles。
Utage 支持对章节进行拆分演出脚本，这样可以让多位写演出的人同时进行工作，来提高开发效率。游戏后面需要通过更新来修复错别字，或者演出脚本错误的话，也可以进行小文件 patch 更新。（经过压缩的脚本大小都在几百kb 左右。）
当然，有分章节需求的，大多数是有需求从服务器（Server）加载章节和资源，来达到缩小游戏安装大小，然后在启动后下载演出资源。Utage 官方也有这个教程，传送门：任意のチャプターのみロードし、最小限のリソースだけダウンロード
不过他的教程里只写了从 Server 加载时需要进行的设置，没有提使用 StreamingAssets 加载时需要注意的地方。
使用 StreamingAssets 加载方式时：
使用 Server 加载方式时：
基本按照官方教程里设置就可以，示例脚本人家也有提供，有自定义需求的需要自己更改实现。
说自定义需求，大概也就是将 Server 和 Chapter asset 的 url 弄到 json 配置里，在启动游戏的时候从服务器下载最新配置，然后将对应 Runtime 平台的配置下载后加载。
开了一个系列来记录下在开发过程中遇到的问题。
这里面有些是 Unity 自身的问题，只要使用 Unity 来开发项目都会遇到，有些是使用 Utage 时才会遇到。
目前 Utage 有多种资源加载方式，完整版加载方式可参考 Utage 文档里的 AdvEngineStarter StrageType
这里主要说的是这 2 种资源加载方式和打包（Build）时遇到的问题。
Utage 的 Sample 示例就是使用的 Resouces 方式加载，整个开发过程都很简单：
之后，就可以在演出脚本里使用定义好的 Label 来显示图片等资源了。
方便归方便，随着项目使用的资源文件数量变多，项目变的复杂之后，会遇到下面几个问题。
这些问题都会导致自己开发了游戏，但是发布的时候却遇到了问题，一般会再开发后期需要进行测试的时候发现，于是开始寻找解决方案。
经过搜索之后发现在 Unity Tutorial 的 Assets, Resources and AssetBundles 中，Chapter3 的 Resources 里有写到
3.1. Best Practices for the Resources System
Don't use it.
好的，Unity Official 在最佳实践教程里面说 不要使用 Resources。
我们经过专业训练，就算再好笑，我们都不会笑。（哈哈哈哈哈哈）
Unity 在挖了一个坑之后，必然会给你指引去使用另一个新的坑，Resources 使用起来有问题，那不如去试试 StreamingAssets？
Utage 在官方教程里有一篇文章介绍如何使用 StreamingAssets 来减小 app 大小的。传送门：StreamigAssets を使ってアプリサイズ削減
使用 StreamingAssets 的优点就是解决了上面的使用 Resources 时出现的问题。
在 Build 的时候 Unity 会把 StreamingAssets 文件夹里的所有文件拷贝到最终包里面，所以不会出现使用 Resources 的时候，明明 Resources 只有 1.x GB 大小的素材，打包出来之后 .resS 文件体积变的超大。
能做到每次打包时间在 1分钟内，具体时间视电脑配置而定，CPU 和 SSD 性能最影响打包时间。
StreamingAssets 里的素材，不会像使用 Resources 的时候每次 build 都会将 Resources 里的素材进行 compress 等耗时操作。
加载图片时出现花屏这个问题，使用 StreamingAssets 方式没出现。
也许是 Unity 在 Build 时压缩 Texture 生成 .resS 文件的时候 出现错误导致的，也有可能是其它问题，具体原因时什么，我也不清楚。
开始吐槽的分割线
使用 Resources 时出现的问题解决了，那用 StreamingAssets 岂不是很完美？世上哪有这么好的事情，下面来说说使用 StreamingAssets 时出现的问题。
第一次 Build 的时候，会给每个资源添加 AssetBundleName，对资源进行 Compress 等操作整个过程非常耗时。
后面 Build 可以选择只将未命名的资源 Rename AssetBundleName，会快点。
每次导入资源之后，都需要 Build AssetBundle 之后，才能启动游戏来验证资源是否更新了。
那么，我应该使用什么方式来管理加载资源？
当然是自己权衡利弊，自己选择适合该项目的方式啦。
Resources 很方便，但出现无法解决的 build 问题之后，可以试试 StreamingAssets。
StreamingAssets 使用时出现了问题，如果是时间和开发机器配置性能的问题，那都不是问题。顶配 + NVMe SSD 会给你带来更好的开发体验的。
如果是 AssetBundle 的视频不能播放，那 Untiy 官方都没啥 workaround，可以试试第三方插件？
也许 Unity 新推荐的使用 Addressable Assets System 也可以试试？不过这个 Utage 虽然有给 Sample package，但后面一句又一句的请自力扩张，让我不敢用到项目上。(你太菜了。)