前言：
本文主要是个人利用一次周末时间，针对一场2019 GDC talk的导读，完成后有不少朋友向我伸手索要，平日也没什么灌水的地方，在知乎上随便发一下。看有许多人在GDC游记里提过这个Talk，群众基础大概有了顺带安利一下,育碧在GDC上有很多非常棒的Gameplay方案的Talk，油管频道里已经公开的比如Houdini地编三部曲,IK三部曲。
这次Talk的主讲人是育碧魁北克的一个程序员兼项目领导，主要内容是介绍他们花了21人年制作推广并且在刺客信条奥德赛落地实装的自动化生产对白动画的工作流。
他们的工作内容和CDPR在GDC2015上的关于巫师3对白动画工具链的Talk上讲到的内容有点关系，但CDPR的Talk主要是罗列自己在项目上制作的各种功能方案，对于有志加入血汗工厂的人而言能获益更多，这场Talk主要是讲如何从一个特定的切入角度出发,设计程序方案代替人力工作，并最后付诸落地的介绍。
正文：
首先,官宣ACOdyssey的文本数据,1200场对白场景,30小时演出时长,25000行对白文本。
提出高效制作内容的三种可选思路，模块化，过程化，自动化。
项目分工
- 任务设计团队，
- 剧情撰写团队，有些项目里是策划担任的，在这次分工里有点小制作人的意思
- 动画设计团队，从头到尾跟进，包含动作，摄像和游戏策划
- 自动化系统，这次talk的主题，由他们项目组引入的工作流
程序化生成的优势，稳定性高，用已有的资源催生灵感，有工具链，内容数量有保障。
工具展示，对白内容分支可视化工具，时间轴可视化工具，游戏画面是P上去的，可能是分屏也可能是演示；每次按下“魔法按钮”重新生成,轨道结构和内容都会变化。
生产流程问题，生成器控制不了很多细节，比如角色走一圈，一开始对Write的需求没有限制，导致所有动画都要重新修改一遍。后面优化成分类制作的模式（一口吃不成胖子，罗马城墙要慢慢推到）
官宣分级化的生产结果，完全自动化-20%，不新增资源-70%，额外资源需求-9%，完全定制-1%。
以上是一批比较宏观的内容，从中可以一窥几乎每个项目都会遇到的关于人员协作和工作流规划的参考，20%的数字看似不高，但伺时找到自动化的切入点，改善工作流，并最后给出了数据可观的工作成果，已是不易。许多项目刚迈出方案协作的第一步就被打死了，技术落地和技术调整更是无从谈起。
生成器的输入，对话内容文字，说话的人，情绪标签，说话对象，音频
总结对白内容，角色，对白，动作，相机，灯光（环境）
舞台的概念，确定人物的位置，创建出所有可能的相机位置，人物站位的方式有很多，相同的人数也可以有不同的站位方式,但可枚举。
相机仓库，人越多镜头就越多（如果用参数镜头描述其实就是几个维度的参数的排列组合）
直观口语描述镜头，三个方向，标准（微斜），侧身，越肩；由近到远五种距离（这里并没有用摄像术语,简单描述几个分类而已）
程序化镜头，镜头全是100%程序化生成的（主要是程序算出镜头位置的意思）
解释镜头计算原则，保持人物头部在屏幕空间的位置，人有高矮之分，镜头有俯仰之别，用程序计算都是一套参数方案。
三种不同的镜头跟随方式（在Unity里可以尝试用Cinemachine的方案）
时间跨度上的镜头生成规则，谁说话给谁镜头，从3*4-5个选项中根据规则打分选择一个高分镜头；这些规则包含前后镜头关系（比如三镜头法，正反打一类的），有表情给特写有动作给中景以上镜头，多人场景保证说话的人都在镜头里，等。
时间维度上增加细节保持对话场景的生动，比如切开过长的镜头，合并过短的镜头，镜头提前或滞后。
动作，根据情绪标签，分析文本词汇，从动作库里选择合适的动作；事先给动作标记好动作幅度阈值和峰值，根据这部分数据融合动画，（每个动画切分播放特写画面里容易动画断裂,从头到尾播完段落感太强）
这部分内容涉及到了业务内容的核心，从制作人员一定会提供的三个重点输入（对话,人,音频）；仅在语义上增加对象和情绪两个输入，就直接根据业务标准（当然要做好预期管理）完成大面积的工作内容。这其中，生成结果的预期管理，构建足够舞台和相机数据,准备充足并规划标记处理的动作库，是大多数项目都无法做到的。但如果降低要求，只是从手K镜头和程序大特写过度到程序正反打镜头，只是从idle变成偶尔播放情绪动画，派出一两个程序员熟悉业务功能后折腾下效果，还是能负担得起的.至于更多周边系统和细节,看个人能力量力而为。
周边系统
口型匹配方案，播片里每个角色持着各国语言秀自动口型，Ref 2006GDC的Talk
LookAt系统，规则很简单，没说话的看向说话的，说话的看向对话目标(输入里填)或者上一次说话的人；子系统单独用来控制角色眼球制造人物情绪。
补光,介绍里只有一盏镜头方向附近的面光，没有补光和轮廓光，强度会根据环境发生变化，（可能他们的景深足够突出角色,在光照上省了功夫）
排除npc干扰，（好像是用navmesh禁区做的,在巫师的动画talk里也提到类似的方案）
适配双主角的对白长度差异（大概是生成两遍）
以上内容就是这场方案里公开的全部技术细节，以前有个同事如此评价育碧，他们的所有方案我们都能想到，但后面添加的细节和为之付出的人力时间，把他们的每个方案拔到大多数公司都不可企及的高度上，我深以为然,而且，育碧在每次talk中表现出的关于方案发展和项目管理的思辨，也是十分充饥的精神食量。
流程和测试，生成方案已经定了，但内容
的问题就摆上台前，对此，他们方案组提供了三个解决思路：
“如果和美术说有个机器人每天晚上都在改你们的场景，美术肯定高兴不起来，所以这件事情要很小心处理”
- 需要持续稳定的展示效果
- 让美术配合调整自动化效果
- 让美术也有完全控制力
- 对于一些问题需要耐心解释是场景问题而不是自动化系统的问题
从美术角度思考流程，生成器这种东西从美术角度看是很不一样的：
- 需要展示给他们看结果，让他们满意
- 需要在很大层面上设计规则去满足他们
- 需要让Writer明确知道系统能做什么不能做什么，因为他们是设计的瓶颈
得到使用者的信任
- 方案的目标是如何更”聪明”的制作内容
- 很多项目推出了新方案但是觉得不值得做工具，或者觉得值得,然后让一个工具组去做。“你知道这个系统这个用户，所以你应该自己写好这个工具”
- 我们是从头到尾跟下了所有工作吹了下育碧之前的一些自动化
- 自动化不意味着不需要美术，我们需要美术确认规则，指导效果，这部分很困难（一些安抚美术的话术...自动化不意味着不需要美术）
找到自动化方案的切入点
- 现在有很多工作都能被总结，有很多工作都有自动化的切入角度
- 后面可能结合机器学习生成动画，运动路径之类的
- 方案的出发点是生产内容
结尾鸡汤
- 稳定自动化能让人物设计团队耕作进入流程，迭代工作
- Writer能更快在游戏里看到效果
- 能让制作人更快更简单就能看到任务的叙事结构
- 我们会持续完善这些系统，希望你们也能有所启发，在项目里使用这种思路制作方案
QA环节
整场Talk加上QA环节几个关键性的问题，基本向我们展示了这个项目的轮廓。因为只是导读不是翻译，有些字词夹带着个人私货。如果你曾经在跨职能分工协作上有过经历和思考，或者曾经尝试过推广渲染或Gameplay技术框架，相信这个Talk分享的项目经验,能够成为不错的范本。
官网详情：
https://gdcvault.com/play/1026381/Procedural-Generation-of-Cinematic-Dialogues
作者：陈祥男
专栏地址：https://zhuanlan.zhihu.com/p/75046600
Steam 
App Store 
闽公网安备 35020302034348号