使用 Magpie 来提升玩 GALGAME 的体验

2021 年了还是有不少 gal 是用 720p 的游戏分辨率制作的,这让一个主屏使用 1440p 显示器,副屏影音娱乐是 4k 显示屏的用户打 gal 时,使用游戏自带设置切换为全屏后,画面文字双双变糊,实在不是一个很好的游戏体验。

今年 3月份的时候,发现了 使用 mpv 和 Anime4K 播放动画视频 来提升观看动画的体验,当时就在想有没有人会开发一个可以让玩游戏时也能用 Anime4K 算法来提升游戏画质,后面 AMD 也推出了个 FSR 算法也是提升游戏画质的,在 GitHub 上以 Anime4K FSR 关键字搜索时,看到 Magpie 这个项目,看介绍也支持 Anime4K 算法,隐约感觉到,这一定就是我在寻找的软件。

引用一下官方 Repo 的介绍:

Magpie可以将任意窗口放大至全屏,支持多种高级缩放算法,包括Lanczos、Anime4K、FSR、FSRCNNX等。

主要用于游戏窗口的放大显示,适用于不支持全屏模式,或者内置的全屏模式会使画面模糊的情况。

下载完打开试用后,果然,这个软件是新时代玩 gal 必备的神器!

当然,使用算法实时渲染提升画质,对显卡来说是有性能要求的,所以要想畅玩享受全屏清晰画质 gal 的话,一个相对来说好点显卡是必须的。

Magpie 项目下载地址:https://github.com/Blinue/Magpie

强烈推荐尝试一下,玩上古游戏使用 Magpie 全屏放大显示,画质提升效果也是很不错的。

Python 在 Galgame 开发中的应用

看了下 bitbucket repo 记录,第一次使用 python 来写脚本处理文件是在 2017 年左右。当时是为了将翻译后的英文 txt 经过一些处理,导出为 csv 格式,以便校对后导出多语言演出脚本,也不是什么复杂的处理,就用 python 写了个脚本,应该是第一次实际使用 python 的样子。

之后,由于在开发游戏的过程中,会遇到一些比较繁琐,具有重复性,又有一定规律的需求的问题需要被解决,我也化身成为捕蟒人(python hunter)写了不少脚本。这里记录分享一些比较有意思的需求和解决思路仅供参考。

制作体验版时剔除未使用的素材资源

在制作游戏体验版时,往往需要把正在开发的项目中未使用过的资源给删除掉,再打包制作出来一个试玩版发布给玩家体验游玩。这个时候有 2 种思路

  1. 将使用过的资源导出一份作为体验版项目的资源。
  2. 删除未使用的资源。

解析演出脚本,将演出中使用过的图片,音乐素材给提取出来相对来说更不容易出错。

这边写的脚本也是这样子去做的。

  • 核心代码在于使用 shutil 标准库里的 copy 方法来复制文件。
  • csv 操作可以使用标准库里的 csv module

操作 Photoshop 导出立绘表情差分图片

可以使用 win32com 接口来操作 PS 来隐藏,显示图层后导出图片,示例可参考 Photoshop scripting with Python 这篇文章

创建 CG 鉴赏配置 cglist.csv

krkr2 的 kagex cg 鉴赏配置是一个 csv 文件,里面需要填写每个 cg 文件名。

由于 cg 鉴赏里配置的文件分辨率都是和游戏分辨率大小一致的,并且文件名大多数都是类似 EV01_1 这种,那么按思路来说可以将 data 文件夹里的所有 jpg png 文件都遍历一遍,将需要写入到 cglist 的文件名分组后,就可以导出为 cglist.csv 了。当然最后还是需要人工调整差分显示顺序,删除不需要的)

  • 判断图片分辨率大小,需要使用 Pillow 库 里的 Image

转换 KAG 脚本到 UTAGE3 脚本

三色绘恋在做手机版移植的时候,最后选择了使用 UTAGE3 这个 Unity Visual Novel Tool 作为系统框架,于是就需要先将 krkr 的 kag 演出脚本转换成 utage3 可以运行的演出脚本。

处理思路很简单:

  1. 解析 kag 脚本的指令
  2. 转换到 utage 对应的指令(这个过程可简单,可复杂)
  3. 生成 utage 用的 excel 演出脚本文件

但写起来挺难受的。

因为 utage3 的指令和 kag 指令的设计差别实在是太大了,再加上 kagex 的 world 功能提供的简单语法,又需要转换为新的指令。

移植这工作,做起来是一堆问题需要处理。

  • python 操作 excel 的库,可以使用 openpyxl
  • 遇到 excel 文件特别大,在 load_workbook 时设置 read_only=True 来处理。参考 Read-only mode
  • 新建 excel 时,写入数据量大时可以在新建 Workbook 时,设置 write_only=True 。参考 Write-only mode

转换剧本到 cv 台本文件

解析剧本人名和台词后

  • 将非当前角色的台词设置为淡灰色,字号变小。
  • 将当前角色的台词设置为黑色,加粗,加大。
  • 人名 和 台词 使用边框进行区分。

样式设置参考 openpyxlstyles

使用 Apple 生态下的设备玩 Galgame 的体验

由于自己非常好奇用 macOS 玩 Galgame 的体验,为了浇灭这股奇怪的欲望,我花了将近一周的时间用 MacBook Pro 15.4 2019 这台机器玩了下 しらたま 老师的最新作:星空鉄道とシロの旅。

这篇文章将作为自己拔草的总结。

macOS 11.1 Big Sur 和 VMware Fusion

BootCamp

在 macOS 下玩游戏,首先想到的是 BootCamp,毕竟这个是苹果官方出的安装 Windows 操作系统的方法,手里这台 2019 年的 MacBook Pro 15寸,在公司采购之后,我拿到手没多久,就用 BootCamp 工具安装了当时最新版的 Windows 10。
不过使用 BootCamp 安装了 Windows 10 之后,用了没多久,我就不想继续启动了,原因很简单,我有性能更强的台式机,为啥还要用这台笔记本呢。(这是最初种草结束的世界线之一。)
扯淡归扯淡,其实就是想边使用 macOS 下的软件,边玩黄油,为了满足这个需求,接下来就需要虚拟机登场了。

VMware Fusion

提到虚拟机,大多数人首先想到的就是 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 造成的错觉?
嘛,没有那种看了之后就回不去的震撼感就对了。

iPad 和 Side Car

去年有段时间,很想买个 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 和 Utage 来开发 Galgame 时遇到的问题系列 1 之资源加载方式和打包

开了一个系列来记录下在开发过程中遇到的问题。

这里面有些是 Unity 自身的问题,只要使用 Unity 来开发项目都会遇到,有些是使用 Utage 时才会遇到。

目前 Utage 有多种资源加载方式,完整版加载方式可参考 Utage 文档里的 AdvEngineStarter StrageType

  • Local 使用 Resources 加载
  • StreamingAssets 使用 StreamingAssets 加载

这里主要说的是这 2 种资源加载方式和打包(Build)时遇到的问题。

初期开发时最方便的加载方式 Resources

Utage 的 Sample 示例就是使用的 Resouces 方式加载,整个开发过程都很简单:

  1. 放需要用到的资源到 Resources 里指定的文件夹。
  2. 写好项目配置文件。

之后,就可以在演出脚本里使用定义好的 Label 来显示图片等资源了。

方便归方便,随着项目使用的资源文件数量变多,项目变的复杂之后,会遇到下面几个问题。

  • Resources 文件在 Build 的时候超过 4GB 会无法打包。Bug: 4GB limit to Textures in standalone build
  • 打包时间很长。(项目资源数量多的时候,Build 一次耗费 30分钟以上时间。)
  • 打包之后加载图片的时候,有些图片加载失败显示花屏。

这些问题都会导致自己开发了游戏,但是发布的时候却遇到了问题,一般会再开发后期需要进行测试的时候发现,于是开始寻找解决方案。

经过搜索之后发现在 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?

后期开发,发布时使用 StreamingAssets

Utage 在官方教程里有一篇文章介绍如何使用 StreamingAssets 来减小 app 大小的。传送门:StreamigAssets を使ってアプリサイズ削減

使用 StreamingAssets 的优点就是解决了上面的使用 Resources 时出现的问题。

  • 解决了在使用 Resources build 时 .resS 文件大小超过 4GB 时无法 build 问题。

在 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 AssetBundle 很耗时。

第一次 Build 的时候,会给每个资源添加 AssetBundleName,对资源进行 Compress 等操作整个过程非常耗时。

后面 Build 可以选择只将未命名的资源 Rename AssetBundleName,会快点。

  • 开发过程变的更加繁琐

每次导入资源之后,都需要 Build AssetBundle 之后,才能启动游戏来验证资源是否更新了。


那么,我应该使用什么方式来管理加载资源?

当然是自己权衡利弊,自己选择适合该项目的方式啦。

Resources 很方便,但出现无法解决的 build 问题之后,可以试试 StreamingAssets。

StreamingAssets 使用时出现了问题,如果是时间和开发机器配置性能的问题,那都不是问题。顶配 + NVMe SSD 会给你带来更好的开发体验的。

如果是 AssetBundle 的视频不能播放,那 Untiy 官方都没啥 workaround,可以试试第三方插件?

也许 Unity 新推荐的使用 Addressable Assets System 也可以试试?不过这个 Utage 虽然有给 Sample package,但后面一句又一句的请自力扩张,让我不敢用到项目上。(你太菜了。)