Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors
post
Filter by Categories
about
FREAK
Official
OST BOOKLET
Scanner
专栏
剧场版
动画
卡牌
宣传物料
工具
废案
旁支
未分类
杂志扫描
正统系列
漫画
秽土转生
美术设定
翻译
老物
解包
设定集
设计者
转载
随想
随笔

【长文】近世代宝可梦模型制作考察

全文大约26000字左右,阅读时长大概率会超过40min,所以完全足够听完K大这组曲子,中间会穿插一些其他应景的BGM。

关于引言

Part 1『阿尔宙斯&朱·紫』 两款宝可梦作品并行开发的情况下的宝可梦模型制作环境——基础概念&模型规格

这篇文章最初构思的时候只是想总结翻译一下Game Freak的CG技术研发组组长——前泽圭一在CEDEC上的演讲内容。

Fig.1 PPT首页

但在筹备资料的时候顺带想起了自己早年翻译的一篇介绍宝可梦模型的文章(当时整个宝可梦社群都在争论剑盾中的模型复用&砍图鉴问题,我在Reddit上看到了有位大佬写了长文分析就着手翻译转载了,多亏了一众大佬的转发相助),加上这两年也搜集到了不少宝可梦制作相关的访谈,其中就包含了CG WORLD日月和剑盾两期的开发组采访。除此之外,2020年以来也逐渐开始用解包去展开一些开发相关的探索。由此,过往的翻译&采访,近期的朱紫建模演讲以及一些解包经验,三者构成了这篇宝可梦模型制作考察的撰写基础,也算是我个人的一个分支研究的阶段性总结。另外,由于学业原因(和拖延症),发布时间从10月初一路延到了朱紫发售前夕,也顺带有了庆祝朱紫发售的意味,读者也能从中一窥Game Freak这三年中为了今年发布的这两款作品所付出的工作。

Fig.2
Fig.3
Fig.4

本文的主线任务:翻译解说Game Freak研发部CG实验室总监——前泽圭一的演讲的三个章节。

支线挑战:插入一些我个人对于Game Freak开发状况的理解,前代技术层面的开发信息,部分内容和游戏表现的体现。

一些基础的解释

Fig.5 游戏狂想家是一家开发『宝可梦』系列作的公司

Game Freak(游戏狂想家):

简称GF狂想家。『宝可梦』系列正统作品的主力开发公司,17-22年来开发的作品

千兆破坏者》(Giga Wrecker),《精灵宝可梦 究极之日·月》,《宝可梦 探险寻宝》(宝可梦 大探险的前身),《精灵宝可梦 Let‘s Go! 皮卡丘·伊布》,《小镇英雄》,《宝可梦 剑·盾》,《宝可梦 剑·盾 扩展票》(第一弹:铠之孤岛,第二弹:),《宝可梦传说 阿尔宙斯》,《宝可梦 朱·紫

Creatures(酷丽恰姿):

简称C社。『宝可梦』系列正统作品的协力开发公司,主要负责针对宝可梦的建模开发工作,近16-20年间参与开发的作品(列举了C社官网上收录的内容)

名侦探皮卡丘~新组合诞生~》,《宝可梦战棋大师》(3D模型),《宝可梦加傲乐》(3D模型),《宝可梦 GO》(3D模型),《宝可梦 铁拳DX》(3D模型),《名侦探皮卡丘》(完整版),《精灵宝可梦 Let‘s Go! 皮卡丘·伊布》(3D模型),《宝可梦 剑·盾》(3D模型),《宝可梦 目标之星》(3D模型)

本文的主线是围绕着CEDEC2022上一篇名为“【アルセウス+スカーレット・バイオレット】ポケモン2つを同時に作る、ポケモンモデル制作環境”(『阿尔宙斯&朱·紫』两款宝可梦作品并行开发的情况下的宝可梦模型制作环境)的演讲的翻译转述构成的,期间会穿插一些我从CG World杂志上了解到的宝可梦模型开发信息以及一些解包时观察到的内容进行补充。并且由于是偏技术向的内容整理,不免会有些枯燥。确实有考虑到这种技术内容更适合视频化,毕竟原本的演讲也得是视频媒介,仅仅整理成文字的传播效果或许还不如直接在原视频上加字幕,但既然写成了文章,我也会竭尽全力发挥文字媒介的优势。若发布后效果不错就尝试对这些内容更好的视频呈现。

*CEDEC全称为Computer Entertainment Supplier’s Association Developers Conference,翻译过来是“计算机娱乐供应商协会开发者大会”

第一章——交付品&开发规格的共通化

Fig.6 宝可梦系列模型制作体制大体上可以分为GF社内的作品开发组,技术研发组以及外包交付品检验组,社外有如Creatures这样的协力开发公司。

3D化后的宝可梦系列模型制作体制大体上可以分为GF社内的作品开发组,技术研发组以及外包交付品检验组,社外有如Creatures这样的协力开发公司。

(一般来说,直接在Staff表里搜Creatures是没有结果的,因为可能合作时间太长了都亲如一家人就不写了,所以近年来也引起过一些终止合作传言的风波。这一点之后再详写。)

其他的协力公司比如阿尔宙斯

POKÉMON MODELING PARTNERS

Fellowship Co., Ltd.
Mox Co., Ltd.
RAYLINE STUDIO INC.
SHIFT Inc.
Silicon Studio Corporation

朱·紫

POKÉMON 3D VISUAL & VFX PARTNERS

CREEK & RIVER Co., Ltd.
C&R Creative Studios
Brushup Co., Ltd.
Soft Gear Co., Ltd.
KOJIRO VFX DESIGN

其中的一些箭头也展示了各个开发组相互之间的合作关系,总的来说就是研发组确定每一世代的引擎的开发框架,开发引擎的基本功能,一部分开发资源的开发任务会分发给外包公司,由检验组核查验收,最后交付给制作组进行全权开发。这些开发资源不限于模型,贴图,地形,也包含代码,企划,AI系统,剧情脚本协力,当然也有最常见的Debug和本地化协力。细数起来有些复杂,但上面这张PPT能很精辟地展示出这些关系。

Fig.7
Fig.8

到『剑·盾』为止的开发环境都是由研发部为每部作品单独给出一个开发环境和仕样内容,制作组根据当前的开发环境和每部作品对应的企划内容开展对应的素材&资源制作。但与此同时所面临的问题在于,宝可梦的模型总数达到了千种以上,每一作都或多或少在进行贴图/动作/模型的翻新和重做。

以剑盾为例,一般来说一部正统作会收录450左右的初始图鉴位,而对应的模型包含公母,形态差异来计数的话,可能会达到500-600的数量级,比如再朱紫中占据小图标的模型就达到了675位(当然也有一些像是彩粉碟这样占了20种的),总体来说突破600还是绰绰有余的。而像LA这样的动作+RPG的模式,算上未知图腾和一些公母&形态差异也能达到350个模型位。不仅朱紫首发的675模型位在一众RPG的怪物数量中一骑绝尘,LA只计图鉴位242的可动模型也在非回合制RPG中也数一数二的,临近其发售的“竞品”——改成实时战斗要素的妖怪手表4++的最终图鉴数量大概是180左右(看了一位贴吧老哥的统计),保留回合制的怪物猎人物语2最终图鉴是141只(考虑了其中的换色换皮怪)。

由此可以看到,在今年的年初年末发售两款画风不同,玩法不同,但图鉴数量和玩法更新程度依旧保持高位的作品所面临的开发挑战是很大的。于是制作组在18年秋季就开始谋求一个同时能在第九世代门槛上发售的两款作品并行开发的运作体制,本篇演讲所讨论的议题也就应运而生——『阿尔宙斯&朱·紫』两款宝可梦作品并行开发的情况下的宝可梦模型制作环境。

宝可梦传说 阿尔宙斯——标题界面曲

Fig.9 戳一下音乐播放

*关键信息:LA的开发计划启动于2018年秋季,目标:日式版画画风+动作要素,朱紫基本是在剑盾开发结束后(19年7-8月)启动开发计划,目标是写实画风+开放世界。不过这里的启动开发一般是指研发部和总监取材构思的开始,拿到开发环境和实际开始动手基本是在一年后的事情。

宝可梦 朱·紫 Title Theme

而如果规划得当的话,其实剑盾DLC开发结束的时间可能也正是朱紫引擎内开发的最初时间,一方面是把剑盾保留的想法和本体改进的呼声逐一实现,另一方面也是在试水一下朱紫想要做的内容和系统沿着什么路径走会更能被玩家所接受。比较明显的是雪原中的开放地图设计加上三条互不干涉的神兽线(蕾冠王的剧情,柱子们的解谜,三鸟的大地图玩法),这一思路在朱紫中得到了极大的增强。同时区域开放也是LA中所重点探索的,柱子的补全,神兽的地区形态化到了LA中也成了象征四季的四云补全,御三家的地区形态化。

Fig.10
Fig.11

回到演讲内容,上图中展示的便是LA和朱紫所采用的全新开发模式,在研发部给出相近的引擎开发环境加上资源开发规格要求,将其传递至本社或者协同开发的外包公司完成对应素材资源的制作,最终再交付给作品开发组进行全力开发。虽然仅仅是分离的开发节点往后延了一节,但实际上大幅加快了开发任务的推进,并且查看各个作品的实机表现并不容易察觉到背后大量的共通性。

Fig.12
Fig.13

背后的共通性之一源自于规定了一份共通的材质标准,比如每只宝可梦基本都有对应在这两份表中的材质,同时如金属外观昆虫的复眼等特化的材质也有对应的新图层。将材质的类型进行明确的归类整合也有助于在运行环境中进行批量处理。而单论眼球这一块材质,在剑盾时期大部分宝可梦的眼球都没有单独建模,对应的表情变化基本都是由贴图的变化来呈现的。而嘴部也是类似,只是剑盾中已经出现了一部分宝可梦的嘴部贴图转换成了建模,也没有如LA那样完全进行覆盖。

Fig.14 Weibo Link

随乐拍一开始的模型观感更佳的原因一部分就是在于其实装了同时带有眼球和嘴部建模的新一批宝可梦模型,不过对应工作量和成本出发的开发规模考量使得其收录宝可梦数量并不多,在一次大版本更新后达到了234只,少于更富交互和玩法深度的LA的242只。提到这些其背后的逻辑在于,宝可梦系列作为最知名的“宠物收集”类游戏,在迈入3D化后其背后的建模和动作制作压力一直都很大,即便是砍图鉴后,其模型数量和对应交互度依然是处于相比其他系列高一个档次的位置,而守住这一位置的要素就在于目前正在讲述的这套模型制作体制(以及日月时期的模型制作体制前身),一部分内容有做尝试但无法完全覆盖因此搁置而展示出的“技术落后”并不能概括这个开发组所完成的工作。当然也不否认这些观感不佳的低技术表现,但问题并不在于Game Freak团队中,甚至外包团队中找不出一个能做出同人作品中实现的一些宝可梦动作和效果,而是在于如何将一个改进在期限内高效推行到所有宝可梦上。因此对于社群所常驻关心模型问题,根本要义并不在于找到一个能做某个效果的人,而是如这份演讲主要传达的内容所展示的——建立一个能高效地将宝可梦建模的每一个改进推广到模型位中的每一只宝可梦的模型制作环境。

Fig.15 PPT中也提到了复眼,这已经在LA中充分体现出来了,也包括小磁怪金属部位的金属质感,鱼类宝可梦的鳞片质感,鸟类宝可梦层叠的羽毛质感
Fig.16 宝可梦模型的基本贴图

一般来说,每只宝可梦都会对应这几种贴图,

Base Color

是把颜色贴图剔除光影变化后,我们看到的最基础的颜色。在PBR工作流中颜色贴图叫做Base Color, 其中包含了电介质的反射颜色 和金属的反射率值这两种类型的数据。因为Base Color Map中带了金属的反射率值,所以需要配合上Metallic Map一起使用的。

Normal Map

(法线贴图)是凹凸映射技术的另一种应用。法线贴图包含角度信息而不包含任何高度信息,其R、G、B三个通道储存的信息表示了斜面的方向和陡峭程度。使用法线贴图和高度贴图可以确保光照和位移是一致的,能够带来更真实的效果。

Metallic

(金属贴图)起到类似于蒙版的作用,区分固有色贴图中的金属和绝缘体数据。在金属性贴图中,0(黑色-0 sRGB)表示绝缘体,而1(白-255 sRGB)表示金属。

Roughness

(粗糙度贴图)定义材质得粗糙度信息,0(黑色-0 sRGB)表示光滑,1(白-255 sRGB)表示粗糙。粗粗糙度是指造成光漫射的表面不规则状况,反射方向根据表面粗糙度自由变化。这改变了光的方向,但是光强度保持恒定不变。表面越粗糙,高光越散越暗。表面越光滑,高光反射集中,尽管反射的光的总量是一点的,表面也会更亮,光会更强。

Emissive Map

(自发光贴图)控制表面发射光的颜色和亮度。当场景中使用了自发光材质时,它看起来像一个可见光。物体将呈现发光效果。自发光材质通常用于某些部位应该从内部照亮的物体上,例如监视器屏幕、高速制动的汽车盘式制动器、控制面板上的发光按钮,或黑暗中仍然可见的怪物眼睛。简单的自发光材质可以通过一个颜色和亮度来定义。

Ambient Occlusion

(AO,环境光遮蔽贴图)描述了较大尺度的光线遮蔽信息,通常由高模烘培得到。指表面某点能获得多少环境中的光,用来模拟物体之间所产生的阴影,在不打光的时候增加体积感。

摘自https://zhuanlan.zhihu.com/p/260973533?utm_source=wechat_session

3DS的宝可梦模型

当然在游戏开发者眼中,这些都是比较基础的知识和用法,因为演讲并没有在此进行细化去描述他们是如何针对宝可梦去选用不同的贴图组合,只是用于说明他们在大规模进行模型开发和调整中所面对的几个基本贴图种类。而日月中的贴图技术程度也并不如玩家想象中低,或者说是平庸。这一点在CG WORLD 2017的第07期中多位负责宝可梦系列建模和美术的工作人员登台接受了采访,大量展示了日月开发中的贴图用法。

https://cgworld.jp/feature/201707-cgw227GG-pokemon.html

Fig.17 建模相关的Staffだち

• 从右往左 美术总监:海野隆雄、总监:大森 滋(以上两位为Game Freak的职员)、宝可梦角色美术总监:氏家淳子、宝可梦动作顾问:畠祐貴、角色建模美工:中廣健吾、宝可梦3D建模负责人:植松俊介氏(以上四位为Creatures员工)

这篇文章比较长,但好在一些关键信息都在我19年翻译的那篇模型复用问题考察中有提到,除了一些比较基本的贴图,比如albedo map(主要体现模型的纹理和颜色),specular map(高光贴图表示高光得范围、强度、颜色),normal map(法线贴图是凹凸映射技术的另一种应用,包含角度信息),emission map(自发光贴图控制表面发射光的颜色和亮度。),environmental map(伪造出金属感或其他焦散特效,例如露奈雅拉的翅膀)。

Game Freak在XY到日月中还使用了主打了一个称为“Monster Shader”的着色方式(Shader=着色器),以仿效杉森建独特的美术风格。

为了实现这种美术风格,原本的模型中需要添加更多的贴图种类:

Game Freak在XY到日月中还使用了主打了一个称为“Monster Shader”的着色方式(Shader=着色器),以仿效杉森建独特的美术风格。

为了实现这种美术风格,原本的模型中需要添加更多的贴图种类:

Fig.18 立绘
Fig.19 模型渲染效果
Fig.20 对象空间法线贴图:修改了会简化着色信息的法线贴图,从而实现更清晰的单元着色。 (具有平滑且不均匀性的法线贴图)
Fig.21 卡通渲染查找贴图:允许艺术设计者调整卡通渲染的参数。(调整光照条件能实现不同的阴影效果)

因此,对于3DS时期的宝可梦建模来说,其背后的工作量和复杂程度也是有目共睹的,这也造成过到了NS上的第一作《精灵宝可梦 Let’s Go! 皮卡丘/伊布》时,玩家会突然觉得这宝可梦渲染的感觉不对味,从侧面反应宝可梦系列的模型制作水准一直是在线的,甚至反过来说从XY起这一套模型的质量能被沿用多年也说明这套模型的质量本身是相当合格,只是在后续维护迈入高清世代中暴露出了一些问题(但被诟病的更多是模型动作层面)。换而言之,宝可梦系列的建模体制的起点并不低,过去以及现在制作组都在探索一个能够高效产出模型的制度,甚至能应对如今这样玩法截然不同,画风也有巨大差异的两部作品同年发售,而这样又回到了本演讲的标题,我们继续往下看。

Fig.22
Fig.23

这两张内容似乎想要表达的是在基色贴图上可以再叠加一层图层蒙版,比如,这里的三层蒙版与黑色,蓝色,绿色相混合,使得原本的白色基色变成了对应的颜色,同时再加一个红色的背景就能看到被混合后的效果,而这一部分内容应用的宝可梦上就能分区域调控一些配色方案,(我个人理解)使得闪光宝可梦的出现不需要单独做一份从前的闪光宝可梦的配色贴图,节省一些容量。(这个结论是我对比剑盾和LA的宝可梦贴图解包结果得出的,并非演讲者本人提到的内容)

Fig.24 阿尔宙斯的贴图解包
Fig.25 剑盾的贴图解包
Fig.26
Fig.27

而宝可梦的眼球会被分配一个专门的材质,以便在游戏运行中对眼球进行识别(大概是视线功能)。 而对应的眼皮、阴影信息等都在一张贴图中上体现。宝可梦的毛发也有专门的材质。 类似于标准着色器的一种变体。右图为模型骨骼的命名演示,从腰部和颈部这些基本的部件开始,逐级定义诸如爪子和翅膀之类的部位。

Fig.28

Displacement Map(置换贴图,也叫移位贴图)

可以改变模型对象的几何形状,但要达到较好的置换效果需要提高模型本身的顶点数,通常结合曲面细分使用。因此在提供最真实的效果的同时也会大幅增加渲染性能的开销。
Fig.29 像大师兄头顶的火焰就用到了位移贴图来表现
Fig.30
Fig.31
Fig.32

P1 研发部会给制作组提供一个内部环境进行开发。 图中是一个编辑器和查看窗口组成的预览界面,背景会打上带有时间和厂商信息的水印以保证开发安全。(前几年就出过开发组内部泄露LGPE伙伴皮卡丘的事件,所幸没有太大的影响,和今年的这些泄露比起来也是小巫见大巫)

P2展示了协力公司(外包公司)给开发组提供了一些带有标准外观的模型成品,随后再由对应的开发组进入标题开发环境中调试符合作品设定的外观效果。同时在这个预览环境中也能同时预览一些不同地点,事件,天气的外观效果,以加速协同开发的效率。

Fig.33 模型规格的检查方案
Fig.34

在验收时会按照如上的标准进行自动化检查于人工检查,并且有一些简单的功能,比如检查模型的多边形重叠程度,用分值化来进行评判。

Fig.35 比如这个皮卡丘的耳部和腿部都有一些多边形的重叠
Fig.36
Fig.37

在各类标准化都完成后,所能达到的效果就是能够更加方便地进行基于各个宝可梦共性的批处理,比如LA中三个日常表现,头目进入晕眩后头上的星星环的位置;宝可梦进食时食物所被摆放的位置;以及ZL按住时宝可梦身上所出现的锁定标识的位置。这三个情形的定位器都能因为标准化后进行批量处理。

Fig.38
Fig.39

同时,像IK(反向动力学)或者注视系统等必要设置也能通过批量处理进行简化,这一点会在下一节中详细阐述。而宝可梦的状态机也能对应每一作的规划用固定模板制作。就比如一个进食后开心的动作,就可以直接套用一个叫“吃饱了开心”这样的模板,无需每一个宝可梦都去做一遍同样的东西。下图中展示就是一部分宝可梦状态动画的数据,在剑盾中这些动作的数量大约是在40左右,我昨晚数了下LA的皮卡丘,发现有82个动画文件,而对应能串联起来的状态数量自然就更恐怖了。

Fig.40

至此,演讲就进入了下一内容版块,本文的撰写也暂告一段落,不知道为啥加引用写了7000字。简而言之,宝可梦系列的建模其实一直是存在一个成熟和高效的制作体制的,但由于需要适应高清世代加上不同玩法,画风作品的并行开发,在2018年,也就是Game Freak在NS上第一作宝可梦还未发售的时期就开始改革,只是中间经历了一些磕磕绊绊,同时文中提到的演讲者所在的研发部,也是在16年日月开发完成后,应对今后的高清化开发而开始建立的。一系列的改革措施让玩家在今年迎来了两款宝可梦系列历史中都具有重要意义的作品,而如何进一步分化去做到这一点,还请看下一章节——焕然一新的图像资源库。

Fig.41 Welcome to Poke Amice!

Part 2 『阿尔宙斯&朱·紫』 两款宝可梦作品并行开发的情况下的宝可梦模型制作环境 之 图形资源库&模型动画

Fig.42
Fig.43
宝可梦传说 阿尔宙斯 -进化

CH.2 前言(一些补充和分析)

第二期原本是打算在朱紫发售日前发布的(带有庆祝发售的意义),但一些学业原因预期推到了发售日当天,而后考虑到17号下午5点解锁的媒体评分&后续的数字版玩家中主要的反馈点都在于画面&帧数表现,感觉有必要在这一期里加一下我个人对相关内容的理解,因此进一步准备到了现在。虽然原本演讲中提到的内容并不包含『朱·紫』实机效果的开发&优化,仅仅涉及“为制作组搭建一个好用高效的开发环境”,但本文撰写的目标就是让读者从技术的角度去理解宝可梦的开发体制及对应细节。在这个时间节点发布,想必读者也更关心我大书特书了这么多,那实际体现在哪。

回到本文的正题,本文虽然还主要围绕着Game Freak的CG技术总监在CEDEC 2022发布的演讲——『阿尔宙斯&朱·紫』两款宝可梦作品并行开发的情况下的宝可梦模型制作环境 的第二&三章——焕然一新的图形资源库&针对动画数量的一些方案,主要介绍开发体制变革达成后两部作品中一些视觉效果和模型动画区别于前代的效果,但演讲原文中的第二&三章相比第一章要少很多,因此也适合整合起来平衡篇幅并做一下补充,大体会补充日月时期的建模体制,剑盾时期的开发模式,另一篇CEDEC演讲中的云端开发迁移,官网上对应的采访描述,朱紫的建模改动以及上一段中提到的对于朱紫画面和帧数问题的个人理解。统合起来也是一篇究极长文了,所以也请读者多多担待。

首先还是回顾&补充一下上一篇的内容,也当是对上一章节的一段小结

上一篇在借着演讲的第一章——交付品&规格的共通化 分析了Game Freak在剑盾之后开启建模体制改革的动机。

Fig.44

从第八世代初期以来Game Freak在NS上推出的作品和完成度来看,在原有的建模&开发体制下,大体只能支撑起LGPE和剑盾这样玩法相近,其中一个作品开发体量还较小的同期开发,这一点和3DS时期相似,复刻和资料片二选一与正统作品同期开发。

Fig.45 到『剑·盾』为止的开发环境都是由研发部为每部作品单独给出一个开发环境和仕样内容,制作组根据当前的开发环境和每部作品对应的企划内容开展对应的素材&资源制作。但与此同时所面临的问题在于,宝可梦的模型总数达到了千种以上,每一作都或多或少在进行贴图/动作/模型的翻新和重做。

而由于切换了平台迈入了高清开发时代,一些原本处于舒适区的传统开发模式和成品其负面效果被放大了。而且从两款作品的完成度来看,当时也各自面临着一些工期限制导致的问题。同时在采访和解包信息中也能知道剑盾的开发是基于LGPE的框架(甚至剑盾Beta版的UI用的还是LGPE里的),同时旷野地带的大批量明雷宝可梦分布也得益于LGPE先行的试验得到积极反馈。在LGPE框架确定后才全力开发到了最终这个以旷野地带为主要卖点的版本。

换而言之,六年前刚步入NS开发时代的Game Freak还无法做到严格意义上并行开发剑盾和LGPE,即便二者的框架相近,开发思路上也有沿革,而得益于18年开始的开发环境/体制的“基础设施建设“在今年如期发售了阿尔宙斯和朱·紫这两款玩法迥异,画风不同的作品的并行开发。

(当然,1.01版本的朱紫还存在着明显的优化和Debug问题,但总体内容量来说,确实是一部优质的宝可梦系列作品。)

其中的策略之一便是将社内和外包同期使用的资源都以相同的标准&规格去制作,直截了当的效果是能将并行开发的两作间的模型和贴图的取用变得更加灵活,而另一方面,规格一致使得内部引擎进行批量处理变得容易,比如阿尔宙斯中玩家注视锁定的框,进食时食物相对于宝可梦位置的摆放等等,由此可以将一个模型和贴图相关的改动想法快速落实到每一只宝可梦上。

 Fig.46 LA中三个日常表现,头目进入晕眩后头上的星星环的位置;宝可梦进食时食物所被摆放的位置;以及ZL按住时宝可梦身上所出现的锁定标识的位置。这三个情形的定位器都能因为标准化后进行批量处理。

以及作为补充,既然是在『朱·紫』发售后的发布,本文自然也会追加『朱·紫』正式版中呈现的改动。

『朱·紫』正式版中呈现的模型层面改动

(本文虽然会涉及朱紫,但并不会出现任何剧情内容相关的截图,请放心食用)

以下10条引用的是Twi上的一位开发BDSP改版的大佬——Yisuno所总结的『朱·紫』在宝可梦模型,动画相关的改进帖(相比剑盾)。

1.所有宝可梦的睡姿,睡醒等动画完成了重做。以及一部分宝可梦新增了游泳动画,比如等鼠类宝可梦新增了游泳动画。

Fig.47 Yisuno的ID
Fig.48 上岸的雷超,祝考研的各位都能上岸!

2.保留了LA中的真实尺寸,但一些宝可梦的尺寸被砍小了,比如无极汰那和流程中常见的热带龙(图鉴中记载的高度是两米)

Fig.49 7m的起源形态帝牙卢卡
Fig.50 身长 6.9m的骑拉帝纳
Fig.51 身高3.5m的固拉多
Fig.52(a),(b)相比剑盾中通过特殊手段调用的明雷无极汰那,朱紫的明雷无极汰那明显小了很多。(一般对战中的模型都是被缩放了比例,因此从剑盾转入朱紫时会对野外战斗中小型宝可梦的尺寸不习惯) 设定中无极汰那的身长为20m。

3.最明显还是宝可梦贴图质量的提升

Fig.53 裂空座的鳞片材质
Fig.54  骑拉帝纳的“金”属感
Fig.55 毛发质感

4.部分宝可梦模型进行了重做,其中最明显的是超梦和喷火龙,二者均更贴近了动画中呈现的造型观感

Fig.56
Fig.57
Fig.58 右图为新模,同样的招牌动作有了更强的压迫感

5.火暴兽在战斗中的待机动画重做

Fig.59 火暴兽的待机动画,并且与野生的有所区分

6.一部分宝可梦会针对不同地形选择战斗姿态(飞行,漂浮or落地),这意味着当年为了XY的空中战斗所制作的那批浮空待机的宝可梦中的大多数终于适配了落地的待机动画,非必要不再需要原地原力滑翔

Fig.60
Fig.61
Fig.62
Fig.63

比如喷火龙和热带龙

Fig.64
Fig.65

不过麻麻鳗鱼王和暴飞龙这俩在战斗中还是飘着的

Fig.66
Fig.67

7.一些宝可梦在捕捉后并不会立刻和玩家友好相处,有时会和玩家唱反调,比如你走东我走西或者无视玩家的指令。

Vid.1

8.一些宝可梦会在明雷状态下表现出生态习性,比如鲤鱼王的高跳——水跃溅

Vid.2

9.和LA中类似的宝可梦战斗待机时会对吼

Fig.68

10.由于适配了图鉴尺寸,训练家普遍站在了宝可梦的左后方(宝可梦视角),以防对方NPC模型被宝可梦所遮挡

VS-妮莫
Fig.69
Fig.70

11.以及LewTwo老哥发现的细节——宝可梦在被捕获后会有更加活跃的战斗中待机动作。

确实能感受到野生宝可梦的动作会相对僵硬,只有在被捕捉后会呈现完整的生态,这在LA中还没有做到。

Vid.3
Vid.4

以及上一章节内容的一些补充——模板化状态机引入后的LA,原本目的应该是实现野生宝可梦针对主角的动作(靠近、投球)进行反应,玩家带着喜欢的食物就凑过来,随后延伸到差异化的图鉴式生态。而其中的妙用便是让队伍中的几只宝可梦一同放出来后放送的“队内沟通”,朱紫中与之相对应的便是队内传球,这个功能虽然在剑盾中就有雏形,但基本只是玩家和单只宝可梦的互动,少见的玩球手切换一般是某只宝可梦没有兴致后的接替,因此也算是引入这个开发模式后的玩法进化。而像这种体现多只宝可梦自然交互的机制自然是无法靠人力去适配全部宝可梦的交互,(比如给每只宝可梦加上受到挑衅后如何,受到),但当使用这些状态机模板进行批量通配,再加手动微调(甚至塞点彩蛋,比如猫鼬斩和饭匙蛇一出来就吵架)就能实现这个效果。宝可梦游戏的开发也通常像是这样在和如何高效通配和手动按照设定构造差异化打交道。

Fig.71
Fig.72

当然也包括『朱·紫』中的一些受到好评的生态实现,比如与野生宝可梦以及NPC对战时的野外宝可梦观战行为,这些都是能够针对所有明雷宝可梦进行批量配置的。

Fig.73

从而得到下面这个视频里的节目效果↓

Fig.74
Fig.75

这里在原版演讲中演示了皮卡丘视线跟随的动图,但CEDEC官网上下到的版本里删掉了,这里顺带也补充一下。而在这里前泽特意提到是在完成了全部宝可梦骨骼部位的标准化命名后,一些反向动力学的配置也会变得容易,同时也能实现宝可梦在倾斜面上模型站立处理的视线系统。

视线在LA中的应用表现为野生宝可梦的警戒值计算,呈现攻击性时目光对主角的锁定→在进入战斗时目光再切向主角的宝可梦,比较经典的便是当主角面对头目宝可梦被击倒一只宝可梦时换人前会将目光切回主角,于是就有这个名场面。

Fig.76 次はお前だ
Fig.77

当然前文所提到的连续放出多只宝可梦的“队内沟通”当然也需要用到这一点,不然说话都不看着对方会非常的尬。

朱紫中虽然没有了“队内沟通”和野生宝可梦对玩家呈现攻击性时的眼神锁定,但依然大量用到了这个机制,比如野生宝可梦的观战(下面这个视频是完美的体现)以及本作新增的自拍系统,也需要让宝可梦能看着镜头,有时野生宝可梦也会对镜头有反应。

Fig.77

看了下字数标记,写到这里就有11000字了,不过对于本文来说,仅仅是完成了对上篇文章的补充,写本文的历程也如同是帕底亚地区的“寻宝”,翻译转述一篇演讲本身作为主线不免显得千篇一律,但能藉由这些内容结合我对近世代Game Freak开发体制的认识和理解,或许能让其成为只属于我自己的宝物。现在还只是出了桌台市,兜兜转转完成了第一条主线,还有两条主线没动呢!

第二章——焕然一新的图形资源库

Fig.78

在这一节,演讲者主要介绍的是在全新的模型制作体制下,Game Freak是如何利用这批共通的图形素材去完成两款画风不同的作品开发,他首先回顾的是关于剑盾时期的宝可梦模型开发机制,不过2017年发售的那一期CG WORLD里正好也介绍了点日月时期的开发体制,我就在这里顺带提一下:

Fig.79

如图所示的便是日月时期的新宝可梦3DCG数据制作流程。 首先,由Game Freak本部提供宝可梦参照插画、设定资料和CG制作需要用到的三视图细节,随后再于Game Freak, Creatures和The Pokemon Company三家之间开会研讨推进。

用于3DCG的模型和动作会先由Creatures创建,并由Game Freak和TPC共同监督,其中3DCG模型的部分包括用于渲染和作为其他作品(非正统游戏,动画以及广告CG等)参考的参考模型,以及用于这项正作的正式模型。 此时制作组会更加留意到两者(正式模型和参考模型)之间在模型面数、网格结构、材料结构、接口数量等方面的联系。 在Creatures内部进行最后检查后,会将模型交付给Game Freak进行最后把关验收。

此时的模型开发参与者还是GF,TPC和Creatures三家,其中TPC主要发挥的是监修作用;GF则主要负责提供适用于该作的宝可梦模型数据库,模型预览环境的接口,原始的参考模型,设定资料,三视图等等;Creatures负责完成最终的模型和配套动作制作。在此体制的基础上,Game Freak继续开发了一些适用于宝可梦开发的程序,比如能直接在Windows系统上查看宝可梦模型格式的程序,专用于宝可梦特效的制作程序,两家采用了Alienbrain来管理开发资源和数据,资源管理方面使用的是Redmine,两周开一次例会来确认开发状况和进展。

(以上内容整理自CG WORLD 2017 07)

Fig.80 全文at link below
Fig.81
Fig.82

而到了剑盾时期,由于吸取了首次高清化开发(LGPE)的经验,Game Freak采用的方法是尽可能的在Maya中完成3DCG的制作来提升效率,于是他们在Maya的ShaderFX中开发了一个能够和NS实机表现相近的着色器,继续采用在3DS时期创建的本家模型格式——GFBMDL。采用ShaderFX可能是出于系列首次面临算上测试和本地化人员数量超过1000人的大规模外包制作的情形,宝可梦模型和动作的开发也不再局限于三家之间,同时地图规模扩大也需要外包出去一部分,而Maya在外包公司的普及度较高,只需要在其中的ShaderFX里添加“移植”的能呈现作品实机表现效果的着色器,就无需把整个内部开发的引擎发给外包公司,同时也能直接预览每个参数和管线节点的效果,对外包组的开发者来说比较友好。

Fig.83

“ShaderFX在工作中属于偶尔用到的东西,毕竟不能把内部shader和引擎(或者自定义部分)都给外包但是外包但是外包又是需要预览最终效果的。这个时候shaderFX就可以拿来凑乎用用。”摘自↓

https://zhuanlan.zhihu.com/p/416850516

不过其中面临的新问题在于,正统作开发规模加上高清化后开发的材料文件数量开始了爆发式增长。同时,在Shader FX中使用的材料都需要保存成Maya中的二进制文件,通过读取这些二进制文件从而才能预览效果,随着开发的图像逐渐复杂化,制作组对于这套制作体制的后续维护难度会很高,毕竟能够进行维护的开发人员数量是有限的,于是在完成了剑盾本体开发之后,Game Freak就着手在这套模型效果预览机制上进行改革。或许这也是为何他们没有推出一款剑盾风格的DP复刻。这是因为在全社步入下一代高清化的开发体制下仍采用旧有的体制去复刻作品的效率并不显得会高,同时采用原先技术的团队也无法在完工后无缝衔接到另一个团队中,由此看LA这样的作品的出现是开发体制改革和玩法思路革新双重作用下的必然结果。

Fig.84 同人制作的剑盾小光mod https://gamebanana.com/mods/251249,常常被用来幻想剑盾风的DP复刻会是什么光景
Fig.85 剑·盾的管线

关于什么是管线(上右图):

视频:

【【游戏开发基础知识】什么是渲染管线?如何绘制3D物体?】 https://www.bilibili.com/video/BV1qY4y1V79z/?share_source=copy_web&vd_source=e86e856b2f3fe6014d8a042bef593a12

文字:

实时渲染管线:(一)基本概念与发展简史 – 木头骨头石头的文章 – 知乎 https://zhuanlan.zhihu.com/p/440584180

大致就是如何编排CPU去分发图形计算的任务为GPU去高效地完成拟定的实时渲染。

Fig.86
Fig.87

针对二进制文件的调用繁复,管线错综复杂导致维护成本较高等问题所推出的新开发环境不再必要将材质在MAYA中制作完成后转换为二进制文件再传递到引擎中运行,而是将材质源文件直接存在运行环境中调用,在MAYA保留一个索引的文件名,从而实现在运行时实时对材质的参数进行调整&数据处理的开发模式。

顺带补充一下,「剑·盾」中对于宝可梦3DCG数据的标准是,模型15000个面数,150个关节,16份材质等。贴图的长宽各是过去的两倍,最大纹理尺寸是1K。

*主要角色拥有10000个面数对于一款NS游戏来说肯定是绰绰有余,因此宝可梦模型一般来说不需要大改,由XY世代修修补补延续至今,在随乐拍和LA中首次大规模引入了完整的眼球和嘴部建模来表现宝可梦的面部。前文里也提到了在朱紫中重做了超梦和喷火龙的模型,一般需要每作重新制作的是针对于不同运行环境渲染效果的贴图以及关节骨骼和配套的动作。剑盾时期被批驳较多的“模型复用”问题实则并不紧要,宝可梦的建模本身一直没有太大的问题,发售前的PV和实机表现更多暴露出的是制作组对贴图和模型动画的精力分配不足。(本段提到的内容均为剑盾世代语境)

Fig.88
Fig.89

以及社群在这几作中比较关心的描边问题,事实上剑盾里也是存在描边的。制作组在CG WORLD刊发的采访中特意提到了这一点。在3DS中的描边由于机能限制只能将描边处理成黑色的,而在NS上则可以“因地制宜”地选择描边的颜色。开发组的处理是将描边的颜色设置为相较宝可梦本身轮廓更深的颜色,从而将宝可梦本身从背景中凸显出来。而这个处理最早的想法也是源自将极巨化的宝可梦边缘处理成红色的。并且如果在高清的大地图上较远的位置用黑色描边渲染一只小宝可梦,本身也会让画面变得很杂乱,同时由于高清化后描边的厚度被加到了2个像素,一般的处理会是根据距离来调整描边的大小,但用了加深描边的处理后只需根据距离来淡化描边深度即可。

回到Fig.82中的内容,在解决了剑盾中模型的实机效果的预览&调试繁复&后续维护成本较高的问题后,新世代的模型开发环境在此基础上增加了可以用一份初始交付品素材构建两种截然不同的渲染效果的作用。由于这样得以用同一份素材针对不同作品定制一份后期处理的规格,也有利于将外包制作的交付品规格和本地运行中所要达到的效果分离开来,由此也无须每次针对作品的概念设定去外包制作新的素材。

Fig.90
Fig.91 这便是上篇文章提到的版画画风的实机效果
Fig.92 不同状态下的光线

以下会以阿尔宙斯中的场景和开发要点为纲,以演示新开发模式的效果。(以图片展示为主)Fig.92中所展示便是LA在选用不同开发阶段的管线所达到的画面效果,①阶为只有贴图本身色彩的画面,②为附加全局光照后的画面,③为增加画面的层次感后的表现,④为增加了一系列调色和微差调整后的画面,也即是最终想要传达的效果。

Fig.93 放大的对比
Fig.94 皮卡丘模型的光照效果 交付品预览效果与实机对比
Fig.95

演讲里有一个比较有意思的细节是,前泽圭一对皮卡丘的称呼是“ピカチュウさん”(皮卡丘先生),有种称呼自己同事的感觉。

Fig.96 进行色彩匹配处理进行色彩匹配处理
Fig.97 计算画面中的渲染负载 用不同深度的颜色进行标注

如果需要针对不同作品的观感对同一份交付品的色彩数值设置进行调整,可以在后期处理的管线中添加“掩膜”,从而批量对色彩表现方面的数值进行修正,虽然纹理参数还是需要一对一的上手调整。同时,也引入了对画面中的物体进行分类,从而检测各个元素在渲染中针对硬件负载的情况,从而直观地去删减画面中不必要的渲染处理,减少了游戏运行时的负载压力。

Fig.98 追加质感&修正bug

在原有交付品的基础上对部分宝可梦添加一些特有的纹理贴图来追加其“符合生物性/设定”的质感,契合作品的视觉主题。同时,在交付品检查后依然会存在一些bug,比如粗糙度以及法线贴图错误,会在进一步微调中及时发现出来。

Fig.99 翅膀的不透明

对于三蜜蜂的蜂蜡质感,就可以采用这种半透明的材质效果,其表面半透明,背部不透明。

Fig.100 火焰和烟雾效果

虽然像鬼斯这样的烟雾质感在LA实机中的观感似乎变拉了,但多了一些边缘随机烟雾飘散的效果,以及烟雾的半透明质感,总体在真实化的方向上迈进。

Fig.101 LA中的鬼斯
Fig.102 剑盾中的鬼斯

以及演讲中没有提到的LA的一些模型提升(复眼,金属光泽,植物纤维,鱼类鳞片)

Fig.102 LA中的三合一磁怪(金属光泽)
Fig.103 LA中的自爆磁怪(金属光泽)
Fig.104 LA中的裙儿小姐(头部的植物纤维)
Fig.105 LA中的超甲狂犀(腰带的岩石纹理)
Fig.106 LA中的霓虹鱼(鱼类鳞片)
Fig.107 LA中的骑拉帝纳(金属质感,以及逆光压迫感)

这类建模上的技术改进虽然能用旧世代宝可梦和前作ver对比中有所体现,不过还有一种对模型观感提升的判断方法是去观察全新加入的宝可梦的实机效果,就比如下图中的洗翠风速狗。

Fig.108 吹火岛的风速狗王
Fig.109 根据画面的概念设定 增加一些层次感
Fig.110 传说·阿尔宙斯 早期设定图

采用版画画面中的元素关系,对背景中的物体根据深度和高度进行雾化处理。人物也增加了对应的纹理进行版画风格化的表现。

VS-望罗

Fig.111 从图库里翻出了这张相对能体现层次感处理的截图
Fig.112 人物也尽量使用大色块
Fig.113(版画样式的)天空中云朵的层次感&水面荡漾的波纹

虽然没有做得尽善尽美,但确实也还原了一些版画中“富有透明感的”水体,在蝦夷风俗志中翻到了这张「小樽ゼニバコ 魟魚の奇異」可以作为参考。

Fig.114 「小樽ゼニバコ 魟魚の奇異」
黑曜原野-白天(PV1 BGM)

Fig.115 相对能够体现水体和岸边的版画画风以及背景层次感的一张截图&在北海道拍摄的天冠山原型——羊蹄山

对这个概念处理得最好的就是群青海岸,从图库里精选了几张能够在不同天气和时间展示上文提到的这几个画面调整概念。虽然也总从中能分辨出一些不尽人意的地方,但从开发的角度来说,Game Freak在登陆NS以来的五部宝可梦作品(算上方可梦的话)采用了五种不同的美术风格进行开发本身也是一种创举,对于每部作品独有的美术风格表达欲的旺盛也在不言而喻地破除“摆烂”的评价。

Fig.116 想做瓜娜小姐的卡蒂狗
Fig.117 夜晚的群青海岸
Fig.118 正对”赤日”的场景表现
Fig.119 个地方用来调查水边的宝可梦最适合不过了
Fig.120 色调补正前后的对比&除此之外的一些过滤器效果

色调补正中主要调整了YCbCr+对比度+Gamma,过滤器中主要泛光+DOF(景深效果)+色差+虚光效果+径向模糊。

泛光 UNREAL介绍

Fig.121 潜入草丛中会让相机四角变暗的效果

虚光效果 UNREAL,(在蹲入草丛中时,镜头边缘会出现的变暗效果)

Fig.122 进入战斗前的过渡

Radiant blur(径向模糊,常见于赛车游戏加速时对周边景物的模糊,LA中对宝可梦战斗的加载就用到了这个效果)

补充资料:

unity radial blur

https://juejin.cn/post/7090102807298048037

由此,在场景层面,凭借诸多新旧技术的引入,LA的画面逐步还原了概念设定中想要表达的效果,同时也为了适配动作玩法的稳定性做出了取舍。这些操作其实也是Game Freak一贯的开发思路的体现,即“在仕样规划上试图达到新效果时才会对应地引入新技术,而不是针对一个新技术的出现去制作对应的场景和玩法。” 好处是Game Freak的作品一般都能达到制作组整体想要传达的效果,因为如今的游戏行业的技术发展已经相当成熟,总能找到适合自己团队和开发周期的解决方案,并不会把自己的作品当成背后厂商的肌肉展示舞台,哪里的画面表现力做不好就是丢了厂商和玩家的面子,从而在某个技术节点无法推行时举步维艰。而坏处自然是所掌握的技术很多时候是现学现卖,一旦开发规模和工期冲突性较大,就容易出现某处突然又拉胯了的表现。

回到演讲内容中最后关于画面表现的解说部分,这两部并行开发的作品采用了GBuffer的渲染手段,使得能在复杂光源的情况下依旧能够完成画面渲染。

Fig.123 针对阿尔宙斯中的观感表现的解说基本到此结束
Fig.124 阿尔宙斯中使用的GBuffer

交互式渲染中的G-Buffer

指Geometry Buffer,亦即“物体缓冲”。区别于普通的仅将颜色渲染到纹理中,G-Buffer指包含颜色、法线、世界空间坐标的缓冲区,亦即指包含颜色、法线、世界空间坐标的纹理。  由于G-Buffer需要的向量长度超出通常纹理能包含的向量的长度,通常在游戏开发中,使用多渲染目标技术来生成G-Buffer,即在一次绘制中将颜色、法线、世界空间坐标分别渲染到三张浮点纹理中。

我们现在一直使用的光照方式叫做正向渲染(Forward Rendering)或者正向着色法(Forward Shading),它是我们渲染物体的一种非常直接的方式,在场景中我们根据所有光源照亮一个物体,之后再渲染下一个物体,以此类推。它非常容易理解,也很容易实现,但是同时它对程序性能的影响也很大,因为对于每一个需要渲染的物体,程序都要对每一个光源每一个需要渲染的片段进行迭代,这是非常多的!因为大部分片段着色器的输出都会被之后的输出覆盖,正向渲染还会在场景中因为高深的复杂度(多个物体重合在一个像素上)浪费大量的片段着色器运行时间。

延迟着色法(Deferred Shading)

或者说是延迟渲染(Deferred Rendering),为了解决上述问题而诞生了,它大幅度地改变了我们渲染物体的方式。这给我们优化拥有大量光源的场景提供了很多的选择,因为它能够在渲染上百甚至上千光源的同时还能够保持能让人接受的帧率。下面这张图片包含了一共1874个点光源,它是使用延迟着色法来完成的,而这对于正向渲染几乎是不可能的(图片来源:Hannes Nevalainen)。
https://learnopengl-cn.readthedocs.io/zh/latest/05 Advanced Lighting/08 Deferred Shading/

朱紫拥有大量城镇,灯光效果以及太晶化等复数复杂光源,需要表达的色调风格是阳光明媚的伊比利亚半岛的南国风情,其渲染的光照物景必然也更复杂,如果没有这项技术应用,恐怕连出现掉帧的画面都很难见到。同时为了实现这一效果,Game Freak在原定的渲染效果基础下扩展了管线,并在后期处理的过程中增加了额外的纹理质感。

Fig.125 下文还有一点针对朱·紫中观感表现的介绍&补充
Fig.126 朱紫中使用的GBuffer

在宝可梦模型表现方面,阿尔宙斯偏重的是色彩相对鲜丽的版画感,朱紫主要体现的是“写实感”,使得不怼脸看时很难触及这些改进点。

Fig.127 相比于阿尔宙斯中的卡通渲染表现 朱紫会着重一些写实的细节,比如图中皮卡丘身上一撮撮的毛
Fig.128 拿着拍照系统怼脸拍毛茸茸的皮卡丘
Fig.129 润水鸭头部的胶状感以及密勒顿轮胎部位的发光粒子

官方的一张朱紫主题曲交响乐演奏招募的宣传海报上也有同样渲染效果的御三家展示,这张图就能看清朱紫中所用贴图的一些写实细节。

Fig.130 御三家的建模细节
Fig.131 绒毛和金属感并存的钢铠鸦
Fig.132 全毛绒质感的宝更可爱了
Fig.133 天空·草地&城镇的画面效果
Fig.134 雨天和雪天的画面效果

当然,以上的解说仅仅是针对朱紫所用的技术的介绍(并没有表示过这些技术本身所谓的高低),如果想在Game Freak的技术演讲会上看到顶尖技术的展示来让脑内对于“Game Freak技术力极低”的印象扭转过来的话,确实是想多了。重点是在于了解这份开发体制所给宝可梦系列未来发展带来的潜力,不同玩法,不同画风的宝可梦可以接连从这个体制中孕育,制作组也并非总是薅着原本的素材和玩法体系毫无改进,而是积极进取地为不同的作品吸纳不同的开发技术。同时,在面对年货化的开发要求,将一条清晰的发展路线上逐步推出的宝可梦作品附以画面和玩法迭代的差异化避免让系列玩家陷入疲劳。这些差异化对应关系有如,LGPE(旧作,新玩法,三头身卡通画风),剑盾(正统新作,传统玩法+LGPE明雷加强版,标准四头身英伦风),BDSP(旧作,传统玩法+部分LGPE明雷,标准二头卡通风),LA(新瓶装旧酒,完全新设定和玩法,版画画风四头身),朱紫(正统新作,传统玩法+开放世界,四头身写实画风)。

这恐怕是一个厂商在迈入高清化开发+应对年货化开发最好的态度。由此认识到了这一点,本文也在写作中途增减过多次,从原本的演讲解说逐渐变成了对宝可梦系列在2022年迈出的这两大步背后的成因和细节的挖掘整合。

补充一个冷门谣言的辟谣:酷丽恰姿撤退事件

19年12月曾经出现过一条新闻,是指Game Freak在更新官网后将Creatures从主要合作对象中删去了。当时引发了一些股权变动的传言,但现在这个传言过去了三年还没发生自然是不攻自破了。但删去这件事的原因实际上还是能从本文中找到答案的。因为在剑盾开发完成后,Game Freak的宝可梦模型开发体制有了重大的变革,Creatures也不再是唯一经手模型部分的外包商。从日月时期的三家合作建模体制转变为了更为灵活高效的外包体制。不过Creatures依然是宝可梦模型方面的主要负责人,这一点在历代的Staff表中都能找到,宝可梦建模组的美术总监一直是Creatures的氏家淳子 、产品经理也一直是Creatures的匡道穴澤。

酷丽恰姿撤退事件讨论帖

回到演讲内容,由于演讲发布于今年8月份,此时朱紫情报公开并不多,因此并没有太多内容进行解说,下面介绍的太晶化则是第二章节的最后一部分。

Fig.135 宝可梦太晶化后,会在头部等部位出现王冠般的太晶宝石,身体表面会像切割后的宝石般闪闪发亮。
Fig.136 不同属性的太晶化演示

虽然前泽没有提及,但细想一下可以发现,相比于极巨化的模型放大,描边改为红色,新增能量体样式的贴图以及极巨招式动画适配。太晶化进化成了每只宝可梦可以适配18属性的太晶化贴图材质,属性王冠的摆放位置。

以及最重要的太晶化,能够让每只宝可梦从极巨化系统中的单一形象适配(上文提到的材质和描边变化),进化到每只宝可梦适配18属性的太晶化贴图材质,属性王冠摆放定位。没有签证的宝导入后就会面临一些贴图错误和王冠位置错位的问题。从Fig.137中也能发现太晶化后的宝可梦其实是能够透过身后的背景,其本身的纹理也同时存在,这一处理方法应该在之后的开发里会有一些妙用。

Fig.137 太晶化的近距离截图
Fig.138 偷渡的卡比兽
Fig.139 前往帕底亚!
Fig.140 One Step by yourself Another Step with your Pokemon

第二章节部分完结撒花! 说实话演讲部分的转译在发售前就基本完成了,但发售前出现了一些优化层面的风波。虽然本文只是在开发体制上进行挖掘,涉及的内容也大多是建模和渲染,不过我认为还是得藉此机会写一点能够解释现状的内容&对两部作品表现更详尽的考察。本文(在微博上)发布的时间已是2022年12月7日,恰逢1.1.0补丁更新,修复了一些常见的Bug以及帧数问题。

Fig.141

在发售后一周左右完成这些内容的修复显然是在发售前以及初期就在高度留意是否会有Bug和帧数问题出现。类似的操作BDSP也干过,11.11(发售前)发布了1.1.0补丁,发售日前夕也发布了1.1.1补丁。

Fig.142

而后就一路修修补补到了十二月底(当然还没修完),到了二月底HOME开放前才完成了复制bug的填补。这意味着两件事,其一是对这类玩法作品的开发模式还不够熟悉,就如同ILCA并不熟悉传统宝可梦的Bug触发规律,负责朱紫开发的一组也并不熟悉开放大地图和任意流程模式下可能发生漏洞的注意点(这一点确实需要经验才能做得好);其二便是从PV完成度能看出的地狱工期所造成的赶鸭子上架,这一点和BDSP也是类似的,显然ILCA在开发后期不光是要面对海量的Bug,还得把先前惨不忍睹的画面提升至合理的水平,双重夹击下造成了这个问题。

Fig.143
Fig.144

而对于朱紫来说,画面的优化自然是一个重要方面,但也需要首先保证开放世界的内容量,用心策划的终盘剧情的演出效果等等,正统续作所代表的全新要素内容加上开放世界需要的进一步内容和细节填补,这便让开发人员在开发的最后冲刺阶段陷入取舍困境。而这一次或许是吸取了剑盾的教训,最终保留了终盘内容体验的完整性,也保全了制作组一直以来被忽视的野心。所以其实画面上的问题,虽然看起来比较不堪,但能像现在这样后续能补救的话,可能已经是当前开发状况下对玩家来说最好的结果了。

不过又话说回来,谁又能保证内容量上被取舍的部分不在少数呢,开发人员即便有足够的工期,最初企划中能够实现的内容也不会太多,在画面问题暴露的背后自然也暗示着有更多内容层面的工作被迫砍掉,因此主要矛盾还是回到了工期问题。或许下个三年,在Game Freak熟悉了这套模式后,我们能玩到一款画面不错,优化良好的,朱紫级别的开放世界宝可梦,但要更进一步,且不论满足玩家对于开放世界宝可梦的幻想,单论复制这三年Game Freak进步跨度的作品,亦或是迈向新的平台进行更加高性能的开发,三年的工期必然还是不够的。开发规模的扩大并不能通过人力的线性增加来解决,当然也需要时间的沉淀,从各个3A大作越来越难产的现象也可见一斑,包括我自己写文章也经常因为想要写完自己素材库里准备的内容延期一两月甚至大半年,如果为了抢时间发布也顶多写点流水账的PV分析文。之前翻译Lewtwo老哥的那条朱紫PV1分析视频的时候其实就是觉得他用视频的形式表达出了我对朱紫开发周期的担忧,最近回顾也是感慨万千(也包括他做BDSP视频做了一年多还没发)。

视频↓

当然,上文提到朱紫Bug体现的俩问题:对开发模式的不熟悉&工期问题并不能回应一些制作水平上的粗糙以及玩法设计上的不成熟。而这个问题则出自Game Freak的一个神奇的特性:新人招进来培训三月后就会直接进宝可梦项目组干活,同时新人的工作成果也会被直接保留入最终成品,好处是确实会给新人压力,鞭策其快速成长,而坏的一面自然是许多“自学三年动画”水平的制作也会混入其中(当然人家可能真的没学到几年)。

Fig.146 Game Freak 官网翻译05——程序介绍 D.N.

Game Freak对于新人的采用态度比较独特,官网上的大森访谈里也提到了他自己在25岁就担任了DP的游戏设计组组长(Game Design Leader),负责了剧情脚本 (Plot Scenario)和地图设计(Map Designer),招聘页面也着重写了重用新人。团队领导年轻化使得宝可梦系列的新点子层出不穷,选用的人设,音乐品味也从来赶在时代前沿,不过也对应的是设计细节上的决策经验,非重兵把守的项目(比如程序和3D美术)在打一枪换一炮的年货压力下表现并不稳定,而这一次的UI设计的拉胯和剧情的爆发也是其中好坏参半的写照。由于年货化项目数量奇多,新人得到的锻炼机会也大增,如此锤炼出的团队开始逐渐适应了高清化,甚至并行开发的模式,但其中好坏参半的表现,也正应了Game Freak这个社名,Freak所代表的“怪胎”,“怪杰”的含义。

Fig.147 Game Freak 官网翻译02——策划对谈

第三章——针对动画数量的一些方案

最后来到演讲的最后一节——针对动画数量的一些方案,由于本文中我个人补充的部分在上一节已经基本完成,这一节会比较快地介绍完。

与上文提到的3D化后宝可梦的贴图材质数量暴增类似,每一个宝可梦新作的动画制作也到了需要压制臃肿的开发成本的情况。尤其到了开放世界,需要体现宝可梦明雷生态的场合,朱紫登场的图鉴位达到了400,模型位超过了600,因此每只宝可梦再增加几个,十几个动作都会面临成千上万的工作量,以及新宝可梦需要适配原有宝可梦的动作数量规格。单纯用外包也无法解决这一棘手的开发情况,自然也呼吁着新开发方针的出现。

Fig.148
Fig.149
Fig.149 鸭制 https://twitter.com/OoCPokemon/status/1599547717344120832
Fig.150 宝可梦的体型分类起到了作用

其中一个方案是观察宝可梦模型库中存在的那些体型相似的宝可梦,比如腕力和路卡利欧同属双足兽型,叶伊布和伦琴猫同属四足兽型。宝可梦体型这一点虽然在图鉴中仅仅是微不足道的一笔,但对于开发者来说却是一个粗分类的好凭据。

Fig.151 https://wiki.52poke.com/wiki/宝可梦列表(按体形分类)

因此,即便无法照搬使用(XY时期宝可梦动作开发的原则是不动作复用,保证每一只宝可梦都是独特的。当然人物除外,指赫普和哈乌),但如果能以相同的动作作为基础进行调整,也能够降低动画素材制作的时间&预算成本。如图所示的腕力和路卡在体型相近的情况下就能直接复用某一个动画(游戏中并没有复用)。

Fig.152
Fig.153
Fig.154
Fig.155

开发组内部会根据宝可梦的体型制作一个体型分类表格,并将来自剑盾的新宝可梦也加入其中,采用了同样的模式开发宝可梦的每一个新动作,同时制作组内部也有一个能将骨骼和体型相近的两只宝可梦之间的动作直接复制过去的开发工具,最直接的应用就是将旧世代宝可梦的模型动画在更换开发环境后直接复制过去,实现跨世代动画迁移。

Fig.156

与此同时,2022年发售的两作宝可梦都实装了宝可梦尺寸差异的系统,于是这一点也有针对性地做了开发,可以实现比例缩放后的动画复制,避免不同尺寸的宝可梦出现动作不一致的情况。同时在骨骼构造有细微差异时,比如腕力比路卡少了一个节点,也能重新对应起来进行定位,这也同样是上篇文章中提到的模型规格共通化的优势。基于IK(反向动力学)的动画是针对模型身体的每一个部位进行转换的,比如手臂对应手臂,腿部对应腿部。对于有双足和四足模型的腿部,在处理的过程中会使用基于Human IK(人体反向动力学)的转换。

Fig.157

而说到宝可梦尺寸差异,在逛4chan正好看到一位老哥做了一些图片对比的总结

原帖:https://archive.alice.al/vp/thread/52528260/#q52528260

Fig.158 这图在文章发出来的时候好像已经传遍了
Fig.159
Fig.160
Fig.161

回到IK动画

Fig.162

IK动画可以通过安置末端受动器,反向调整整个骨骼的体系姿态。

比如,要让角色行走在凹凸不平的路面上,可以通过确定角色脚与地面的接触位置、旋转,自动计算身体其他部位的姿势,通过改便每一步的步幅与地面接触位置,就可以实现角色在不平路面的行走动画。
https://blog.csdn.net/qq_31042143/article/details/113778262

接着来看几个例子:

Fig.163 对应有翅膀和尾巴的宝可梦
Fig.164 对应四足宝可梦的场景
Fig.165 对应蛇形宝可梦的场景
Vid.5
Vid.6
Fig.166 允许在蜿蜒的蛇形宝可梦的模型之间进行映射

这就类似上文提到的状态机模板,相似类型的宝可梦能够有更便捷的方式进行适配开发,但同时也能观察到无论是旧作宝可梦之间还是与朱紫新登场的宝可梦相比,各个宝可梦生态动作的差异性并没有缩小,新宝的动作和设定并没有因为这些便捷开发模式的出现与旧宝同质化,一定程度反应了制作组在使用这些功能的同时也心有余悸,做出每只宝可梦的特色依然是第一要务。

Fig.167 社内动作捕捉场景

大约是在一年前,Game Freak在自己的办公室里也做了一间动捕房间(之前都是外包的),里面有24个光学摄像头。同时这一次则是将不同动捕的数据(Vicon和MVN)和宝可梦模型的骨骼进行了打通,从而可以实时预览宝可梦对应动捕动作时的表现,不过还没有完全导入正统作品的开发,或许之后的过程会有某只神兽or御三家活灵活现的身影。

Vid.7

在缓解了模型动作制作的压力后,除此之外还面临的挑战在于业界擅长建模和动画制作的公司和人员都比较充足,但对于能胜任骨骼绑定这一工作的人员来说却相对稀少。由此在Game Freak内部提出了一种叫做『ポケリグ』的解决方案,也就是将宝可梦模型的各个部分的骨骼进一步特制化,拆解成模块,就如同将将雕刻的难度转换成了拼高达模型,每次只需要按照说明书拼一个版块,将骨骼绑定的工作变得相对容易起来,从而解决了骨骼绑定师人员不足的问题,同时标准化后也扩大了这一工作的适用范围,每个人建模和动画师都能随手做&调整一部分。

Fig.168
Fig.169

对于正向动力学的控制,可以采用基本控制模块Fig.109对宝可梦模型进行绑定和标记,从而实现Fig.109中铁甲犀兽身体各个部位的绑定效果。

Fig.170
Fig.171

而对于IK(反向动力学),实现控制,以及一些控制宝可梦微差动作表情变化的滑块,也可以用同样的方式去实现(在对应部位绑定一个控制模块,从而在运行界面上调试其调整效果)

Fig.172

同时尾部的样条线IK也能用于蛇形宝可梦的定位的骨骼控制。Fig.112演示了蛇形宝可梦使用该功能后进行空间“曲线运动”的案例,其中上文提到的『动作拷贝』工具也是Poke Rig的一部分。

Fig.173
Fig.174
Fig.175 模拟脊柱的情况
Vid.8

Fig.179 四足宝可梦的姿态控制
Vid.9 针对 Spine动画模拟开闭的效果对比

以及非蛇形的情况下出现的一些骨骼伴随动作的模拟,视频中伦琴猫的头部动作明显更加自然,但同时在LA中也能感受到配合眼神跟随的机制,宝可梦点头的频率偏高也出现了对应不自然的观感,或许能在下一作中能看到对应的优化。

Fig.180

上文提到的,在引入反向动力学后,适配了一些在倾斜平面移动的初步能力,但同时也需要将宝可梦的移动姿态针对倾角的大小进行适配,故勒顿以及密勒顿的乘骑功能的开发就需要大量调整这一要素。

Vid.10
Fig.181 采用了Two Bone IK 的接地过程
Fig.182 所有参数都是由对应界面可以针对作品的目标进行修改

就此,演讲的正文部分到此结束。

因为有点长,就来简要回顾一下演讲中三大主题,其一是上篇文章中提到的,实现并行开发的基础——外包交付品与规格要求的共通环境,使得一份材质资源可以经过后期处理同时为两份作品服务,同时这两份作品的差异也能拉开得足够大;

Fig.183

其二便是在此基础上各制作组进行差异化开发,针对企划的美术概念指导,以及游戏机制设计上的目标进行创作开发,同时在引擎内独立开发了一些适用于宝可梦系列模型处理数据量的工具&功能,以做到将渲染效果上的微小调整快速布及全收录模型位的宝可梦;

Fig.184

以及其三,将骨骼绑定,模型动画制作数量这类老大难问题做针对性解决,在相似体型的宝可梦动画效果可迁移的情况下进一步做宝可梦之间的动作差异化。

Fig.185

而其中穿插了大量在考察过程中搜集得到的资料以及基于这些资料的分析,尝试继续在这个采访匮乏的年代里管中窥豹一番Game Freak近年来的开发状况(毕竟前两篇也是这么挺过来的),由此完成了这篇文章的撰写,也感谢各位读到这里。


结语:

不知道一直关注近年来宝可梦作品开发动向的读者有没有一种错觉,就是开发组Game Freak似乎并没有受到疫情的影响。在每部作品工作量激增的情况下,相比过去还没迈入高清化的世代产量不减反增。

其中一个原因自然是由于采取了这个长文系列着重挖掘的新模型开发体制,而另一个没有提到且至关重要的原因,则是Game Freak在疫情前就开始推行了居家办公的体制,在家办公的设备由公司出钱补贴,同时上下班制度也相对灵活,早上最晚十一点上班,工作满八小时下班。在CEDEC2022的另一个同期演讲中,研发部的运营管理组组长——立原 春木讲述了自己在剑盾时期尝试引进,在阿尔宙斯以及朱紫中完全引入的云端开发制度,能将渲染管线的布置投放到亚马逊的AWS云端服务。从而不仅在办公的物理位置上解放了制作组,并且云端集中的高性能设备也使得开发时的响应等待时间以及构建时间大幅缩减,总体大约缩减到了原本的三分之一,其中管线的延迟时间能够缩减90%。以及由于云端设备的配置基本一致,对于设备的维护成本也大幅降低(本地不同时期配置的主机和服务器的配置都会有点不同),由此可以使用Ansible进行自动化更新配置,从而在多个项目中通用各类资源。

Fig.186
Fig.187

因此,Game Freak对于年货化&高清化后宝可梦三年一世代的开发这一难题其实确实做了充足的准备,同时也提早布局云端化抗住了疫情的大部分冲击,在其余大作普遍难产和延期的情况下依然能够保持着高效开发。很难想象2017年还在开发掌机+回合制作品的厂商能在年货化的压力下于5年后接连走过了动作游戏&开放世界这两大难关(虽然能看出来这两部作品这个系列在这两个游戏门类中呈现的初步形态)。遗憾固然有,开发时间依旧紧缩带来的优化问题造成了大规模的负面体验,不过我想系列玩家在游玩这两款作品后更看到的是一个极速成长的开发组,目前出现的问题也都是能用稍许更多的时间和经验去解决的(甚至一些改进中LA里已经实现了)。

而时间能够解决不只是画面和优化,也能让制作组将现有的技术和想法沉淀起来,新的开发体制和技术引入仅仅让Game Freak原本的奇思妙想得到部分解放,就完成了剑·盾到阿尔宙斯&朱·紫的跨越。剑·盾时期的大量呼声(地图,剧情,宝可梦生态等)都在朱·紫和阿尔宙斯中得到实现,能看得出来他们确实很关注玩家群体的声音,只是需要时间去在下一作实现,或者说当前作中确实因为当时技术不足和开发时间紧缩搁置了这部分内容。比如备受诟病的剑·盾本体的旷野地带地图,由于剑·盾的明雷是在LGPE试验后才决定加入的,很难说他们能多少时间去设计这张以明雷宝可梦为卖点的地图,而当时制作组转移精力去做明雷地图和宝可梦分布后,道馆战后期流程的开发不足似乎又导致了游戏流程后期剧情表现的不足。社群所期待的旷野之息式,荒野大镖客式宝可梦也必然少不了对等时间的投入,虽然依我看在现行的发行体系下还是难以实现,但要说一款富有惊喜,少有遗憾的宝可梦作品应该已经近在咫尺了,毕竟坐在Game Freak办公室里的开发者并不是玩家的敌人,而是同为宝可梦爱好者,在这套年货发行体制下挣扎向前的人们

Fig.188

(FIN)

评论区

[elementor-template id=”13722″]