使用 吉里吉里2 和 Unity 开发 Galgame 的体验

在分别使用 吉里吉里2 / krkr2 和 Unity 开发过完整的作品之后,现在可以分享对比下我的开发体验结果了。

吉里吉里2 / krkr2 + KAGEX

krkr2 在开发纯文字冒险游戏,体验很好。

  • 硬件配置要求低。
    • 不管是开发硬件要求,还是用户运行硬件要求。
  • 资源性能高效,简单,方便。
    • Image,Sound,Video 放到对应文件夹后,立马可以开始进行脚本修改。
  • 演出脚本调试体验很棒。
    • 修改当前行之后使用重载,可以在不重启游戏的情况下即时预览修改后的当前行演出效果。
  • 打包发布文件体积小,打包步骤简单又快。

Unity + Utage3

在制作 Galgame 之外,有额外的游戏系统和需求的情况下,体验很好。

  • 使用 Unity Editor 开发 UI 简单又方便。
  • Utage 使用 Excel 作为演出脚本,多语言支持很方便。
  • 支持跨平台。
  • Unity 引擎很强大,第三方插件丰富。
    • DOTween 可以很方便的支持各种 Tween 动画。
    • TextMesh Pro 文字显示效果很棒。(切换高分辨率屏幕文字依然清晰锐利。)
    • Colorful FX 的镜头滤镜效果很好用。
    • SoftMask 遮罩效果好用。
    • 支持 Live2D 插件。

虽然 Unity 很强大,但是整体开发体验很差,为什么这样说呢?

  • 资源管理体验很糟糕,耗时。
    • 导入大量 Assets(Texture,Sound)时需要等待(Hold on)很长时间才能开始工作。
    • 你会说这不是等待一次就好了吗?但是,在你切换平台之后,又会进行 Hold on。
    • 那你不会用 Cache Server 吗?用了,效果不好,没节省多少时间,甚至在测试的某些情况下切换平台耗时更多。
    • 能理解 Unity 要对 Asset 进行转换来缓存成 GPU 读取的格式,但是 Hold on 的体验实在是太糟糕了。
  • Asset Bundle Build 很耗时。
    • 有很多人都在抱怨,但是目前并没有很好的解决方案。
  • 内存占用很难优化。
    • 这个一方面是程序员自身的技术能力问题,一方面引擎本身也要背个锅。
  • 开发硬件要求,运行硬件要求高。
    • 导入耗时怎么办?CPU SSD 配置拉满,设备成本飞起来就对了。

以上,就是在使用 吉里吉里2 开发 Tricolour Lovestory 和 Unity 开发 Sunnyrain Lovestory 之后的体验了。

Utage 分章节加载 Galgame 演出脚本时需要注意的地方

Utage 支持对章节进行拆分演出脚本,这样可以让多位写演出的人同时进行工作,来提高开发效率。游戏后面需要通过更新来修复错别字,或者演出脚本错误的话,也可以进行小文件 patch 更新。(经过压缩的脚本大小都在几百kb 左右。)

当然,有分章节需求的,大多数是有需求从服务器(Server)加载章节和资源,来达到缩小游戏安装大小,然后在启动后下载演出资源。Utage 官方也有这个教程,传送门:任意のチャプターのみロードし、最小限のリソースだけダウンロード

不过他的教程里只写了从 Server 加载时需要进行的设置,没有提使用 StreamingAssets 加载时需要注意的地方。

使用 StreamingAssets 加载方式时:

  1. 记得在 AdvEngineStarter 里勾选 Separate Chapter,并将 Chapter Names 填好。
  2. 使用 Resource Converter 的时候也记得勾选 Separate Chapter。

使用 Server 加载方式时:

基本按照官方教程里设置就可以,示例脚本人家也有提供,有自定义需求的需要自己更改实现。

说自定义需求,大概也就是将 Server 和 Chapter asset 的 url 弄到 json 配置里,在启动游戏的时候从服务器下载最新配置,然后将对应 Runtime 平台的配置下载后加载。

Unity 开发 Galgame 时遇到的问题2 内存占用

最近在游戏开发最后阶段,需要在真机上进行测试,内存占用这个问题在 PC 上基本不存在(目前主流玩游戏的 PC 内存容量都在 8GB 以上。),但是在移动设备上,这个情况就不一样了,iPhone 8 发布于 2017年,身边的人有不少还在使用,这个设备是得考虑到兼容列表里的,然而 Apple 给 iPhone 8 的 A11 Bionic 配备了 2GB RAM,不愧是你(Apple)。

吐槽归吐槽,2GB RAM 第三方 app 能使用的安全范围在 1.2GB 左右,峰值超过这个数字,大概率会闪退。

在测试的时候,没经过对 Unity Asset 进行手动压缩设置的情况下,iOS 版本最高内存能跑到 2.X GB,这一看就不行嘛,怎么玩。

该 Google 老师的出场了,在参考下面几个有用链接里的内容之后,开始尝试对素材进行设置

iPhone 6s 之后的机型都支持 astc 图片压缩格式,iOS 就使用这种压缩格式了。

  • 背景使用 astc 8×8
  • 带人物立绘的使用 astc 6×6(需要 Alpha 的选择对应的。)
  • Live2D 贴图,Dicing Sprite 调整 max size 为 2048,压缩格式为 astc 6×6。
  • BGM 设置加载方式为 Compressed in memory。(使用 Decompress on Load 时,占用内存 20MB 以上,调整之后占用 8MB 左右。)

调整完 Import Settings 之后,重新 build AssetBundle 之后,查看 StreamingAssets 占用磁盘空间大小也减少了很多,内存占用也减少了,效果还是非常显著的。

看 Unity 的文档里的说明,能理解为什么这样做,但是现在这样做之后,产生的问题也很烦人,Library 文件夹巨大,切换平台速度巨慢,让人又爱又恨的 Unity。

2020 年在不同显示设备上看漫画的体验

从 COVID-19 新冠肺炎大规模爆发开始到现在,宅在家里已经 2个多月了,这 2个月期间怎么度过的,简单来说和中学时候放暑假的时候差不多,不过现在的心态和以前就不一样了,每天比较焦虑。(还是回忆中的生活比较美,现实太残酷了。)

焦虑归焦虑,生活还是得过,怎么让自己不无聊的度过每一天才是保持自己健康心态的根本,这次补了不少以前看的动画作品,看的时候也开始慢慢尝试一些以前没试过的娱乐方式,漫画就是其中之一。

2017 年的时候有在 Amazon 日区里购买过电子版的漫画和杂志,不过由于观看起来没动画综合体验棒,3分钟热度就过去了,没有深入体验。这次宅在家里的时间实在是太长了,重看 Saki 动画的时候(本篇 + 阿知贺篇 + 全国篇)实在忍不住动画里全国篇只到 8 强的进度,于是便开始追漫画。在看完现有漫画剧情之后看到 BookWalker 和 BookLive 上都有 Saki 第20卷即将发售的消息,于是就在 BookWalker 上购买了电子版。

下图为突然想写这个 post 的时候拍的照片:

上:Dell U2718Q 27 寸 4k

下左:iPad Pro 10.5 下右:MacBook Pro 15.4 (2019)

27寸 4k 显示器上双页看起来很舒服。

MacBook Pro 15 上双页显示之后,单页尺寸和 iPad Pro 10.5 差不多,不过由于使用距离比 iPad Pro 10.5 手持时要远,视觉观感并没有 iPad Pro 10.5 舒服。(如果只有这一个设备的话,使用起来也还不错。)

iPad Pro 10.5 不管从尺寸还是重量握感上都很适合作为看漫画的利器。

要说缺点的话,目前大多数漫画的分辨率都跟不上设备的分辨率,iPad Pro 10.5 横屏显示双页的时候可以明显看到字体很锐利,分辨率和原图很接近,但是横屏的时候字又比较小,长时间看起来比较费力,体验并不好。

没有上镜设备使用体验也简单说下:

Dell U2147H 24寸 1080p,2020年了,1080p 大颗粒看起来实在是比较瞎眼,本能拒绝。

iPhone 11 这么长的屏幕,就中间显示那一小块儿,一言难尽。

看,是个显示设备都能看,要想看的舒服,还是得做下选择。

使用 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,但后面一句又一句的请自力扩张,让我不敢用到项目上。(你太菜了。)

 

Adobe Air Native Extension 开发笔记

这次 mission 的主要内容是将 Facebook 相关的库,Firebase 和 Google 登录的 SDK集成到 Adobe Air Native Extension (ANE)中去。

由于写这个笔记前后时间相差 1周多,中间经历了换电脑,换新开发环境,既有繁体文字又有简体文字。

開發環境

macOS Mojave 10.14.6
Xcode 11.2
IntelliJ IDEA 2019.2.4 Ultimate Edition
Adobe AIR SDK 32
Oracle JDK 8 Update 231

IntelliJ IDEA

如果要使用 IntelliJ IDEA 来开发 Adobe Air/Flex app 的话,需要 Ultimate 版本才能使用。

我已经订阅了很久 JetBrains Toolbox 了,不过使用频率高的只有 Rider,拿来开发正在制作的 Unity 游戏。

在和 Adobe Air 游戏开发者讨论过程中,谈到 Adobe Air 2020 年之后的 SDK 更新的时候,说是被三星的一个开发工作室接手了后续的开发工作,于是我就也去了后续新的官网上查了下,看到 Adobe Air SDK 33 的使用说明,里面有说使用 IDEA 开发 Adobe Air 应用的说明,搜索了一下,按照 IDEA 的文档进行了环境配置之后,就开始进行开发了。

目前 Air SDK 33 不支持 iOS,只支持 Android 打包,最终还是使用 Air SDK 32 进行开发了。

KeyRemap

个人习惯调成了 IntelliJ IDEA Classic

添加外部庫

Shift Shift 打開 Search Everywhere

輸入 Project Structure 打開項目配置

切換到 Modules 裏的 Dependencies

點擊 New 來進

更改最低 iOS linker 版本

更改 linker 中的 minimum ios 版本爲 9.0 之後打包顯示下列錯誤。

Undefined symbols for architecture arm64:

猜測是因爲第三方 Framework 還是沒有打包進去。

Facebook SDK Undefined symbols

Undefined symbols for architecture arm64:
  "___isOSVersionAtLeast", referenced from:
      -[FBSDKApplicationDelegate application:openURL:options:] in FBSDKCoreKit(FBSDKApplicationDelegate.o)
      -[FBSDKApplicationDelegate application:openURL:sourceApplication:annotation:] in FBSDKCoreKit(FBSDKApplicationDelegate.o)
      

看 Adobe 論壇裏討論,是這個樣子

AIR-4198557 @available keyword in ANE causes IPA build to fail

To do this without using a custom DEFINE ( and to use closed source Frameworks which use @available such as latest Firebase )

1. Copy this file /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/cl ang/9.1.0/lib/darwin/libclang_rt.ios.a
to
[AIRSDK_PATH]/lib/aot/lib/libclang_rt.ios.a

2. Add this to your linkerOptions in platform.xml
<linkerOptions>  
  <option>-lclang_rt.ios</option>  
</linkerOptions>  


Hopefully Adobe can add libclang_rt.ios.a to AIR SDK dist

*Credit to Eugene Petrenko @JetBrains
https://jonnyzzz.com/blog/2018/06/05/link-error-2/

Comment by Eoin L.

更換完 clang 編譯器之後可以自動編譯成功了。

ANE 使用 ThirdPartyLibrary 的總結

解決 Facebook 和 Firebase 最新版 SDK 集成的時候出現的編譯問題

  1. 在 Iphone-ARM 文件夾下新建 Frameworks 文件夾,將第三方庫都拷貝到裏面。
  2. 在 iOS 的 platformoptions.xml 里添加對應的 packagedDependency 定義。
<packagedDependencies>
    <!-- Facebook -->
    <packagedDependency>Frameworks/FBSDKLoginKit.framework</packagedDependency>
    <!-- ...示例中省略其它的必须的库配置 -->
</packagedDependencies>

3. 根據 AIR-4198557 @available keyword in ANE causes IPA build to fail 里的解決方法,將 Xcode 里的 clang 編譯器拷貝到 AIRSDK 文件夾對應的位置。

4. 在 linkerOptions 添加 clang 編譯器的 option

<linkerOptions>
    <option>-ios_version_min 9.0</option>
    <option>-lclang_rt.ios</option>
    <option>-rpath @executable_path/Frameworks</option>
</linkerOptions>

5. 打包 ANE,在項目中引用,啓動 app,應該就可以編譯通過了。(第三方庫已經在 packagedDependencies 里定義好了,編譯器會自動查找到 ANE 里面引用的庫進行 auto link,無須手動在 linkerOptions 里定義。)

6. 也可以尝试将第三方库拷贝到 AIRSDK 文件夹里(clang 编译器同级的位置),再尝试进行 ANE 打包。

参考链接:

  1. Adobe AIR SDK from HARMAN FAQ
  2. IntelliJ IDEA ActionScript and Flex
  3. Building a native extension for iOS and Android – Part 3: Building the iOS library | Adobe Developer Connection
  4. Adobe Flash Platform * Building the native library

iPhone 11

9月的时候 Apple 发布了新的 iPhone 11 系列,对我来说,没有令人惊喜的功能更新,唯一让我感到亮点是价格降回 iPhone 6s 那一代差不多的价格。

手中的 6s 在 2016 年 2 月份购入,到现在也用了 3年多,去年换了一次电池,然而续航还是  1 天  2 充令我困扰,iPhone 11 的价格合适,思考之后还是决定购买新 iPhone。

目前使用了 1个半月,使用感受如下:

  1. 每天早上充好电之后,晚上到家还是绿色的电量,比较满意。
  2. 性能上比 6s 确实快了很多,geekbench5 上跑分是 3倍多的结果。
  3. 屏幕太大,重量太重。这个重量问题,在使用了快 2个月之后的现在,拿起 6s(143g)感觉超级轻……下次换机不会选这么 11(194g)重的手机了。

对比 18年初购买的 Android 机器 OnePlus 5T,目前还是 iOS 的软件生态圈适合我。

FaceID 比指纹解锁体验好太多,1Password,付款类 app 都支持,体验是真的不错,并且不用担心自己的面部数据被泄漏

 

艦これ

睡不着觉,好久没更新 blog 了,想恢复更新,写点关于 kancolle 这个游戏,顺便适应下 WP 这个新版的 Visual Editor 。

入坑

在 2018 年 8 月 17日的时候,身边有人在等 kancolle 二期维护结束开服,经过一番推(忽)荐(悠)之后,决定玩一下试试看,于是在服务器维护结束之后,打开了熟悉的 DMM 页面,加载游戏创建帐号,开启了一段养成之旅。

辅助工具之 Poi

玩了几天之后,看 Poi 的航海日志记录是从 2018/08/20 11点左右的时候开始有记录,也就是差不多 3天,在朋友推荐之下,下载了这个辅助工具。

起因是因为看不到船战意高昂(俗称:闪)状态,似乎还有个制空权,BB 和 CA 不会出昼战连击,才开始用的。

(当然,这些名词都是后来经过一段时间学习适应之后才知道的。)

抜錨!連合艦隊、西へ! (2018 年初秋イベント)

作战难度最终选择了:

E1 E2 E3 E4 E5

作为入坑的第一次活动,入场前在低保,入场后依然在低保,不过好在听朋友建议以通关活动为目标,成功拿到所有新船。

这次活动最开心的当然是 Jiji 画的新船 Maestrale。

下面的练度都是基于目前时间 2019/09/30 日的练度从 kc3 里面截图的。

邀撃!ブイン防衛作戦 (2019 年冬イベント)

作战难易度最终选择了:

E1 E2 E3

E3 捞 Johnston 捞到昏迷。

発動!友軍救援「第二次ハワイ作戦」 (2019 年春イベント)

作战难度最终选择了:

E1 E2 E3 E4 E5

我想要 504,特别想要,她不是一般的可爱,她就是那种…

Flecher 真难捞,E4丙都好难 S胜,我太菜了。

E5P1 打捞 150 多把之后终于出了 Saratoga。(boss 点设置空气,真有你的啊.jpg)

欧州方面反撃作戦 発動!「シングル作戦」(2019 年夏イベント)

作战难易度最终选择了:

E1 E2 E3

E1 切血条丁捞到 U-511 和 Richelieu 之后就切甲斩了。(吕500 太可爱太可爱了。)

E2 先切血条丁捞到 Gracale,然后切甲打到斩杀之后,出击了 10多次,每次都是差一口气,考虑了一下,我还是去捞 libe 比较好,于是切乙一把斩掉。

乙太简单了,甲太难了。

打 E3P1 丁难度捞船,在 P1 斩杀局的时候出了 libe,有点后悔切难度了。(不)

E3P2 捞船体验还好,出了四个 Littorio,就是没有 Roma,不过最后还是捞到了,没啥遗憾的。

尾话

目前经过的 4次活动大概是这个样子,说实话,挺肝,挺累的,也挺充实的。

能让自己坚持重复的 click 的动力,我想大概是因为自己想要去听,去看,去观察这个角色,让自己的生活充满 power 吧。

kancolle 在各种设定上很有意思,也只有着实玩过,思考过,参考过现有玩家总结出的经验,体验过 Event 活动的氛围,才能体会到这种「有意思」的点在哪里。

暂时先这样子好了,后面更新会稍微频繁点,把游戏开发过程中遇到的坑分享下。

备注:

  1. 部分副标题是参考日文 kancolle wiki 期间限定活动页面整理的信息。

Summer Pockets

Summer Pockets 可以说是今年玩的新作中最让我感动的了。

没时间的话,下面的就可以不看了.jpg

最初放出消息的时候,是因为剧本是「新岛夕」和音乐是「水月陵」这两位有参与,引起了我很大的兴趣。 原因有下面几点:

  1. 恋 × シンアイ彼女 的主剧本是新岛夕,BGM 是水月陵
  2. はつゆきさくら 的剧本是新岛夕,BGM 是水月陵
  3. あなたに恋する恋愛ルセット 的 BGM 是水月陵

这三部作品的 BGM 我都很喜欢,Summer Pockets 里水月陵负责的那几首曲子的味道也很有水月陵的味道,当然,主要还是曲调悲伤的那几首,很有感觉。

至于新岛夕,喜欢的人,对他的文字挺有感觉的,不喜欢的也不少。

当然,Summer Pockets 是很多人一起共同制作出来的作品,点这两位 staff 的名出来是表明我很在意这两位在这部作品中让大家看到的成果是个什么样子。

在玩了 Summer Pockets 之后我是越来越喜欢剧情锁了,这种让人在欣赏玩几个不同人物的故事之后,很好奇接下来会发生的事情,却不能直接看到结果,在脑里总有一颗石头落不下地的感觉,对,就是这种等不急的感觉,很棒。 前提是每个角色的故事都足够吸引人。

全线通了之后,最喜欢的果然还是鸥线的故事,要来一场令人激动的冒险吗?

下面我还是从自己关注的引擎性能,系统资源占用情况上说说自己的看法好了,其它的自己也不怎么会分析

Summer Pockets 用的也是 SiglusEngine,2017 年 12 月 发售的 金色ラブリッチェ,2018 年 5 月发售的 神待ちサナちゃん 也是 SiglusEngine,分辨率都是 FHD(1080p),性能上来看 金色ラブリッチェ 立绘点头,抖动都有卡顿的感觉,神待ちサナちゃん 有用 E-mote 感觉上稍微好一点,到 Summer Pockets 基本没出现卡顿的情况,似乎还是慢慢做了优化了的。

虽然,SiglusEngine 启动需要磁盘验证,锁日区地区和时间,锁日文 UI 语言还是一如既往的丧心病狂。

内存占用的话,Summer Pockets 平时 177MB~500+MB 的情况多点,最高似乎没见到超过 1GB 的,在用 FHD(1080p)的情况下还有这种内存占用率,挺好的。(SiglusEngine 对 CPU 和 GPU 的要求会高点。)

最后还有一个想要提的演出这个,看 ED staff 上剧本和导演基本都有出现在演出这个职位栏下,还是剧本自己最能把握住想要的演出结果,有几个场景的 画面 运用和 bgm 搭配挺有感染力的。

说了这么多,没把评价和游戏特定场景说出来是本意,游戏还是要自己玩,自己体会才能感受到那种玩游戏的感觉,才能感受到这个游戏给自己带来的感动。

Summer Pockets 剧情上做的挺好的,我很喜欢,谢谢。

我,吹爆,Summer Pockets。

等 VFB 和 OST 发售了都买了吧。

好久没更新了,估计接下来会保证每个月都更新吧,说说当月玩的エロゲ,当然依然是废文。也会更新点日常开发中遇到的问题。总比什么都不做好点。

为啥你说话,会用那么多当然啊???,求求你改改吧。