在 开发 或者 测试发布 游戏时，有时候会因为素材还没有准备就绪，但是需要进行 test play 的情况，这时候打开 dummy 文件功能，可以来避免资源卡住加载问题。
开启方法：
打开游戏场景，比如 Utage 示例的 Sample.scene。
在 Hierarchy 窗口展开定位到 Managers > FileManager。
在 Inspector 窗口中找到 AssetFileManager 组件，鼠标滚轮滑到 Dummy Files 部分。
勾选 Is Enable，设置好 Texture Sound Text Asset 的 dummy 文件。
Ctrl + S 保存场景，完成。
设置完毕后，点击 Play 按钮运行游戏，遇到缺素材文件的时候就不会弹出资源加载错误弹窗了，而是使用 dummy 文件来替代不存在的资源。
2021 年了还是有不少 gal 是用 720p 的游戏分辨率制作的，这让一个主屏使用 1440p 显示器，副屏影音娱乐是 4k 显示屏的用户打 gal 时，使用游戏自带设置切换为全屏后，画面文字双双变糊，实在不是一个很好的游戏体验。
今年 3月份的时候，发现了 来提升观看动画的体验，当时就在想有没有人会开发一个可以让玩游戏时也能用 Anime4K 算法来提升游戏画质，后面 AMD 也推出了个 FSR 算法也是提升游戏画质的，在 GitHub 上以 Anime4K FSR 关键字搜索时，看到 Magpie 这个项目，看介绍也支持 Anime4K 算法，隐约感觉到，这一定就是我在寻找的软件。
引用一下官方 Repo 的介绍：
Magpie可以将任意窗口放大至全屏，支持多种高级缩放算法，包括Lanczos、Anime4K、FSR、FSRCNNX等。
主要用于游戏窗口的放大显示，适用于不支持全屏模式，或者内置的全屏模式会使画面模糊的情况。
下载完打开试用后，果然，这个软件是新时代玩 gal 必备的神器！
当然，使用算法实时渲染提升画质，对显卡来说是有性能要求的，所以要想畅玩享受全屏清晰画质 gal 的话，一个相对来说好点显卡是必须的。
Magpie 项目下载地址：https://github.com/Blinue/Magpie
强烈推荐尝试一下，玩上古游戏使用 Magpie 全屏放大显示，画质提升效果也是很不错的。
看了下 bitbucket repo 记录，第一次使用 python 来写脚本处理文件是在 2017 年左右。当时是为了将翻译后的英文 txt 经过一些处理，导出为 csv 格式，以便校对后导出多语言演出脚本，也不是什么复杂的处理，就用 python 写了个脚本，应该是第一次实际使用 python 的样子。
之后，由于在开发游戏的过程中，会遇到一些比较繁琐，具有重复性，又有一定规律的需求的问题需要被解决，我也化身成为捕蟒人（python hunter）写了不少脚本。这里记录分享一些比较有意思的需求和解决思路仅供参考。
在制作游戏体验版时，往往需要把正在开发的项目中未使用过的资源给删除掉，再打包制作出来一个试玩版发布给玩家体验游玩。这个时候有 2 种思路
解析演出脚本，将演出中使用过的图片，音乐素材给提取出来相对来说更不容易出错。
这边写的脚本也是这样子去做的。
shutil 标准库里的 copy 方法来复制文件。可以使用 win32com 接口来操作 PS 来隐藏，显示图层后导出图片，示例可参考 Photoshop scripting with Python 这篇文章
krkr2 的 kagex cg 鉴赏配置是一个 csv 文件，里面需要填写每个 cg 文件名。
由于 cg 鉴赏里配置的文件分辨率都是和游戏分辨率大小一致的，并且文件名大多数都是类似 EV01_1 这种，那么按思路来说可以将 data 文件夹里的所有 jpg png 文件都遍历一遍，将需要写入到 cglist 的文件名分组后，就可以导出为 cglist.csv 了。当然最后还是需要人工调整差分显示顺序，删除不需要的）
Pillow 库 里的 Image 类三色绘恋在做手机版移植的时候，最后选择了使用 UTAGE3 这个 Unity Visual Novel Tool 作为系统框架，于是就需要先将 krkr 的 kag 演出脚本转换成 utage3 可以运行的演出脚本。
处理思路很简单：
但写起来挺难受的。
因为 utage3 的指令和 kag 指令的设计差别实在是太大了，再加上 kagex 的 world 功能提供的简单语法，又需要转换为新的指令。
移植这工作，做起来是一堆问题需要处理。
openpyxl load_workbook 时设置 read_only=True 来处理。参考 Read-only modeWorkbook 时，设置 write_only=True 。参考 Write-only mode解析剧本人名和台词后
样式设置参考 openpyxl 的 styles
由于自己非常好奇用 macOS 玩 Galgame 的体验，为了浇灭这股奇怪的欲望，我花了将近一周的时间用 MacBook Pro 15.4 2019 这台机器玩了下 しらたま 老师的最新作：星空鉄道とシロの旅。
这篇文章将作为自己拔草的总结。
在 macOS 下玩游戏，首先想到的是 BootCamp，毕竟这个是苹果官方出的安装 Windows 操作系统的方法，手里这台 2019 年的 MacBook Pro 15寸，在公司采购之后，我拿到手没多久，就用 BootCamp 工具安装了当时最新版的 Windows 10。
不过使用 BootCamp 安装了 Windows 10 之后，用了没多久，我就不想继续启动了，原因很简单，我有性能更强的台式机，为啥还要用这台笔记本呢。（这是最初种草结束的世界线之一。）
扯淡归扯淡，其实就是想边使用 macOS 下的软件，边玩黄油，为了满足这个需求，接下来就需要虚拟机登场了。
提到虚拟机，大多数人首先想到的就是 VMware Workstation Pro，不过这个只有 Windows 版，macOS 消费者版本对应的有个 VMware Fusion，在 Big Sur 刚出的时候看到有新闻说 VMware 最新版会为个人免费，自己就想着下载个看看，在花了几分钟时间漫游在很长的介绍对比页面后，点击个人版需要注册什么的，感觉好麻烦，还是点了下 Pro 版本直链下载试用 30天好了。
经过几小时的折腾，终于安装好了 VMware Fusion，选择从 BootCamp 启动虚拟机，配置好 VMware Tools，拷贝好游戏，可以开完了。
先放个对比效果，图1：
上面的是 27寸 2560×1440 分辨率的 Dell S2721DGF，游戏窗口模式下运行。
下面的是 MacBook Pro 15寸，虚拟机分辨率为 2560×1440，游戏全屏模式下运行。
实际观感上游戏对话框字体大小其实是差不多的，2个游戏画面的实际面积也差不多。
在 MacBook Pro 15 上对话框字体是经过缩放后的不锐利的视觉效果，没有点对点，糊糊的。不过图像看起来是要比 S2721DGF 要舒服点，或许是高 PPI 造成的错觉？
嘛，没有那种看了之后就回不去的震撼感就对了。
去年有段时间，很想买个 Surface Pro 来玩黄油，不过最终因为价格劝退，没入手。
不过自己目前主力是使用的 Windows 设备，没上大学的时候那么关注 macOS 更新，iPad 倒是因为要拿来看漫画，隐约记得在哪个 macOS 系统中加入了个 Side Car（随行） 功能，可以让 iPad 作为 Mac 的副显示器用，趁着这次测试正好试试看看拿来玩 gal 怎么样。
Side Car 连接上之后，iPad 显示效果还是很不错的，文字渲染质量和图片质量都不错，甚至把我曾经想用 4:3 比例的显示器的欲望都除草了。
游戏画面显示效果，我甚至有点不敢相信自己的眼睛，感觉游戏对话比 MacBook Pro 内置屏幕上的更清晰点。（当然依然不是点对点，不锐利。）
在立绘进行移动的时候（入场，离场动作）会有轻微跳帧，可以接受。（比 Duet 用线连接时候的效果好很多。）
用 iPad 的时候，声音输出还是使用的 MacBook Pro，在系统设置里看了下也不能更改输出到 iPad。
正当我躺在床上模拟场景的时候，突然想到有个每天只在上下班地铁用不到 1h 的 AirPods（初代），连接上耳机后，声音终于不是在右边桌子上听到了，舒服多了。
MacBook Pro 开 Side Car 运行游戏到 iPad 上，音频输出使用 AirPods。
这个搭配拿来躺床上玩エロゲ岂不是很爽？！
不过致命缺点是 Side Car 下的 iPad 是不能模拟鼠标点击的，很遗憾，只能开 Auto 模式推游戏。这对必须使用 Ctrl 来推エロゲHS的我是不能忍受的。
可是最后还是买了台 MacBook Air M1 来当打字机，上网冲浪专用机了。
开了一个系列来记录下在开发过程中遇到的问题。
这里面有些是 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，但后面一句又一句的请自力扩张，让我不敢用到项目上。(你太菜了。)