【长文】近世代宝可梦模型考察（二＆三）——图形资源库＆模型动画
本文原本是模型考察连载系列的第二篇文章，由于拖的时间较长，就顺带写成了二&三合集，这个系列是基于Game Freak的CG技术研发组组长——前泽圭一在CEDEC上的演讲内容转译，同时也融入了我这几年搜集到的大量宝可梦制作相关的访谈内容，自己游玩&解包对应作品得到的信息，三者构成了这篇宝可梦模型制作考察的撰写基础，这篇的完结也算是我个人的一个分支研究的阶段性总结，读者也能从中一窥Game Freak这三年中为了今年发布的这两款作品所付出的工作。
（没有读过第一篇的宝友可以先去读一下稍短的第一篇）
前言：
第二期原本是打算在朱紫发售日前发布的（带有庆祝发售的意义），但一些学业原因预期推到了发售日当天，而后考虑到17号下午5点解锁的媒体评分&后续的数字版玩家中主要的反馈点都在于画面&帧数表现，感觉有必要在这一期里加一下我个人对相关内容的理解，因此进一步准备到了现在。虽然原本演讲中提到的内容并不包含『朱·紫』实机效果的开发&优化，仅仅涉及“为制作组搭建一个好用高效的开发环境”，但本文撰写的目标就是让读者从技术的角度去理解宝可梦的开发体制及对应细节。在这个时间节点发布，想必读者也更关心我大书特书了这么多，那实际体现在哪。
回到本文的正题，本文虽然还主要围绕着Game Freak的CG技术总监在CEDEC 2022发布的演讲——『阿尔宙斯&朱·紫』两款宝可梦作品并行开发的情况下的宝可梦模型制作环境 的第二&三章——焕然一新的图形资源库&针对动画数量的一些方案，主要介绍开发体制变革达成后两部作品中一些视觉效果和模型动画区别于前代的效果，但演讲原文中的第二&三章相比第一章要少很多，因此也适合整合起来平衡篇幅并做一下补充，大体会补充日月时期的建模体制，剑盾时期的开发模式，另一篇CEDEC演讲中的云端开发迁移，官网上对应的采访描述，朱紫的建模改动以及上一段中提到的对于朱紫画面和帧数问题的个人理解。统合起来也是一篇究极长文了，所以也请读者多多担待。
首先还是回顾&补充一下上一篇的内容
上一篇在借着演讲的第一章——交付品&规格的共通化 分析了Game Freak在剑盾之后开启建模体制改革的动机。
从第八世代初期以来Game Freak在NS上推出的作品和完成度来看，在原有的建模&开发体制下，大体只能支撑起LGPE和剑盾这样玩法相近，其中一个作品开发体量还较小的同期开发，这一点和3DS时期相似，复刻和资料片二选一与正统作品同期开发。
而由于切换了平台迈入了高清开发时代，一些原本处于舒适区的传统开发模式和成品其负面效果被放大了。而且从两款作品的完成度来看，当时也各自面临着一些工期限制导致的问题。同时在采访和解包信息中也能知道剑盾的开发是基于LGPE的框架（甚至剑盾Beta版的UI用的还是LGPE里的），同时旷野地带的大批量明雷宝可梦分布也得益于LGPE先行的试验得到积极反馈。在LGPE框架确定后才全力开发到了最终这个以旷野地带为主要卖点的版本。
换而言之，六年前刚步入NS开发时代的Game Freak还无法做到严格意义上并行开发剑盾和LGPE，即便二者的框架相近，开发思路上也有沿革，而得益于18年开始的开发环境/体制的“基础设施建设“在今年如期发售了阿尔宙斯和朱·紫这两款玩法迥异，画风不同的作品的并行开发。
（当然，发售时1.01版本的朱紫还存在着明显的优化和Debug问题，但总体内容量来说，确实是一部优质的宝可梦系列作品。）
其中的策略之一便是将社内和外包同期使用的资源都以相同的标准&规格去制作，直截了当的效果是能将并行开发的两作间的模型和贴图的取用变得更加灵活，而另一方面，规格一致使得内部引擎进行批量处理变得容易，比如阿尔宙斯中玩家注视锁定的框，进食时食物相对于宝可梦位置的摆放等等，由此可以将一个模型和贴图相关的改动想法快速落实到每一只宝可梦上。
以及作为补充，既然是在『朱·紫』发售后的发布，本文自然也会追加『朱·紫』正式版中呈现的改动。
（本文虽然会涉及朱紫，但并不会出现任何剧情内容的截图，请放心食用）
以下10条引用的是Twi上的一位开发BDSP改版的大佬——Yisuno所总结的『朱·紫』在宝可梦模型，动画相关的改进帖（相比剑盾）。
1.所有宝可梦的睡姿，睡醒等动画完成了重做。以及一部分宝可梦新增了游泳动画，比如皮卡丘等鼠类宝可梦新增了游泳动画。
2.保留了LA中的真实尺寸，但一些宝可梦的尺寸被砍小了，比如无极汰那和流程中常见的热带龙（图鉴中记载的高度是两米）
3.最明显还是宝可梦贴图质量的提升
4.部分宝可梦模型进行了重做，其中最明显的是超梦和喷火龙，二者均更贴近了动画中呈现的造型观感
5.部分宝可梦在战斗中的待机动画重做
6.一部分宝可梦会针对不同地形选择战斗姿态（飞行，漂浮or落地），这意味着当年为了XY的空中战斗所制作的那批浮空待机的宝可梦中的大多数终于适配了落地的待机动画，非必要不再需要原地原力滑翔
比如喷火龙和热带龙
不过麻麻鳗鱼王和暴飞龙这俩在战斗中还是飘着的
7.一些宝可梦在捕捉后并不会立刻和玩家友好相处，有时会和玩家唱反调，比如你走东我走西或者无视玩家的指令。
8.一些宝可梦会在明雷状态下表现出生态习性，比如鲤鱼王的高跳——水跃溅
9.和LA中类似的宝可梦战斗待机时会对吼
10.由于适配了图鉴尺寸，训练家普遍站在了宝可梦的左后方（宝可梦视角），以防对方NPC模型被宝可梦所遮挡
11.以及LewTwo老哥发现的细节——宝可梦在被捕获后会有更加活跃的战斗中待机动作。
确实能感受到野生宝可梦的动作会相对僵硬，只有在被捕捉后会呈现完整的生态，这在LA中还没有做到。
以及上期内容的一些补充——模板化状态机引入后的LA，原本目的应该是实现野生宝可梦针对主角的动作（靠近、投球）进行反应，玩家带着喜欢的食物就凑过来，随后延伸到差异化的图鉴式生态。而其中的妙用便是让队伍中的几只宝可梦一同放出来后放送的“队内沟通”，朱紫中与之相对应的便是队内传球，这个功能虽然在剑盾中就有雏形，但基本只是玩家和单只宝可梦的互动，少见的玩球手切换一般是某只宝可梦没有兴致后的接替，因此也算是引入这个开发模式后的玩法进化。而像这种体现多只宝可梦自然交互的机制自然是无法靠人力去适配全部宝可梦的交互，（比如给每只宝可梦加上受到挑衅后如何，受到鼓舞等等），但当使用这些状态机模板进行批量通配，再加手动微调（甚至塞点彩蛋，比如猫鼬斩和饭匙蛇一出来就吵架）就能实现这个效果。宝可梦游戏的开发也通常像是这样在和如何高效通配和手动按照设定构造差异化打交道。
当然也包括『朱·紫』中的一些受到好评的生态实现，比如与野生宝可梦以及NPC对战时的野外宝可梦观战行为，这些都是能够针对每一只明雷宝可梦进行批量配置的。
从而得到下面这个视频里的节目效果↓
另外，上一期里还有因为时间原因没把PPT中的俩视频做成动图放进来
这里在原版演讲中演示了皮卡丘视线跟随的动图，但CEDEC官网上下到的版本里删掉了，这里顺带也补充一下。而在这里前泽特意提到是在完成了全部宝可梦骨骼部位的标准化命名后，一些反向动力学的配置也会变得容易，同时也能实现宝可梦在倾斜面上模型站立处理的视线系统。
视线在LA中的应用表现为野生宝可梦的警戒值计算，呈现攻击性时目光对主角的锁定→在进入战斗时目光再切向主角的宝可梦，比较经典的便是当主角面对头目宝可梦被击倒一只宝可梦时换人前会将目光切回主角，于是就有了这个名场面。
当然前文所提到的连续放出多只宝可梦的“队内沟通”当然也需要用到这一点，不然说话都不看着对方会非常的尬。
朱紫中虽然没有了“队内沟通”和野生宝可梦对玩家呈现攻击性时的眼神锁定，但依然大量用到了这个机制，比如野生宝可梦的观战（下面这个视频是完美的体现）以及本作新增的自拍系统，也需要让宝可梦能看着镜头，有时野生宝可梦也会对镜头有反应。
看了下字数标记，写到这里就有4000字了，作为一篇日常文章即便在这里完结应该也很正常。不过对于本文来说，仅仅是完成了对上篇文章的补充，写本文的历程也如同是帕底亚地区的“寻宝”，翻译转述一篇演讲本身作为主线不免显得千篇一律，但能藉由这些内容结合我对近世代Game Freak开发体制的认识和理解，或许能让其成为只属于我自己的宝物。现在还只是出了桌台市，兜兜转转完成了第一条主线，还有两条主线没动呢！
第二章——焕然一新的图形资源库
在这一节，演讲者主要介绍的是在全新的模型制作体制下，Game Freak是如何利用这批共通的图形素材去完成两款画风不同的作品开发，他首先回顾的是关于剑盾时期的宝可梦模型开发机制，不过2017年发售的那一期CG WORLD里正好也介绍了点日月时期的开发体制，我就在这里顺带提一下：
如图所示的便是日月时期的新宝可梦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）
而到了剑盾时期，由于吸取了首次高清化开发（LGPE）的经验，Game Freak采用的方法是尽可能的在Maya中完成3DCG的制作来提升效率，于是他们在Maya的ShaderFX中开发了一个能够和NS实机表现相近的着色器，继续采用在3DS时期创建的本家模型格式——GFBMDL。采用ShaderFX可能是出于系列首次面临算上测试和本地化人员数量超过1000人的大规模外包制作的情形，宝可梦模型和动作的开发也不再局限于三家之间，同时地图规模扩大也需要外包出去一部分，而Maya在外包公司的普及度较高，只需要在其中的ShaderFX里添加“移植”的能呈现作品实机表现效果的着色器，就无需把整个内部开发的引擎发给外包公司，同时也能直接预览每个参数和管线节点的效果，对外包组的开发者来说比较友好。
“ShaderFX在工作中属于偶尔用到的东西，毕竟不能把内部shader和引擎（或者自定义部分）都给外包但是外包但是外包又是需要预览最终效果的。这个时候shaderFX就可以拿来凑乎用用。”
摘自↓
https://zhuanlan.zhihu.com/p/416850516
不过其中面临的新问题在于，正统作开发规模加上高清化后开发的材料文件数量开始了爆发式增长。同时，在Shader FX中使用的材料都需要保存成Maya中的二进制文件，通过读取这些二进制文件从而才能预览效果，随着开发的图像逐渐复杂化，制作组对于这套制作体制的后续维护难度会很高，毕竟能够进行维护的开发人员数量是有限的，于是在完成了剑盾本体开发之后，Game Freak就着手在这套模型效果预览机制上进行改革。或许这也是为何他们没有推出一款剑盾风格的DP复刻。这是因为在全社步入下一代高清化的开发体制下仍采用旧有的体制去复刻作品的效率并不显得会高，同时采用原先技术的团队也无法在完工后无缝衔接到另一个团队中，由此看LA这样的作品的出现是开发体制改革和玩法思路革新双重作用下的必然结果。
关于什么是管线（上右图）：
视频：
【【游戏开发基础知识】什么是渲染管线？如何绘制3D物体？】 https://www.bilibili.com/video/BV1qY4y1V79z/?share_source=copy_web&vd_source=e86e856b2f3fe6014d8a042bef593a12
文字：
实时渲染管线:（一）基本概念与发展简史 - 木头骨头石头的文章 - 知乎 https://zhuanlan.zhihu.com/p/440584180
大致就是如何编排CPU去分发图形计算的任务为GPU去高效地完成拟定的实时渲染。
针对二进制文件的调用繁复，管线错综复杂导致维护成本较高等问题所推出的新开发环境不再必要将材质在MAYA中制作完成后转换为二进制文件再传递到引擎中运行，而是将材质源文件直接存在运行环境中调用，在MAYA保留一个索引的文件名，从而实现在运行时实时对材质的参数进行调整&数据处理的开发模式。
顺带补充一下，「剑·盾」中对于宝可梦3DCG数据的标准是，模型15000个面数，150个关节，16份材质等。贴图的长宽各是过去的两倍，最大纹理尺寸是1K。
*主要角色拥有10000个面数对于一款NS游戏来说肯定是绰绰有余，因此宝可梦模型一般来说不需要大改，由XY世代修修补补延续至今，在随乐拍和LA中首次大规模引入了完整的眼球和嘴部建模来表现宝可梦的面部。前文里也提到了在朱紫中重做了超梦和喷火龙的模型，一般需要每作重新制作的是针对于不同运行环境渲染效果的贴图以及关节骨骼和配套的动作。剑盾时期被批驳较多的“模型复用”问题实则并不紧要，宝可梦的建模本身一直没有太大的问题，发售前的PV和实机表现更多暴露出的是制作组对贴图和模型动画的精力分配不足。（本段提到的内容均为剑盾世代语境）
以及社群在这几作中比较关心的描边问题，事实上剑盾里也是存在描边的。制作组在CG WORLD刊发的采访中特意提到了这一点。在3DS中的描边由于机能限制只能将描边处理成黑色的，而在NS上则可以“因地制宜”地选择描边的颜色。开发组的处理是将描边的颜色设置为相较宝可梦本身轮廓更深的颜色，从而将宝可梦本身从背景中凸显出来。而这个处理最早的想法也是源自将极巨化的宝可梦边缘处理成红色的。并且如果在高清的大地图上较远的位置用黑色描边渲染一只小宝可梦，本身也会让画面变得很杂乱，同时由于高清化后描边的厚度被加到了2个像素，一般的处理会是根据距离来调整描边的大小，但用了加深描边的处理后只需根据距离来淡化描边深度即可。
回到Fig.48中的内容，在解决了剑盾中模型的实机效果的预览&调试繁复&后续维护成本较高的问题后，新世代的模型开发环境在此基础上增加了可以用一份初始交付品素材构建两种截然不同的渲染效果的作用。由于这样得以用同一份素材针对不同作品定制一份后期处理的规格，也有利于将外包制作的交付品规格和本地运行中所要达到的效果分离开来，由此也无须每次针对作品的概念设定去外包制作新的素材。
以下会以阿尔宙斯中的场景和开发要点为纲，以演示新开发模式的效果。（以图片展示为主）Fig.53中所展示便是LA在选用不同开发阶段的管线所达到的画面效果，①阶为只有贴图本身色彩的画面，②为附加全局光照后的画面，③为增加画面的层次感后的表现，④为增加了一系列调色和微差调整后的画面，也即是最终想要传达的效果。
演讲里有一个比较有意思的细节是，前泽圭一对皮卡丘的称呼是“ピカチュウさん”（皮卡丘先生），有种称呼自己同事的感觉。
如果需要针对不同作品的观感对同一份交付品的色彩数值设置进行调整，可以在后期处理的管线中添加“掩膜”，从而批量对色彩表现方面的数值进行修正，虽然纹理参数还是需要一对一的上手调整。同时，也引入了对画面中的物体进行分类，从而检测各个元素在渲染中针对硬件负载的情况，从而直观地去删减画面中不必要的渲染处理，减少了游戏运行时的负载压力。
在原有交付品的基础上对部分宝可梦添加一些特有的纹理贴图来追加其“符合生物性/设定”的质感，契合作品的视觉主题。同时，在交付品检查后依然会存在一些bug，比如粗糙度以及法线贴图错误，会在进一步微调中及时发现出来。
对于三蜜蜂的蜂蜡质感，就可以采用这种半透明的材质效果，其表面半透明，背部不透明。
虽然像鬼斯这样的烟雾质感在LA实机中的观感似乎变拉了，但多了一些边缘随机烟雾飘散的效果，以及烟雾的半透明质感，总体在真实化的方向上迈进。
以及演讲中没有提到的LA的一些模型提升（复眼，金属光泽,植物纤维，鱼类鳞片）
这类建模上的技术改进虽然能用旧世代宝可梦和前作ver对比中有所体现，不过还有一种对模型观感提升的判断方法是去观察全新加入的宝可梦的实机效果，就比如下图中的洗翠风速狗。
采用版画画面中的元素关系，对背景中的物体根据深度和高度进行雾化处理。人物也增加了对应的纹理进行版画风格化的表现。
虽然没有做得尽善尽美，但确实也还原了一些版画中“富有透明感的”水体，在蝦夷风俗志中翻到了这张「小樽ゼニバコ 魟魚の奇異」可以作为参考。
对这个概念处理得最好的就是群青海岸，从图库里精选了几张能够在不同天气和时间展示上文提到的这几个画面调整概念。虽然也总从中能分辨出一些不尽人意的地方，但从开发的角度来说，Game Freak在登陆NS以来的五部宝可梦作品（算上方可梦的话）采用了五种不同的美术风格进行开发本身也是一种创举，对于每部作品独有的美术风格表达欲的旺盛也在不言而喻地破除“摆烂”的评价。
色调补正中主要调整了YCbCr+对比度+Gamma，过滤器中主要泛光+DOF（景深效果）+色差+虚光效果+径向模糊。
虚光效果 UNREAL,（在蹲入草丛中时，镜头边缘会出现的变暗效果）
Radiant blur（径向模糊，常见于赛车游戏加速时对周边景物的模糊，LA中对宝可梦战斗的加载就用到了这个效果）
补充资料：
https://juejin.cn/post/7090102807298048037
由此，在场景层面，凭借诸多新旧技术的引入，LA的画面逐步还原了概念设定中想要表达的效果，同时也为了适配动作玩法的稳定性做出了取舍。这些操作其实也是Game Freak一贯的开发思路的体现，即“在仕样规划上试图达到新效果时才会对应地引入新技术，而不是针对一个新技术的出现去制作对应的场景和玩法。” 好处是Game Freak的作品一般都能达到制作组整体想要传达的效果，因为如今的游戏行业的技术发展已经相当成熟，总能找到适合自己团队和开发周期的解决方案，并不会把自己的作品当成背后厂商的肌肉展示舞台，哪里的画面表现力做不好就是丢了厂商和玩家的面子，从而在某个技术节点无法推行时举步维艰。而坏处自然是所掌握的技术很多时候是现学现卖，一旦开发规模和工期冲突性较大，就容易出现某处突然又拉胯了的表现。
回到演讲内容中最后关于画面表现的解说部分，这两部并行开发的作品采用了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在原定的渲染效果基础下扩展了管线，并在后期处理的过程中增加了额外的纹理质感。
在宝可梦模型表现方面，阿尔宙斯偏重的是色彩相对鲜丽的版画感，朱紫主要体现的是“写实感”，使得不怼脸看时很难触及这些改进点。
官方的一张朱紫主题曲交响乐演奏招募的宣传海报上也有同样渲染效果的御三家展示，这张图就能看清朱紫中所用贴图的一些写实细节。
当然，以上的解说仅仅是针对朱紫所用的技术的介绍（并没有表示过这些技术本身所谓的高低），如果想在Game Freak的技术演讲会上看到顶尖技术的展示来让脑内对于“Game Freak技术力极低”的印象扭转过来的话，确实是想多了。重点是在于了解这份开发体制所给宝可梦系列未来发展带来的潜力，不同玩法，不同画风的宝可梦可以接连从这个体制中孕育，制作组也并非总是薅着原本的素材和玩法体系毫无改进，而是积极进取地为不同的作品吸纳不同的开发技术。同时，在面对年货化的开发要求，将一条清晰的发展路线上逐步推出的宝可梦作品附以画面和玩法迭代的差异化避免让系列玩家陷入疲劳。这些差异化对应关系有如，LGPE（旧作，新玩法，三头身卡通画风），剑盾（正统新作，传统玩法＋LGPE明雷加强版，标准四头身英伦风），BDSP（旧作，传统玩法+部分LGPE明雷，标准二头卡通风），LA（新瓶装旧酒，完全新设定和玩法，版画画风四头身），朱紫（正统新作，传统玩法+开放世界，四头身写实画风）。
这恐怕是一个厂商在迈入高清化开发+应对年货化开发最好的态度。由此认识到了这一点，本文也在写作中途增减过多次，从原本的演讲解说逐渐变成了对宝可梦系列在2022年迈出的这两大步背后的成因和细节的挖掘整合。
补充一个冷门谣言的辟谣：酷丽恰姿撤退事件
19年12月曾经出现过一条新闻，是指Game Freak在更新官网后将Creatures从主要合作对象中删去了。当时引发了一些股权变动的传言，但现在这个传言过去了三年还没发生自然是不攻自破了。但删去这件事的原因实际上还是能从本文中找到答案的。因为在剑盾开发完成后，Game Freak的宝可梦模型开发体制有了重大的变革，Creatures也不再是唯一经手模型部分的外包商。从日月时期的三家合作建模体制转变为了更为灵活高效的外包体制。不过Creatures依然是宝可梦模型方面的主要负责人，这一点在历代的Staff表中都能找到，宝可梦建模组的美术总监一直是Creatures的氏家淳子 、产品经理也一直是Creatures的匡道穴澤。
回到演讲内容，由于演讲发布于今年8月份，此时朱紫情报公开并不多，因此并没有太多内容进行解说，下面介绍的太晶化则是第二章节的最后一部分。
虽然前泽没有提及，但细想一下可以发现，相比于极巨化的模型放大，描边改为红色，新增能量体样式的贴图以及极巨招式动画适配。太晶化进化成了每只宝可梦可以适配18属性的太晶化贴图材质，属性王冠的摆放位置。
以及最重要的太晶化，能够让每只宝可梦从极巨化系统中的单一形象适配（上文提到的材质和描边变化），进化到每只宝可梦适配18属性的太晶化贴图材质，属性王冠摆放定位。没有签证的宝导入后就会面临一些贴图错误和王冠位置错位的问题。从Fig.82中也能发现太晶化后的宝可梦其实是能够透过身后的背景，其本身的纹理也同时存在，这一处理方法应该在之后的开发里会有一些妙用。
第二章节部分完结撒花！ 说实话演讲部分的转译在发售前就基本完成了，但发售前出现了一些优化层面的风波。虽然本文只是在开发体制上进行挖掘，涉及的内容也大多是建模和渲染，不过我认为还是得藉此机会写一点能够解释现状的内容&对两部作品表现更详尽的考察。本文发布的时间已是2022年12月7日，恰逢1.1.0补丁更新，修复了一些常见的Bug以及帧数问题。
在发售后一周左右完成这些内容的修复显然是在发售前以及初期就在高度留意是否会有Bug和帧数问题出现。类似的操作BDSP也干过，11.11（发售前）发布了1.1.0补丁，发售日前夕也发布了1.1.1补丁。
而后就一路修修补补到了十二月底（当然还没修完），到了二月底HOME开放前才完成了复制bug的填补。这意味着两件事，其一是对这类玩法作品的开发模式还不够熟悉，就如同ILCA并不熟悉传统宝可梦的Bug触发规律，负责朱紫开发的一组也并不熟悉开放大地图和任意流程模式下可能发生漏洞的注意点（这一点确实需要经验才能做得好）；其二便是从PV完成度能看出的地狱工期所造成的赶鸭子上架，这一点和BDSP也是类似的，显然ILCA在开发后期不光是要面对海量的Bug，还得把先前惨不忍睹的画面提升至合理的水平，双重夹击下造成了这个问题。
而对于朱紫来说，画面的优化自然是一个重要方面，但也需要首先保证开放世界的内容量，用心策划的终盘剧情的演出效果等等，正统续作所代表的全新要素内容加上开放世界需要的进一步内容和细节填补，这便让开发人员在开发的最后冲刺阶段陷入取舍困境。而这一次或许是吸取了剑盾的教训，最终保留了终盘内容体验的完整性，也保全了制作组一直以来被忽视的野心。所以其实画面上的问题，虽然看起来比较不堪，但能像现在这样后续能补救的话，可能已经是当前开发状况下对玩家来说最好的结果了。
不过又话说回来，谁又能保证内容量上被取舍的部分不在少数呢，开发人员即便有足够的工期，最初企划中能够实现的内容也不会太多，在画面问题暴露的背后自然也暗示着有更多内容层面的工作被迫砍掉，因此主要矛盾还是回到了工期问题。或许下个三年，在Game Freak熟悉了这套模式后，我们能玩到一款画面不错，优化良好的，朱紫级别的开放世界宝可梦，但要更进一步，且不论满足玩家对于开放世界宝可梦的幻想，单论复制这三年Game Freak进步跨度的作品，亦或是迈向新的平台进行更加高性能的开发，三年的工期必然还是不够的。开发规模的扩大并不能通过人力的线性增加来解决，当然也需要时间的沉淀，从各个3A大作越来越难产的现象也可见一斑，包括我自己写文章也经常因为想要写完自己素材库里准备的内容延期一两月甚至大半年，如果为了抢时间发布也顶多写点流水账的PV分析文。之前翻译Lewtwo老哥的那条朱紫PV1分析视频的时候其实就是觉得他用视频的形式表达出了我对朱紫开发周期的担忧，最近回顾也是感慨万千（也包括他做BDSP视频做了一年多还没发）。
视频↓
（原文此处为视频，存档未收录）
当然，上文提到朱紫Bug体现的俩问题：对开发模式的不熟悉&工期问题并不能回应一些制作水平上的粗糙以及玩法设计上的不成熟。而这个问题则出自Game Freak的一个神奇的特性：新人招进来培训三月后就会直接进宝可梦项目组干活，同时新人的工作成果也会被直接保留入最终成品，好处是确实会给新人压力，鞭策其快速成长，而坏的一面自然是许多“自学三年动画”水平的制作也会混入其中（当然人家可能真的没学到几年）。
Game Freak对于新人的采用态度比较独特，官网上的大森访谈里也提到了他自己在25岁就担任了DP的游戏设计组组长（Game Design Leader），负责了剧情脚本 （Plot Scenario）和地图设计（Map Designer），招聘页面也着重写了重用新人。团队领导年轻化使得宝可梦系列的新点子层出不穷，选用的人设，音乐品味也从来赶在时代前沿，不过也对应的是设计细节上的决策经验，非重兵把守的项目（比如程序和3D美术）在打一枪换一炮的年货压力下表现并不稳定，而这一次的UI设计的拉胯和剧情的爆发也是其中好坏参半的写照。由于年货化项目数量奇多，新人得到的锻炼机会也大增，如此锤炼出的团队开始逐渐适应了高清化，甚至并行开发的模式，但其中好坏参半的表现，也正应了Game Freak这个社名，Freak所代表的“怪胎”，“怪杰”的含义。
第三章——针对动画数量的一些方案
最后来到演讲的最后一节——针对动画数量的一些方案，由于本文中我个人补充的部分在上一节已经基本完成，这一节会比较快地介绍完。
与上文提到的3D化后宝可梦的贴图材质数量暴增类似，每一个宝可梦新作的动画制作也到了需要压制臃肿的开发成本的情况。尤其到了开放世界，需要体现宝可梦明雷生态的场合，朱紫登场的图鉴位达到了400，模型位超过了600，因此每只宝可梦再增加几个，十几个动作都会面临成千上万的工作量，以及新宝可梦需要适配原有宝可梦的动作数量规格。单纯用外包也无法解决这一棘手的开发情况，自然也呼吁着新开发方针的出现。
其中一个方案是观察宝可梦模型库中存在的那些体型相似的宝可梦，比如腕力和路卡利欧同属双足兽型，叶伊布和伦琴猫同属四足兽型。宝可梦体型这一点虽然在图鉴中仅仅是微不足道的一笔，但对于开发者来说却是一个粗分类的好凭据。
因此，即便无法照搬使用（XY时期宝可梦动作开发的原则是不动作复用，保证每一只宝可梦都是独特的。当然人物除外，指赫普和哈乌），但如果能以相同的动作作为基础进行调整，也能够降低动画素材制作的时间&预算成本。如图所示的腕力和路卡在体型相近的情况下就能直接复用某一个动画（游戏中并没有复用）。
开发组内部会根据宝可梦的体型制作一个体型分类表格，并将来自剑盾的新宝可梦也加入其中，采用了同样的模式开发宝可梦的每一个新动作，同时制作组内部也有一个能将骨骼和体型相近的两只宝可梦之间的动作直接复制过去的开发工具，最直接的应用就是将旧世代宝可梦的模型动画在更换开发环境后直接复制过去，实现跨世代动画迁移。
与此同时，2022年发售的两作宝可梦都实装了宝可梦尺寸差异的系统，于是这一点也有针对性地做了开发，可以实现比例缩放后的动画复制，避免不同尺寸的宝可梦出现动作不一致的情况。同时在骨骼构造有细微差异时，比如腕力比路卡少了一个节点，也能重新对应起来进行定位，这也同样是上篇文章中提到的模型规格共通化的优势。基于IK（反向动力学）的动画是针对模型身体的每一个部位进行转换的，比如手臂对应手臂，腿部对应腿部。对于有双足和四足模型的腿部，在处理的过程中会使用基于Human IK（人体反向动力学）的转换。
而说到宝可梦尺寸差异，在逛4chan正好看到一位老哥做了一些图片对比的总结
原帖：https://archive.alice.al/vp/thread/52528260/#q52528260
回到IK动画
IK动画可以通过安置末端受动器，反向调整整个骨骼的体系姿态。
比如，要让角色行走在凹凸不平的路面上，可以通过确定角色脚与地面的接触位置、旋转，自动计算身体其他部位的姿势，通过改便每一步的步幅与地面接触位置，就可以实现角色在不平路面的行走动画。
接着来看几个例子：
（原文此处为视频，存档未收录）
这就类似上文提到的状态机模板，相似类型的宝可梦能够有更便捷的方式进行适配开发，但同时也能观察到无论是旧作宝可梦之间还是与朱紫新登场的宝可梦相比，各个宝可梦生态动作的差异性并没有缩小，新宝的动作和设定并没有因为这些便捷开发模式的出现与旧宝同质化，一定程度反应了制作组在使用这些功能的同时也心有余悸，做出每只宝可梦的特色依然是第一要务。
大约是在一年前，Game Freak在自己的办公室里也做了一间动捕房间（之前都是外包的），里面有24个光学摄像头。同时这一次则是将不同动捕的数据（Vicon和MVN）和宝可梦模型的骨骼进行了打通，从而可以实时预览宝可梦对应动捕动作时的表现，不过还没有完全导入正统作品的开发，或许之后的过程会有某只神兽or御三家活灵活现的身影。
（原文此处为视频，存档未收录）
在缓解了模型动作制作的压力后，除此之外还面临的挑战在于业界擅长建模和动画制作的公司和人员都比较充足，但对于骨骼绑定这一工作来说却相对稀少。由此在Game Freak内部提出了一种叫做『ポケリグ』的解决方案，也就是将宝可梦模型的各个部分的骨骼进一步特制化，拆解成模块，就如同将将雕刻的难度转换成了拼高达模型，每次只需要按照说明书拼一个版块，将骨骼绑定的工作变得相对容易起来，从而解决了骨骼绑定师人员不足的问题，同时标准化后也扩大了这一工作的适用范围，每个人建模和动画师都能随手做&调整一部分。
对于正向动力学的控制，可以采用基本控制模块Fig.109对宝可梦模型进行绑定和标记，从而实现Fig.109中铁甲犀兽身体各个部位的绑定效果。
而对于IK（反向动力学），实现控制，以及一些控制宝可梦微差动作表情变化的滑块，也可以用同样的方式去实现（在对应部位绑定一个控制模块，从而在运行界面上调试其调整效果）
同时尾部的样条线IK也能用于蛇形宝可梦的定位的骨骼控制。Fig.112演示了蛇形宝可梦使用该功能后进行空间“曲线运动”的案例，其中上文提到的『动作拷贝』工具也是Poke Rig的一部分。
（原文此处为视频，存档未收录）
在运行界面中实时开闭脊柱模拟的效果，各个节点随着头部的运动去计算下一帧所伴随运动出现的位置，从而实现阿伯蛇的蛇形移动。
（原文此处为视频，存档未收录）
以及非蛇形的情况下出现的一些骨骼伴随动作的模拟，视频中伦琴猫的头部动作明显更加自然，但同时在LA中也能感受到配合眼神跟随的机制，宝可梦点头的频率偏高也出现了对应不自然的观感，或许能在下一作中能看到对应的优化。
上文提到的，在引入反向动力学后，适配了一些在倾斜平面移动的初步能力，但同时也需要将宝可梦的移动姿态针对倾角的大小进行适配，故勒顿以及密勒顿的乘骑功能的开发就需要大量调整这一要素。
（原文此处为视频，存档未收录）
就此，演讲的正文部分到此结束。
因为有点长，就来简要回顾一下演讲中三大主题，其一是上篇文章中提到的，实现并行开发的基础——外包交付品与规格要求的共通环境，使得一份材质资源可以经过后期处理同时为两份作品服务，同时这两份作品的差异也能拉开得足够大；
其二便是在此基础上各制作组进行差异化开发，针对企划的美术概念指导，以及游戏机制设计上的目标进行创作开发，同时在引擎内独立开发了一些适用于宝可梦系列模型处理数据量的工具&功能，以做到将渲染效果上的微小调整快速布及全收录模型位的宝可梦；
以及其三，将骨骼绑定，模型动画制作数量这类老大难问题做针对性解决，在相似体型的宝可梦动画效果可迁移的情况下进一步做宝可梦之间的动作差异化。
而其中穿插了大量在考察过程中搜集得到的资料以及基于这些资料的分析，尝试继续在这个采访匮乏的年代里管中窥豹一番Game Freak近年来的开发状况（毕竟前两篇也是这么挺过来的），由此完成了这篇文章的撰写，也感谢各位读到这里。
结语：
不知道一直关注近年来宝可梦作品开发动向的读者有没有一种错觉，就是开发组Game Freak似乎并没有受到疫情的影响。在每部作品工作量激增的情况下，相比过去还没迈入高清化的世代产量不减反增。
其中一个原因自然是由于采取了这个长文系列着重挖掘的新模型开发体制，而另一个没有提到且至关重要的原因，则是Game Freak在疫情前就开始推行了居家办公的体制，在家办公的设备由公司出钱补贴，同时上下班制度也相对灵活，早上最晚十一点上班，工作满八小时下班。在CEDEC2022的另一个同期演讲中，研发部的运营管理组组长——立原 春木讲述了自己在剑盾时期尝试引进，在阿尔宙斯以及朱紫中完全引入的云端开发制度，能将渲染管线的布置投放到亚马逊的AWS云端服务。从而不仅在办公的物理位置上解放了制作组，并且云端集中的高性能设备也使得开发时的响应等待时间以及构建时间大幅缩减，总体大约缩减到了原本的三分之一，其中管线的延迟时间能够缩减90%。以及由于云端设备的配置基本一致，对于设备的维护成本也大幅降低（本地不同时期配置的主机和服务器的配置都会有点不同），由此可以使用Ansible进行自动化更新配置，从而在多个项目中通用各类资源。
因此，Game Freak对于年货化&高清化后宝可梦三年一世代的开发这一难题其实确实做了充足的准备，同时也提早布局云端化抗住了疫情的大部分冲击，在其余大作普遍难产和延期的情况下依然能够保持着高效开发。很难想象2017年还在开发掌机+回合制作品的厂商能在年货化的压力下于5年后接连走过了动作游戏&开放世界这两大难关（虽然能看出来这两部作品这个系列在这两个游戏门类中呈现的初步形态）。遗憾固然有，开发时间依旧紧缩带来的优化问题造成了大规模的负面体验，不过我想系列玩家在游玩这两款作品后更看到的是一个极速成长的开发组，目前出现的问题也都是能用稍许更多的时间和经验去解决的（甚至一些改进中LA里已经实现了）。
而时间能够解决不只是画面和优化，也能让制作组将现有的技术和想法沉淀起来，新的开发体制和技术引入仅仅让Game Freak原本的奇思妙想得到部分解放，就完成了剑·盾到阿尔宙斯&朱·紫的跨越。剑·盾时期的大量呼声（地图，剧情，宝可梦生态等）都在朱·紫和阿尔宙斯中得到实现，能看得出来他们确实很关注玩家群体的声音，只是需要时间去在下一作实现，或者说当前作中确实因为当时技术不足和开发时间紧缩搁置了这部分内容。比如备受诟病的剑·盾本体的旷野地带地图，由于剑·盾的明雷是在LGPE试验后才决定加入的，很难说他们能多少时间去设计这张以明雷宝可梦为卖点的地图，而当时制作组转移精力去做明雷地图和宝可梦分布后，道馆战后期流程的开发不足似乎又导致了游戏流程后期剧情表现的不足。社群所期待的旷野之息式，荒野大镖客式宝可梦也必然少不了对等时间的投入，虽然依我看在现行的发行体系下还是难以实现，但要说一款富有惊喜，少有遗憾的宝可梦作品应该已经近在咫尺了，毕竟坐在Game Freak办公室里的开发者并不是玩家的敌人，而是同为宝可梦爱好者，在这套年货发行体制下挣扎向前的人们。
（FIN）
本文原发布于微博头条文章（专栏：宝可梦友会），2022-12-07。图片已转存；文中引用的微博保留为引用块，视频未收录。微博原文 · 更多随手发的碎片 →
Link Context