就随便聊聊最近比较上头的一个动画, 上头到看了也买了原作漫画, 甚至不可思议地写了这篇日记来聊. 这是一个几乎没什么剧情可言的动画, 讲了一个嗜烟如命的猫娘和同公寓其他有着各种不良嗜好的猫娘们的屎尿屁日常, 没错, 正是尼古喵喵「ヤニねこ」. 完全可以想象, 这种设定必会劝退大部分人. 因此就算本作作画质量上乘, 我也不会试图向任何人安利这部充斥着令人生理不适的屎尿屁, 低俗成人笑话, 以及影射阴暗现实的黑色幽默的作品. 尽管如此, 我依然”不幸”地被这部作品吸引, 并试图弄明白是怎么回事. 我很难不联想到更早时候播出的丧女, 两者在我的观看体验上似乎有某种相似之处.

首先想到的可能吸引我的便是某种猎奇, 他们都满足部分人窥探他人生活的好奇. 不过在我涉猎范围里, 这也并非是纯正意义上的「グロ」. 只是说在角色选择与故事设定上, 是商业作品中相对少见的类型, 这些设定确实会引起大部分人的观看不适. 大部分的观众多少是带着一种娱乐或欣赏的心态来观看作品, 预期获得的是正面的感受, 像是热血, 爽快, 治愈, 可爱, 而对于人性丑恶的展现通常是反感的. 这类带着丑恶设定的人物是期望作为反派被主角击败出现的, 而且既然都是反派了, 甚至会期望这类人物也有自己”崇高”的邪恶理想, 在某种信仰的高度上是与主角相当的, 我们可能还会说这叫优秀的反派塑造. 要不然, 他就只能是一个卑微的龙套或喽啰, 几乎不会被观众所关注到, 也永远不会有什么高光时刻. 而尼古喵喵与丧女似乎就是让这样的角色成为了主角, 即社会的某种边缘人, 而打败他们的甚至都不是什么残酷的现实, 只是那个不成熟的自己. 丧女是缺少基本的陌生人社交能力而沉溺于幻想. 尼古猫则是缺少基本的自制力而沉溺于当下的享受, 两者可以说是处在相反的极端. 我觉得最有意思和有争议的是, 两部作品能否归类到”搞笑”这个门类. 这种割裂的原因如前所述, 有观众可能并不会觉得看一个人尴尬到死或自甘堕落是用来搞笑的, 因为对于这些观众而言, 这无异于是对”弱者”的嘲笑, 而这又是不道德的, 我完全能够理解.

而对于另一部分观众, 我依然想提示一种可能忽略的理解, 那就是自嘲. 我知道很多人谈论这两部作品都会谈及背后时代背景和社会现象, 这种现实的真实也是构成猎奇感的一部分. 但我一向是不愿意上升到宏大的方面去聊, 更想从个人的角度多谈一点. 就我自己而言, 个人特质也好, 社会影响也罢, 是多少能让我带入其中的角色的, 部分场景也能产生生活经历上的共鸣. 虽然不至于像作品中描述的如此极端, 我也时常在某些社交场合社恐闹出过不少笑话, 也会对一些事物痴迷到上瘾的程度而耽误计划, 过后又悔恨不已, 如此往复. 往往我在自嘲的同时也依然会萌生对角色的同情, 因此就会陷入一种边笑边哭的复杂情绪之中. 不过不同的是, 黑木智子似乎更多时候是处在某种负面情绪之中. 而尼古猫则是一个无可救药的乐天派, 我反而经常反问自己, 有没有可能尼古猫其实真的正过着自己想要的潇洒生活, 这确实能让我释怀一点点.

如果再仔细观察两作, 会发现他们剧作上的一些同构之处. 角色想要去做某事, 用自己不成熟的方法和手段, 最后不出意外地失败. 丧女里是不切实际的妄想, 而尼古猫则是对自身欲望的无底线纵容. 然而出人意料的是, 整个过程中, 世界的周遭都对角色保持开放和善意, 甚至可以说是被深深爱着的, 这种设定无疑使观者情感更加复杂. 比如丧女的父母和各种相遇的人们, 尼古猫的妹妹以及房东邻居的善待, 更别说尼古猫经常翘班, 也总能找到工作攒钱买烟, 这绝对称得上作者最后的善意. 只有如此, 这些角色才能一次次作死而没有任何反思, 这也是作品最不真实的一点, 不得不说这种既现实又童话的微妙感也是吸引我的原因之一. 对我而言, 我甚至会觉得这是这些作品成立的原因. 而反过来, 类似晚安布布, 章鱼噼的原罪这类作品对我就没那么地有吸引力.

我还想再多谈一点尼古猫的生活方式与成瘾行为. 前面提到, 这个温柔的世界是作者创造的乌托邦, 在这个世界里, 角色可以尽情地放纵自己, 而完全不考虑未来, 只追求当下享受. 尼古猫唯一需要付出的努力是打个零工弄到买烟钱, 还经常搞砸. 有烟时受本能支配无所事事, 没钱买烟时则又可以完全抛弃自己的尊严和主体性. 正如我们听闻的一些当代非常边缘的生活方式, 尼古猫对现代人的常识观念也完全没有认知, 什么干净, 整洁, 精致, 健康, 尊严, 效率, 目标. 当她说出常抱怨的那句「にゃーは悪いことしてないのに」时也不带有任何反思, 似乎就是在说「为什么不通过努力就没办法获得快乐呢？」是啊, 为什么呢? 如果从存在主义角度, 一个残酷的真相似乎是, 快乐确实就是需要挣来或者赢得的. 不止快乐, 一切人希望获得的东西与感受都需要你挣扎着做些什么. 如果你认为什么也做不到, 什么也不做, 人单单只能活着(在纸片人的世界里当然不会饿死啦), 还有令人难耐的虚无感. 而缓解这种虚无感最廉价最不需要努力的方式之一正是陷入某种成瘾行为. 我有时甚至会觉得这类行为本身并不真正给人带来快乐, 而只是麻痹了人对于时间的感知. 因为感到虚无时间变短了而获得的某种短暂舒缓的感觉. 它是一种自欺, 人无法在这种行为中保持基本的清醒, 也就无所谓抉不抉择. 当人在某个时刻不经意地意识到现实与自己的有限性时, 就会突然从这个迷梦中惊醒, 再次把我们拉回到那个避无可避的虚无问题面前. 然后呢? 是做些什么, 还是继续成瘾. 类似的成瘾行为其实非常广泛, 绝非局限于使用尼古丁这一类的生理成瘾的物质. 到这里不得不提一嘴奇巧计程车「ODD TAXI」的神回ep.4田中革命, 也深刻探讨了这个心理过程.

尼古猫的活在当下和随性而为也是对我特别有吸引力的部分之一, 这也可以作为她被周围人善待的解释. 在现在优绩主义盛行与效率至上的时代里, 不知怎的, 就是会让我觉得这类特质闪闪发光. 我当然不会认为这种生活方式是一种解法, 那会让我们彻底失去对自我和未来的掌控感. 但她确实带来了反思并揭示了一种可能性, 一种我们有时忽视甚至不敢想象的可能性. 先发散聊这么多吧, 尼古喵喵就动画而言还有太多可以聊, 也有非常多让我有特别感受的场景, 细节与设定. 我看到过网上有一些考据, 确实能感受到制作组非常有想法, 这里就先不展开了.
.
.
.
終わり

为什么写了 konfi

本着找到能用的就绝不手写的原则, 一番检索后, 试了下被提到最多的 Luban. 毫无疑问, 这是一个强大且成熟的导表框架, 有着非常丰富的特性. 但我觉得它在易用性以及和我项目适配上并不太理想. 其配置语法在我看来也还是有点繁琐的. 并且导出的数据格式主要是基于 json, 然后可根据需要再转成其他语言的数据结构. 我个人认为用 json 去描述游戏配置信息并不够好, 比如 json 竟然不支持用整数做 key, 而用整数 id 做主键的配置表则非常普遍. 其实最理想还是直接把配置导出为所用编程语言的数据结构, 在保留信息的同时也方便读取. 另一方面, luban 对于我的项目而言实在有点过于庞大了, 有太多我几乎用不上的特性, 其源码都是我项目的好几倍了… 于是, 我又尝试了一些实现较简单的开源工具, 但大多又已年久失修. 最后想着这类工具反正是一劳永逸的, 需求也不会特别复杂, 不妨就自己实现一个算了.

konfi 的实现也参考了其他的导表工具的设计, 但总体原则是简单, 易用, 可扩展. 简单指核心实现不到千行, 只实现最常用的基础功能. 易用是希望无需额外配置, 直接建表即可运行导出, 配置语法简洁, 统一且符合直觉. 可扩展则是说可以方便地增加或修改导出流程和数据类型, 从而更好地适配项目. 接下来就简单聊聊如何使用以及如何扩展 konfi, 就当是 konfi 的使用文档了. 嘛, 话虽这么说, 其实也不算安利啦, 更多是分享一个思路, 毕竟 konfi 本身就是缺少测试的, 除非你觉得可以解决使用过程中出现的任何问题. 另外, 有些好用但我目前用不上的特性仍在斟酌中, 也暂时没有实现, 在后面会简单提一嘴.

如何使用 konfi

使用篇

有必要先说明一些基础设定. 一般比较常用的有三种配置表, 即枚举表, 数据表, 键值表. 枚举表用于配置项目中的枚举, 便于在整个项目中引用, 比如职业就可以是一个枚举类型, 有剑士, 小偷等职业. 有了枚举之后可以在项目或数据表中引用. 数据表通常包含了最主要的配置内容, 比如游戏中的角色, 物品信息等, 有非常多的属性数据, 角色此时也应当可以使用职业枚举来配置其职业属性. 键值表包含最简单的 key-value 结构, 用于简单的字典结构数据或杂项配置. 以上也可以看出枚举表应该比其他类型的表优先处理, 这样才能引用枚举表的数据.

在这个 repo 的 design 目录中有两个示例的 excel 表格, 演示了常用的一些配置方法. 枚举表因为需要优先导出故通常作为单独的 excel 文件. 为了导出 design 内的配置表, 可以直接运行 export_table.py 这个脚本, 配置将导出到 data 目录下.

运行环境 Python 3.11+, 依赖包括 openpyxl(excel 文件读取) 与 black(Python格式输出).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

from konfi import Exportor

def main():
    table_dir = "./design"
    data_dir = "./data"
    writer_ext = "py"
    enum_tables = { "枚举" }
    
    exportor = Exportor(
        table_dir = table_dir,
        data_dir = data_dir,
        writer_ext = writer_ext,
        enum_tables = enum_tables,
        is_inc = False,
    )
    exportor.run()

if __name__ == "__main__":
    main()

枚举表

先看 枚举.xlsx 文件内容.

test_enum 这个 sheet 中配置了两个枚举类型, 导表过程会先读取一个目录内的所有 excel 文件, 然后逐文件, 逐 sheet 进行导表操作. 使用 _enum 作为后缀名的 sheet 会视为枚举表, 并用枚举表的导表规则进行导出.

konfi 要求表格内容划分为三个区域, 首先是保留的第一列, 主要用来对单行的内容做标记, 比如标记哪些行是配置行. 在上面的例子中, 使用 !var 标记了枚举表所需的一个配置行, 使用 # 标记了一个注释行. 然后是配置行, 配置行的每一列用于描述该列的数据是什么. 枚举表要求 !var 的配置行有 enum_cls, enum_cls_alias, enum_name, enum_alias, enum_val 这 5 列. 最后则是数据行, 即除第一列和配置行以外的右下区域.

以导出 python 数据结构为例, 这个枚举表导出的内容为

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

# 枚举.xlsx/test_enum
# export by konfi

from enum import Enum

class ClassisEnum(Enum):
    """ 职业枚举
    """
    SWORDMAN = 0 # 剑士
    BANDIT   = 1 # 山贼
    ARCHER   = 2 # 弓手
    THIEF    = 3 # 小偷
    MAGE     = 4 # 魔法使


class CombatAttrEnum(Enum):
    """ 战斗属性枚举
    """
    ATK  = 0 # 物攻
    MATK = 1 # 魔攻
    AVO  = 2 # 回避
    HIT  = 3 # 命中
    CRIT = 4 # 暴击
    BLK  = 5 # 格挡

konfi 目前也支持导出 lua 与 json(通过修改 writer_ext 为 lua 或 json), 但我自己只使用 python, 故其他格式的导出支持可能没那么完善. 但理论上通过扩展, konfi 是可以导出任何格式的数据的.

关于枚举表的一些细节

• 枚举值一列需配置整数, 也可以和 python 枚举一样使用 auto 让 konfi 自行决定枚举值.
• 枚举类型在其他配置表中被引用时, 可以使用 枚举名 或 枚举别名 进行配置, 这一点后面我们会看到例子.
• 没错, 使用 # 进行注释也借鉴自 python. 在 konfi 中, 这是一个统一的注释语法, 使用 # 不仅可以注释行, 写在配置行的里也可以注释列, 甚至可以写在 excel 或 sheet 名字前进行注释. 被注释的内容会跳过导出处理.

数据表

接着我们看内容最复杂的数据表, 测试.xlsx/test.test

上表导出的 python 数据结构为

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

# 测试.xlsx/test.test
# export by konfi

# id          : int id
# name        : string 名称
# class       : ClassisEnum? 职业
# level       : int? 等级
# range       : float 攻击距离
# combat_attr : dict_m[CombatAttrEnum,  int] 战斗属性
# combat_attr2: dict[CombatAttrEnum, int] 战斗属性2
# equip       : list_m[int] 装备
# equip2      : list[int] 装备2
# equip3      : set[int] 装备3
from ...enum import ClassisEnum, CombatAttrEnum

test = {
    1001: {
        "id": 1001,
        "name": "皮皮洛",
        "class": ClassisEnum.MAGE,
        "level": 100,
        "range": 1.2,
        "combat_attr": {
            CombatAttrEnum.ATK: 1,
            CombatAttrEnum.MATK: 50,
            CombatAttrEnum.AVO: 10,
            CombatAttrEnum.HIT: 100,
        },
        "combat_attr2": {
            CombatAttrEnum.ATK: 1,
            CombatAttrEnum.MATK: 50,
            CombatAttrEnum.AVO: 10,
            CombatAttrEnum.HIT: 100,
        },
        "equip": [12, 4, 0],
        "equip2": [12, 4, 0],
        "equip3": {2},
    },
    1002: {
        "id": 1002,
        "name": "布库尔",
        "class": ClassisEnum.SWORDMAN,
        "level": None,
        "range": 8.5,
        "combat_attr": {
            CombatAttrEnum.ATK: 50,
            CombatAttrEnum.MATK: 1,
            CombatAttrEnum.AVO: 10,
            CombatAttrEnum.HIT: 100,
        },
        "combat_attr2": {
            CombatAttrEnum.ATK: 50,
            CombatAttrEnum.MATK: 1,
            CombatAttrEnum.AVO: 10,
            CombatAttrEnum.HIT: 100,
        },
        "equip": [11, 2, 34],
        "equip2": [11, 2, 34],
        "equip3": {2, 11, 34},
    },
}

注意到, 这里的 sheet 名是 test.test, 没有后缀说明是一个普通的数据表. 不过名字中使用了 . 作为分割, 点前面的部分作为这个表数据的模块名. 简单来说就是这个表导出的内容会放到 data/test 目录下. 如果没有模块名则会直接放到 data 目录下, 以便于数据管理. 通常同一个功能模块的配置表是单独的一个 excel 文件, 其中的 sheet 使用相同的模块名.

表的第一列出现了几个新的标记

• !var, 配置字段表示一列数据的变量名
• !type, 配置字段表示一列数据的类型名
• !lable, 配置字段表示一列数据的标签名, 用于增加额外说明
• !param, 用于解析列时提供一些额外的用户设定信息, 比如修改数据类型的解析方式. 后面会解释效果.
• 使用 # 进行了行注释, 可以看到第一行也用 # 注释了 can_fly 这一列.

另一个不同是, 数据表本质是一个字典结构, 所以会需要至少一个主键, 在 !var 配置行前加 * 表示主键, konfi 也支持多级主键.

类型系统

类型系统是导表工具要解决的核心问题之一, 一个完善的类型系统会使许多功能的实现成为可能, 比如将数据转成任意语言的原生数据类型, 支持扩展配置的数据类型, 以及进行数据字段的校验等等. konfi 也实现了一个非常简单的类型系统去支持上述这些特性.

类型支持

之所以需要类型, 是因为我们需要告诉游戏程序如何去理解这些配置数据, 比较常见的有整型, 字符串, 布尔类型等等基础类型. 还有一类被称作泛型类型, 或容器类型, 比如列表, 集合, 字典等. 目前 konfi 内置支持的类型有

可以看到这些类型名也都取自 python, 泛型类型的配置方式也类型 python 的类型注释.

可空类型

如果一个指定类型的表格没有配置会发生什么? 例如上面例子中 布库尔的等级 这一数据格就是空的. konfi 也尝试引入了 可空类型(nullable) 这一概念, 用以避免 默认值 与 空值 带来的混乱. 通过在任意类型后加 ? 标记一个类型为可空类型. 可空类型在解析一个空格时会作为空值处理, 在 python 中就是 None. 否则会解析为类型的默认值. 所以上面布库尔的等级其实是导出的 None.

枚举类型

枚举类型是一个非常特别的类型, 因为其依赖枚举表导出的数据. 其使用的配置名即枚举表中的枚举类, 例如上面的 职业 这一列, 使用了枚举表中的 ClassisEnum. 而数据可以填 枚举值 或 枚举别名. 其他用法上与基础类型无异.

泛型类型

konfi 支持的每种泛型类型都有两种配置版本, 单格 与 多格, 可以参考 combat_attr, combat_attr2, equip, equip2 的配置方式. 前面提到 !param 这个标记, 对于单格泛型类型可以用这个标记的配置去修改默认的解析分隔符. 之所以有这个需求是因为如果容器里的类型配置格式比较复杂, 容器默认的分隔符可能被占用, 此时就需要换一个符号来分割. 而对于多格字典类型, 目前使用该标记可以指定配置的字典 key 值.

扩展类型

konfi 支持自定义类型的扩展, 可以自行决定如何解析配置的数据, 不过会需要一些 python 的编码.

分表

另外 konfi 也实现了一个简单的分表功能, 可以把一张大表拆成多个 sheet 进行配置, 在导出时合并为一个整体. 需要保证合并的表的配置行一致. 在例子中有 测试.xlsx/#test.test@test2 这张表, 因为使用了 # 对 test.test@test2 进行了注释, 所以没有导出. 去掉 # 将其导出时, @ 之前的部分表示这个子表在导出时应该合并到 test.test 这个表的数据中.

分表的功能在大型表拆分时会有用, 我暂时是用不到这个功能了, 所以缺少测试.

键值表

键值表是最简单的一种配置表, 通常只需要两列配置项 key 与 val, 例如 测试.xlsx/test_kv, 使用 _kv 后缀的即视为键值表.

导出的 python 数据为

1
2
3
4
5
6
7

# 测试.xlsx/test_kv
# export by konfi
# key: string 键
# val: int 值
test_kv = {
    "移动距离": 5,
}

关于键值表其他就没什么可说的了, 我个人是感觉这个键值表功能上还是有点简单了, val 这一列只能是一种类型, 这在作为杂项表时不太便利. 我在考虑是否应该支持更动态的类型, 比如直接支持配置 python 数据或 json 数据, 这在某些时候还是挺方便的.

其他

以上就是 konfi 主要功能的使用方式了, 这里再补充一些细节和将来可能会考虑实现的特性(请不用抱任何期待)

增量导出

这个还是挺有用的, 特别是配置表比较多, 而改动比较少的时候. 姑且实现了一个简单的, 创建 Exportor 时传入 is_inc = True 即可开启增量导表. 开启后导表会在 data 目录生成一个记录每个 sheet 数据 md5 的 json 文件, 如果没有变化则会跳过导出.

表格依赖

在有些情况下需要规定数据表的导出数据的顺序, 比如进行一些导出后校验等等, 也即此时表格之间是存在依赖关系的, 当前在 konfi 中并没有处理. 仅有的顺序也只是保证 枚举表 的优先导出.

导表效率

选择 python 实现在一定程度上就是用编码效率换运行效率, 尽管如此, 其实也是可以加入多进程导表, 优化导出流程等加速的方案, 但是目前看不到实现计划, 反……反正又不是不能用!

通过配置生成类型

我觉得这算一个比较进阶的功能了(luban 已有实现), 增强了配置表的功能, 也降低了扩展自定义类型的难度. 实现设计上需要非常小心, 感觉弄不好就非常鸡肋. 不过我暂时也用不上就是了.

扩展篇

简单说下 konfi 实现和扩展的思路. 大体思路其实就是先把 sheet 转换为 python 特定的中间数据结构, 然后再把这个数据结构按导出语言进行重构, 写入到配置文件脚本.

konfi 的设计中划分了一些概念, 比如

• 导出器(Exportor), 用于控制整个导表流程
• 解析器(Parser), 用于把一个 sheet 解析为 python 中间类型数据. 每个解析器可以自行决定如何匹配及处理 sheet.
• 类型(EType), 即中间类型, 用于描述 sheet 配置数据.
• 写入器(Writer), 用于把中间数据按特定语言写入到文件导出.

其中的每个部分理论上都可进行扩展. 比如对于解析器, 首先需要继承 Parser 类, 然后有两种方式筛选该 Parser 期望处理的 sheet.

1. 类变量 match 可以直接列出匹配解析 sheet 的名字
2. 实现 filter 函数, 参数为 openpyxl 的 Worksheet
   接着需要实现 parse 方法, 确定 sheet 的导出规则. 可以参考已有的数据表解析器(CommonParser).

类型扩展是更常用的, 比如下面这个用 python tuple 构造的位置类型.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

class EPos(EType):
    """ 位置坐标
        (x, y)
    """
    etype_tag = "pos"
    default = (0, 0)
    
    def __init__(self, val: Any, nullable: bool = False):
        super().__init__(val, nullable)
        self._convert()
        
    def _convert(self):
        if self.val is None:
            if self.nullable:
                self.py_val = None
            else:
                self.py_val = self.__class__.default
            return
        try:
            self.py_val = literal_eval(self.val)
        except ValueError:
            raise ValueError(f"无法将值 {self.val} 转换为 {type(self).__name__}") from None

Enjoy.
.

.

.

.

.

.

.

.

終わり

几天前看到石黑正数转了一个「それ町」20周年问答的推文, 是的, 2025年已经是连载开始的20周年了. 因为看起来有点意思, 自己业余翻译一下, 如有错误翻得不好请见谅. 这里只翻译了问答的部分, 共27问, 感兴趣可以直接去看原文. 话说原文的观感很好, 作者很用心地给每个提问的人配上了对应心情的步鸟截图…

• 原文: 20th Soremachi Anniversary Q&A With Masakazu Ishiguro!
• 原推: Daily Soremachi

注: 文中「それ町」指「それでも町は廻っている」中文官方译名《女仆咖啡厅》. 鉴于官方译名太烂保留使用「それ町」.

这个海外的粉丝团体在去年也有过一个问答, 可以看Q&A With Masakazu Ishiguro on Soremachi, Tengoku Daimakyou and more!. 从这次的问答内容中可以看出, 如果有机会的话, 石黑还是很想画「それ町」后续的, 这一点真可以期待一下. 以及问到石黑创作过程的一些细节. 另外, 到底是谁问想知道步鸟闻起来味道的, 站出来一下, 保证不打死你(老父亲脸).

最后, 「それでも町は廻ている」也是我最喜欢的漫画之一, 再一次向大家安利这部似牛乳般浓郁纯粹的好作品!

Q1 from Internet Lurker:

Hello sensei. Soremachi is one of my favorite slice of life manga along with Yotsubato and Girls’ Last Tour. I always wonder if you ever read other fellow mangaka’s works? if so what are your favorites.

My first time experience with Soremachi was on Twitter, I randomly stumbled upon a fan account of your work which shocked me. The fact that there are people outside of 4chan who know of your work really was unexpected. (The reasons for my surprised was that not many people in western sphere care much for obscure manga with exception being 4chan).

Anyway I was kinda curious if you ever look around internet community outside of Japan before? Sites like 4chan for example have dedicated people who love manga from many kind. You could see people talk about Yokohama Shopping Trip, Yotsubato, Sayonara Zetsubou Sensei to popular stuff like HxH, Berserk, Mushoku Tensei, Pretty series and Aikatsu and even old anime from 80s-90s!

Sorry for the long post though, I hope you have fun reading it.

老师您好, 「それ町」是我最喜欢的日常漫画之一, 与《四叶妹妹》和《少女终末旅行》并列. 我一直想知道您是否读过其他漫画家的作品? 如果有, 您最喜欢的是哪些?

我第一次接触「それ町」是在推特上, 契机是偶然发现了一个您作品的粉丝账号, 这个作品让我感到很震惊. 同时让我没想到的是, 除了4chan之外还有其他人知道您的作品. (我吃惊的原因是, 在西方圈子里, 除了4chan外, 很少有人关注那些冷门漫画).

不管怎么说, 我还是相当好奇您是否曾经关注过日本之外的网络社群. 像4chan这样的社群, 有一群专门喜欢各种类型漫画的人, 你可以看到人们讨论《横滨购物纪行》, 《四叶妹妹》,《再见, 绝望老师》, 到人气漫画像是《全职猎人》, 《剑风传奇》, 《无职转生》, 《美妙系列》, 《偶像活动》甚至80, 90年代的老动画.

抱歉我的提问有点长, 希望你读起来会觉得有趣.

石黑正数:

こんにちは。僕はあまり他の作家の漫画を読まない方でして、子供の頃に影響を受けた漫画を今も繰り返し読んでいます。その中で荒木飛呂彦先生のジョジョはずっと連載が続いているので今も単行本を追っています。

インターネットコミュニティも、普段は海外どころか日本のもほとんど見ないです。見ないようにしていると言えます。

しかし「天国大魔境」のアニメ放映時は海外の視聴者の反応が見られるコミュニティも見に行きました。

你好, 我个人好像确实没有读太多其他漫画家的作品, 小时候受到影响的漫画现在也依然反复在读. 这其中荒木飞吕彦老师的jojo一直连载至今, 现在也会追单行本看.

网上社群也是, 我平时不太关注海外的社群, 甚至是日本国内社群也不怎么看. 倒不如说是故意不去看的.

但是《天国大魔境》动画播放时期, 倒是也去过能看到海外观众反应的社群.

Q2 from Lily, USA:

Hello, Ishiguro-sensei. Thank you so much for creating Soremachi, which is one of my all-time favorite manga. I have to ask: it seems like there were a few moments where you teased a romantic attraction between Kon and Hotori (for example, the chapter where the latter walks in on the former sleeping and the paneling fakes you out into thinking she’ll try to kiss her). Did you ever think of taking this possibility more seriously? Or, underneath the gags, did you only ever conceive of them as having a deep, but platonic friendship?

你好, 石黑老师. 非常感谢你创作了「それ町」, 这是我至今最喜欢的漫画. 我想要问: 在作品里似乎有一些像在是营造绀与步鸟之间恋爱氛围的情节. (例如有一话, 后者走进来时前者在睡觉, 格子的布局似乎让人误以为她想要亲吻她). 你是否有曾经更严肃地想过这个可能性? 又或者, 在这些玩笑背后, 是否只是把她们之间的关系视作一种深厚但纯洁的友谊.

石黑正数:

現時点では友達以上の親密さはあるものの恋愛感情は無いと思います。将来的に状況によっては恋愛感情が芽生えるかもしれないです。
紺先輩→歩鳥はあり得そうですが、歩鳥→紺先輩が想像できないんですよね。

目前她们之间有超越朋友的亲密关系, 但我认为并没有恋爱感情. 未来在某些情况下, 产生恋爱感情也说不定.
从绀学姐对步鸟的角度看, 似乎是有可能的, 但我无法想象步鸟会对绀学姐产生恋爱感情.

Q3 from Sarah G, USA:

Thank you for responding to my previous question! It was really exciting to hear from an author that I like so much.

1. Do you have a favorite chapter of Soremachi? How about a favorite episode of the anime?
2. I noticed that in your works you have a lot of very unique alien designs (which I like a lot). What is the process of designing something like a Hiruko?

感谢回复我上一次的提问! 收到喜欢作者的回复实在是让人激动万分.

1. 在「それ町」中, 您最喜欢的一话是什么? 动画里最喜欢的又是哪一话呢?
2. 我注意到您的作品中有大量独特的外星人的设计(我非常喜欢). 你设计的过程是怎样的, 比如蛭子的设计?

石黑正数:

漫画の中で気に入っているのは15巻の「修学旅行」や歩鳥がオンラインゲームをする回などです。アニメだと「べちこ焼き」の回が好きです。

ヒルコのデザインは、古代の動物や微生物、海洋生物っぽく見えるようデザインしています。そういった図鑑を眺めて、気持ち悪いなぁと思う形をスケッチしてストックしています。それと縄文土器のデザインも参考にしています。

漫画中最喜欢的是15卷毕业旅行(122话)与步鸟玩在线游戏(79话)的那几话. 动画的话, 喜欢「べちこ焼き」那一集.

至于蛭子的设计, 是为了看起来像古代的动物, 微生物, 海洋生物设计的. 我会翻看这类图鉴, 把那些有着让人感到不舒服形态的画下来并存下来. 此外, 也参考了绳文土器的设计.

Q4 from T, USA

I understand that the first epilogue chapter was more than a joke than anything, but hypothetically how accurate was it? Would a grown up Tatsuno actually get fat and marry Sanada?

我知道第一个尾声篇(98话)更多是一个玩笑, 但假设一下, 这个结局的准确度有多高? 长大后的辰野真的会变胖一点并且和真田结婚吗?

石黑正数:

歩鳥なりに本気で考えたリアルな未来なので半分くらいは実現するんじゃないでしょうか。辰野さんも本人が気を抜いたら太るのかもしれません。

这是步鸟认真考虑后的真实未来, 大概有一半可能真的实现吧. 辰野如果本人松懈大意的话说不定真的会变胖.

Q5 from whonever, Chile

It’s a pleasure to be able to ask you something!! Soremachi was an incredible journey, I recently decided to give it a try and it always made me smile, I’ve been wondering if Ishiguro-sensei has any moment that made him smile while working on Soremachi! THANK YOU! 🙏

能向您直接发问真的非常高兴!!
阅读「それ町」是一段绝妙的旅程, 我最近又试着读, 它总能把我逗笑. 我一直想知道石黑老师在创作「それ町」时, 让您笑出来的瞬间! 谢谢!

石黑正数:

描いているキャラクターと同じ表情筋を使ってしまうので、キャラが笑っている時は僕も笑っているし、怒っている時はしかめっ面で描いています。

漫画のネタに自分で笑う事は、あんまりないです。

因为画的过程中总是和角色使用相同的面部表情, 所以角色笑的时候我也在笑, 生气的时候我也皱着眉头画.

对漫画中的梗自己笑出来则基本不太有.

Q6 from Alaino, Brazil

Hello Ishiguro-sensei, I’m a big fan of your work
Was the “Masked Liger” show from Soremachi inspired by any specific rider show or is it just a general idea of one, I loved your suit designs so that always made me curious.

您好, 石黑老师, 我是你作品的头号粉丝.
在「それ町」中出现的假面英雄是受哪个具体的假面骑士启发, 还是仅仅是一个泛泛的概念. 我喜欢你的战斗服设计, 所以一直好奇这一点.

石黑正数:

「平成ライダー」と呼ばれる一連のシリーズに寄せて描いています。とくに「仮面ライダーカブト」のデザインに最も影響を受けていると思います。

我是受所谓”平成骑士”系列的影响画这个角色的. 特别是受”假面骑士甲斗王”的设计影响最深.

Q7 from Boat, Argentina:

Is the usage of teenagers over adults intentional in Heavenly Delusion despite being written in a seinen magazine?

尽管天国大魔境在青年漫画杂志上连载, 但是依然使用青少年而非成人的角色设定, 这个是故意的吗?

石黑正数:

あまり深い意味は無く、日本の漫画は主人公が15～18歳くらいなのが一番メジャーなのでそこに合わせたものです。

ただ、昔から「自分が主人公だったら、その年齢でその行動が可能か？」という事をずっと考えて生きて来たので、主人公の年齢に相応しい行動から逸脱しないよう常に気を配って描いています。

这个设定并没有什么深刻的意味, 因为日本漫画主角15到18岁最为常见, 所以就照着这个设定来做了.

只不过, 从以前开始, 我就一直在思考”如果自己是主角的话, 在那个年龄能做出那种行为吗?”, 所以我总是画得很小心, 确保角色的行为不过于偏离与其年龄相符的范围.

Q8 from Shayb, USA

Who’s your number 1 favorite character from both a series you are a fan of and your own series? And for the character in a series you’re a fan of specifically, did they influence your own original characters at all?

在您喜欢的系列与自己创作的系列中, 谁是最喜欢的角色? 另外, 您喜欢作品的那个角色, 是否有影响到您自己原创角色的创作?

石黑正数:

自分が作った中で一番好きなキャラクターは、時々変わるのですが今はキルコですかね。他の作品の好きなキャラクターは一番を決めるのが難しいくらい沢山います。ジョジョ4部の「仗助」、ルパン対複製人間の「マモー」、ＡＫＩＲＡの「金田」など。

自己创作的作品中最喜欢的角色一直有在变, 当前的话应该是斩子. 其他人的作品喜欢的角色太多了所以很难决出最喜欢的. jojo第四部的仗助, 鲁邦三世鲁邦vs复制人中的马摩, 阿基拉的金田等等.

Q9 from J, USA:

Ishiguro-sensei, I have heard that you are a fan of mystery novels. Have you read any works by the authors Seiryōin Ryūsui (清涼院 流水) or Maijō Ōtarō (舞城 王太郎)?

Do you think Hotori prefers Shimada Sōji (島田 荘司), or Ayatsuji Yukito (綾辻 行人)?

石黑老师, 我听说您是推理小说迷. 您有读到过清凉院流水和舞城王太郎的作品吗?

您认为步鸟会更喜欢岛田庄司还是绫辻行人呢?

石黑正数:

清涼院流水さんと舞城王太郎さんの作品は、全部ではないですが読んだ事があります。20年前はやたらと推理小説を読み漁っていたのですが今はそれほどでもないです。

歩鳥は島田荘司さんが好みだと思います。

清凉院流水与舞城王太郎的作品, 我虽然没有全部, 但读过一些. 20年前我非常喜欢而且阅读了大量推理小说, 但现在没那么沉迷了.

至于步鸟, 我觉得她应该会喜欢岛田庄司.

Q10 from Poko, USA

Both Soremachi and Heavenly Delusion have a lot of complex story lines and details. How do you keep track of it all?

Also, we saw the beginning of Hotori’s writing career but what kind of career would Kon get into after graduating?

无论是「それ町」还是《天国大魔境》都有着大量复杂的故事线和细节. 您是怎么把所有这一切梳理清楚的?

另外, 我们能看到步鸟写作事业的起步, 那么绀学姐毕业后会怎么发展职业呢?

石黑正数:

どちらの作品も大まかなタイムテーブルを作って、細部の整合性は作品を作りつつ合わせています。

この方法は頭が混乱して大変なので解放されたいです。

绀先輩の進路は・・・大学に行った後はわかりません・・・。

这两个作品我都会先制作一个大致的时间表, 细节上的一致性在创作过程中逐步调整.

这种方法会让人头脑混乱, 相当辛苦, 我还是希望能摆脱它.

绀学姐的未来去向…上了大学后就不知道了…

Q11 from Airship, Australia

Hello Ishiguro-sensei! Congratulations on 20 years of Soremachi!

I really loved Murofushi Ryou appearance in Soremachi. She was a very chaotic character and added a different energy compared to Hotori, Tattsun, Kon and more.

What did you wanted to do with her addition to the story?

Were there more stories planned for her as she only appeared in a few chapters in the second half of the story?

What was the inspiration for her character?

石黑老师您好, 「それ町」20周年恭喜!

我真的很喜欢「それ町」中室伏凉的登场, 她是一个非常混乱的角色, 与步鸟, 辰野, 绀等角色相比, 增添了一种非常不同活力.

您带着何种目的让她在故事中登场?

之后有计划创作更多关于她的故事吗? 因为目前她只在故事后半段的少量几话中登场.

这个角色的灵感来源是什么呢?

石黑正数:

室伏涼は、端的に言えば将来的に歩鳥の敵になるかもしれないキャラクターとして登場させました。

ヒーローに対するヴィランです。

歩鳥と似て非なる、歩鳥がたじろいでしまうようなキャラにしたかったので、普段よりもキャラを立てることに尽力したような気がします。

「それ町」の作中での役割は「悪」を受け継ぐ事なので、それ以上登場予定はないですが、未来の話を描くならまた出てくるかもしれません。

室伏凉, 简而言之, 是想作为将来可能成为步鸟敌人的角色登场的.

她是英雄对应的反派.

我想让室伏凉成为一个虽然与步鸟相似, 但又有所不同、能让步鸟感到畏惧的角色. 所以, 我觉得自己在塑造这个角色时比平时还要努力.

因为她在「それ町」中的角色定位是继承”恶”的使命, 所以除此之外没有登场的安排, 但如果会画将来的故事, 她可能会再次登场.

Q12 from zabuzabuzazaa, Australia

When was the last time you cried?

您上一次流泪是什么时候?

石黑正数:

落涙するほど泣いたのは子供が生まれた時だったかと思います。

哭到流眼泪程度的话应该是孩子出生时候.

Q13 from Danny, Germany

If you were to start Soremachi today, but with all of your current knowledge, would you change something?

如果您今天才开始创作「それ町」, 但是拥有您当前所有的知识, 你会做改变吗?

石黑正数:

最初の方のノリが変わると思います。もっと地味な始まり方をするかもしれません。

あと、室伏涼をもっと早い段階で登場させたいです。

我可能会调整故事开始时的节奏. 可能会以更平淡的方式叙事.

另外, 也想让室伏凉在更早的阶段登场.

Q14 from Majin Hotori, USA:

Hello, Ishiguro-sensei. Recently, I finished the Soremachi manga and absolutely adored it. I really appreciated the mid to late 2000s vibe the series has throughout, from bulky, portable DVD players to original DS systems. Did you ever struggle with accidentally putting anachronistic elements as time passed?

Additionally, thank you for creating Kon-senpai. She has some of my favorite expressions drawn to a manga.

您好, 石黑老师. 我最近读完了「それ町」漫画, 非常喜欢. 我特别欣赏这作带有的贯穿2000年代中期到后期的氛围, 从笨重的便携DVD播放器到初版DS系统. 在创作过程中, 随着时间推移, 您有没有遇到不小心加入了时代不符元素的情况?

石黑正数:

描き始めてから終わるまでに、世間ではブラウン管テレビが液晶になり、放送はデジタルに完全移行し、色々な変化がありました・・・。

基本的には思い出の中から話を作っているので時代錯誤な物を間違って描いたことは無いのですが、あえて作中の時代感を曖昧にするため作品後半ではスマホを登場させた事があります。

从开始画到结束, 社会上发生了很多变化, 比如CRT电视变成了液晶电视, 广播完全转向了数字化, 还有各种各样其他的变化…

基本上, 我是从记忆中创造故事的, 所以基本没有错画时代不符的东西. 不过, 为了故意模糊作品中的时代感, 在作品后半部分我确实加入了智能手机的出现.

Q15 from Danny, Germany

1. What is your favourite character that only appeared for a single chapter?
2. Is there a character you wish you would have used more?
3. Have you ever abandoned a story line you planed on making?

1. 在单话登场的角色中, 您最喜欢的是哪位角色呢?
2. 是否有一个角色您想让他再次登场?
3. 您是否有过在创作过程中途放弃一条原本计划好的故事线

石黑正数:

1、「それ町」だと木星人、「天国大魔境」だと地獄夢(ヘルム)ですかね・・・。
2、「天国大魔境」のミチカです。
3、 あります。ネームまで描いて担当さんからＯＫと言われたのに捨てて描き直した事もあります。

1. 「それ町」里的话是木星人, 《天国大魔境》的话则大概是地狱梦.
2. 《天国大魔境》的美千花.
3. 有过. 虽然我已经画到了分镜阶段并得到了编辑的认可, 但还是丢掉重新画过.

Q16 from のつ, 日本

歩鳥は作中でたまに小学生の頃に起きたことや、幼少期にシーサイドで起きた出来事などをわりと鮮明に思い出している(追体験している？)のですが、石黒先生もこういったことが出来る方なのでしょうか。

タケルのエピソードで描かれる男子小学生の様子がめちゃくちゃリアルで、自分では思い出せなかったけれど(確かにこんなことあったな)と共感出来る事ばかりなので面白いです。

女子と遊ぶやつは女だぞ！など、自分もやったわ確かに！という懐かしさがあります。

步鸟在作品中有时会非常清晰地回忆起小学或幼年时期在Seaside发生的事(可说是追溯过去的体验?), 不知道石黑老师是不是也是能做到这类事的人呢?

小猛的几话里对于小学男生的表现刻画得十分真实, 我自己虽然记不起来那些事(好像确实有过这样的事啊)类似感同身受的时刻有好多, 这点也非常有趣.

和女生一起玩的人就是女生哦! 这种话, 我自己以前确实也说过! 这种怀念的感觉油然而生.

石黑正数:

昔の事を思い出したり誰かに話すというのは普通の事だと思っていたのですが・・・。いや多分誰でもできると思います。
のつさんも普段必要がないから思い出さないだけで、切っ掛けや必要性があれば思い出すと思いますよ。

我一直觉得回想起过去的事情和与别人谈论过去都是很普通的事情…不, 我感觉大概谁都能做到吧.
のつさん平时只是因为没有必要才没有去回忆, 如果有个契机或必要性, 我想您一定也是能回想起来的.

Q17 from Nichole, Hong Kong

You are my favourite mangaka of all times! Soremachi ended around the time I was graduating and I still remember how I felt after reading Soremachi for so long. How did you decide that Soremachi was going to end and how did it feel when you finally finished the work? Do you think you will feel the same way for Tengoku Daimakyou?

您一直是我最喜欢的漫画家! 「それ町」是在我毕业那段时间完结的, 但我一直记得读完「それ町」时的感受. 您是如何决定要完结「それ町」的? 当您完成这部作品时是什么感受? 您觉得对于《天国大魔境》也会有同样的感受吗?

石黑正数:

ありがとうございます。

「それ町」を終わらせようと思ったのは、「それ町」におけるパフォーマンスのピークを迎えたと自分の中で思ったからのような気がします。

終わった時は感慨深さもありましたが、「この先の収入はどうしよう？」という不安が強かったです。

多分「天国大魔境」が終わらせた時も、その先の事で不安になるのが今から目に見えています。

非常感谢.

我之所以想要完结「それ町」, 大概是因为在我心里, 这部作品的展现内容差不多到达了极限.

完结的时候虽然也有很深的感慨, 但”接下来的收入怎么办?”这样的不安感更加强烈.

大概《天国大魔境》完结的时候, 也会因为之后的事情而感到不安吧, 这一点现在已经可以预见了.

Q18 from Bacassu, Brazil

Thank you for creating manga, Soremachi is currently my favorite manga and possibly story ever, with Tengoku Daimakyou in second place. I have a few questions:

1. Do you still plan to make more Soremachi content of any kind? If not, how do you see the relationship between Hotori and Kon evolving after the manga, could they really end up working together in a detective agency? What about the relationship between Hotori and Shizuka? I would love to see more content of the 3 of them, they’re my favorite characters.

2. I noticed that, in different chapters of the story, Kon picks up a stick from the ground and carries it with her, which I think is amazing because it’s a mundane detail that adds consistency and realism to the character. How did you keep track of these small details when building such a complex and rich story that took years to complete?

3. What is your favorite Soremachi chapter?

4. What are your favorite mystery and detective novels?

5. How do you feel knowing that, despite not being very famous, your story manages to deeply captivate and inspire readers even overseas? Did you expect something like that when you started creating? Were you at any moment surprised by the emotional depth of your own story?

感谢您创作了这部漫画, 「それ町」不只是我目前最喜欢的漫画, 也可能是我最喜欢的故事作品了, 《天国大魔境》排在第二. 我有几个问题想问:

1. 您是否还打算创作更多其他形式的「それ町」相关的内容? 如果没有, 您认为在漫画结束之后步鸟和绀学姐的关系会怎样发展, 她们真的会在一个侦探事务所里一起工作吗? 步鸟和静姐的关系会怎么发展呢? 我非常想看到更多关于她们三个的故事, 她们是我最爱的几个角色.
2. 我注意到, 在故事的不同章节里, 绀都有从地上捡起一根棍子并随身带着的情节. 我觉得这非常了不起, 因为通过这样一个平凡的小细节, 让角色更具一致性和真实感. 在创作这样一个复杂丰富且花费多年才完成的故事时，您是如何保持关注这些小细节的呢？
3. 在「それ町」中, 您最喜欢哪一话?
4. 您最喜欢的推理小说是什么?
5. 当得知尽管这部作品没有非常出名, 但依然能成功深深打动和激励国内外读者时, 您有什么感受? 在您刚开始创作时有预想到会这样吗? 您有没有曾经对自己创作的故事中蕴含的深厚情感感到惊讶？

石黑正数:

1、今の所「それ町」に新たなエピソードを加える予定は無いのですが、何か機会があれば描くかもしれません。しかし歩鳥は探偵にはならないと思います。

2、各キャラクターは自分自身が投影されていたり、実在の人物のように頭の中に存在していたので、その時々で各キャラクター本人らしい行動を取っているんだろうなぁ、と思っています。あまり自分で管理している気はしないです。

3、1番を決めるのは難しいのですが10巻の「歩鳥の戦争」ですかね。

4、島田荘司の「異邦の騎士」です。

5、海外の方々に読んで頂けるとは当初まったく考えていなかったので、楽しんで頂けたなら嬉しいです！

1. 目前还没有计划为「それ町」增加新的剧情, 不过如果有什么机会的话也许会再画. 只是我想步鸟大概做不了侦探.
2. 每个角色或多或少都有自己的投影, 在我的脑海中就像真实存在的人一样. 我觉得这样会让他们在不同的情境下做出符合自己性格的行为, 我倒并不觉得是有在刻意地控制这些角色.
3. 要选出个第一是很难的, 大概是第十卷的”步鸟的战争”吧.
4. 岛田庄司的《异邦骑士》.
5. 起初完全没想过会有海外的读者阅读，如果大家喜欢的话，我很开心！

Q19 from eita, 日本

Although a lot of eggplant food comes out in Soremachi. Does Mr. Ishiguro like eggplants?

「それ町」中出现了大量的茄子料理. 石黑老师您喜欢茄子吗?

石黑正数:

ナスは好きですが、とくに1番好きという事はなくて。

「それ町」にやたらとナスが出てくるのは、ジャガイモやコーンなみにナスが加工されて使われたら面白いのでは？思ったからです。

虽然我喜欢茄子, 但也说不上特别喜欢.
「それ町」里茄子频繁登场, 是因为我在想, 如果茄子像土豆或玉米那样被各种加工料理的话, 会不会很有趣呢?

Q20 from whonever, Chile

Hello, Ishiguro-sensei! Hotori sure prefer books, but do you think she’d also enjoy the internet if given proper tools and instructions? What kind of stuff would she search for? Thank you!

石黑老师, 您好! 步鸟显然非常喜欢看书, 不过您觉得如果有人给她提供合适的工具和指导, 她也会喜欢上互联网吗? 她会上网查些什么呢? 谢谢!

石黑正数:

「未解決事件」とか「都市伝説」とか「怖い話」、それとしょうもない雑学などを調べるのが目に浮かびます。

我已经可以想象她会去查“未解之谜”, “都市传说”, “恐怖故事”, 还有一些没什么卵用的小知识之类的东西了.

Q21 from Twig, USA

Ishiguro-Sensei, what kind of job do you think Kon will end up getting in the future?

石黑老师, 您觉得绀将来会做什么工作呢?

石黑正数:

よく聞かれるんですが、思い付かないんです。服飾系の大学に行った事になっているので、上手くすればそっち方面の仕事に就くのではないかと。

经常有人问我这个问题, 但我想不出来. 因为设定上是去读了服装设计相关的大学, 如果顺利的话, 大概会从事那方面的工作吧.

Q22 from gubber, Panama

What does Hotori smell like?

步鸟闻起来是什么味道的?

石黑正数:

飾り気がない子なので、前の晩に使った石鹸やシャンプーの匂いがするんじゃないでしょうか。

因为她是个不爱打扮的孩子, 所以可能会带着前一天晚上用的香皂或洗发水的香味吧.

Q23 from DonMayo!, USA

I had a few questions regarding the anime production for the series! With the huge amount of staff behind the production, was there any conflicted/changes you told the head staff?

The anime opening movie had a ton of great key animators, like Nozomu Abe, was it a joy to have Yasuomi Umetsu direct the opening!?

Final question, what was your thoughts of the staff behind the anime Soremachi! You had the great people at studio shaft to create another banger! With my favorite being Ryo Imamura!

我有几个关于这个系列动画的问题! 动画的制作背后涉及很多人, 您有和核心制作团队提出过一些异议或修改建议的地方吗?

这部动画的OP有非常多优秀的动画师参与, 像是阿部望, 这很让人兴奋吧? 梅津泰臣担任了OP导演!?

最后一个问题, 您对于「それ町」动画的幕后制作团队有什么想法! 这次也由出色的Shaft工作室负责制作, 又一部精彩作品! 我最喜欢的今村亮也参与了!

石黑正数:

アニメはアニメの表現方法があるので基本的には現場にお任せする姿勢だったのと、「それ町」の時は結構な回数打ち合わせに参加したので方向性の食い違いというのは無かったです。

梅津泰臣さんは好きなアニメーターなのでＯＰを担当していただいたのは嬉しかったですし、素晴らしいＯＰだと思います。

アニメに関わっていただいたスタッフの皆様には感謝しかないです。

因为动画有其独特的表现方式, 所以我基本是采取交由现场制作团队决定的态度. 而且在「それ町」的动画制作期间我也参加了不少次会议, 因此没有出现方向性的分歧.

梅津泰臣先生是我很喜欢的动画师, 能有幸请他来负责OP让我很开心, 我也觉得这是一个非常精彩的OP.

对参与动画制作的所有工作人员, 我只有满满的感激.

Q24 from Mayday, Malaysia

Congratulations on the 20th anniversary of Soremachi! You had mentioned that Soremachi was initially planned to run for just 4 volumes but it went on to go for 16 volumes.

When did you realize that Soremachi was going to be a successful series? Was it the anime announcement, the volume sales, more people recognizing you or something else?

And how did that change your approach to writing the rest of the Soremachi manga?

「それ町」20周年恭喜! 您曾经提到「それ町」最开始只计划画4卷, 但是最后画了16卷之多.

您什么时候意识到「それ町」将会成为一个成功的系列? 是在动画化宣布的时候? 销量提高的时候? 还是有更多读者认识你的时候? 还是别的什么?

这些变化有改变您接下来创作「それ町」漫画剩下部分的方式吗?

石黑正数:

「それ町」が連載として軌道に乗ったと思ったのは4巻くらいの財宝探しの話を描いた頃で、作品として上手くいっていると感じたのは7巻が出た頃ですね。

「それ町」の連載の継続には自分の精神的な余裕の有無が一番大きく関わっていた気がします。

そういった意味でアニメ化の企画は精神的余裕をもたらしてくれたと思います。

我觉得「それ町」开始步入连载正轨, 是在画到第4卷寻宝故事那一话的时候. 而感受到作品风格逐渐完整成型, 大概是第7卷出版的时候.

关于「それ町」连载能否持续, 最关键的其实是我有没有精神上的余裕.

从这个意义上来说, 我认为动画化的企划确实带给我很大的精神支持.

Q25 from Ringo Arashiyama, 日本

1. The chronology of each episode of SOREMACHI is backwards and forwards. Was that your intention from the beginning of the series?
2. How far in advance did you think about the story when you started serializing it?
3. Please choose your favorite episodes as if you were compiling a masterpiece selection.

1. 「それ町」各话时间顺序是前后跳跃的, 这是您在创作初期就有意识地安排的吗?
2. 在开始连载这部作品的时候, 您提前构思了多少故事内容?
3. 如果要您亲自编一套故事精选集的话, 您会挑哪些自己最喜欢的话数呢?

石黑正数:

1、時系列シャッフルは、「サザエさん」のようなループでもなく「あすまんが大王」のようなリアルタイムでもない方法としてうっすら構想はありましたが、ハッキリやれそうだと思い実行したのは1巻の途中だっと思います。
2、一応、歩鳥が天国から戻る話、放火魔の話、サイコロの絵関連の話、溝口ナメ子事件などは初期からありました。
3、その時々の気分で変わってくるので割愛しますが、旅行に行く系の話は好きですね。

1. 关于打乱故事时间顺序的做法, 我一开始就隐约有这个构想. 我想尝试一种既不是像《海螺小姐》那样时间循环, 也不是像《阿兹漫画大王》那样按现实时间推进的方式. 不过, 真正明确地觉得”这种方式可以做”并开始付诸实践, 是在第1卷连载到一半的时候.
2. 步鸟从天国回来的故事、纵火犯事件、骰子画相关的故事、沟口奈美子事件等等, 这些情节其实从创作初期就已经构思出来了.
3. 喜欢的故事会随当时的心情而有所不同, 就不一一列举了, 不过我挺喜欢”去旅行”这一类的故事的.

Q26 from Kirashura, USA

How do you combat lack of motivation and laziness? I imagine with manga being a job for you the obligation is a push but I’ve been quite curious how someone in the industry, especially one of my favorites, battles such.

您是怎么对抗动力缺乏和懒惰的? 我能想到创作漫画作为你的职业, 本身的责任感或许是一个推动力. 但我还是很好奇像您这样的业内人士, 尤其是我很喜欢的创作者, 是怎么对抗创作中的惰性的？

石黑正数:

「焦り」です。働いて家族を養う責任、描き続けないと保たれない社会的な立場などに駆り立てられて描いています。

それと、自分で納得のいくストーリーを思い付く事です。自分で面白いと思えない物を仕上げる事ほど苦痛な事はないので。ストーリーが気に入っていれば仕上げるモチベーションになります。

是”焦虑”. 我是在用工作养家糊口的责任感, 以及”如果不继续创作就难以维持现在社会身份”的焦虑驱使下, 持续画下去的.

还有一点就是, 想创作出自己真正满意的故事. 如果要把一个连自己都觉得无趣的东西做完, 那是最痛苦的了. 只要自己喜欢这个故事, 它本身就能成为完成它的动力.

Q27 from poko, Singapore

Hello Ishiguro-sensei, I’ve been reading Furutto recently and enjoy the simple but relaxing gag comedy of it. It made me realize that I would want a spinoff Soremachi 4koma manga with Josephine as the protagonist!

What do you think of the idea? How many volumes do you think you can write about it and was the idea of Furutto inspired by Josephine in some way? I always wondered what Josephine do when no one is at the Arashiyama household.

石黑老师, 您好! 我最近在读《我家的街猫》, 很喜欢它那种简单又轻松的搞笑风格. 这让我想到, 如果有一部以「それ町」的乔瑟菲奴为主角的四格漫画衍生作品, 我一定会想读!

您觉得这个主意怎么样呢? 如果真要画的话, 您觉得能画几卷呢? 阿抖的灵感是否在某种程度上来自乔瑟菲奴呢? 我一直想知道乔瑟菲奴在岚山家没人的在做什么.

石黑正数:

フルットを続けている限りはジョセフィーヌの漫画を自分で描くことは無いと思いますが、仮にフルットではなくジョセフィーヌが主人公だった場合、やはり15年くらい連載し続けるんじゃないかと思います。

ジョセフィーヌは家に誰もいない時、寝てると思います。子犬だったころはティッシュの箱を噛みちぎり中身をぶちまけたり、本をバラバラに破壊したと思います。うちの犬がそうでしたから。

只要我还在连载《我家的街猫》, 我应该不会再自己去画乔瑟菲奴的漫画了. 但如果不是阿抖, 而是让乔瑟菲奴当主角的话, 恐怕也会像《我家的街猫》一样, 连载个15年左右吧.

我觉得乔瑟菲奴在家里没人时, 大概就是在睡觉吧. 不过还小的时候可能会咬烂纸巾盒, 把里面的纸撒得满地都是, 甚至还把书撕成碎片. 因为我们家的狗以前就是这样的.
.
.
.
.
.
.
.
.
.
.
.
.
.

終わり

本作原名「路傍のフジイ〜偉大なる凡人からの便り〜」, 连载自小学馆「週刊ビッグコミックスピリッツ」的2023年24号, 目前隔周连载中, 作者为鍋倉夫(なべくらお), 日版单行本已出三卷, 2025年2月28日发售第四卷.

.
.
.
.
.
.
.
.
.
.
.
.
.

終わり

回到正题, jess 在这个视频中分享了她如何通过 unity shader graph 实现 Pixel Art 风格的水体, 并且开源了示例工程, 还非常”贴心”地更新了 godot 的实现(似乎 jess 也在之前的 unity 收费政策风波中打算把工程迁移至 godot). 如果你只关心实现, jess 的分享显然比这干巴巴的文字直观生动多了, 推荐直接去看.

而在这篇文章中, 我首先尝试用 unity 的 shaderlab 重写了 jess 的实现, 以便更容易地在项目中复用. 接着又试着实现一个2d水体倒影和水深效果的方案, 以期让水体与其他物体的交互看起来更生动. 事先申明, 这篇文章可能会涉及多个话题, 包括2d水体渲染、URP、shader、tilemap、渲染合批, 这每一个话题都是大坑, 也都值得单独拿出来讲. 如果你曾关注过这些关键词, 那么这个分享就不会有太多障碍, 可能还能些许帮到你. 同时必须说这些分享也还没有经过足够的实践, 仍需进一步迭代和验证.

复刻2d水体渲染

水体渲染算是图形学中比较基础且重要的部分, 有大量的研究和实践, 但通常是对于3d游戏而言. 不过近年来3d与2d实现方法结合的2d游戏似乎也越来越流行. 就我之前自己的调研来看, 传统2d, 特别是基于 tilemap 的游戏最常见的做法还是手绘水体 tile, 要更生动一点, 可以做一个 tile 的动画循环播放. 而有一些则在”2d游戏”里使用偏真实的水体渲染. 其实近年来也挺多的, 让我印象深刻的像是风来之国最后夜晚海面演出的那段. 再比如这个“2d游戏”的水体看起来也非常 nice. jess 的方案也是类似, 通过把3d水体渲染方法进行简化和 Pixel Art 风格化来实现, 这种方法基于纯 shader 实现, 在复用性非常高的同时还让水体有丰富的变化. 而 2d 与 3d 不同的部分(比如没有体积与深度)则需要使用一些特殊方法, 这也是比较有趣的一点. 但反过来说, 这类的分享却非常少看到, 特别是像 jess 如此细腻2d水体的分享.

另一个我觉得需要说明的是水体是一个大类, 海洋, 湖泊, 河流, 瀑布中水的表现是存在差异的. 这也是我觉得这个标题有那么点名不副实的地方. jess 实现的水体其实更接近海洋与湖泊的水体, 特点是运动缓慢, 泛着波光. 而河水通常水流较急, 运动具有明显方向性, 波光也相对规律.

水体的tile

在具体的 shader 实现前, 必须先提这个方案中水体材质的载体 tilemap. jess 的游戏是基于 tilemap 的, 她使用内部(水体部分)为黑色, 边缘为白色的图块作为水体的 tileset. 如图1是我自己做的水体 tileset. 这里同样可以做成 animate tile, 增加水体伸展的动画. 而 shader 则负责在黑色的部分画出水体效果. 这种制作方式同样有极高的复用性, 只需要更换材质, 不必重新制作 tileset 就可以做出不同的地形表现.

思路

在这个 jess 的方案中, 考虑了水体表现的几个部分, 如图2,

• 海水近岸颜色渐变

海水远离沙滩岸边, 随着海水变深, 岸底能见度下降, 海水颜色与沙滩颜色的混合渐变.
这是一个非常细节的表现, 其实很少在2d游戏中看到. 同样, 做法也非常地3d, 使用高度图或深度图进行颜色混合. jess 的游戏是一个程序生成地形的开放世界游戏, 所以本身就有这个高度信息. 我自己的实现中不存在这个地形高度, 所以这一条不考虑在内.

• 波纹

波纹的表现通常是在水体有相当透明度时出现, 有两个部分, 其一是使用散焦纹理(Caustic Texture)实现波纹底色的部分(图2位置1), 以及在底色基础上增加的高亮(图2位置2), 使水体看起来像是有深度且受光的表现.
同时这个波纹有扰动效果, 以及波纹的渐隐渐现, 体现水体的运动.

• 波光

即水面模拟受光镜面反射(Specular)的部分(图2位置3).

• 泡沫

泡沫(Foam)也是水体重要的部分. 其实严格来说也有好几种, 一种通常称为岸边泡沫, 是海岸与海水分界线上产生的细密泡沫(图2位置4). 另一种是物体在水中, 接触面上产生的交互泡沫. 在 jess 的另一个分享 How I Made Pixel Art Water Trails - Godot Visual Shader 中正分享了她是如何实现交互泡沫的.

大体上就是这些, 在 jess 的分享中似乎还不涉及光影的部分.

实现

完整的实现水体渲染 shader 如下, 部分函数定义在 pixel_art.hlsl 与 common.hlsl 见附录1.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200

Shader "Custom/PixelWater3"
{
    Properties
    {
        _MainTex("Texture", 2D) = "" {}
        _Color("Color", Color) = (0, 0.57, 1, 1)
        _PPU("Pixels Per Unit", Range(1, 100)) = 32

        _CausticTex("Caustic Texture", 2D) = "" {}
        _CausticColor("Caustic Color", Color) = (0, 1, 0.98, 0.12)
        _CausticScale("Caustic Scale", Range(0.01, 0.1)) = 0.08
        _CausticSpeed("Caustic Speed", Range(0, 2)) = 0.8
        _CausticHighlightTex("Caustic Highlight Tex", 2D) = "" {}
        _CausticHighlightColor("Caustic Highlight Color", Color) = (1, 1, 1, 0.67)
        _CausticNoiseScale("Caustic Noise Scale", Range(0, 2)) = 1.63
        _CausticNoiseBlendScale("Caustic Noise Blend Scale", Range(0, 0.1)) = 0.018
        _CausticSquash("Caustic Squash", Range(0.1, 2)) = 1.3 // 散焦 y 轴缩放
        _CausticFadeNoiseScale("Caustic Fade Noise Scale", Range(0, 1)) = 0.41
        _CausticFadeMultiplier("Caustic Fade Multiplier", Range(0, 1)) = 0.12

        _SpecularSpeed("Specular Speed", Range(0, 2)) = 0.3
        _SpecularNoiseScale("Specular Noise Scale", Range(0.1, 2)) = 0.83
        _SpecularStaticScale("Specular Static Scale", Range(0.1, 5)) = 3.68
        _SpecularColor("Specular Color", Color) = (1, 1, 1, 0.87)
        _SpecularThreshold("Specular Threshold", Range(-1, 1)) = -0.65

        _FoamTex("Foam Texture", 2D) = "" {}
        _FoamColor("Foam Color", Color) = (1, 1, 1, 1)
        _FoamScale("Foam Scale", Range(0, 1)) = 0.5
        _FoamBlurScale("Foam Blur Scale", Range(0, 5)) = 3
        _FoamTexelSize("Foam Texel Size", Range(0, 0.01)) = 0.003

        // 倒影扭曲
        _ReflectionNoiseScale("Reflection Noise Scale", Range(0, 0.1)) = 0.01
        _ReflectionNoiseBlendScale("Reflection Noise Blend Scale", Range(0, 1)) = 0.2
        _ReflectionIntensity("Reflection Intensity", Range(0, 1)) = 0.5
    }

    SubShader
    {
        Tags
        {
            "Queue" = "Transparent"
            "IgnoreProjector" = "True"
            "RenderType" = "Transparent"
        }

        ZWrite Off
        Blend SrcAlpha OneMinusSrcAlpha
        Cull Off

        Pass
        {
            Name "RenderWater"
            HLSLPROGRAM
            #pragma vertex vert
            #pragma fragment frag
            #include "Packages/com.unity.render-pipelines.universal/ShaderLibrary/Core.hlsl"
            #include "Assets/AssetsPackage/Shader/Includes/pixel_art.hlsl"
            #include "Assets/AssetsPackage/Shader/Includes/common.hlsl"

            CBUFFER_START(UnityPerMaterial)
            float _PPU;

            SamplerState linear_clamp_sampler;
            SamplerState point_clamp_sampler;
            SamplerState point_repeat_sampler;
            SamplerState linear_repeat_sampler;

            Texture2D _MainTex;
            float4 _Color;
            float4 _MainTex_TexelSize;

            // 散焦纹理
            Texture2D _CausticTex;
            Texture2D _CausticHighlightTex;
            float4 _CausticColor;
            float4 _CausticTex_TexelSize;
            float _CausticScale;
            float _CausticSpeed;
            float4 _CausticHighlightColor;
            float _CausticSquash;
            // 噪声扰动
            float _CausticNoiseScale;
            float _CausticNoiseBlendScale;
            // 散焦渐隐
            float _CausticFadeNoiseScale;
            float _CausticFadeMultiplier;

            // 高光
            float _SpecularSpeed;
            float _SpecularNoiseScale;
            float _SpecularStaticScale;
            float4 _SpecularColor;
            float _SpecularThreshold;

            // 边缘泡沫
            Texture2D _FoamTex;
            float4 _FoamColor;
            float _FoamScale;
            float _FoamBlurScale;
            float _FoamTexelSize;

            // 倒影
            Texture2D _CameraSortingLayerTexture;
            Texture2D _ReflectionTex;
            Texture2D _UnderwaterTex;
            float _ReflectionNoiseScale;
            float _ReflectionNoiseBlendScale;
            float _ReflectionIntensity;
            CBUFFER_END

            struct a2v
            {
                float4 vertex: POSITION;
                float2 texcoord: TEXCOORD0;
                float4 color: COLOR;
            };

            struct v2f
            {
                float4 vertex: SV_POSITION;
                float2 uv: TEXCOORD0;
                float4 color: COLOR;
                float3 world_pos: TEXCOORD1;
                float4 screen_pos: TEXCOORD2;
            };

            v2f vert(a2v input)
            {
                v2f output;
                output.vertex = TransformObjectToHClip(input.vertex.xyz);
                output.uv = input.texcoord;
                output.color = input.color;
                output.world_pos = mul(unity_ObjectToWorld, input.vertex).xyz;
                output.screen_pos = ComputeScreenPos(output.vertex);
                return output;
            }

            float4 frag(v2f input) : SV_Target
            {
                float3 world_pos = pixelate_world_pos(input.world_pos, _PPU);
                float2 uv = input.uv;

                // 散焦纹理uv扰动
                float2 squash_uv = world_pos.xy * float2(1, _CausticSquash);
                float2 caustic_uv = squash_uv * _CausticScale;
                float caustic_noise = gradient_noise(squash_uv + _Time.y * _CausticSpeed, _CausticNoiseScale);
                float2 caustic_noise_uv = float2(caustic_noise, caustic_noise);
                caustic_uv = blend_subtract(caustic_uv, caustic_noise_uv, _CausticNoiseBlendScale);

                // 倒影 / 水深
                float2 screen_uv = input.screen_pos.xy / input.screen_pos.w;
                screen_uv += caustic_noise_uv * _ReflectionNoiseScale / unity_OrthoParams.y;
                // float4 screen_col = _CameraSortingLayerTexture.Sample(point_clamp_sampler, clamp(screen_uv + caustic_noise_uv * _ReflectionNoiseScale, 0, 1));
                float4 reflection_col = _ReflectionTex.Sample(point_clamp_sampler, screen_uv);
                float4 underwater_col = _UnderwaterTex.Sample(point_clamp_sampler, screen_uv);
                float4 screen_col = lerp(underwater_col, reflection_col, _ReflectionIntensity);

                // 散焦纹理
                float4 caustic_col = _CausticTex.Sample(point_repeat_sampler, caustic_uv) * _CausticColor;
                float4 highlight_col = _CausticHighlightTex.Sample(point_repeat_sampler, caustic_uv) * _CausticHighlightColor;
                caustic_col = lerp(caustic_col, highlight_col, highlight_col.a);
                // 散焦渐隐
                float fade_noise = gradient_noise(input.world_pos.xy, _CausticFadeNoiseScale) * _CausticFadeMultiplier;
                caustic_col.a = clamp(caustic_col.a - fade_noise, 0, 1);

                // 高光
                float2 delta = float2(_Time.y, 0) * _SpecularSpeed;
                float noise_left = gradient_noise(world_pos.xy + delta, _SpecularNoiseScale);
                float noise_right = gradient_noise(world_pos.xy - delta, _SpecularNoiseScale);
                float noise_static = gradient_noise(world_pos.xy, _SpecularStaticScale);
                float specular_noise = blend_overlay(noise_left, noise_right, 1);
                specular_noise = blend_subtract(specular_noise, noise_static, 1);
                float4 specular_col = step(specular_noise, _SpecularThreshold) * _SpecularColor;

                // 泡沫
                float4 foam_col = _FoamTex.Sample(point_repeat_sampler, input.world_pos.xy * _FoamScale) * _FoamColor;
                float4 blur = gaussian_blur_5x5(_MainTex, point_repeat_sampler, uv, float2(_FoamTexelSize, _FoamTexelSize)) * _FoamBlurScale;
                foam_col.a *= blur.r;

                // 混合 主色, 散焦, 高光, 泡沫, 倒影
                caustic_col.rgb = lerp(_Color.rgb, caustic_col.rgb, caustic_col.a);
                caustic_col = lerp(caustic_col, specular_col, ceil(caustic_col.a) * specular_col.a);
                caustic_col = lerp(caustic_col, foam_col, foam_col.a);
                caustic_col = lerp(caustic_col, screen_col, screen_col.a * _ReflectionNoiseBlendScale);

                uv = pixelate_uv(uv, _MainTex_TexelSize);
                float4 col = _MainTex.Sample(point_clamp_sampler, uv);
                foam_col = _FoamColor * (col.r * col.a); // 复用 foam_col 变量
                col.rgb = lerp(caustic_col.rgb, foam_col.rgb, col.r * col.a);
                col.a = col.a * _Color.a;

                return col;
            }

            ENDHLSL
        }
    }
}

分块简单解释一下

• 产生散焦贴图uv扰动

1
2
3
4
5

float2 squash_uv = world_pos.xy * float2(1, _CausticSquash);
float2 caustic_uv = squash_uv * _CausticScale;
float caustic_noise = gradient_noise(squash_uv + _Time.y * _CausticSpeed, _CausticNoiseScale);
float2 caustic_noise_uv = float2(caustic_noise, caustic_noise);
caustic_uv = blend_subtract(caustic_uv, caustic_noise_uv, _CausticNoiseBlendScale);

这里使用世界坐标加扰动来生成采样散焦纹理(_CausticTex)的uv坐标. 使用 _CausticSquash 对竖直方向进行缩放, 以用模拟斜视水面的效果. gradient_noise 用于产生扰动uv所需的柏林噪声(Perlin Noise), 其定义见附录1.

• 倒影与水深

1
2
3
4
5
6
7

// 倒影 / 水深
float2 screen_uv = input.screen_pos.xy / input.screen_pos.w;
screen_uv += caustic_noise_uv * _ReflectionNoiseScale / unity_OrthoParams.y;
// float4 screen_col = _CameraSortingLayerTexture.Sample(point_clamp_sampler, clamp(screen_uv + caustic_noise_uv * _ReflectionNoiseScale, 0, 1));
float4 reflection_col = _ReflectionTex.Sample(point_clamp_sampler, screen_uv);
float4 underwater_col = _UnderwaterTex.Sample(point_clamp_sampler, screen_uv);
float4 screen_col = lerp(underwater_col, reflection_col, _ReflectionIntensity);

在这个实现方案中, 倒影(_ReflectionTex)与水深(_UnderwaterTex)有两个单独的渲染纹理(RT, Render Texture), 在渲染水体时进行采样, RT的生成参考倒影与水深实现方案一节. _ReflectionIntensity 用于控制两者混合的权重. 我感觉通常倒影和水深的效果只需取其一, 否则混合后重叠看着有点乱.

• 散焦纹理采样

1
2
3
4
5
6
7

// 散焦纹理
float4 caustic_col = _CausticTex.Sample(point_repeat_sampler, caustic_uv) * _CausticColor;
float4 highlight_col = _CausticHighlightTex.Sample(point_repeat_sampler, caustic_uv) * _CausticHighlightColor;
caustic_col = lerp(caustic_col, highlight_col, highlight_col.a);
// 散焦渐隐
float fade_noise = gradient_noise(input.world_pos.xy, _CausticFadeNoiseScale) * _CausticFadeMultiplier;
caustic_col.a = clamp(caustic_col.a - fade_noise, 0, 1);

这里有散焦底色的纹理(_CausticTex)与高亮的纹理(_CausticHighlightTex), 后者由前者图像处理腐蚀后生成, 保证了高亮的部分一定在底色的纹理之上, 看起来就像是部分波纹变成了高亮. 同时用柏林噪声增加了散焦纹理部分渐隐效果.

1
2
3
4
5
6
7
8

// 高光
float2 delta = float2(_Time.y, 0) * _SpecularSpeed;
float noise_left = gradient_noise(world_pos.xy + delta, _SpecularNoiseScale);
float noise_right = gradient_noise(world_pos.xy - delta, _SpecularNoiseScale);
float noise_static = gradient_noise(world_pos.xy, _SpecularStaticScale);
float specular_noise = blend_overlay(noise_left, noise_right, 1);
specular_noise = blend_subtract(specular_noise, noise_static, 1);
float4 specular_col = step(specular_noise, _SpecularThreshold) * _SpecularColor;

高光的部分使用2个反向运动的柏林噪声与一个静态的柏林噪声混合生成.

• 泡沫

1
2
3
4

// 泡沫
float4 foam_col = _FoamTex.Sample(point_repeat_sampler, input.world_pos.xy * _FoamScale) * _FoamColor;
float4 blur = gaussian_blur_5x5(_MainTex, point_repeat_sampler, uv, float2(_FoamTexelSize, _FoamTexelSize)) * _FoamBlurScale;
foam_col.a *= blur.r;

这里 _FoamTex 泡沫贴图是散焦贴图缩放后得到的, 用于表现细小的岸边泡沫. 不同于3d中使用深度确定泡沫显示范围, jess 的方案使用高斯模糊使白色边缘具有渐变效果, 然后与泡沫纹理混合. gaussian_blur_5x5 的定义见附录1.

高斯模糊 + tilemap 会有一个隐含的坑点. 说来话长, 我把这个话题放到附录2中讨论. 其实可以预先在 tileset 中就处理好渐变, 这样可以省去高斯模糊这一步, 我看到 jess 后续的分享似乎也改变了泡沫的实现方法.

• 混合以上所有颜色

1
2
3
4
5
6
7
8
9
10
11

// 混合 主色, 散焦, 高光, 泡沫, 倒影
caustic_col.rgb = lerp(_Color.rgb, caustic_col.rgb, caustic_col.a);
caustic_col = lerp(caustic_col, specular_col, ceil(caustic_col.a) * specular_col.a);
caustic_col = lerp(caustic_col, foam_col, foam_col.a);
caustic_col = lerp(caustic_col, screen_col, screen_col.a * _ReflectionNoiseBlendScale);

uv = pixelate_uv(uv, _MainTex_TexelSize);
float4 col = _MainTex.Sample(point_clamp_sampler, uv);
foam_col = _FoamColor * (col.r * col.a); // 复用 foam_col 变量
col.rgb = lerp(caustic_col.rgb, foam_col.rgb, col.r * col.a);
col.a = col.a * _Color.a;

pixelate_uv 的定义见附录1, 原理可以参考这篇文章浅谈Pixel Art缩放及抗锯齿问题 | Granvallen;Nest.
以上从我自己测试来看, 相同参数下, 水体表现和 jess 的实现基本一致. shader 中所用到的3张贴图(_CausticTex, _CausticHighlightTex 和 _FoamTex)都来自 jess 的示例工程, 实现效果如图3,

调整部分参数的效果变化如图4,

2d水体的倒影与水深

在我少量的调研中, 那些使用3d技术的2d游戏中, 为了表现水的真实, 大多都实现了这类效果, 特别是水深的效果. 而在纯2d游戏中也有少部分实现了简单的黑色模糊倒影效果, 水深则较为少见.

说是2d, 其实2d的游戏表现方式五花八门, 最常见的有横版平台跳跃, 类似 jess 这个游戏的正面(Top-down)视角, 以及2d等距视角(Isometric), 这里只讨论正面 Top-down 视角的情况. 关于这个视角, 突然想起王老菊有个视频很有意思未来科技开发日记#1.

思路

尝试寻找解决方案之前, 先考虑下这个问题最复杂的情况, 如果能处理好复杂的情况, 那更通常的情况应该也是ok的. 比如一个复杂的情况是, 一个有一半没入水中的动态物体在水的边缘处. 这种情况会同时出现动态的倒影与水深, 以及倒影和水深在水不规则边缘的处理.

一种2d倒影简单且广泛采用的实现思路是物体的倒影是单独贴图, 事先做好, 控制渲染顺序, 先渲染出倒影, 然后渲染水体时抓取屏幕贴图, 对水体范围的颜色进行叠加和扰动. 比如这个分享中的做法 UnityShader实现2D水面及物体水面投影的渲染.

显然这个思路是可行的, 但对于稍复杂的情况就暴露出一些问题, 需要进一步改进. 比如,

• 因为是独立的贴图, 所以对于静态物体是比较好处理的, 但是如果贴图本身会动, 像是角色有序列帧动画, 就需要额外处理倒影贴图的变化, 这个就不太方便.
• 因为是先渲染的倒影, 渲染出来后屏幕才能抓到帧进行水体表现效果, 而如果物体在水边缘, 露出来的部分倒影就会穿帮. 期望应该是倒影只会在水体内渲染.
• 如果想处理地更精细一点, 单独控制倒影与水深的强度, 简单的抓帧显然是做不到的.

我初期尝试对这种方案进行修补, 但最终放弃了. 这里 URP 2D 渲染管线 + 屏幕抓帧也有很多坑, 如果有人采用这个方案我简单提一嘴碰到的问题. URP 中无法使用 Build-in 管线中 GrabPass 进行屏幕抓帧, 而是需要在 Render Pipeline Asset 检视界面中勾选 Opaque Texture, 这样屏幕贴图会自动渲染到一个内置的全局RT _CameraOpaqueTexture 中, 在 shader 中采样这个RT即可. 而如果你使用 URP 2D 管线, 那么这个方法也是失效的, 你需要单独设置一个 layer 和在 Render Data 检视界面中新增 Render Object 来进行屏幕贴图的渲染, 然后使用 _CameraSortingLayerTexture 进行采样, 这种做法目前有很多局限, 可以参考这个讨论 Is it possible to have transparents using the 2D renderer in URP? - Unity Engine - Unity Discussions.

如果沿用这个屏幕空间反射的2d倒影实现思路, 对于上面要解决的问题可以简单总结为

1. 倒影/水深贴图怎么获取?
2. 怎么只在水体范围内渲染这些贴图内容?

对于第一个倒影贴图怎么来的问题, 如果要精细控制还是需要倒影与水深分开获取. 对于倒影, 需要能实时地渲染出物体的动态倒影, 这个也有几种方案, 像是屏幕空间上下倒转, 物体贴图的倒转. 水深与倒影的处理类似, 只是不需要进行倒转操作.

对于第二个问题, 倒影只出现在水体范围内, 大致有两种做法, 一是使用模板缓冲(Stencil Buffer), 水体渲染需要两个 pass, 第一个 pass 渲染水体时只写入模板缓存, 然后渲染倒影/水深时读取模板, 最后水体第二个 pass 读取倒影渲染结果再混合渲染水体颜色. 然而 URP 似乎不支持多 pass 的 shader, 只能作罢. 模板匹配的另一个麻烦之处在于水边缘处理, 如果边缘是不规则的, 就需要根据透明度的情况处理模板缓存.

另一种做法则更直接, 把倒影与水深渲染到单独RT上, 而主相机中不对其进行渲染, 然后水体渲染时读取RT进行混合. 这个方案使用自定义的 Renderer Featuer 可以很容易做到.

于是我想到一种简单可行, 且统一反射与水深的方案. 给每个入水物体节点再挂两个 Sprite 节点, 一个设置为倒影层用于渲染倒影, 一个设置为水深层渲染水深, 每帧把主 Sprite 的贴图更新到这两个子 Sprite 上, 而这两个 Sprite Renderer 各自使用单独的 shader 渲染自己的贴图, shader 的参数也可以直接在更新时赋值. 只需要这两个 Sprite 设置为不同的 Layer 比如反射层(Reflection) 与 水深层(Underwater), 借助自定义 Renderer Feature 就可以渲染出这两个单独的RT.

光这样还不够, 还需要实现一个特殊的 Sprite 分割 shader, 外部脚本可以传参数进去, 一个参数决定 Sprite 在 y 方向上显示的分割线, 另一个参数决定是分割线以上还是以下的部分显示, 这样就可以模拟出 Sprite 没入水中的效果.

实现

自定义的 Renderer Feature 与 Render Pass 代码如下,

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

using UnityEngine.Rendering.Universal;
using UnityEngine;

public class RenderLayerFeature : ScriptableRendererFeature
{
    private RenderLayerPass _pass;
    [SerializeField]
    private LayerMask layer_mask;
    [SerializeField]
    private string rt_name = "_TempRenderLayer";
    [SerializeField]
    private RenderPassEvent pass_event = RenderPassEvent.BeforeRenderingOpaques;
    [SerializeField]
    private TransparencySortMode sort_mode = TransparencySortMode.Default;
    [SerializeField]
    private Vector3 custom_axis = Vector3.up;

    public override void Create()
    {
        _pass = new RenderLayerPass(layer_mask, rt_name, pass_event, sort_mode, custom_axis);
    }

    public override void AddRenderPasses(ScriptableRenderer renderer, ref RenderingData rendering_data)
    {
        _pass.Setup();
        renderer.EnqueuePass(_pass);
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

using UnityEngine.Rendering.Universal;
using UnityEngine.Rendering;
using UnityEngine;

public class RenderLayerPass : ScriptableRenderPass
{
    private RenderTargetHandle rt_handle;
    private string rt_name;
    private ShaderTagId shader_tag_id = new ShaderTagId("SRPDefaultUnlit");
    private FilteringSettings filtering_settings;
    private LayerMask layer_mask;
    private TransparencySortMode sort_mode;
    private Vector3 custom_axis;

    public RenderLayerPass(LayerMask layer_mask, string rt_name, RenderPassEvent pass_event, TransparencySortMode sort_mode, Vector3 custom_axis)
    {
        this.layer_mask = layer_mask;
        this.rt_name = rt_name;
        this.sort_mode = sort_mode;
        this.custom_axis = custom_axis;
        renderPassEvent = pass_event; // 设置渲染时机

        filtering_settings = new FilteringSettings(RenderQueueRange.all, layer_mask);
        rt_handle.Init(rt_name);
    }

    public void Setup()
    {

    }

    public override void Configure(CommandBuffer cmd, RenderTextureDescriptor cameraTextureDescriptor)
    {
        RenderTextureDescriptor rt_desc = cameraTextureDescriptor; // RenderTexture 描述符

        cmd.GetTemporaryRT(rt_handle.id, rt_desc.width, rt_desc.height, 0, FilterMode.Bilinear, RenderTextureFormat.ARGBHalf); // 临时 RT
        cmd.SetGlobalTexture(rt_name, rt_handle.Identifier()); // 设置全局纹理

        // 配置渲染目标和清除设置
        ConfigureTarget(rt_handle.Identifier());
        ConfigureClear(ClearFlag.All, Color.clear);
    }


    public override void Execute(ScriptableRenderContext context, ref RenderingData rendering_data)
    {
        // 手动创建剔除参数
        Camera camera = rendering_data.cameraData.camera;

        // 必须设置, 否则倒影渲染顺序会有问题
        camera.transparencySortMode = sort_mode;
        camera.transparencySortAxis = custom_axis;

        if (!camera.TryGetCullingParameters(out ScriptableCullingParameters culling_params))
            return;

        // 设置剔除遮罩
        culling_params.cullingMask = (uint)layer_mask.value;
        CullingResults culling_results = context.Cull(ref culling_params);
        DrawingSettings draw_settings = CreateDrawingSettings(
            shader_tag_id, 
            ref rendering_data, 
            SortingCriteria.SortingLayer | SortingCriteria.CommonTransparent
        );
        context.DrawRenderers(culling_results, ref draw_settings, ref filtering_settings);
    }

    public override void FrameCleanup(CommandBuffer cmd)
    {
        cmd.ReleaseTemporaryRT(rt_handle.id);
    }
}

这个 RenderLayerFeature 实现的功能非常简单, 就是把特定 Layer 的内容渲染到一个自命名的全局RT里, 可以在 Render Data 资源检视界面里创建两个实例分别渲染物体的倒影层(_ReflectionTex)与水深层(_UnderwaterTex).

至于入水物体 shader 的实现, 这就不得不提到 Sprite Renderer 的一个坑点.

水中物体处理与Sprite合批

在前面提到的实现思路中, 水中物体需要一个分割 Sprite 的 shader, 一种实现如下,

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

v2f vert(a2v input)
{
v2f output;
input.vertex.y -= _OffsetY; // 竖直移动
output.local_pos = input.vertex;
output.vertex = TransformObjectToHClip(input.vertex.xyz);
output.uv = input.texcoord;
output.color = input.color * _Color;
return output;
}

float4 frag(v2f input) : SV_Target
{
// sprite 剔除
float is_discard = _Upper * input.local_pos.y + (1.0 / _PPU - input.local_pos.y) * (1 - _Upper);
clip(is_discard);

float2 uv = pixelate_uv(input.uv, _MainTex_TexelSize);
float4 col = _MainTex.Sample(linear_clamp_sampler, uv);
return col * input.color;
}

当场景中该物体只有一个时表现符合期望, 但当场景中有两个以上的相同物体时, Sprite 的渲染就会出现问题, 看表现像是 shader 中的局部坐标不再可靠. 检索之后才知道 Sprite Renderer 会自带一个动态合批处理(与工程本身合批配置无关), 当场景中有多个相同 Sprite 且材质相同时, 就会触发这个幕后的动态合批, 进行网格合并操作, 以便同时绘制多个Sprite. 但这导致 shader 中上述局部空间坐标的失效, 参考,

• How to prevent sprite batching OR display sprites without using sprite renderer? - Unity Engine - Unity Discussions
• How to get an absolute object-space position when draw calls are batched? - Unity Engine - Unity Discussions

解决方法是在 shader 中加个禁止 batching 的 tag,

1

"DisableBatching" = "True"

• Batching and Sprite Renderers - Unity Engine - Unity Discussions
• SRP Batcher & SpriteRenderer - Unity Engine - Unity Discussions

似乎 unity 2023 版本 Sprite Renderer 才支持了 SRP Batcher.

不过好在已经有人探索过相关的解决方案了, 比如

• 为Unity Sprite实现GPU Instancing
• GitHub - ownself/UnitySpriteGPUInstancing: A Unity Sprite GPU Instancing Implementation Demo

从这个分享中看, 我猜铃兰之剑似乎也使用了类似的方案. 思路是自己创建管理相同的渲染网格, 用 Mesh Renderer 代替 Sprite Renderer 进行渲染, 而这个流程支持 GPU Instancing, 可以说是一个相当优雅的解决方案了. 那么问题就由创建 Sprite, 变成创建 Mesh. 处理后我们可以在 frame debuger 中看到, 所有物体是由单个批次绘制的. 物体挂载脚本 MapObjectRenerer.cs 与物体 shader mapobject.shader 实现如下,

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217

using System.Collections.Generic;
using UnityEngine;

[RequireComponent(typeof(SpriteRenderer))]
public class MapObjectRenderer : MonoBehaviour
{
    private SpriteRenderer _sprite_renderer;
    private MaterialPropertyBlock _prop_block;
    private int _tex_index = 0;
    private Vector4 _pivot;
    private Vector4 _uv;
    private float _ppu = 32f;
    public float offset_y = 0f;

    // sprite mesh
    private GameObject _sprite_mesh_go;
    private MeshRenderer _sprite_mesh_renderer;

    // reflection mesh
    private GameObject _reflection_mesh_go;
    private MeshRenderer _reflection_mesh_renderer;

    // underwater mesh
    private GameObject _underwater_mesh_go;
    private MeshRenderer _underwater_mesh_renderer;

    // 静态变量
    private static Mesh _mesh;
    private static Dictionary<Texture2D, int> tex_indexes = new Dictionary<Texture2D, int>();
    private static int array_size = 128;
    private static Texture2DArray tex_array;
    private static int tex_count = 0;

    private void Awake()
    {
        _sprite_renderer = GetComponent<SpriteRenderer>();
        _sprite_renderer.enabled = false;

        _ppu = _sprite_renderer.sprite.pixelsPerUnit;
        Texture2D tex = _sprite_renderer.sprite.texture; // tex 是 sprite sheet

        if (tex_array == null)
        {
            tex_array = new Texture2DArray(tex.width, tex.height, array_size, tex.format, false);
            tex_count = 0;
        }

        if (_prop_block == null)
        {
            _prop_block = new MaterialPropertyBlock();
        }

        if (!tex_indexes.ContainsKey(tex))
        {
            Graphics.CopyTexture(tex, 0, 0, tex_array, tex_count, 0);
            _tex_index = tex_count;
            tex_indexes[tex] = _tex_index;
            tex_count++;
        }
        else
        {
            _tex_index = tex_indexes[tex];
        }

        if (_mesh == null)
        {
            _mesh = create_mesh();
        }

        create_sprite_mesh();
        create_reflection_mesh();
        create_underwater_mesh();
    }

    private void Update()
    {
        update_mesh();
    }

    private Mesh create_mesh()
    {
        Mesh mesh = new Mesh();

        // 定义顶点，枢轴位于底部中心
        Vector3[] vertices = new Vector3[]
        {
            new Vector3(-1f, 0f, 0), // 左下
            new Vector3(1f, 0f, 0),  // 右下
            new Vector3(-1f, 2f, 0), // 左上
            new Vector3(1f, 2f, 0)   // 右上
        };

        // 定义 UV
        Vector2[] uvs = new Vector2[]
        {
            new Vector2(0, 0),
            new Vector2(1, 0),
            new Vector2(0, 1),
            new Vector2(1, 1)
        };

        // 定义三角形
        int[] triangles = new int[]
        {
            0, 2, 1,
            2, 3, 1
        };

        mesh.vertices = vertices;
        mesh.uv = uvs;
        mesh.triangles = triangles;
        mesh.RecalculateNormals();
        mesh.RecalculateBounds();

        return mesh;
    }

    // 更新 pivot uv 变量
    private void update_pivot_uv()
    {
        Sprite sprite = _sprite_renderer.sprite;

        _pivot.x = sprite.rect.width * 0.5f / sprite.pixelsPerUnit;
        _pivot.y = sprite.rect.height * 0.5f / sprite.pixelsPerUnit;
        _pivot.z = (sprite.rect.width * 0.5f - sprite.pivot.x) / sprite.pixelsPerUnit;
        _pivot.w = sprite.pivot.y / sprite.pixelsPerUnit;

        _uv.x = sprite.uv[1].x - sprite.uv[0].x;
        _uv.y = sprite.uv[0].y - sprite.uv[2].y;
        _uv.z = sprite.uv[2].x;
        _uv.w = sprite.uv[2].y;
    }

    private void create_sprite_mesh()
    {
        if (_sprite_mesh_go != null)
            DestroyImmediate(_sprite_mesh_go);

        _sprite_mesh_go = new GameObject("sprite_mesh");
        _sprite_mesh_go.layer = gameObject.layer;
        _sprite_mesh_go.transform.SetParent(transform);
        _sprite_mesh_go.transform.localPosition = Vector3.zero;
        _sprite_mesh_go.transform.localRotation = Quaternion.identity;
        _sprite_mesh_go.transform.localScale = Vector3.one;

        MeshFilter mesh_filter = _sprite_mesh_go.AddComponent<MeshFilter>();
        mesh_filter.sharedMesh = _mesh;

        _sprite_mesh_renderer = _sprite_mesh_go.AddComponent<MeshRenderer>();
        _sprite_mesh_renderer.enabled = true;
        _sprite_mesh_renderer.sortingLayerID = _sprite_renderer.sortingLayerID;
        _sprite_mesh_renderer.sortingOrder = _sprite_renderer.sortingOrder;
        _sprite_mesh_renderer.sharedMaterial = ResMgr.instance.load_material("Material/mapobject.mat");
        _sprite_mesh_renderer.sharedMaterial.SetTexture("_Textures", tex_array);
    }

    private void create_reflection_mesh()
    {
        if (_reflection_mesh_go != null)
            DestroyImmediate(_reflection_mesh_go);

        _reflection_mesh_go = new GameObject("reflection_mesh");
        _reflection_mesh_go.layer = LayerMask.NameToLayer("Reflection");
        _reflection_mesh_go.transform.SetParent(transform);
        _reflection_mesh_go.transform.localPosition = Vector3.zero;
        _reflection_mesh_go.transform.localRotation = Quaternion.identity;
        _reflection_mesh_go.transform.localScale = new Vector3(1, -1, 1);

        MeshFilter mesh_filter = _reflection_mesh_go.AddComponent<MeshFilter>();
        mesh_filter.sharedMesh = _mesh;

        _reflection_mesh_renderer = _reflection_mesh_go.AddComponent<MeshRenderer>();
        _reflection_mesh_renderer.enabled = true;
        _reflection_mesh_renderer.sharedMaterial = ResMgr.instance.load_material("Material/mapobject.mat");
        _reflection_mesh_renderer.sharedMaterial.SetTexture("_Textures", tex_array);
    }

    private void create_underwater_mesh()
    {
        if (_underwater_mesh_go != null)
            DestroyImmediate(_underwater_mesh_go);

        _underwater_mesh_go = new GameObject("underwater_mesh");
        _underwater_mesh_go.layer = LayerMask.NameToLayer("Underwater");
        _underwater_mesh_go.transform.SetParent(transform);
        _underwater_mesh_go.transform.localPosition = Vector3.zero;
        _underwater_mesh_go.transform.localRotation = Quaternion.identity;
        _underwater_mesh_go.transform.localScale = Vector3.one;

        MeshFilter mesh_filter = _underwater_mesh_go.AddComponent<MeshFilter>();
        mesh_filter.sharedMesh = _mesh;

        _underwater_mesh_renderer = _underwater_mesh_go.AddComponent<MeshRenderer>();
        _underwater_mesh_renderer.enabled = true;
        _underwater_mesh_renderer.sharedMaterial = ResMgr.instance.load_material("Material/mapobject.mat");
        _underwater_mesh_renderer.sharedMaterial.SetTexture("_Textures", tex_array);
    }

    private void update_mesh()
    {
        update_pivot_uv();

        _sprite_mesh_renderer.GetPropertyBlock(_prop_block);
        _prop_block.SetFloat("_PPU", _ppu);
        _prop_block.SetFloat("_TexIndex", _tex_index);
        _prop_block.SetVector("_Pivot", _pivot);
        _prop_block.SetVector("_UV", _uv);
        _prop_block.SetFloat("_Upper", 1);
        _prop_block.SetFloat("_OffsetY", offset_y);
        _sprite_mesh_renderer.SetPropertyBlock(_prop_block);

        _reflection_mesh_renderer?.SetPropertyBlock(_prop_block);

        _prop_block.SetFloat("_Upper", 0);
        _underwater_mesh_renderer?.SetPropertyBlock(_prop_block);
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122

Shader "Custom/MapObject2"
{
    Properties
    {
        _Color("Color", Color) = (1, 1, 1, 1)
        _Textures("Textures", 2DArray) = "" {}
    }

    SubShader
    {
        Tags
        {
            "Queue" = "Transparent"
            "IgnoreProjector" = "True"
            "RenderType" = "Opaque"
            "PreviewType" = "Plane"
            "CanUseSpriteAtlas" = "True"
            // "DisableBatching"="True"
        }

        ZWrite Off
        Lighting Off
        Cull Off
        Blend SrcAlpha OneMinusSrcAlpha
        
        Pass
        {
            HLSLPROGRAM
            #pragma vertex vert
            #pragma fragment frag
            #pragma require 2darray
            #pragma multi_compile_instancing
            #include "Packages/com.unity.render-pipelines.universal/ShaderLibrary/Core.hlsl"
            #include "Assets/AssetsPackage/Shader/Includes/pixel_art.hlsl"

            Texture2DArray _Textures;
            SamplerState linear_clamp_sampler;
            SamplerState point_clamp_sampler;
            float4 _Textures_TexelSize;
            float4 _Color;

            UNITY_INSTANCING_BUFFER_START(Props)
            UNITY_DEFINE_INSTANCED_PROP(float, _PPU)
            UNITY_DEFINE_INSTANCED_PROP(float, _TexIndex)
            UNITY_DEFINE_INSTANCED_PROP(half4, _Pivot)
            UNITY_DEFINE_INSTANCED_PROP(half4, _UV)
            UNITY_DEFINE_INSTANCED_PROP(float, _Upper)
            UNITY_DEFINE_INSTANCED_PROP(float, _OffsetY)
            UNITY_INSTANCING_BUFFER_END(Props)

            struct a2v
            {
                float4 vertex: POSITION;
                float2 texcoord: TEXCOORD0;
                float4 color: COLOR;
                UNITY_VERTEX_INPUT_INSTANCE_ID
            };

            struct v2f
            {
                float4 vertex: SV_POSITION;
                float2 uv: TEXCOORD0;
                float4 color: COLOR;
                float4 local_pos: TEXCOORD1;
                UNITY_VERTEX_INPUT_INSTANCE_ID
            };

            v2f vert(a2v input)
            {
                UNITY_SETUP_INSTANCE_ID(input);

                v2f output;
                UNITY_TRANSFER_INSTANCE_ID(input, output);

                // pivot
                half4 pivot = UNITY_ACCESS_INSTANCED_PROP(Props, _Pivot);
                half4x4 pivot_m = {
                    pivot.x, 0,       0,      pivot.z,
                    0,       pivot.y, 0,      pivot.w,
                    0,       0,       1,      0,
                    0,       0,       0,      1
                };
                float offset_y = UNITY_ACCESS_INSTANCED_PROP(Props, _OffsetY);
                input.vertex = mul(pivot_m, input.vertex);
                input.vertex.y -= offset_y; // 竖直移动
                output.vertex = TransformObjectToHClip(input.vertex.xyz);
                output.local_pos = input.vertex; // 记录局部坐标用于剔除

                // uv
                half4 uv = UNITY_ACCESS_INSTANCED_PROP(Props, _UV);
                half3x3 uv_m = {
                    uv.x, 0,    uv.z,
                    0,    uv.y, uv.w,
                    0,    0,    1
                };
                output.uv = mul(uv_m, half3(input.texcoord, 1)).xy;

                output.color = input.color * _Color;
                return output;
            }

            float4 frag(v2f input) : SV_Target
            {
                UNITY_SETUP_INSTANCE_ID(input);

                // sprite 剔除
                float ppu = UNITY_ACCESS_INSTANCED_PROP(Props, _PPU);
                float upper = UNITY_ACCESS_INSTANCED_PROP(Props, _Upper);
                float is_discard = upper * input.local_pos.y + (1.0 / ppu - input.local_pos.y) * (1 - upper);
                clip(is_discard);

                float2 uv = input.uv;
                uv = pixelate_uv(uv, _Textures_TexelSize);
                int tex_index = UNITY_ACCESS_INSTANCED_PROP(Props, _TexIndex);
                float4 col = _Textures.Sample(linear_clamp_sampler, float3(uv, tex_index));
                return col * input.color;
            }

            ENDHLSL
        }
    }
}

挂上这个脚本后, 原来的 Sprite Renderer 会停止渲染, 渲染的工作交给三个子节点上的 Mesh.
最终实现的效果如图5,

附录

common.hlsl 与 pixel_art.hlsl

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145

#ifndef _INCLUDE_COMMON_HLSL_
#define _INCLUDE_COMMON_HLSL_

#include "Packages/com.unity.render-pipelines.universal/ShaderLibrary/Core.hlsl"

// ref: https://docs.unity3d.com/Packages/com.unity.shadergraph@12.1/manual/Blend-Node.html
float blend_overlay(float base, float blend, float opacity)
{
    float result1 = 1.0 - 2.0 * (1.0 - base) * (1.0 - blend);
    float result2 = 2.0 * base * blend;
    float zero_or_one = step(base, 0.5);
    float output = result2 * zero_or_one + (1 - zero_or_one) * result1;
    return lerp(base, output, opacity);
}

float blend_subtract(float base, float blend, float opacity)
{
    return lerp(base, base - blend, opacity);
}

float2 blend_subtract(float2 base, float2 blend, float opacity)
{
    return lerp(base, base - blend, opacity);
}
// -------------------------------------- Gradient Noise --------------------------------------

// gradient noise
// ref: https://docs.unity3d.com/Packages/com.unity.shadergraph@6.9/manual/Gradient-Noise-Node.html
float2 gradient_noise_dir(float2 p)
{
    p = p % 289;
    float x = (34 * p.x + 1) * p.x % 289 + p.y;
    x = (34 * x + 1) * x % 289;
    x = frac(x / 41) * 2 - 1;
    return normalize(float2(x - floor(x + 0.5), abs(x) - 0.5));
}

float gradient_noise(float2 uv, float scale)
{
    float2 p = uv * scale;
    float2 ip = floor(p);
    float2 fp = frac(p);
    float d00 = dot(gradient_noise_dir(ip), fp);
    float d01 = dot(gradient_noise_dir(ip + float2(0, 1)), fp - float2(0, 1));
    float d10 = dot(gradient_noise_dir(ip + float2(1, 0)), fp - float2(1, 0));
    float d11 = dot(gradient_noise_dir(ip + float2(1, 1)), fp - float2(1, 1));
    fp = fp * fp * fp * (fp * (fp * 6 - 15) + 10);
    return lerp(lerp(d00, d01, fp.y), lerp(d10, d11, fp.y), fp.x) + 0.5;
}

// -------------------------------------- Gaussian Blur --------------------------------------

#define SAMPLE_KERNEL(i, x, y) \
    color += kernel[i] * tex.Sample(ss, uv + texel_size.xy * float2(x, y));

// Gaussian Blur Function
float4 gaussian_blur_3x3(Texture2D tex, SamplerState ss, float2 uv, float2 texel_size)
{
    // Gaussian kernel
    float kernel[9] = {
        0.0625, 0.125, 0.0625,
        0.125, 0.25, 0.125,
        0.0625, 0.125, 0.0625,
    };

    // Sample the texture
    float4 color = float4(0.0, 0.0, 0.0, 0.0);
    SAMPLE_KERNEL(0, -1, -1);
    SAMPLE_KERNEL(1,  0, -1);
    SAMPLE_KERNEL(2,  1, -1);
    SAMPLE_KERNEL(3, -1,  0);
    SAMPLE_KERNEL(4,  0,  0);
    SAMPLE_KERNEL(5,  1,  0);
    SAMPLE_KERNEL(6, -1,  1);
    SAMPLE_KERNEL(7,  0,  1);
    SAMPLE_KERNEL(8,  1,  1);

    return color;
}

float4 gaussian_blur_5x5(Texture2D tex, SamplerState ss, float2 uv, float2 texel_size)
{
    // Gaussian kernel
    float kernel[25] = {
        0.00390625, 0.015625, 0.0234375, 0.015625, 0.00390625,
        0.015625, 0.0625, 0.09375, 0.0625, 0.015625,
        0.0234375, 0.09375, 0.140625, 0.09375, 0.0234375,
        0.015625, 0.0625, 0.09375, 0.0625, 0.015625,
        0.00390625, 0.015625, 0.0234375, 0.015625, 0.00390625,
    };

    // Sample the texture
    float4 color = float4(0.0, 0.0, 0.0, 0.0);
    SAMPLE_KERNEL(0,  -2, -2);
    SAMPLE_KERNEL(1,  -1, -2);
    SAMPLE_KERNEL(2,   0, -2);
    SAMPLE_KERNEL(3,   1, -2);
    SAMPLE_KERNEL(4,   2, -2);
    SAMPLE_KERNEL(5,  -2, -1);
    SAMPLE_KERNEL(6,  -1, -1);
    SAMPLE_KERNEL(7,   0, -1);
    SAMPLE_KERNEL(8,   1, -1);
    SAMPLE_KERNEL(9,   2, -1);
    SAMPLE_KERNEL(10, -2,  0);
    SAMPLE_KERNEL(11, -1,  0);
    SAMPLE_KERNEL(12,  0,  0);
    SAMPLE_KERNEL(13,  1,  0);
    SAMPLE_KERNEL(14,  2,  0);
    SAMPLE_KERNEL(15, -2,  1);
    SAMPLE_KERNEL(16, -1,  1);
    SAMPLE_KERNEL(17,  0,  1);
    SAMPLE_KERNEL(18,  1,  1);
    SAMPLE_KERNEL(19,  2,  1);
    SAMPLE_KERNEL(20, -2,  2);
    SAMPLE_KERNEL(21, -1,  2);
    SAMPLE_KERNEL(22,  0,  2);
    SAMPLE_KERNEL(23,  1,  2);
    SAMPLE_KERNEL(24,  2,  2);

    return color;
}

float4 gaussian_blur(Texture2D tex, SamplerState ss, float2 uv, float2 texel_size, float blur)
{
    float4 col = float4(0.0, 0.0, 0.0, 0.0);
    float kernel_sum = 0.0;

    int upper = (blur - 1) * 0.5;
    int lower = -upper;

    for (int x = lower; x <= upper; ++x)
    {
        for (int y = lower; y <= upper; ++y)
        {
            kernel_sum++;
            float2 offset = float2(texel_size.x * x, texel_size.y * y);
            col += tex.Sample(ss, uv + offset);
        }
    }

    col /= kernel_sum;
    return col;
}

#endif

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

#ifndef _INCLUDE_PIXEL_ART_HLSL_
#define _INCLUDE_PIXEL_ART_HLSL_

#include "Packages/com.unity.render-pipelines.universal/ShaderLibrary/Core.hlsl"

float2 pixelate_uv(float2 uv, float4 texel_size)
{
    float2 tpp = clamp(fwidth(uv) * texel_size.zw, 1e-5, 1);
    float2 tx = uv * texel_size.zw - 0.5 * tpp;
    float2 tx_offset = smoothstep(1 - tpp, 1, frac(tx)) + 0.5; // saturate((frac(tx) + tpp - 1) / tpp) + 0.5;
    uv = (floor(tx) + tx_offset) * texel_size.xy;

    return uv;
}

float3 pixelate_world_pos(float3 world_pos, float ppu)
{
    return floor(world_pos * ppu) / ppu;
}

#endif

Tilemap 的缝隙问题与解决方案

正文中提到在 tilemap 中使用 高斯模糊 特定情况下可能会有问题, 如果模糊采样的范围(_FoamTexelSize)扩得太大, tile 的表现可能会异常. 具体到泡沫这里的例子, 随着 _FoamTexelSize 的增大, 水体内部的 tile 可能会出现异常的白色.

这个问题要从 tilemap 缝隙问题谈起, 这是一个几乎所有刚开始使用 tilemap 的人都会遇到的一个坑, 表现是 tilemap 在镜头移动过程中会出现缝隙, 即使所使用的 tileset 是严丝合缝的. 关于这个问题, 比较好的解释可以参考 Fixing Seams - Tiled2Unity, 简单来说是 shader 在采样 tile 贴图时, 由于数值的精度问题会导致采样到贴图外面. 处理的方法也很多, 一种方式类似 jess 的 tileset 中的处理, 会发现每个 16x16 tile 的外面多一个像素宽度的颜色, 防止采样到 tile 外面后颜色不对导致缝隙.

我使用 Supertile2Unity 这个项目, 把 Tiled 导出的 tilemap 导入到 unity. 在最新版本中, 这个插件会自动分割整张 tileset 纹理, 为了实现 seamless 的 tilemap, 可以手动创建一个 Sprite Atlas, 把这些分割的 sprite 做成一个图集, 此时这些 tile 的图像边缘会自动增加外扩的像素(在 Atlas 不勾选 Alpha Dilation 的情况情况下), 从而避免缝隙的产生. 只是打成图集后, 这些 tile 图片挨得非常近, 只有几个像素的间距(Atlas 检索面板中只能设置 2, 4, 8 个像素距离), 所以模糊采样时, 如果范围太大, 就会采到相邻图片的颜色. 一种解决办法是自定义图集的生成, 扩大图集中每张图片的间距. 这里也有一些坑, 不过和这次的主题差太远就先不提了.

其他参考

2d游戏水体的参考

• Creating a 2D Water Shader in Unity - YouTube
• How to create a Water Tile Map Shader in Godot 4 - 2 minutes tutorial - YouTube
• 基于屏幕的2D实时反射
• Creating Animated Pixelart Water - Aseprite Tutorial - YouTube

3d游戏水体的参考

有时可以从真实水体渲染方案中找找灵感

• Unity URP 风格化水 – 放課後ティータイム
• 在URP实现水面效果 | Musoucrow’ BLOG
• Unity 实现平面反射（基于 URP）
• TA实践分享：材质与渲染——水体(Unity+UE） - UWATech
• Making Interactive Water using RenderTexture | Patreon
• 水面シェーダーを作成する方法 [Unity] – Site-Builder.wiki
• Are water shaders still popular? (breakdown video) : r/Unity3D
• Yet Another Stylised Water Shader - Half Past Yellow | Blog
  .
  .
  .
  .
  .
  .
  .
  終わり

这种感觉多出现于读完一个戳中我内心的好作品, 所谓贤者时间嘛. 好作品倒常见, 但真直达我心深处的却不那么多. 我似乎感觉到一种作者就是给像我一样的读者创作的感觉. 这种没有任何阻碍的信息传达, 每一个细节都精准击中的感觉, 实在是太舒服, 太让人回味, 以及太让人害怕失去了. 惊喜之后, 你就要付出面对终结后无尽苦闷的代价, 甚至是远没有到终结那天, 已经开始品尝终结的痛苦滋味. 这种痛苦在相遇之时就已注定, 无可避免.

前面我谈及了最表层的两种感觉, 已经略感纠结. 越是高看作品价值的人, 越是容易被这种感觉缠住无法自拔, 乃至不忍卒读. 我现在依然能回忆起的, 像是高分少女, 昨日之歌完结之时也都有类似症状. 如果再追问一步, 到底是什么放大了这种感觉, 可能就是对故事中的角色产生了相当的代入感, 也就是俗话说的入戏太深. 这其中大多是角色而不是故事在起作用. 不过话说回来, 哦, 原来你小子也是吃角色这一套的, 尽管在此之前我从不这么认为. 也许还可以看出, 这些多少都可以归到某种偏真实系的爱情剧, 这难道是我又一个软肋? 上面提到的作品, 可能远说不上伟大, 但我都愿意不吝称他们是好故事, 好角色, 情感真诚细腻且丰富, 确实很对我胃口.

回到前面说的直面这种苦闷, 何解? 有人说这种苦闷并不稀罕, 年轻人, 多读读经典的好作品, 你就发现等你还没来得及接受苦闷洗礼, 就会被下一个惊喜冲昏头脑了! 也有人说这种苦闷不值得, 年轻人, 多体验体验生活, 经历多了就看淡了. 长远来看是有些道理, 但对于此刻正处于苦闷的我来说如隔靴搔痒. 最后得出最可操作的做法是, 妈的, 得想个办法把进度推到最新, 然后熬着.

熬着, 我估摸着这应该也算不上是一种精神自虐吧. 想来这苦闷也不尽然全是坏处, 比如可以反思下自己的当下, 作者创作的”狡黠”, 最少也有一个念想.

说到创作者, 我这里不展开聊冬目景老师的事, 而是想说一类作品的共性. 高分少女和昨日之歌给我的感觉其实不太一样, 昨日之歌与百木田因为作者是同一人所以感觉确实是相近的, 而此之外, 石黑和小原漫画的感觉则和冬目景更近. 就是我想说这其中一定有某个东西贯穿了这些作者和作品, 同时不知怎得也把我连在其中, 让这些成了我最喜欢的一类作品. 我说不清这种感觉到底是什么, 思前想后, 有时在脑袋中会闪过这样一个具象画面, 是一个眯着眼睛笑着说话的角色!? 这些作品里确实也都有这样场景或角色. 更多地, 角色的说话方式, 剧情编排, 漫画的分格与分镜, 难道是某些共同的经验, 让我们对一个特定的漫画表现方式产生了特殊的感觉, 又或者说, 达成了某种对于漫画这一事物认知的共识? 这个话题我只能深入到这里. 也可能是我错了, 大错特错, 这些都是作者创作出的可恶的幻觉…

这苦闷之中似乎还有头绪, 我知道了我喜欢什么样的作品, 然后呢? 是的, 我满怀欣喜消费这些作品, 甚至恨不得直接把钱塞到创作者的钱袋子里, 我想是人都来者不拒的. 不可否认, 支持是重要的, 然而却并不总是稀有, 有时似乎创作者并不缺我这一份支持. 当然在创作者处境艰难时, 这个支持会格外有分量, 我也并不是说不缺支持就不支持, 只是这种分量, 你要说是某种爱也行, 仿佛被稀释了. 做一个只有10个粉丝的创作者的粉丝, 和一个百万粉的创作者的粉丝心态上会有不同吗. 当这种分量被削减后, 我又似乎希望通过其他方式进行补偿, 也就是, 该付出什么代价才能在心里弥补这个作品的价值, 又或者对于我们曾共同信仰的共识有几分贡献? 仿佛差额被抹平后, 才能和作者平等地对话.

好了, 以上都是我胡诌的, 但百木田家的古书时光是好作品不是. 我的贡献…我的贡献也就最多能拉个人头了, 本作双周刊グランドジャンプ好评连载中, 单行本已出版5卷, 台版东立出版1卷, 希望大家去看…
.
.
.
.
.
.
終わり

其实我在准备一个更长~篇的更新, 千真万确, 不过目前可公开的情报还不多. 那么在我们仍未知道的更新到来之前, 这次, 难得正经地, 来简单聊聊 Pixel Art 的缩放及抗锯齿问题吧…

序

さて, 为什么会谈及这个问题? 我在处理像素艺术(Pixel Art)相关渲染的过程中, 遇到了这个问题. 具体可以描述为, 当像素风格纹理的精灵图(Sprite)在缩放或移动时, 会出现像素抖动与闪烁的现象, 看上去像是像素的波浪, 非常影响观感. 如图1左上角的例子.

顺带一提, 精灵图上的角色是GBA游戏《公主联盟》中的大天使マリエッタ.

这个问题其实非常常见, 稍作检索就能找到原因与解决方法. 一个简单的规则是, 像素图的放大需要是原尺寸的整数倍, 否则会出现畸变(Distorted). 这种畸变是规律性的, 在放大或移动过程中就会出现有规律抖动和闪烁. 这里, 通常我们默认像素原图是比较小的, 所以在屏幕显示时主要是进行图像放大操作, 即Upscaling.

以上, 虽然是简单的理解, 但从某种角度说确实是最优解, 即不做任何的妥协, 让像素艺术分毫不损地显示到屏幕上吧! 在大部分时候, 上述方法并不会增加什么负担, 不过是限制游戏分辨率而已. 也可以参考 unity 官方的 2d-pixel-perfect: Pixel Perfect Camera项目的方案.

但还是让人不禁想问, 是否有什么办法能让 Pixel Art 突破分辨率的桎梏, 同时不丢失太多表现力呢? 说到这里, 我回忆起之前3DS模拟器上玩到的结合3D场景与像素角色的游戏, 也有类似的观感.

相比之下, 尝试解决突破这个限制的分享和讨论则不是很多. 不过, 好在以我的检索能力依然能找到一些, 同时看到方法演进的思路. 我觉得更重要的是, 这些分享的内容都丰富且详尽, 是相当好的参考. 只是这样, 我也会认为这些技术值得分享.

这里自然不必把别人发明的东西再发明一遍, 我会在下面列出这些参考. 如果你也在解决类似问题, 可以参考看看(保佑你不是先看过了下面的内容后才看到这里).

• Manual texture filtering for pixelated games in WebGL – Algorithmic Pensieve
• Superior texture filter for dynamic pixel art upscaling
• Scaling Pixel Art Without Destroying It
• Crafting a Better Shader for Pixel Art Upscaling - YouTube
• Pixel Art AA Video Notes | Patreon

上面的顺序正好是这几个作者相互引用的顺序, 其中第五个参考是 t3ssel8r 对于第四个参考(其所制作视频)的进一步解释. 关于 t3ssel8r 大佬还想多说几句, 很早之前看到过 t3ssel8r 关于3D像素艺术渲染的 Demo, 效果非常惊艳, 竟然能把像素画面调教地这么舒服. 至今还能在油管上看到其他人对 t3ssel8r demo 的 recreation. 不仅如此, t3ssel8r 其他游戏开发相关的分享, 质量也是高的可怕. 只是最近一年里频道貌似不怎么活动了, 不知进展是否顺利.

那么, 这篇文章到这里就结束了… 即使不理解原理, 只拿参考中简短的 shader 代码就能够得到图1下边一行的结果, 肉眼可见, 效果是相当明显的. 对了, 可能唯一容易漏掉的是, 如果使用Unity, 记得把对应纹理的滤波模式(Filter Mode)从最近邻插值(Point)调整为双线性插值(Bilinear).
.
.
.
.
.
虽然就想这样结束, 但出于笔记的完备, 我依然想稍微深入地谈谈对于这个问题的理解, 这些理解大体也不会超出参考的内容, 只算作是一个注解罢了.

问题引入

让我们试着重新理解为什么像素 Sprite 在放大后(非整数倍放大), 会出现像素畸变.

要理解这个问题, 需要先理解像素(pixel), 纹素(texel)与纹理采样(Texture Sampling)的概念. 像素通常意义下指的是屏幕显示的最小单元, 我们知道显示器分辨率即是用显示多少像素定义的. 而纹素指的是纹理贴图(Texture)最小色块单元. 在 Pixel Art 的语境下, 纹理贴图也通常带有明显的风格化特点. 纹理采样即是把贴图显示到屏幕上的过程. 某个像素的屏幕坐标$(x, y)$, 通过纹理坐标映射转换到归一化的纹理坐标$(u, v)$, 最终采样到纹理的颜色并显示在像素上.

如此我们可以知道, 在一定条件下, 像素与纹素是可以相同大小的, 此时像素与纹素将一一对应, 每个像素显示一个纹素的颜色. 在使用 Pixel Art 的纹理贴图时, 大部分情况下, 都需要对贴图进行放大显示, 因为原始像素素材通常是很小的, 而现代显示器的分辨率又辣么大. 一旦进行贴图的放大操作, 可以想见, 此时纹素色块也被扩大了, 会出现多个像素对应同一个纹素的情况.

事实上在 Unity 中, 当 Sprite 放大时, 会使用设定的 Filter Mode 对纹理进行插值操作. 插值是为了让像素在纹理放大后依然采样到期望的颜色. 就像上面提到的, 即使此时多个像素对应同一个纹素, 在不同应用场景下(比如期望像素颜色平滑过渡), 这些像素也并非就期望取对应纹素的颜色, 而是交由插值方法来最终决定的. 可以说, 不同的插值方法定义了像素纹理采样时参考纹素颜色的方式.

特别地, 对于像素艺术风格的纹理, 通常 Filter Mode 会选择设置为 Point, 即最近邻插值(Nearest Neighbor Interpolation). 简单说, 就是直接使用距离最近纹素颜色作为采样像素的颜色. 这种插值方式不会造成像素的模糊, 保持了像素色块间颜色的锐利变化, 也即保持了所谓的”像素感”. 可以说是像素艺术纹理理想的插值方法.

唯一的问题是, 当放大倍数为非整数倍时, 会有部分落在插值参考纹素边缘的采样像素, 这些像素无论最终选择插值为边界哪一边的颜色, 都不可避免地让色块组成的形状产生畸变. 这里引用下 Cole 在 Scaling Pixel Art Without Destroying It 一文中的图, 非常直观地说明了这一点.

从图2可以看到, 下边的纹理在放大$\frac{7}{3}$倍后, 采样后的像素色块的形状发生了扭曲. 但是又如上边的例子所示, 却可以无损地放大2倍. 观察一下最近邻插值的过程, 纹理放大后, 每个像素的颜色都被定义为距离最近的放大后原纹素的颜色.

解决思路

上述提到的参考, 核心的解决思路其实是相同的. 如果牺牲在所难免, 那就只能尽可能减少牺牲. 事实上, 我们对于最近邻插值在靠近参考的原纹素中心附近的插值结果还是很满意的. 而落在那些参考纹素边缘的, 模棱两可的像素采样点(如图2中被虚线横穿的那些采样点)择需要被进一步调教. 具体来说, 我们希望这些像素的颜色是作为边缘两侧颜色的过渡(平滑). 这样就避免在放大或移动过程中, 因为边界线的移动, 导致这些像素颜色的跳变. 也就是类似图3(依然引自 Cole 文章)中的效果.

毫无疑问, 这会损失一些”像素感”, 但好在这些平滑只发生在边界处, 通常占像素数量的比例很少. 那么接下来的问题就剩两个了, 如何找到这些边界处的采样像素, 以及如何确定这些采样点的颜色. 当然, 一个足够好的解决方法, 最好能同时解决这两个问题.

在上面两个问题中, 相对容易确定的是后者. 对于采样点颜色的平滑, 依然可以借助插值. 作为应用最广泛的双线性插值(Bilinear Interpolation)正满足这种需求. 二维平面上, 在给定4个参考点的情况下, 双线性插值对于任意一个参考点范围内的采样点进行两个维度上共三次线性插值. 双线性插值得到的采样是平滑的, 因而非常不适合 Pixel Art 纹理, 而对于绝大部分其他类型的纹理来说, 则是兼具性能与效果的选择. 其也作为基础插值方法, 内置于各大引擎. 因为不算很复杂, 我在附录1中也简单解释了其插值原理及性质, 算是对SIFT特征提取算法理解与实现中提到的三线性插值做一个补充.

解决第一个问题的思路最早在Manual texture filtering for pixelated games in WebGL – Algorithmic Pensieve这篇博客中被分享. 其提出的解决问题的思路可用下图来说明,

我们首先定义一个 tpp(texel per pixel) 值, 这个值描述了像素与纹素的大小比例. 如 tpp = $\frac{1}{2}$, 表示一个纹素有两个像素长或宽. 当纹理放大时, 纹素对于像素就越大, tpp 的值就会相应变小. 接着, 我们可以把纹理上的纹素视作紧密排布的方形色块, 如图4中较大正方形所示. 同时像素也可以视为方形色块. 采样时像素方块映射到纹理坐标下, 如图四中较小正方形所示. 图四中 tpp 为 $\frac{1}{2}$, 此时可见, 像素是纹素方块的$\frac{1}{4}$大小.

图四上下两图中可以看到, 经过纹理映射的采样像素在水平方向上穿越一个纹素的过程. 当采样像素的区域完全落在同一纹素区域内时(如紫色方块之间的部分), 像素应该采样该纹素的颜色, 即之前认为的像素离这个纹素中心足够近的情况. 而采样区域如果落在多个纹素之间(如绿色方块附近), 此时就需要进行平滑插值计算采样值. 可以想象, 当区域落在4个纹素的交界中心时, 此时插值效果最平滑, 即插值需要平均地参考4个覆盖纹素的颜色.

如果这个纹理插值方法直接使用双线性插值, 而非最近邻插值, 那么此时在纹素内部采样得到的颜色是已经经过线性插值平滑的(如图四紫色采样区域, 虽然区域完全在单纹素区域内, 但采样结果也是经过附近纹素颜色线性插值过的). 只有当采样区域落在纹素正中心时, 采样值才与纹素颜色完全一致(线性插值完全参考某个参考值的情况).

这篇文章中提出, 可以在纹理采样时手动调整纹理坐标$(u,v)$, 调整的结果是使得上图两紫色区域之间位置的纹理坐标的$u$修正为0.5, 即此时采样的是原本纹素颜色. 而其余位置的$u$则不做处理, 直接采样纹理平滑插值后的值. 同时在另一个维度$v$也进行同样的修正操作.

上述的$(u,v)$坐标的修正可以用图5所示的分段函数实现. 注意, 图5中横坐标为$lu$, 含义为采样点(采样区域中心)落在纹素上的局部$u$坐标(如右侧图示). 当$lu=0.5$, $lv=0.5$时, 采样点将位于纹素的中心. 我们可以通过微调$(lu,lv)$间接调整纹理坐标$(u,v)$. 可以发现, 图5中从$lu$调整为$lu’$的映射是一个分段函数, $lv$的映射也是类似.

关注下这个映射函数的分段点$\alpha$. 这个$\alpha$的位置即图4中上方一图的紫色采样区域, 此时正处于采样平滑插值与采样纹素中心颜色的分界点. 如果我们定义像素采样区域的宽高为$[pw, ph]$, 纹素宽高为$[tw,th]$, 那么有,

可见这个$\alpha$与 tpp 的值有关, 也即与纹理放大倍数有关. 以上就是该方法的核心思路, 接下来是针对效果及实现上的优化, 在上述参考中也都有提及.

首先, 图5的分段映射函数存在两个问题. 其一是分段点的突变. 当采样点在边界采样经过临界点$\alpha$时, 该处的平滑插值与纹素颜色存在一个突变的色差. 为了有一个平滑过渡, 可以调整从0~$\alpha$的采样点分布, 如图6所示,

调整后的映射使得平滑插值处采样点向远离原点的方向偏移, 从而消除了颜色的突变.

第二个问题是如何在 shader 中实现这个分段函数, 为避免使用条件逻辑, 文章 中使用两个 clamp 函数组合的形式来实现. 如图7中红色与蓝色两个 clamp 函数所示, 可知两个函数之和即为上述分段函数.

这两个 clamp 和可以表达为,

实现

Cole 在 Scaling Pixel Art Without Destroying It 中将上述思路在 unity 中进行了实现, 其核心的 shader 代码如下,

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

float tpp;

struct a2v
{
    float4 vertex : POSITION;
    float2 texcoord : TEXCOORD0;
};

struct v2f
{
    float4 vertex : SV_POSITION;
    float2 texcoord : TEXCOORD0;
};

v2f vert(a2v input)
{
    v2f output;
    output.vertex = UnityObjectToClipPos(input.vertex);
    output.texcoord = input.texcoord * _MainTex_TexelSize.zw; // 乘以纹理尺寸
    return output;
}

fixed4 frag(v2f input) : SV_Target
{
    float2 luv = frac(input.texcoord);
    float2 txOffset = clamp(luv / tpp, 0, 0.5) + clamp((luv - 1) / tpp + 0.5, 0, 0.5);
    float2 uv = (floor(input.texcoord) + txOffset) * _MainTex_TexelSize.xy;
    return tex2D(_MainTex, uv);
}

简化 clamp 计算

Cole 在评论中说明了关于 tpp 值的设定问题, 其做法是在相机的脚本中根据相机的 size 进行设置. 后续我们可以看到这个流程可以进一步优化. 不过在此之前, 我们先进一步简化上面的 clamp 计算.

上述讨论中, 我们默认把$(lu, lv)$设定为采样区域的中心. 为了简化, 我们也可以定义$(lu’’, lv’’)$设定为左上角, 用$lu’’$和$lv’’$来描述偏移. 此时上述分段映射函数可以调整为图8所示,

其中,

此时映射函数可以用 saturate 函数来描述,

这里稍微再多解释下图8. 同样是为了保证平滑过渡, 当$lu’’$取1时, 需映射为1.5而不是1, 也即此时需采样右侧纹素的中心. 因为, 当采样点在这个临界值继续向右移动时, 将完全地进入右侧纹素.

由此, 片元着色器的代码可以进一步简化. 这也是 t3ssel8r 在视频 Crafting a Better Shader for Pixel Art Upscaling - YouTube 中所进行简化的由来.

1
2
3
4
5
6
7
8

fixed4 frag(v2f input) : SV_Target
{
    float2 tx = input.texcoord - 0.5 * tpp;
    float2 txOffset = saturate((frac(tx) + tpp - 1)) / tpp) + 0.5; // luv = frac(tx)
    float2 uv = (floor(tx) + txOffset) * _MainTex_TexelSize.xy;
    
    return tex2D(_MainTex, uv);
}

优化 tpp 变量

前面提到, tpp(texel per pixel) 变量描述了纹素与像素的大小关系. Cole 曾提到可以通过相机参数计算该值并传入 shader. 我们希望能更合理地设置这个值, 以便在任何缩放尺度下达到最佳的效果. 相关技术最早在 Superior texture filter for dynamic pixel art upscaling 中被提及, t3ssel8r 在其视频中做了更深入的阐释.

在比较少见的 Sprite 三维旋转的情况下, 前述方法会出现新的问题, 如图9所示,

图9左侧为不做任何处理的效果, 最右侧为使用前述方法和固定 tpp 后的效果, 中间的在右侧基础上使用动态计算的 tpp. 从上图可以看到, 使用固定 tpp 值在旋转角度较大时, 依然会出现像素抖动.

原因可以理解, 发生旋转后, 纹理上的纹素不再与像素轴对齐, 此时上述讨论方法就会失效. t3ssel8r 在视频中非常直观地展示了这个过程, 并重新对这个问题进行了建模. 其核心思路是用最小轴对称包围盒替代像素经过纹理映射后被旋转的采样区域进行采样, 如图10所示.

重新回到纹理映射, 该过程把像素坐标$(x, y)$映射为归一化纹理坐标$(u,v)$, 可以用矩阵乘法进行描述,

代入归一化后的像素方格四个顶点坐标$(0,0)$, $(0,1)$, $(1, 0)$和$(1, 1)$, 得到经过对应纹理坐标为$(0, 0)$, $(\frac{\partial u}{\partial y}, \frac{\partial v}{\partial y})$, $(\frac{\partial u}{\partial x}, \frac{\partial v}{\partial x})$和$(\frac{\partial u}{\partial x}+\frac{\partial u}{\partial y}, \frac{\partial v}{\partial x}+\frac{\partial v}{\partial y})$.

分别取四个坐标$u$, $v$两方向上的最大值与最小值相减, 就得到了包围盒的长与宽.

上式中的 w 与 h 即前面讨论中使用的 pw 与 ph. 其值可借助 fwidth 函数计算得到. 于是我们可以调整 shader 为,

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

struct a2v
{
    float4 vertex : POSITION;
    float2 texcoord : TEXCOORD0;
};

struct v2f
{
    float4 vertex : SV_POSITION;
    float2 uv : TEXCOORD0;
};

v2f vert(a2v input)
{
    v2f output;
    output.vertex = UnityObjectToClipPos(input.vertex);
    output.uv = input.texcoord;
    return output;
}

fixed4 frag(v2f input) : SV_Target
{
    float2 tpp = clamp(fwidth(input.uv) * _MainTex_TexelSize.zw, 1e-5, 1);
    float2 tx = input.uv * _MainTex_TexelSize.zw - 0.5 * tpp;
    float2 txOffset = saturate((frac(tx) + tpp - 1)) / tpp) + 0.5;
    float2 uv = (floor(tx) + txOffset) * _MainTex_TexelSize.xy;

    return tex2D(_MainTex, uv);
}

以上就是关于这个话题我想说明的所有内容. 前文提到的参考中(如 t3ssel8r 的视频)解决了更多关联问题, 这里就不再展开了. 最终的效果即图1左下所示, 而右下为 Cole 的效果, tpp 根据相机参数设置.

关于像素 Tilemap 中的抖动

上述方法应用于 Tilemap 中也可以很大改善 像素Tile 抖动问题, 但是如果仔细观察, 会发现 Tile 的边缘依然会出现抖动现象. 这是因为 Tile 的纹理是从 Tileset 纹理中截取的, Tile 与 Tile 的边界并非通过直接插值得到, 可以看到这些边缘依然是锐利的. 我目前没看到有比较好处理这个问题的办法, 不过通过适当增加相机移动速度倒可以一定程度掩盖这个问题. 关于这个问题如果有后续进展, 会继续更新到这里.

附录

1 关于双线性插值(Bilinear Interpolation)

让我们先从基础的一维线性插值开始. 线性插值简单来说, 是用直线连接两个参考点, 采样点居于参考点之间, 根据其与两个参考点距离的比例关系作为权重, 对两个参考值线性加权后计算得到采样值. 如下图,

其中, $x_0$与$x_1$为两个参考点, $x$为插值采样点, 目的是求得插值$f(x)$. 利用简单的相似三角形即可求得.

如果把 $x$ 归一化到 $[0, 1]$, $x’=\frac{x-x_0}{x_1-x_0}$则有,

线性插值中, $f(x_0)$与$f(x_1)$的权值即$x$分别到$x_0$与到$x_1$距离的反比. 也就是距离越远的参考点, 其权重就越小, 非常符合插值的直觉.

要把线性插值应用到二维平面会稍微麻烦些, 不过这些麻烦只是形式上的. 具体来说, 可以分维度依次进行线性插值, 如下图,

A, B, C, D为二维平面四个参考点, 其构成的四边形为轴对齐矩形. 先选择一个方向进行两次线性插值. 这里选择x还是y轴方向不影响最终结果, 如上图为先进行x轴方向插值, 得到$f(x, y_0)$与$f(x,y_1)$. 直接套用线性插值的结果有,

接着进行y方向线性插值,

代入前面的插值结果, 化简得,

若对x, y进行归一化, 令$x’=\frac{x-x_0}{x_1-x_0}$, $y’=\frac{y-y_0}{y_1-y_0}$,

与线性插值时相同, 这里各参考值线性加权的权重比例按面积划分. 采样点越靠近参考点, 此时对角的参考点与采样点围成的面积越大, 即权重越大. 各面积区域作为权重与对应参考点关系如下图.

同样原理, 可以类推三线性插值(Trilinear interpolation), 其分别在三个维度方向上依次进行线性插值. 并且也具有体积比权重性质.
.
.
.
.
.
.
.
終わり

这篇文章粗浅地介绍用Python开发Unity的一种可行的姿势, 以及可能会踩的一些坑.

背景是最近在尝试用Unity开发独立项目, 说实话, 一开始打算使用Python与Unity的组合确实没有料想到会有这么多问题, 毕竟一边是当前最主流的商业游戏引擎, 而另一边则是当前最主流的编程语言, 官方支持暂且不提, 各种应用一定很丰富吧. 但当我开始检索不得不认清事实, 相关资料少得可怜, 这个技术路线更多被应用于科研, 这倒也并非不可理解.

如前所述, 本文只是粗浅介绍一种用Python开发Unity的姿势, 除自己折腾外实则并不推荐. 显然就商业项目而言, Lua+Unity才是各种成本最小的选择. 简单一提, 因为热更新的需要, 通常把需要频繁更新的逻辑用解释型语言来编码. 除此之外, 在Unity中引入动态语言的好处还有不少, 比如相比原生C#有更高编码效率, 更容易上手, 改写动态语言编码的逻辑也不会触发Unity耗时的重编译. 至于为什么选择用Python更多是个人喜好, Python原生支持面向对象, 基础设施较为完备, 语法优雅, 美中不足是牺牲一些运行效率.

本文并不会涉及如何构建基于Unity的Python框架, 及优化Unity和Python调用性能等高级话题, 或许等到我有了些许心得的时候再聊.

当我们决定用Python来开发Unity时, 我们在想什么? 首先, 这从理论上可行性如何? 因为目前主流已有不少使用Lua开发Unity的方案, 所以应该可行, 需要了解下Python相关的支持如何. 也许可以试试Unity官方Python插件?

Python Scripting插件

没错, 实际上Unity官方确实提供了一个Python插件, 利用该插件可以在Unity编辑器中执行Python脚本, 具体用法可参考官方文档与插件包内的例程. 安装可以参考这个讨论Python for Unity Install - Unity Forum. 截至目前, 这个插件竟然已迭代到了第七版(然而文档依然很简略), 安装插件会自带一个Python解释器.

然而经过简短的使用后发现一些问题, 首先这个Python解释器似乎是与Unity编辑器进程绑定的, 每次进入Play模式依然保留有上次运行的状态, 包括导入的module等, 更关键的是在代码中使用了Python插件相关接口Unity会无法build, 也就是无法利用这个插件开发独立的Unity应用. 也许是我看漏了, 我好像没有注意到官方文档有相关的说明, 直到我看到了这个讨论Python for Unity Editor Only - Unity Forum.

所以, 如果只是拿Unity和Python做个编辑器应用这个插件还是绰绰有余的, 但想更进一步就得自己动手了. 这个讨论也启示了一种使用Python开发Unity独立应用的方法, 最新的回帖坛友分享了他解决方案的一个例子Showcase - Python for Unity - Unity Forum.

启示, Python Scripting插件底层接口是依赖于一个叫Python.NET的开源项目, 借助这个开源项目能够实现Python与C#的相互调用, 这正是我们所需要的.

Python.NET

因为Unity本身是基于.Net平台的, 可以把思路转换成Python在.Net环境下开发. 检索了一下, 目前比较主流有两种方案. 其一是前面提到的Python.NET, 另一个是同样开源的IronPython项目. IronPython是C#的Python实现, 有更好的C#支持, 而Python.Net支持的是CPython实现, Python这边的支持更好, 接口调用方式来看差异倒不是很大, 都值得尝试. 这里选择更新稍勤奋的Python.NET进行测试.

为了便于测试, 首先创建一个的Unity目录结构, 只列举必要的文件夹.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Assets/
    |- Plugins/               第三方插件dll
    |    |- PythonRuntime/
    |
    |- PythonScripts/         Python代码
    |    |- main.py
    |    
    |- Scripts/               C#代码
    |    |- Manager/
    |    |    |- PythonMgr.cs
    |    |- GameLauncher.cs
    |
    |- SteamingAssets/
    |    |- Python/
    |
    ...

然后需要下载一个Python实现及Python.NET项目编译输出的dll, 分别放在Python与PythonRuntime文件夹内.

以Python3.10为例, 从Python Releases for Windows | Python.org下载3.10版本的Windows embeddable package压缩包, 解压后放到Python目录即可, 这个package的python貌似是不带pip, 可能需要手动安装.

至于Python.NET编译的dll需要把项目源码从Github上下载下来, VS打开并编译一下Runtime这个子项目, 拿到Python.Runtime.dll并放入PythonRuntime目录.

Python.NET源码版本的选择这里有个问题, 即前面提到的, Unity编辑器进入Play模式运行Python脚本后, 再退出Play模式, Python运行时不会关闭, 依然会保留之前运行的状态(重新初始化也不会生效), 这自然对开发过程带来很大的不便. 而且可能因为Python侧引用失效, 存在第二次运行Play模式时崩溃的隐患. Python.NET在早前的一个版本中加入了SoftShutdown模式可用来处理上述情况, 但在最近的几次更新中把上述功能移除了(尽管不会再崩溃). 具体细节可参考以下资料

• Python can’t reliably re-initialize; new proposal for Unity’s domain reload · Issue #957 · pythonnet/pythonnet · GitHub
• Add soft shutdown by amos402
• Python for NET domain reload
• Removed ShutdownMode. Now always behaves like original Reload by lostmsu · Pull Request #1638

如果为了使用soft shutdown带来的便利, 我们可以暂时使用pythonnet 3.0.0 alpha-2版本来编译.
关于Python.NET开发相关资料可参考:

• Python.NET
• Home · pythonnet/pythonnet Wiki · GitHub
• Python.NET documentation

Python与C#互相调用

总算看到点希望了, 简单说下测试环境. Unity空场景中创建一个Game空物体, 给Game挂上一个GameLauncher.cs作为应用的启动脚本.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// GameLauncher.cs
using UnityEngine;

public class GameLauncher : MonoSingleton<GameLauncher>
{
    private void Awake()
    {
        PythonMgr.instance.InitEnv();
    }

    private void Start() 
    {
        Debug.Log("[GameLauncher] EinS Start!");
        PythonMgr.instance.StartGame();
    }
}

PythonMgr类用于管理Python运行时, 内容如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

// PythonMgr.cs
using UnityEngine;

using Python.Runtime;
using System.IO;

public class PythonMgr : Singleton<PythonMgr>
{
    public string python_code_path;

    public void InitEnv()
    {
        Runtime.PythonDLL = Path.Combine(Application.streamingAssetsPath, "Python\\python310.dll");
        PythonEngine.Initialize(mode: ShutdownMode.Soft);
        Debug.Log("[PythonMgr] python interpreter version: " + PythonEngine.Version);

        python_code_path = Path.Combine(Application.dataPath, "PythonScripts/");
        Debug.Log("[PythonMgr] python_path: " + python_code_path);
    }

    public void StartGame()
    {
        Debug.Log("[PythonMgr] StartGame");

        using (Py.GIL())
        {
            dynamic sys = Py.Import("sys");
            sys.path.append(python_code_path);

            dynamic main = Py.Import("main");
            dynamic res = main.StartGame();
        }

        PythonEngine.Shutdown();
    }
}

为了通过Python.NET调用Python运行时需要用到Python.Runtime命名空间. 根据Python.Net的文档, 初始化PythonEngine前需要设置Runtime.PythonDLL到对应Python版本dll的路径, 或者设置PYTHONNET_PYDLL环境变量. 接着使用ShutdownMode.Soft进行初始化. StartGame中运行Python代码前需使用using(Py.GIL())获取到Python的GIL锁. 然后就可以使用Py.Import导入模块, 并调用模块方法了. 这里我们把PythonScripts路径加入sys.path, 然后加载Python脚本启动模块main, 并调用其StartGame方法.

注意要让untiy支持dynamic关键字, 需要在Unity project settings/player 中把api compatibility level 调整为 .Net Framework.

来到Python一侧, main.py内容如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# main.py

# -*- coding: UTF-8 -*-
from clr import GameLauncher

import UnityEngine as ue
from System.IO import Path

def StartGame():
    ue.Debug.Log(Path.Combine(ue.Application.dataPath, "PythonScripts/main.py"))
    
    game = ue.GameObject.Find("Game")
    gameluncher = game.GetComponent(GameLauncher)
    ue.Debug.Log(gameluncher.name)

通过clr模块, 我们可以把自定义的类类型导入进来使用, 如果这些自定义类是在命名空间中, 则需要先导入命名空间.

关于这个话题的一些参考:

• Python for Unity doesn’t support Custom class - Unity Forum
• How to call a dynamic library · pythonnet/pythonnet Wiki · GitHub

开发与调试环境

最后再简单聊一下另一个比较关键的问题, 开发与调试环境. 本来可以期待着可以All In One, 使用VS code作为开发环境, 但是Unity官方最近放弃了继续支持VS Code的插件, 具体见Official - Update on the Visual Studio Code package - Unity Forum. 所以对于C#的调试还是使用Visual Studio吧. 至于Python依然可以使用VS Code + Python插件来调试.

使用VS调试Unity的C#代码不用说是容易的, 而使用VS Code调试Python可以参考Python.NET的建议, 参考Various debugging scenarios of embedded CPython · pythonnet/pythonnet Wiki · GitHub, 我们可以使用最简单的第三种远程调试方式, 其中ptvsd已被微软所废弃, 作为替代可以使用debugpy库. 原理就是VS Code开启一个调试服务, 执行的Python脚本使用debugpy.connect进行连接调试.

VS Code新建一个Python调试配置, 内容如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

// launch.json
{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python debug",
            "type": "python",
            "request": "attach",
            "justMyCode": true,
            "listen": {
                "host": "0.0.0.0",
                "port": 5678,
            },
            "pathMappings": [
                {
                    "localRoot": "${workspaceFolder}",
                    "remoteRoot": "${workspaceFolder}"
                }
            ]
        },
    ]
}

然后在main.py中增加

1
2

import debugpy
debugpy.connect(("localhost", 5678))

完成后VS Code先开启调试, Unity进入Play模式运行python脚本即可, 与调试普通Python脚本相同.

Enjoy.
.

.

.

.

.

.

.

.

終わり

P5华丽不失精致的外壳

当代电子游戏作为一种高度工业化的商品, 可以从很多视角去说, 像是美术, 配乐, 故事设定等. 初见P5, 上述三个方面是最直接能感受到制作组用心的地方, P5的这个组合更是有意思, 至少已经勾起了我浓厚的兴趣继续玩下去.

美术

P5的美术绝对值得单独拿出来提的. P5在色彩上为了和怪盗的设定契合大量使用了红黑的配色, 不得不说非常符合怪盗即优雅又神秘的气质. 在菜单画面的设计上也用了非常多的大色块, 使得很多画面非常鲜艳. 此外, 也许是为了让玩家能在眩目的菜单中抓到重点, 也用了很多动态的元素, 比如背景是大色块的缓慢变化, 而所选的选项则用不规则抖动的色块所包裹, 这也是我经验中很少看到的. 我在游戏里第一次看到约瑟交换花朵的菜单时被彻底惊艳到了.

P5除了在菜单画面中用了非常多的动态元素, 另一个特别细节的设计是界面间的切换使用了大量转场动画(切换动画). 如三角键进入的菜单切换是joker各种连续改变姿势的动画(LoadData菜单还有几率刷出joker出糗的动画, 太细节了). 在游戏的战斗界面中这种转场更是无处不在, 选择一种操作就进行一次镜头切换, 人物的姿态也对应发生变化. 再比如制作潜入道具时把菜单像纸一样揉成团和展开的动画. 这些转场让菜单的操作也变得如此炫酷, 同时提升了流畅度. 看到网上调侃, P5是第一个用转场动画强行延长游戏时间的游戏, 当然, 我不清楚做这些动画是否会带来过高的成本. 上述提到的这些设计在P4中是几乎没有的.

聊到P5的人设反而没什么可聊的, P4P5都是中规中矩的日系人设. 反而人格面具的形象设计可能是P系列风格化的另外一点, 因为出乎意料地非常不符合日式审美. 精神象征人格面具这东西在P系列中也是玩法的核心之一(没错, 就是jojo的替身), 每个人格面具设计的出发点是世界各国文化与传说中的一些人神魔兽等, 还是相当考究的, 只是有些我觉得设计得非常放飞自我, 一些魔物的设计真是有点让我联想到剑风蚀之刻里的怪物(当然也没那么夸张, 剑风里的怪物设计真是狂掉san值).

游戏的剧情对话界面则和大部分日式游戏没有太大区别, 对话框用的抖动气泡, 比较特别的是为了增强表现力常常在对话中插入人物面部特写, 我个人是很喜欢这些漫画式的表现方式.

配乐

除了画面之外, 另一个能直接让人喜欢上的就是P系列祖传的目黑的配乐了. 最开始吸引我接触女神异闻录系列就是P4G的配乐, 那时候就觉得P4G的配乐真是时髦度爆表, P4G的背景明明是乡下, 听着逛街曲《Heartbeat,Heartbreak》楞是感觉来到了灯红酒绿的大都会. 由于配乐而入了某个坑在我这也挺常见的, 奥日与大逆转也差不多是这种情况, 未来大概也会去试试尼尔吧.

单从风格上说, 目黑将司拿手的我大概知道是爵士和蓝调, 虽然在P4中略显不搭, 只能说配乐风格太强烈, 但到了P5里, 却和怪盗的主题意外地很相称. 说来也非常有意思, 爵士配黑帮怪盗其实很早就有这种印象, 但一直不知道缘由. 看网上有介绍说在jazz最为盛行的20世纪20年代, 当时出了几部比较有影响力的黑帮电影, 像是美国往事, 都大量采用了爵士配乐, 所以这种印象被保留下来, 并且被后世的作品不断强化. 就我自己接触到的像黑帮动画《永生之酒》与怪盗《鲁邦三世》也都大量采用了爵士配乐, 前者的《GUN’S & ROSES》和后者大野雄二的《Theme From Lupin 3》可说是经典中的经典了. 但是也能明显感觉到, 虽说都是爵士, 目黑的爵士与前面提到的还是不太一样, 看网上评论说应该更接近酸爵士(Acid Jazz), 或称迷幻爵士, 属于爵士和Hip-hop的融合, 其实就不太有爵士味了, P5的曲子中有一首《Life Goes On》我觉得应该是非常标准的酸爵士. 顺着这条线, 我也非常幸运地找到了这一风格喜欢的音乐人, 比如加拿大的Four80East组合, 比较有代表性的作品是《Noodle Soup》和《Drive Time》.

说回P5, 当然目黑除了一些风格强烈的配乐外, 更多是比较常见的偏”洗脑”(重复旋律)的RPG配乐, 比如几个固定场景, 战斗和迷宫探索的配乐. 日式RPG游戏时长一般都比较长, 在跑图, 探索以及一些需要刷刷刷的部分会花很多时间, 自然需要一些可长时间循环且不会让玩家烦躁的配乐, 这部分我觉得P5做得也还不错. 就我自己来说, 这部分的配乐我会更关注也更喜欢, 因为每当听到这些配乐, 在游玩过程中经历的种种场景仿佛又重现于脑海. 如网上在这些曲子下的评论都是玩家的各种回忆, 如果是一些较难关卡的配乐, 甚至听到时会产生PTSD. P5的几个迷宫曲子都还挺”洗脑”的, 双叶殿堂的《母のいた日々》, 生存游戏商店的《Layer Cake》, 新岛殿堂的《The Whims of Fate》以及丸喜殿堂的《Gentle Madman》印象都挺深. 这些曲子如果单拿出来听感觉一般, 但是在重复了几十个小时后已经牢牢地和游戏体验绑定在一起, 或许这也是配乐或者说原声音乐(OST)的魅力所在吧.

P5配乐的另一个有意思的地方在于有相当一部分配乐是有英语人声的, 事实上整个P系列都一直如此, 现在这一类反传统的配乐也是出现得越来越多了. P5的几个主要战斗曲都有人声的版本, 只在战斗的最高潮时切入, 像是《Last Surprise》和《Rivers In the Desert》. 至于为什么用英语人声, 貌似并没有什么特别的理由, 我记得在一个什么目黑的访谈中提到只是因为日本人对于英文发音有种”虽然听不懂但是很厉害的样子”这种印象?

要从乐理层面聊配乐我是完全不够格的, 好在网上也能找到一些比较专业的评价, 如音乐人Alex做过的一个系列音乐制作人谈P5名曲《Last Surprise》好在哪？, Ranking Persona 5’s Palace Themes (as a Music Producer).

设定

抛开没接触过的P3等前几作不谈, P系列的主要设定都是与人精神世界的冒险相关, 现实中人的认知与具现化精神世界(即殿堂)中的人(或者称为阴影)相联系, 而主角们正是进入精神世界展开各种行动, 最终达到改变现实中人认知的目的. 在殿堂中, 主角们自然也是使用精神世界的代表来进行战斗, 这就是人格面具(Persona). 这一设定在每作之间大体相同, 只是在细节上略有差异. 另一个则是每作与之联系的主题设定, 在P4中主角们是以事件调查团的身份行动, 目的是让现实中的人接受真实的自己, 而在P5中主角们化身怪盗团, 通过借由偷走殿堂中的秘宝来改变现实中人的认知并使其悔改. 我确实也更喜欢P5的设定, 一是感觉靠最后一通让人幡然悔悟的嘴炮, 不如像偷秘宝这样来得简单直接(不过设定的解释会是一个瑕疵), 整个行动过程也非常帅气优雅. 二是还有什么比作品里那些满是丑恶嘴脸的大人亲口忏悔自己的罪过来得更爽快的呢.

简单聊聊P5的玩法

如前所述, P5的主要玩法可分为现实世界与精神世界的体验两部分, 在现实世界的部分主要是日常生活的体验, 像是上学, 打工, 与某个社群(coop)的伙伴加深羁绊等, 这些活动的目地除了推进剧情, 更是为了解锁在探索精神世界时非常有用的技能(主要是通过提升coop等级解锁). 所谓精神世界的探索即是探索悔改目标的殿堂(设定上欲望扭曲者会拥有殿堂), 殿堂是一个有着特定主题, 并集战斗, 探索, 解谜一体的大型迷宫, 直至最后找到殿堂的秘宝, 战胜殿堂主盗走秘宝, 推动剧情进入下一章.

简单说一说其中我关注的一些设计. 我觉得P系列和其他jrpg很不一样的一个地方是用了替身战士即人格面具的设计, 也就是P系列的战斗不仅要关注角色的成长, 更要关注人格面具的培养, 这是两套相互联系却又很不同的系统. 在使用人格面具的战斗中, 敌人攻击的是玩家而不是人格面具, 因此在日常生活中的锻炼提升的是角色的5维属性, 但玩家又能获得所装备人格面具的抗性与弱点, 也可以使用人格面具进行魔法物理攻击, 反而角色则很少进行攻击行动(平A). 那么如何培养强大的人格面具呢? 只是通过传统的战斗是不行的, 虽然我不知道战斗的经验值是如何分配的, 就我自己的体验来看, 战斗也主要是提升角色等级, 而让人格面具升级提升5维属性是比较困难的, 一般需要在装备同一个人格面具的情况下进行大量战斗, 这是不现实的, 因为战斗中需要利用不同人格面具的抗性与技能, 总体玩下来在战斗中让主角人格面具升级的次数屈指可数. 当然这种设计也是有意为之的, 不然这么大本人格面具图鉴就白设计了. 游戏机制给出的引导是提升现实生活中coop的等级, 这样可以合成出5维属性更高, 抗性也更好的面具, 属性通常都会大大高于已经拥有的人格面具. 这种设计在我初次接触P系列还蛮不适应的, 因为我此前在玩其他的时候总想着主角可以不断地成长, 一些技能的搭配越来越完善, 逐渐形成一种套路化的战斗流程, 到了P系列这, 每次为了提升自己的实力, 都需要对已有的人格面具重新洗牌, 重新搭配技能, 才能确保自己有全属性的打击面. 所以到中期的时候我基本就放弃这种想法了, 只盯几个特殊的打击面, 其他有什么用什么. 不过到了后期…嗯…后期的人格面具培养是另外一种玩法了.

P系列另一个有特点的系统就是coop社群系统, 虽然P4也有, 但P5中才把这个系统做得更具价值. 要说明这点还是要先回过头去说P5的殿堂, 我觉得P5的殿堂体验真是太棒了.

P5中的殿堂迷宫总算是有迷宫的样子了, 除了一些常规的迷宫收集要素, 密道, 近道等设计, 每个迷宫都有别出心裁的主题, 并且围绕这个主题设计了一些剧情和谜题. 不过就解谜来说P5的设计还是相当简单, 都是一些非常经典谜题, 但聊胜于无. 而反面教材我觉得就可以拿P4举例, 体验基本上就是P5中印象空间的简化版. P5的迷宫相比P4有另外两个我觉得非常人性化的改进, 可能是P4的失望在先, 当我看到有安全小屋和加入隐匿移动时不由拍手叫好. 安全小屋让探索迷宫时去某个地方可以更方便地快速移动, 利用后者在迷宫拐角也不用一直先盯着小地图红点, 等着阴影转身时慌张地冲过去, 开房间门时也不用因为突然出现阴影而吓个半死. P5的迷宫还有一点也非常有意思, 隐藏, 跳跃, 使用钩爪都使用的是提示加弹出操作按钮的设计, 而非可自由地做这些动作(固定场景才可执行这些操作), 这不知道是成本上的限制, 还是觉得迷宫复杂容易让玩家摸不着头脑, 总之体验还算流畅, 游戏中的机制第三只眼可高亮这些场景. P5迷宫中的大头除了探索自然就是战斗, P系列的战斗由于人格面具加入还蛮有意思的, P5又通过增加属性和新的战斗要素(如枪械), 使回合制的战斗过程也充满了乐趣. 我个人最喜欢换手这个设计, 当打击弱点致使敌人倒地时会触发One more, 即可再行动一次, 此时可执行换手即把行动权让给队友, 换手后队友获得回血回蓝攻击力buff, 通常队友会再次击中敌人弱点(已倒地敌人不行), 从而换手的过程得到连锁, 我感觉这种不断换手打出高伤害的设计真是燃爆了, 当然特效也非常燃, 另外被换手的队员并不消耗他自己本回合的行动权. P5双人合体技Show time也依旧保持了无厘头搞笑的风格.

说回coop系统, 在P5中把战斗和探索殿堂各种方便的技能作为coop升级的奖励, 因此随着游戏的进行, 战斗与迷宫探索的丰富和便利程度也在上升, 如龙司coop后期可获得的对于等级低很多的阴影冲刺可瞬杀, 再比如东乡coop最后解锁的东乡系统, 可让伙伴自行交换上场也非常实用. P5战斗时通常是固定的4人上场, 前期只有joker行动时可以更换伙伴上场, 像这种后期体验的改善还有不少. P5游玩体验做到了即使到了中期依然不断地有新的战斗和探索的要素解锁, 从而能一直保持新鲜感. 然而这个设计有一个微妙的地方. 在P5中coop的提升意味着和特定伙伴羁绊的加深, 达到一定程度可发展为特殊关系, 没错, P5是有简单的恋人系统的(要不怎么说不少人就是拿P5当Galgame玩的). 但是即使和某人成为恋人关系后, 由于游戏机制, 为了提升coop解锁技能, 玩家依然需要和其他角色单独约会, 参与游戏设计好的逛街看电影等等. 当然, 在游戏中(或者任何其他文艺作品中)带入现实考量是否有必要这一话题也一直是存在争议的, 这一话题之后聊到jrpg时可能仍然会提起. 至于P5在这点上倒也没有做得特别过分就是了.

关于P5的战斗最后再提一点, 就像攻壳的聂俊(说好的P5鉴赏视频呢?)在P5S鉴赏中提到的, 击中弱点(Weak)倒地触发One more的设计实际上降低了战斗的容错率, 使得战斗更加惊险刺激. 利用得当, 玩家可无伤解决战斗, 而一旦被敌人击中弱点也会被连续打击致使我方损失惨重. 不过由于这个机制过于强大, Boss战的设计就需要一些特别考虑. 我记得之前的感受就是打打小怪的时候各种利用弱点, 而到了Boss就特没劲, 为了突出难度通常就是全属性抗性, 只能硬着头皮打. 因此可以看到P5中的有些Boss有多个部分的设计, 各个部分抗性与弱点各不相同, 像是斑目Boss的设计. 另外一些Boss的设计就不是战斗这么简单了, 比如新岛Boss和双叶殿堂的Boss, 加入了新的互动要素和机制, 比如能够改变自身的抗性等.

顺便一说, P系列魔法的名字一直念起来很怪, 什么玛哈, 米吉多, 其实是有所考究的, 可参考这篇文章: 闲聊女神转生及Persona系列技能命名方式

人格面具的合成是我到后期才发掘的乐趣, 本身还是达成某一种套路的成就感, 这种感觉类似于培养一支宝可梦对战的队伍. 人格面具也有特性与技能的搭配, 特性只能通过合成遗传, 技能可以通过遗传, 技能卡或者人格面具绞刑进行组合搭配, 5维可以通过人格面具的升级或监禁焚香培养. 各个人格面具的合成本身遵循特定的规律, 因此最后要合成并培养一个人格面具, 需要对整个流程进行计算和设计, 细节就不多说了, 我甚至在网上看到有用Dijkstra算法优化合成路径的文章. 我自己也花了点时间合成了几个比较知名的p(网上一般把人格面具简称为p, xxp即是某些做好技能抗性搭配, 专门用于某种用途的面具), 比如物攻p易经, 即死p爱丽丝, 开场p湿婆, 魔法p兰达等. 不得不说P5R中的公开处刑机制(联机使用网络上的人格面具进行合成)大大降低了玩家自己合成一个理想面具的难度, 主要是很多吸收的抗性都可以很方便地获得. 一旦合成了这些最终人格面具, 战斗就变成了另一个画风, 不再需要小心翼翼地试探敌人弱点, 因为大多数时候都是一回合结束战斗, 不过用自己辛苦合成出来的面具战斗本身就是非常愉悦的.

最后再说说对P系列对日常生活模拟的观察(不一定是这么回事), 看似琐碎枯燥的日常生活也是P系列最具特色的玩法之一. 现代很多游戏的简化设计利用了玩家的生活经验和想象力, 这在P系列中也已经随处可见. 比较明显的几个例子, 比如P5中对看DVD与玩游戏的模拟, 镜头是对着joker看不到电视画面的, 只能听到散乱的剧情对话配音或者8bit游戏音乐. 再比游戏中角色说话不是全语音的, 而是只在适当的时间点, 比如表达惊讶, 说话转折时才有几个语气和单词的配音, 我记得早时候如果游戏不用配音还想说话有声音就一般用机械音代替, 像是逆转裁判这一类. 其他游戏如塞尔达旷野之息也是同样处理, 只有音调的配音. 另外比如动森里很多生活中有的道具都可简单的交互, 雷电做客天地无用播客聊动森时提到了他最爱的咖啡机, 互动就只有咕咚一下, 但就是能让人想象出使用咖啡机的场景. 我个人是能接受也挺喜欢这种简化的表现的, 制作也确实省下了成本.

关于玩家看不到的场景设计细节, 看到一个好玩的视频: P5视角外的世界

是时候聊聊P5的故事和表达了

依然是剧透预警, 但这里不会聊太细节的剧情.

.

.

.

.

.

.

.

.

.
.

.

.

.

.

.

.

.

.

P5充满欢乐的日常故事和P4一样, 已经处理得足够好不必多谈, 只简单说说P5R主线故事的表达(P5R与P5剧情上存在差异, 这也是争议点之一). P5R的故事作为一个重故事的jrpg来讲已经很不错了, 相信是不会让大部分jrpg玩家失望的. 设定上虽然有不严谨的地方但总体上能自圆其说(或者说那些细节对于表达无伤大雅), 故事也是有曲折有高潮以及多次的反转, 也不像某作留下了一堆坑没填就匆匆结束. 当然我觉得最重要的还是把故事想要表达的东西清楚表达出来了, 并且这个东西能得到大家的认可.

P5R的故事感受下来, 算上皇家版追加的第三学期, 我觉得是要表达或者说探讨三个问题. 击败狮童与第三学期开始可以看作两个分界点.

第一段的故事主要就是心之怪盗团的成长, 不停地寻找悔改目标(其实都是目标自己撞上来的), 结识新伙伴, 提升怪盗团的社会影响力. 在怪盗团的努力下, 社会中的恶人一次次悔改并当众忏悔自己的罪行. 然而就在这个当下, 怪盗频道上抛出了一个问题: 你认为怪盗团是正义的吗? 嗯, 这恐怕不是一个可以简单回答的问题, 可以从很多的角度看这个问题, 比如是不是应该把强制执行的悔改看作一种手段不明的私刑. 或者从上帝视角, 那些恶人也是因为威胁到了怪盗团, 怪盗团才不得不对他们进行悔改. 又或者可以不用想那么多, 这些恶人的悔改自然促进了社会的正义, 而不用在乎使用的是什么手段, 有没有得到社会大众的认可. 这些角度的讨论在故事进行中是相互角逐的, 也体现在怪频上怪盗团的支持率来回摆动. 不由得想起死亡笔记中夜神月的理想与其所作所为, 不过在那个作品里, 月的正义和对其的探讨其实已经无关紧要, 月和L的斗智才更被人们所关心. 回到P5R, 击败了最后一个恶人狮童, 故事突然画风一转, 伪神圣杯出现, 怪盗团的任务突然变成了拯救世界拯救人类. 后半段故事的转向用到了前半段的几条暗线, 回过来看, 也不能说处理得太突兀, 只是前面提到的第一个问题因为这样的转向而忽略了. 这里当然不能说因为最后怪盗团拯救了人类所以取得了正义性, 这和前面的故事是两码事不是吗. 对于第一个问题, 虽然P5R没有给出正面的回答, 但我隐约觉得是想表达对于怪盗团来说, 被认为正义不正义不重要, 怪盗团自己行动的初心才更重要.

第二段与第三段的表达比较直白. 比如第二段我觉得表达的就是经常被提起的相信人类的可能性这一点, 这就非常适合用一个人类危机的环境来表达. 虽然略显中二, 但还是很感动, 现在脑海里还能回忆起打败伪神后的播片, Mona发着光离开时感慨: 世上并不存在”真实的世界”, 世界是由每个人的感受所形成的, 这便是世界的真相, 所以世界是无限的, 就算眼前一片漆黑, 只要握着别人的手, 用羁绊连结在一起的话, 世界就不会终结, 世界就在你们的心里. 回到家后, Mona? 你怎么诈尸了, 把我感动的眼泪还给我!

第三段我也挺喜欢, 是P5R中新加的故事. 丸喜可以说是P5R里非常不同的Boss了, 他继承了之前被怪盗团打败的伪神的力量(窃取了革命的果实), 获得了能够改写现实的能力. 虽然这个能力很强大, 但经历了失去至爱之痛的丸喜决心用这个能力让人类远离痛苦. 嗯, 确实到这里有不少设定上的瑕疵, 也把人类的痛苦说得过于轻巧了, 但要抛给玩家的问题我想已经表达出来了: 我们是否应该或者说有资格剥夺他人的痛苦. 这个问题有意思的地方在于不是剥夺快乐和美好, 而是负面情绪和苦痛. 丸喜给出的选择就是作为神一样的存在, 为自己看到的每一个人改写原本现实的不幸之处, 为此丸喜也甘愿承受无法被人理解的孤独. 丸喜无疑和本作中其他Boss一样有自己的欲望, 但是其欲望本身的内容却是剥夺他人痛苦. 在游戏中丸喜不断给joker时间, 让他好好感受身边伙伴是否因为新创造的现实而过得更快乐. joker可以选择在期限之日与丸喜战斗, 否定他的所作所为, 或者也可以选择接受. 这里选择抗争也是有理由的, 我觉得关键倒不是说丸喜创造的现实就是虚伪的, 而是人类的苦痛同样可以提取出人类完善自己的碎片, 放弃即意味着设限. 约定之日, 丸喜带着忧伤且失落的神情说道: 还以为是你的话能够理解我的理想…作为一款游戏遗憾之处也在于最终只能用战斗的方式来击碎丸喜傲慢的理想. 最后的最后, 在高楼上, 失去人格面具的两人因信念的不同肉身扭打在一起…

后来一想这意涵引的不就是《美丽新世界》嘛.

“但我不要舒适。我要的是神，是诗，是真实的危险，是自由，是善良，是罪孽。”

P5R中明智这个角色的塑造一直很有争议. 我觉得是前半段塑造得太好了, 确实有名侦探的样子, 与joker也建立了很深的羁绊(相爱相杀), 不是说不能接受后面明智因为立场出卖怪盗团或者有自己的野心, 而是在表现上把他往变态愉快犯的方向塑造(这类日系人设最近还挺流行的).

最后

P系列是一个以现代生活为背景的jrpg, 以我有限的jrpg经验来说感受是非常特别的. P4G是现代的乡下生活, P5R则是现代的都市生活. 并且P系列尝试去关注和描绘现代生活中人们的精神状态, 我觉得挺好的.

本来只是想把玩P5R时所有想法和感想都写下来, 没想到篇幅已经这么长了, 还是有一些没有记下来, 比如关于丸喜我不知道怎么想到了漫画犬屋敷(鬼知道当时我是怎么联想的), 总之先到这里结束吧(摊手)…

.

.

.

.

.

.

.

.

.

終わり

本来感觉这个点灯游戏也没什么, 感觉还是有博弈的游戏像是点格棋更有意思一些, 直到我看到了知乎专栏的这篇文章点灯游戏: 简单的游戏能否很美?, 说实话确实很美, 甚至感到有些震撼. 于是我打算稍微探索一下这个游戏, 所幸文章作者写得非常认真, 相关的结论和参考都有总结, 遗憾的是没有提到结论的证明. 虽然是已经被前人研究得比较透彻的问题, 但我还是想写点自己的理解, 于是就诞生了这篇不务正业的文章…

搜索算法解

要用搜索算法来解点灯问题就比较简单粗暴, 遍历所有点灯方案找出满足要求的方案即可(在leetcode中还需要得到操作最少的方案). 在解决问题之前首先必须对问题有足够的理解, 我们必须先说明下面虽明显但重要的两点, 即:

• 操作的顺序无关性. 对于将所有灯从初始状态状态转换成全亮的点灯方案, 其一系列操作的顺序可以是任意的, 这很好理解, 因为对于点灯游戏, 灯的最终状态只取决于两点, 即初始状态与状态翻转的次数, 而与翻转的先后次序无关.
• 操作的非重复性. 这即是说如果我们需要找到一个操作最少的方案, 那么每盏灯被选择改变状态的次数是最多一次. 结合前面操作的顺序无关性很容易说明. 假设有这么一组操作方案是点灯游戏的一个解, 而这组操作中包含了多次选择同一盏灯进行翻转的操作, 我们可以利用顺序无关把这些操作集中到一起, 也就是连续对同样的灯进行翻转. 由于灯只有两种状态, 偶数次的相同操作相当于没操作, 奇数次的相同操作相当于操作了一次, 因此该方案都不可能是操作最少的方案.

了解了上面两点我们才可以尝试着去解决问题, 其实这里我还尝试着考虑了下操作的唯一性, 但是无果. 有了更多的了解之后才意识到解确实不是唯一的.

算法的大致构思即测试所有点灯方案, 如满足要求记录下该方案. 剩下来的就是一些技术问题, 我们怎么存储点灯方案, 灯的当前状态又如何表示? 这里用二进制数来进行表示是一个比较好的想法, 其一是比较节省存储空间, 其二是状态的翻转可以用对相应位的异或来实现. 但是二进制矩阵不太容易实现, 对于小型规模的点灯游戏, 用c++内置类型即可, 如4字节int型可以用于存储32盏灯的状态, 这里涉及到的一个问题是两者从矩阵到数列坐标的转换. 对于测试的每一种点灯方案, 也可以用一个int来存储, 1的那些位表示直接选择翻转的灯. 当然别忘了选择翻转的灯的上下左右(如果存在的话)也需要进行翻转. 操作的次数只需要计算存储电灯方案int中二进制下1的个数即可. 下面是code.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

class Solution {
public:
    int minFlips(vector<vector<int>>& mat) {
        int m = mat.size(); // 灯矩阵行数
        int n = mat[0].size(); // 灯矩阵列数
        int stat = 0; // 存储初始灯的状态
        int plan = 0; // 当前应用的电灯方案
        int ans = -1; // 存储最少的操作次数 若不可解则返回-1

        for (int i = 0; i < m * n; i++) // 初始状态生成
        {
            stat = stat << 1;
            stat += mat[i / n][i % n];
        }

        while (plan < pow(2, m * n)) // 遍历所有点灯方案 共 2^(mn) 种
        {
            int cnt = 0; // 存储当前点灯方案操作次数
            int num = plan;
            while (num)
            {
                ++cnt;
                num &= (num - 1);
            }
// 如果该方案操作次数超过了之前解的操作次数 直接跳过该方案
            if (ans != -1 && ans <= cnt)
            {
                plan += 1;
                continue;
            }
            
            int temp = stat ^ plan; // 将temp初始化为 初始状态下翻转该方案选择操作的那些灯 后的结果
            for (int i = 0; i < m * n; i++) // 遍历plan
            {
                if (plan & (1 << m * n - i - 1)) // 翻转选择操作的那些灯上下左右的灯
                {
                    if (i / n - 1 >= 0)
                        temp ^= (1 << (m * n - (n*(i / n - 1) + i % n) - 1));
                    if (i / n + 1 < m)
                        temp ^= (1 << (m * n - (n*(i / n + 1) + i % n) - 1));
                    if (i % n - 1 >= 0)
                        temp ^= (1 << (m * n - (n*(i / n) + i % n - 1) - 1));
                    if (i % n + 1 < n)
                        temp ^= (1 << (m * n - (n*(i / n) + i % n + 1) - 1));
                }
            }
            if (temp == 0) // 当temp为0时 即灯全亮 是一个解
                ans = cnt;
            plan += 1; // 处理下一个点灯方案
        }
        return ans;
    }
};

上面的实现思路是比较简单的, 具体实现中其实也并没有遍历所有点灯方案的必要(在只要求找到最少操作方案的条件下), 因此当我们遍历到一个点灯方案操作灯的数量多于已经找到的解时, 将直接跳过这个方案的处理(无论这个方案是否为解). 上述搜索算法时间复杂度显见是$O(2^{mn}*mn)$的. 这意味着当灯的数量较少时才可能在比较短的时间内找到解, 以我现在手头上的i5surface laptop来说, 找到4*4规模初始状态为灯全灭的点灯游戏的最优解(操作最少的解)需0.007s, 5*5需要11.829s, 而6*6则已经在30分钟以上了.

线性代数解

讨论完了暴力的搜索算法, 那么从数学的角度如何求解点灯问题呢? 根据每盏灯最终状态可由总翻转次数与初始状态确定这一点, 可以列线性方程来求解. 以下内容可参考Mathematica博客的这篇文章Lights Out Puzzle.

以3*3规模的点灯游戏为例, 我们首先需要得到一个9*9的二元对称矩阵$\boldsymbol{A}$,

矩阵$\boldsymbol{A}$中只有元素0和1, 且是对称矩阵, 对于同样规模和规则的点灯游戏, 矩阵$\boldsymbol{A}$都是相同的. $\boldsymbol{A}$的每一行是这么来的, 依然把3*3的9盏灯按行展开排成一行, $\boldsymbol{A}$的第i行由将第i盏灯和其上下左右灯(如果存在的话)的位置置1其余置0得到. 如$\boldsymbol{A}$的第一行, 先把第一个位置自己置1, 然后在点灯游戏中第一盏灯在最左上角, 把其下与其右的灯的位置(2与4)也置1, 其余位置为0. 也可以说成$\boldsymbol{A}$的第i行相当于把所有影响第i盏灯状态的位置都置1, 其余置0.

一旦构成了$\boldsymbol{A}$, 那么顺理成章, 我们将点灯方案排成一列, 为9*1的列向量, 规定选择翻转的位置为1其余为0, 用$\boldsymbol{x}$表示. 同理我们可以假设$\boldsymbol{r}$为所有灯最终状态, 而$\boldsymbol{c}$表示所有灯初始状态, 那么上述向量之间的关系为,

注意上式我们只在GF(2)内进行讨论(关于伽罗华域顺便安利一下介绍纠错码的这篇文章), 因为灯的状态只有0和1这两种. 将上式改成,

剩下来的问题就是解上面的非齐次线性方程组了. 可以用我们熟悉的高斯消元法(Gaussian elimination)来解, 就是用初等变换将增广矩阵化为行阶梯型来求解, 解不唯一时需要先求对应齐次方程组通解与其本身一个特解, 然后组合通解与特解得到所有方程组的解. 由于方程组是定义在GF(2)上的, 解的每一位从0与1中取值, 因此化为阶梯型后对于有$d$个自由变量的方程组共有有$2^d$个解. 所以这个解的数目确实不是唯一的, 下图是2*3规模点灯游戏初始状态为全灭的4个解(黑色表示选择翻转的灯, 下同). 从图中可以看出解具有对称性.

求解代码放在这里, 为了能够存储任意位数的二元矩阵使用了bitset类型, 其支持一些方便的位操作. 高斯消元法的时间复杂度为$O((mn)^3)$, 接着遍历找多解复杂度$O(2^d)$, 同样初始全灭的条件下, 解100*100规模点灯游戏找到所有的解需要15s, 相比搜索算法已经快了不少. 至于更快的方法主要是优化GF(2)下的方程组求解, 使用并行计算或改进高斯消元法. 下图为100*100的唯一解,

随便再放些不同规模解的图案吧, 可以发现有相当多的解是对称的, 特别是5倍数规模的解, 非常具有对称美. 以下为部分5倍数规模且解唯一的解图.

对于一些多解的情况也有不少是对称的, 下面是4*4, 5*5, 9*9, 16*16的多解图.

部分规模的解实在是太多了, 如30*30规模有$2^{20}$个解. 另外一个比较有意思的是对于有多解的情况, 存在着一种或多种最终不改变所有灯状态的点灯方案, 可由对应齐次方程组的解得到. 如下图是5*5不变的方案.

番外 解存在性讨论

事实上对于任意的m和n, 只要是满足自反(reflexive)与对称(symmetric)的点灯游戏, 初始状态为灯全灭的情况下, 可以证明游戏必定有解. 当然, 如果初始状态时已经有部分灯点亮则不一定有解. 证明之前先解释一下点灯游戏满足的自反与对称是什么.

自反即是说当选择一盏灯时, 除了翻转与这盏灯相邻灯的状态, 这盏灯本身也会状态翻转. 而对称是说相邻的两盏灯的状态相互影响, 当其中一盏翻转时, 另一盏灯的状态也会翻转. 其实点灯游戏有非常多的变种(就和魔方一样), 有些并不完全满足上面的两点, 比如Merlin Magic square游戏.

说明完毕, 推理证明如下.

使用反证, 假设存在着满足上述要求(自反, 对称, 初始状态为灯全灭)的点灯游戏无解, 且我们认为无解的情况中规模最小的有n盏灯, 此时n-1盏灯的点灯游戏则是可解的(如果不可解, 那么无解情况中规模最小的就应该是n-1盏灯了). 需要注意的是, 这里我们其实无视了灯的空间排列, 前面的讨论中, 点灯游戏普遍把所有灯排列成一个正方形或矩形, 这样只是为了让人容易看清(共享边的两盏灯是相互影响的), 但就本质上说, 我们完全可以用有向图(Directed Graphs)的结构来描述这个点灯游戏, 每盏灯是图中的一个结点, 由于游戏是对称的, 相互影响的灯的关系可以用双向的连线来表示, 因此这里不需要纠结n或者n-1盏灯能不能排列成矩形的空间结构的问题, 或者说能构成矩形空间结构的有向图在我们现在讨论的图的基础上需要更苛刻的条件.

如前所述, 那么我们必然有把这n盏灯中n-1盏灯点亮而只剩1盏灯灭掉的点灯方案(点灯方案指的就是n盏灯中选择哪几盏灯进行状态翻转), 这里的根据就是n-1盏灯的点灯游戏是可解的. 从n盏灯中选出n-1盏灯构成一个更小规模且可解的点灯游戏, 如果当这个小规模的点灯问题解决后(这n-1盏灯全点亮), 剩下来的那盏灯的状态是点亮的, 那么这个n盏灯的点灯游戏就也是可解的了, 这与假设矛盾, 因此孤立出来的那盏灯的状态必定是灭掉的. 对于总共n盏灯, 这n-1盏灯的选择显然有n种, 且这n种选择都能够完成上面所说的n-1盏灯亮1盏灯灭, 如此便得到了相应的n种点灯方案.

将上面得到的n种点灯方案从灯全灭的初始状态开始连续施行一次, 我们发现当n为偶数时, 所有灯的状态正好翻转奇数(n-1)次, 如此一来最终n盏灯的状态就都是点亮的了! 因而n盏灯的点灯游戏就可解, 与假设再次矛盾, 推出结论n只可能是奇数(当n为奇数时, 我们执行完上述n种点灯方案后, 所有灯翻转偶数次, 即状态不变, 全为灭).

我们继续讨论这n盏灯中是否存在着与偶数(包含0)盏其他灯相关联的灯(从有向图的观点来说, 就是这n个结点中是否存在着与偶数个其他结点双向连接的结点), 也就是这盏灯的状态翻转将影响其他奇数盏灯的状态翻转. 我们先假设存在这样满足条件的灯, 取其中的一盏来讨论, 把这盏灯和其关联的另外奇数盏灯单独划分为一组, 组内就有奇数盏灯. 我们从前面得到的n种点灯方案中挑选出以组内灯为最后灭掉的灯的那些方案, 将挑选出的这奇数个点灯方案同样从灯全灭的初始状态开始连续施行一次, 此时n盏灯中非组内灯的状态都改变了奇数次, 故都为点亮状态, 而组内灯状态则都改变了偶数次, 状态不变. 最后我们选择改变前面提到的满足条件的那盏灯, 如此组内灯的状态将再都改变一次, 即也都将被点亮. 此时我们发现所有灯都被点亮, 此n盏灯的点灯游戏可解, 再次与假设矛盾, 由此得到结论这n盏灯的每一盏灯都与其他奇数盏灯相关联, 而不可能是偶数盏.

推到这里, 其实我们已经找到了矛盾, 只是不是特别明显, 即点灯游戏的对称性与我们前面推出的有奇数盏灯且每盏灯都与其他奇数盏灯相关联之间存在矛盾. 点灯游戏的对称性也可以推出一个结论, 那就是当执行所有灯都选择点亮一次的点灯方案时, 不计算那些直接选择的灯的那次翻转, 只计算那些因其他灯选择翻转由于受关联而间接翻转的次数, 在这个意义下所有灯的累计翻转次数总是偶数次的. 道理也是显而易见的, 这里所谓游戏的对称性就是两盏相关联的灯是相互影响的, 选择一盏灯直接地状态翻转会间接地翻转相关联的另一盏灯, 而对那另一盏灯来说也同理. 当上述点灯方案都选择一次翻转后, 就这两盏相互关联的灯来说实际翻转了4次, 前面说这里我们不计算因直接选择的翻转, 所以计间接翻转的2次. 可见每一组相关联的灯都会计间接翻转的两次, 故最终所有灯累计的间接翻转次数必为2的倍数即偶数. 严谨起见, 我想还需要补充两点说明. 其一是这里计算的是因间接影响的翻转次数, 这仅仅是为了推理讨论的便利性(虽然其本身的理解增加了复杂性?). 其二是严格来说, 对于实际的一个点灯问题自然是不会出现孤立的灯的情况(这盏灯不与其他任何灯相关联), 但当存在孤立的灯时, 上述由对称性得到的结论仍然是正确的, 因为当选择点亮孤立的灯时, 由于没有与其相关联的灯, 所以计入的翻转次数为0.

但是如果点灯游戏中有奇数盏灯, 依然执行所有灯都选择翻转状态一遍的点灯方案, 为了能获得总共偶数次的间接翻转, 必然不可能每盏灯相关联的灯的数目都是奇数的, 或者说必定存在着与其他偶数盏灯(包括关联0盏的孤立的灯)相关联的灯, 这样我们就推得了最后一个矛盾, 从而否定了最开始无解的n盏灯的点灯游戏的存在性假设, 命题得证.

文字描述的证明有些地方确实啰嗦了点, 但我想还是尽可能留下更多的细节便于理解. 用线性代数的视角我们可以得到更简洁又严密的证明. 这里最后再说明一点, 在我参考的The Mathematics of Lights Out博客中, 作者对于最后一个矛盾的阐述举了一个更生动的例子, 但需要注意其与点灯游戏之间的差异. 这个例子是说有奇数个人参加聚会, 在聚会上自然少不了有些人会相互握手, 但是无论有多少人握手, 总存在和偶数个其他人握手的人(包括一次都没有和其他人握手的人). 这个例子确实容易理解很多, 而这个例子与点灯游戏的差异在于握手是关联的双方同时进行的, 且每一次握手操作都只涉及握手的双方. 而对于点灯游戏, 每一次的操作是选择一盏灯进行状态翻转, 故灯之间的相互影响(间接翻转)是分开进行的, 且一次操作同时影响多盏其他的灯, 但我们依然可以理解这背后其实是一回事, 也就是对称性的体现. 另一个差异则是点灯游戏具有自反性, 握手则自然不可能自己与自己握手, 因此在上面讨论中我们忽略了直接选择时的状态翻转.

同样引入线性代数能很大程度简化证明, 我们知道当非齐次线性方程组无解时有$\mathrm{rank}(\boldsymbol{A})<\mathrm{rank}(\boldsymbol{A|\boldsymbol{c}’})\leqslant mn$. 那么必然存在着非$\boldsymbol{0}$列向量$\boldsymbol{v}$有,

并且,

这里稍微解释下, 若上式不成立则,

这样方程组便有解了.

由于点灯游戏的自反与对称性, $\boldsymbol{A}$是定义在GF(2)上的对称矩阵, 且对角线元素都为1, 因此有,

这是因为左边展开后混合项都是成对出现, 故其系数皆为0, 只留下二次项. 结合最前面的式子便可得到,

于是,

这与$\boldsymbol{v}$为非零向量矛盾, 假设不成立, 因此解必定存在.

其实在线性代数中有一个更强的定理, 对于定义在GF(2)上的对称矩阵$\boldsymbol{A}$, 存在$\boldsymbol{x}$满足$\boldsymbol{Ax}=\mathrm{Diag}(\boldsymbol{A})$, 翻译过来就是二元对称矩阵$\boldsymbol{A}$对角线元素构成的列向量必定在$\boldsymbol{A}$的列空间中, 详细证明见这里. 如果知道这个定理对点灯游戏解的存在性甚至都不需要进一步说明, 因为在点灯游戏的设定下, 对称保证了$\boldsymbol{A}$是对称矩阵, 自反保证了$\boldsymbol{A}$对角线元素全为1, 而初始状态的$\boldsymbol{c}’$也总是全为1…

最后的最后, 这点灯游戏竟然让我找回了小时候摆弄万花筒的感觉, 这大概也算是数学的魅力之一吧…

参考

• Lights Out (game) wiki
• The Mathematics of Lights Out
• Lights Out Puzzle
• 5x5 Lights Out
• Using your Head is Permitted March 2011 riddle
• Lights Out
• Range of Symmetric Matrices over GF(2)
• Turning Lights Out with Linear Algebra
• Erasure-Code-擦除码

.

.

.

.

.

.

終わり

CodeCraft是华为2015年起开始举办的编程挑战赛, 强调享受用coding解决问题的乐趣. 其实那段时间(两个月前)有好几个华为组织的比赛什么销售, 云计算等等. 我因为之前都没参加过, 加之感觉coding会好玩一些所以报名了CodeCraft. 虽然最后完成了程序但没及时上传（；´д｀）ゞ, 嗯, 从结果来说好像连炮灰也没当成?

题目在这里, 简单来说就是车辆调度的问题, 官方给出car.txt, road.txt和cross.txt三个文件即车, 路和路口信息, 根据简化后的交通规则, 你的程序需要输出每辆车的上路时间以及行驶路线. 拿到题目首先就必须研究下这个设定的交通规则, 其中涉及到不少细节问题, 大体规则可以参考官方文档, 以下是一些当时有疑问的细节和官方解答.

规则细节

关于车辆在路上行驶的规则

车辆如果行驶过程中, 发现前方有车辆阻挡, 且阻挡的车辆为终止车辆, 则该辆车也被标记为终止车辆. （与前方阻挡的车辆的距离记为s）则该车辆最大行驶速度为v = min(最高车速, 道路限速, s/t) 其中t=1, 该车辆最大可行驶距离为s.

这里官方文档第二句话少了”否”字, 应为

否则该车辆最大行驶速度为v = min(最高车速, 道路限速, s/t) 其中t=1, 该车辆最大可行驶距离为s.

也就是说当有前车开得比较慢时, 该车也要降低速度. 而第一句是说如果前车停了, 则该车立即停止. 因此, 每辆车的速度每次轮到时都要根据前车情况重新计算. 另外如果前车是等待调度状态, 那么该车也是等待状态.

下面是官方给出的例子:

假定道路有如下车辆, 车AB车速为3, CD均为车速为1
A空空B空空CD （路口）

按步骤一后ABCD均为等待状态.

在处理待状态车辆D后, 假定D前进到其他道路后, 此刻道路状态变化为

A空空B空空C空 （路口）

接下来因D车辆的前进后, 需要对该条道路该车道的所有车辆进行一次调度

因此:

C的车速为1, 则C车前进1个距离, 且为终止状态. A空空B空空空C （路口）

B的车速为3, 则B车前进3个距离, 且为终止状态. A空空空空空BC （路口）

A的车速为3, 则A车前进3个距离, 且为终止状态. 空空空A空空BC （路口）

调度后道路车辆分布为: 空空空A空空BC （路口）, 且ABC均为终止状态

关于车辆在路口调度的规则

例子如下图:

在本路口调度道路的顺序为

5000、5001、5010、5018、5000、5001、5010、5018、5000、5001、5010、5018…5000、5001、5010、5018

整个系统调度按路口ID升序进行调度各个路口, 路口内各道路按道路ID升序进行调度.

也就是说, 路口调度顺序与各道路的调度顺序是固定的.

首先调度5000道路, 只有D100可以走, 因为D101左转与5010道路的D200冲突, 所以必须等待5010车道上没有直行冲突.

这里的D101官方又写错了, 应该是L101, 该车是当前5000道路优先级最高的车, 但与5010最高优先级直行的车D200冲突(都要到5018道路), 直行的优先级更高, 故对5000道路的调度先搁下了(当道路最高优先级的车停下, 其他车也不能动).