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 发售了都买了吧。

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

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

2017

点击开启 2017 一年份的碎碎念。

原本还准备再拖一段时间再继续写的,不过昨天在玩 よりくれ 进入个人线之后玩了 3个多小时,感觉读不下去了,不如休息下,明天继续写 2017 年的年终碎碎念,于是今天照计划开始继续写碎碎念了。

分话题,一个部分一个部分单独拿出来记录下好了。

设备

用 ThinkPad T460P 当主力机一年,总体上还是很满意的。

不过在 8.17 日的时候入手了 DELL U2718Q 深受 Windows 在高分屏下各种软件不适配的痛苦,脑抽的情况下在 8.27 日的时候下单了个 MacBook Air 13 (2017)i7 + 8G RAM + 128G SSD(7688 RMB)。 到手之后,连上 4k 显示器使用起来是特别棒,然而由于窝日常工作都需要在 Windows 下完成,MBA 就一直在家里放着吃灰,在 2018年 1月底的时候因为需要找一个新的租房,在京东回收上以 3695 RMB 的价格卖出去回血了……(毕竟放着吃灰,不如直接出掉算了。顺便 MBA 的屏幕,我的评价只有 2个字「垃圾」,色彩只能用惨淡来形容了。)

年底回家之后,用以前买的螺丝刀套装拆了 T460P 清理了下 CPU 风扇的灰尘,过完年到武汉之后顺便把买的 2.5英寸 2TB 的 HDD 替换掉现在用的 500G 的 HDD 好了,如果今年开发的时候对硬盘性能有要求的话,看情况入个 2.5英寸的 SSD 替换掉 HDD。(日常还是 gal 占用的空间最大,然而玩 gal 并不需要 SSD)

软件(Software)

时间追踪(Time Tracking)

用了差不多一年的 RescueTime,2018.1 的时候开了个高级会员,下了一份报告,看了下年度时间花费,排名大概是 Social -> Web Browsing -> Game -> Software Development,和日常情景差不多(聊天,上网,游戏,开发)。

在 Telegram 群里有人推荐了 ManicTime,2018 年时间花费记录应该会切换到这个软件上,比 RescueTime 要强大点,当然最大的好处是不用联网。

操作系统(Operating System)

因为目前开发的环境是 Windows 环境必须,在大学用了三年 Mac OS X 之后,毕业后到现在又转回用 Windows,除了 Windows 的一些硬伤(字体渲染)和第三方软件开发者未适配(HiDPI 应用),感觉还行。

当然 エロゲ 基本都是 Windows Only,也就必须用 Windows 了,虽然虚拟机也不是不能用,某些强迫症患者,或者说各种私人观念,还是实体机比较方便。

现在日常日区 Locale + 日文 UI + 东京时区,玩 gal 还是挺方便的,不过遇到必须在中区 Locale 的情况下,需要切换重启,也比较烦就是。

工作(Working)

目前个人活跃度还算可以,2017 年也算做了不少微小的工作

同人

我主要是做些和脚本相关的事情(用 Node.js 写了个把 演出剧本 转换成 演出脚本 的工具)

合作

基本就是把 Steam 插件接入,然后封包上传发布到 Steam。

公司

三色绘恋用的是 吉里吉里2(Engine)+ KAGEX(System)的组合,我主要是负责把系统相关的代码根据需求修改,以及做一些和 UI 上对应的脚本。(这里基本上就是看 krkr2 的 doc,tjs2 的 doc 和 kag 的 doc,然后读源码进行修改自定义。)

不过有些角色在 2018.2.9 日更新的时候,有 400+ 的表情,像导出表情的自动化这种也需要我去写脚本完成,毕竟重复工作量太大。(用 Python + win32com 调用 Photoshop API 来做自动化导出处理。)

因为目前没有想到更好的多语言系统方案,还有像生成英文的脚本这种,也需要写脚本来自动生成。(用 Python 写的自动化处理。)

2017 年从编程语言上来看基本上都是在和 TJS2 JavaScript Python 打交道,虽然没写什么复杂的代码,不过日常拿来用还是可以的。

官网和几个特设页的 HTML 代码也是我写的(设计另有人做,毕竟我不会设计x),可是自我感觉惨不忍睹,嘛,还是设计优先,实现了效果,还行,还行,还行……(不自觉的留下了羞愧的眼泪)我不会写前端。我不会写前端。我不会写前端。

比较好奇日本的会社这个 Workflow 是怎么个流程,然而没有机会参观……

エロゲ(Eroge)

2018.1 月初整理了下 PicPick Screenshot 文件夹,里面只有从 2017.3 月份开始的,并且在玩的时候有些游戏也没截图,这个列表也不完整就是,嘛,窝算是 2017 年入坑エロゲ的。(居然有人是在大学之后工作的第一年才入坑 eroge 的

这个列表可以滑动快速略过

[Laplacian] ニュートンと林檎の樹
[Yuzusoft] 千恋*万花
[ぱれっと] 9-nine - ここのつここのかここのいろ
[Lose] ものべの -happy end-
[SWEET&TEA] 枯れない世界と終わる花
[TYPE-MOON] 魔法使いの夜
[Yuzusoft] サノバウィッチ
[Us:track] 恋 × シンアイ彼女
[Lose] まいてつ
[ALcot] Clover Day's Plus
[ま~まれぇど] お家に帰るまでがましまろです
[CUBE] your diary +H
[ねこねこソフト] ルリのかさね ~いもうと物語り~
[SMEE] Making*Lovers
[Parasol] 桜ひとひら恋もよう
[Curefull Base] ツギハギめいくぴーす -pretending friendship-
[Recette] しゅがてん!-sugarfull tempering-
[あかべぇそふとすりぃ] まほ × ろば -Witches spiritual home-
[RASK] Re:LieF ~親愛なるあなたへ~
[すみっこソフト] あきゆめくくる
[SAMOYED SMILE] 夜巡る、ボクらの迷子教室
[GIGA] 添いカノ ~ぎゅっと抱きしめて~体験版
[Lump of Sugar] 縁りて此の葉は紅に 体験版
[MOONSTONE] 妹ぱらだいす!3体験版
[ねこねこソフト] すみれ

然后,窝需要单独拿出来几个说说

サノバウィッチ

2016 年底窝玩 千恋万花 的时候还不知道 柚子社,那个时候也确实不知道 Developer 是谁(信息不自觉型无视),不过在群里聊天的时候,有人推荐窝去玩下 魔女的夜宴 这作,玩了之后就一发不可收拾,如果没有 ReStart 的话,刀片不可避。

然后就开始在意 brand(品牌)了,魔女的夜宴挺不错的,让窝知道了 Yuzusoft 和相关的画师,剧本,各种对应职位的 staff,在通了宁宁线之后,可以转到下一个作品。

恋 × シンアイ彼女

如果说 Sanoba Witch 让窝知道了一些 staff 的话,那 koikakei 是让我脑子记住了可能这几年之内都会忘不了的那几位 staff。

主剧本担当的新岛夕,原画之一的きみしま青,音乐制作的水月陵。

koikakei 这个作品让我产生了一种「到底发生了什么事情,能让创作者做出这样的作品」,这个作品想要表达出来的东西,令我难以忘记。

まほxろば 剧情就比较平淡了,虽然こなつ很可爱,但是……bug 比较致命,可以说是年度程序 bug 甚至能让人拿出来专门说的程度了。

your diary +H

your diary 在大学的时候有一个好朋友有段时间很沉迷,不过我当时沉迷看新番补旧番,不玩 eroge,时至今日,因为片头曲,OP,カントク以及工作上一个演出需求的效果,尝试扫雷了下。

ゆあ,可爱。

不过在 clear 了一条线之后,故事虽说没有那种难以忘怀的感觉,但是 bgm 所营造的氛围可以说也是那种可遇不可求的作品之一了。(Duca 的 OP 曲实在是好听的不得了。)

ルリのかさね ~いもうと物語り~

这是我第一部入正的 エロゲ

原本在公司里有看到过 ラムネ2的周边,不过没太在意,正好不知道是几月份的时候 ruri 出了体验版,玩了下感觉有点意思,就试着在 sofmap 上预定了下,然后不出意料的,跳票了 233。嘛,10月底的时候发售了,拿到手的时候,我已经 clear 了 ruri 线,剧情(催泪,哭死我),音乐,CG 都挺好的。

至于猫猫社和片冈不得不说的秘密(雾)其实并没有,原本 OP 发出来的时候因为公司里有人也参与了视频制作,在 OP 里看到公司的名字出现在制作协力上也是一种神奇的体验。

ルリ很可爱,可爱即正义。

Making*Lovers

一句话送给 Making * Lovers(个人评价)

2017 年度最搞笑作品

SMEE 的作品质量还是一如既往,完全 OK,刚发售就完售,实在厉害。剧情里笑梗非常多,OP 也很魔性,循环起来很带感。

夜巡る、ボクらの迷子教室

迷子教室这作可以说是 11 月的一部剧情作,并且今年出的新作里,剧情作排名(个人)可以入前三。(这排名没意思,只是想说,剧情起伏比较大,各种情节也比较现实,总之就是,挺好的。

动态 CG 很实用 =_=

最后

白箱动画里的有一句台词很有趣,大意是:「这个业界充满了怪人,正是因为这样,才有趣。」。大概这也适用于不同的业界,正是因为有很多人,不停的在想做出自己认为有趣的东西,才让观众能够看到一些不同的作品。

作品是由创作者做出来的,在作品有趣的情况下,难免会让人产生一种,为什么作者会这样子做呢?好想问下他/她。

这里可以推荐下 Twitter 这个社交平台,以 エロゲ业界 来说,能在 Twitter 上能找到各个品牌的宣传官推,剧本,原画,声优,音乐制作人,企划,监督,等等职位的创作者。

观察人是一件很有趣的事,能看到不同人的各种行为。(STK