2021 年我的 GALGAME 游玩和开发时间统计

已经 2022 年 1月 1日了,又到了一年一度数据党公布年度统计结果的时候了。

以下是我个人的 GALGAME 游玩时间和开发时间,以及其它时间统计的数据结果。

有兴趣可以看,不看也行,随便。(早上好,不好也行,随便。

时间统计

依旧是使用 ManicTime 这款软件进行自动统计的结果。

XPS 8930

  • Web Browsing 778h

  • Game 623h

    •  

    • 雷电模拟器(公主连接R) 79h37m

    • poi(舰队Collection)35h40m

    • ゆきいろ 33h50m

    • そらいろ 33h29m

    • レコンキスタ 31h32m

    • yourdiary+H 30h46m

    • White -blanche comme la lune- 29h33m

    • さくらの雲*スカアレットの恋 29h

    • 創作彼女の恋愛公式 27h30m

    • 嫁探しが捗りすぎてヤバい。 23h47m

    • 思い出抱えてアイにコイ!! 19h53m

    • ラムネ2 18h57m

    • 俺の恋天使がポンコツすぎてコワ~い。 18h33m

    • ラムネ 17h40m

    • ウチはもう、延期できない。13.85h

    • 朱-Aka- 13.45h

    • アインシュタインより愛を込めて APOLLOCRISIS 9h22m

    • アメサラサ 12h18m

    • みずいろ 9h45m

    • 銀色 7h25m

    • さくら、もゆ。 -as the Night’s,Reincarnation- 5h49m

    • Whiteちょこっとファンディスク 5h9m

    • 以及其它

  • Social 342h

  • Video 99h

  • Utils 89h

  • Development 43.45h

百分比: 1974.45 / 2065.43 = 95.595%

这么看来,今年一共打了 600 多小时的游戏,Windows 电脑就是拿来打游戏的!(叉腰.jpg)

除了玩游戏就是刷油管和推,在家就是网络废人,游戏废人,娱乐至死。

不过看着这时间统计,娱乐确实很爽,生产很苦逼,虽然刚开始可能做起来很舒服,但是随着时间投入的增加,项目越来越大,最后激情就会被磨灭,能在一个相对合理的时间内做完一个作品,完成一件让自己感到有成就感的事情,不容易。

世界上根本不存在什么没有成本的东西,什么都是成本,就算只是坐在电脑前玩游戏,投入的时间,喝的肥宅快乐水(无糖可乐),也是成本。但只要能让自己感到快乐,那些所需要的成本,又算个啥。

R7000P

  • Software Development 624h

  • Web Browsing 575h

  • Social 321h

  • Util 127h

  • Game 125h

百分比:1645 / 1845 = 89%

这么一看,纯开发占时间有 (624+127) / 1845 = 40%

开发这个统计是需要算上文件管理器处理文件的耗费时间的,不算的话就只有 33% 了,这种繁琐的但少不了的必要步骤,真是时间大杀器。

如果再算上查文档和学习资料的话,占比应该是有 50%

社交对接耗费时间就不好算了,比较复杂。

结论

2065.43 + 1845 = 3910.43 / 365 = 10.71351h

2021 年每天花费在使用电脑的时间上平均 10.7 小时。

这个数字有多准确,我也不清楚,但是应该能大致反应一些问题。

生产与消费

以玩游戏和制作游戏为例。

一个需要玩家花费几小时来体验的游戏,可能需要很多制作人员投入几百个小时的时间去制作,在这种投入产出消费比完全不对等的情况下,对于制作人员来说,作品做出来了,自己的工作已经到了生产阶段的结束。

后续等待的就是 消费者 对于这个作品的评价。

  • 大家的评价不错,那自然开心。

  • 大家的评价褒贬不一,那作为生产者需要思考一下,为什么会这样子。

  • 大家的评价都很差,那作为生产者,也许自己的方向不是很对,但凡能做出一个值得让大家肯定的地方,也不至于差评如潮。

创作本身是一个自我表现的过程,而作品是创作的结果,结果没有令自己或观众满意,那一定是哪里出了问题,要么是自己的错,要么是世界的错。


分割线


当然,

作为一个生产者,自己投入了几百,几千小时的努力,不管别人评价如何,自己已经做出来了,证明自己可以制作一个这样的作品。

作为一个消费者,自己花钱购买了,想怎么玩,就怎么玩,想怎么评价,怎么说,就怎么说,这都是作为消费者的特权,既然你让我看到了这样的作品,那我的感受怎么样,说出来又如何。

也许双方不能达成共识,但现实就是这样子构成的,不会让所有人满意,不会让所有人都得到自己心中的完美答案,双方的时间都是,花了就花了,没办法收回来。

写了这么多,在合适的时机,做合适的事情,将自己的时间投入到自己想做的事情里,让自己过的开心,才是最重要的。

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。

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

 

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

测试 krkr2 最大支持多少分辨率

有点好奇 krkr2 在用使用
drawDevice.preferredDrawer = global.Window.PassThroughDrawDevice.dtDBD3D;

之后,支持最大分辨率是多少。

首先说下测试环境:

krkr2版本:2.31.2013.411

系统:Windows 10 1607

CPU:Intel Core i7 6700HQ

内存:20GB(16GB+4GB)

在 macro.ks 的 initscene 宏里使用 [laycount layers=25 messages=10] 将 layers 和 messages 设置到一个演出层会使用到的大致数字

打开初始化之后,message1 载入一张 1080p 的图片,layer0 载入一张 1080p 的图片。

4k(3840×2160),直接报错

 

2k(2560×1440)可以打开,内存占用接近 920MB,基本可以说告别很多复杂演出。

FHD(1920×1080)将近 570MB,感觉似乎还行,需要进行复杂演出测试。(同时有 10 个左右的 layer/message layer进行演出)

900p(1600×900),在 420MB 左右,感觉还行,如果是保守起见的话,其实 900p 的分辨率也够用了,至少在 1080p 显示器和 4k 显示器上观感比 720p 要好太多了。

720p(1280×720)在 300MB 左右,目前是这样子的,为什么会占用这么多,后面说下吧(x)

为什么内存冷启动,只载入 2 张图(其实还有对话框和一堆按钮)会占用这么多内存呢?

宏观来看:

在使用 [laycount layers=25 messages=10] 之后会把 kag.fore.layers,kag.back.layers,kag.fore.messages,kag.back.messages 都初始化为设置的数量(加起来其实有多达 25+25+10+10=70 个 layer),如果用不了这么多层的话,那将数字设置变小之后,内存占用量会显著减少。

在 FHD layers=25 messages=10 时占用 570MB 左右(图见上面测试的)

在 FHD layers=15 messages=10 时占用 390MB 左右(图见下面)

另外 KAG 和 KAGEX 的内存占用量占用区别也是很大的,KAGEX 中系统增加了许多新的功能,相对的内存占用量也会很大。

不过,目前来看,似乎 900p 和 1080p 的如果演出不是很复杂的话,krkr2 也完全可以用的样子,具体还需要更详细的演出测试来实践。

然后,估计有人会说都 2017 年了,怎么还在用 krkr2 这么老的引擎在做 gal?

下面是窝个人的分析(可能会长,也可能不长,窝也不知道会写多少x):

目前开源的 gal 用的引擎和系统,能做到比 krkr2 + kag3exe3 简单的似乎并不多,并且要达到同样的演出效果投入上可能比上面的搭配要多。

大概就是上面的。(个人感觉,不要相信,根据自己需求做东西最好,别听别人瞎 bb,自己试过才知道到底好不好。)

恩,原本想写下最近玩的 gal 的 系统体验 的,还是等下次更新吧。

入手了 DELL U2718Q 4k 显示器

图超大,流量警告!

图超大,流量警告!

图超大,流量警告!

上面三个 1270*720 分辨率的。

下面两个 1920*1080 分辨率的。

当然同时不可能玩 5 个游戏的,怎么可能同时玩 5 个嘛。

实际情况大概是这样子。(然而也不太可能同时看这么多信息就是。)

接下来又是吃土还债的日子。(虽然已经持续一年了 2333)

显示器接上去调成 1080P 的 HiDPI 开始体验了,重新玩了 2 个小时左右的千恋万花共通线,恩,真长,还是柚子适合老子.jpg(趁机再吹一波,BGM 真好听,画真好看,SD 真搞笑x)

这周基本都在玩 Clover Day’s Plus 杏璃线,双子线,回家棉花糖的汐线(然而因为太长了就还没有正式开始玩……)

至于软件开发相关的,啥时候想写了再写吧。

好了,继续 Clover Day’s Plus 去了。

 

 

整天打黄油,能找到女朋友么,为你未来担忧啊。(来自老爸早上的电话……)

ルリのかさね/Clover Day’s Plus/お家に帰るまでがましまろです/景の海のアペイリア

这周工作日的几天回家后大概就在玩上面那几个游戏,不过除了 ルリのかさね 体验版通了,其她的单人线都没通,都在共通线就是。稍微说下玩的时候的一些看法。

ルリのかさね

因为都是片冈的剧本,和过去的作品都会有一点既视感,不过体验版剧本上还是挺让窝满意的……有几处场景有泪点,画面因为(窝是一个 萝莉控 )看起来棒极了,已入 sofmap 预约特典版。 吃土,吃土,吃土

Clover Day’s Plus

因为某天晚上,某人说某人连 CDP 里的 SD 演出都写不出来,然后窝也没有打通过一条单人线,于是把尘封了好几个月的 CDP 打开重新玩了几小时……。评价的话,没打通要怎么评(x)杏铃好可爱。

お家に帰るまでがましまろです

因为体验版的时候就玩了几个小时,最大的体验和玩千恋万花的时候感受差不多吧『1080P 的画面真清晰,老婆们看起来真细腻。』。

景の海のアペイリア

因为秋野花才去玩的。

看 F娘 也在吐槽最近怎么出的 AI 的越来越多了……

 

非常短的一篇体验文结束。

 

不过说到底,适不适合自己还是需要亲身体会下才知道就是。

 

TEST ON GALGAME PLAY TIME

于是窝花了 5 月份一个月时间来测试一部全价 galgame 慢速 play 所花费的时长是多少。

当然上面说的有误就是。

结果

5 月份

从目前测试的来看,单人线需要 15h 左右(10h 共同线 + 5h 单人线)

Imgur"

上图依次是

Game Title Brand Played Time
恋×シンアイ彼女 Us:track 29h 41min
サノバウィッチ Yuzusoft 18h 6min
ものべの-happy end- Lose 17h 47min

4 月份

Imgur

Game Title Brand Played Time
千恋*万花 Yuzusoft 22h 38min

感想

恋×シンアイ彼女

这个是窝玩的时间最长的将近 30 小时,详细玩了 星奏线 彩音线 终章,小鞠线 和 会长线 暂时还没玩(也不知道未来会不会去玩……),嘛,总之,大概就是 2 个人线 + 终章 将近 30h。

游戏本身的评价来说,个人评分 10/10,不论哪一方面都给我带来了很爽的体验(虽然有些爽的比较 dant 就是。)

サノバウィッチ

宁宁线 clear,RESTART clear,然后其她 2 个人(除了学妹之外)稍微 c 了下,中间有停顿看一些剧情……,时间差不多也是那个样子吧。

游戏评价来说,窝 gal 玩的少,Yuzusoft 脑残粉 10/10 吧。

ものべの-happy end-

心情复杂,因为故事本身比较沉重加上中间不是女主相关剧情太多,3 条个人线都是有些细看,有些 c 过去的,17h 的时间大概是 2 个 + 1 个半没有细玩的个人线吧……

虽说窝也是 Lose 脑残粉,要评分的话……恩,9/10 好了。(额,你的评分真奇怪。是的,不用看的,tan90)

千恋*万花

芳乃线,ムラサメ 线部分 clear 将近 23 小时。芳乃线是没 c 看完的,似乎花费时间也是 14~15 小时。ムラサメ 前半部分和后半部分是细看的,感觉时间上还是挺准确的样子……

评价上,柚子大法好,10/10。不得不说,音乐太洗脑……

生活

5 月份大部分时间都在推游戏……每到周末和晚上的时候就推,以后估计不会这样子做了,太耗费精力和时间了。

倒不是说没有好玩的游戏,只是时间上和个人能力提高所需花费的时间会产生冲突,以至于要想好好分配自己的「能力提高时间」的话必须减少自己的「娱乐时间」,最终结果还是,玩游戏的时间变少了,仅此而已。

Imgur

毕竟 5 月份看上图显示的可是花费了 111h/359h,将近有 1/3 用电脑的时间都在推游戏,这普通情况下做不到的……并且某些天,座在电脑旁的时间能达到 14h 47min,将近 15 小时。

Imgur

这太疯狂了……然后窝看了下 5 月 24 号是因为脖子痛(估计是扭到脖子了)然后请假了一天,那天就从起床之后就坐在电脑旁一直到晚上……一天用电脑时间能 15 小时,怕不是要成仙了(不)。

嘛,一天不超过 12 小时左右是微软 Windows10 的标准,其实还算是比较正常的,虽然大家都在吐槽……

上面所有有关时间统计的图都是使用 RescueTime 来进行统计的。软件挺好的,免费版也够用,能让自己知道自己用电脑时的时间到底花费到哪里去了。(当然如果 3 分钟以上时间没有动鼠标或者键盘的话,会被认定为休眠状态,不会统计使用数据,所以那个时间还是比较可信的……虽然如果你玩 gal 的时候一遍开着 auto,一遍打开 QQ 水群的话,会被认定你一直在水群……)

买买买

这个月因为把助学贷款还清了,不自觉的就剁手了……

转运

尝试了下 baggageforward 转运服务,买了 2 本千恋万花的漫画,运费+手续费花了 1800 JPY 左右……(EMS 1400 JPY),以后花费不超过 8000 JPY 的时候还是不用转运好了……运费还是比较伤的

DMMGame

まいてつ 因为 2016 萌えゲーアワード 在 dmm 上 50%off 想着补票于是就把 DL 版和 HS 大量 patch 给补票了……下载起来挺 dant,5.25g 的 DL 本体,挂了个代理,下了好几个小时……(感觉以后还是实体转运或者代购吧……,就算是补票……)

Kindle Store

把 まいてつ 和 恋×シンアイ彼女 的 Visual Fan Book 入了,挺好的。

感觉剁手有点多,需要自制下。

吃土去。

以上。