看完这篇晦涩长文,你们这个疯狂烧钱的美术环节能少走5年弯路!
引子
笔者在北美游戏业快十八年了,主要的经历有三块儿。
1. AAA游戏过场动画领域的经验,参与过Red Faction(红色派系)系列、Saints Row(黑道圣徒)系列的完整研发,这些项目多为开放世界游戏,负责构建Real time in-game cinematic pipeline和制作具体的过场动画。最新项目是《Saints Row 5》,可惜受疫情影响估计要2022年才能在次世代平台发售了,不能多说。
2. 跟我哥有一个专注于美术服务的公司,以乙方身份跟几乎所有欧美大厂都合作过,过去十几年经手的项目从AAA游戏到爆款手游,光是Marvel的复联项目就有5、6款,主要负责合作流程、项目管理和艺术指导。
3. 近几年在主导自研游戏的Zing Games Inc.,作品登过App Store全球第一,也收获了若干业内奖项。最新作品《Zombie Rollerz: Pinball Heroes》去年12月在Apple Arcade独家首发,今年会上PC和主机平台。
从Indie小品到欧美大厂的AAA开放世界游戏,从内部团队的实际研发工作到外部顾问,从外包管理到美术指导,从甲方到乙方。不光是参与的项目数量不少,而且在这些项目中所处的身份也不同,这种多样性的经历,让我可以从不同的角度来分析游戏开发中的种种。
新年初始,几个国内做游戏研发的朋友,不约而同地问我关于游戏内过场动画的问题。从跟他们的聊天中,我明显体会到国内游戏研发公司从产品质量和研发流程上正飞速地向海外AAA公司靠拢。
而在这个飞速的过程中,速度过快也成为一个问题,甚至可能是一个雷。因为人才数量、文化差异的问题,如何借鉴海外成熟AAA公司的经验和流程,可能会是国内制作人和研发管理层需要思考的问题。不过这个问题太大了,我也聊不了,这里主要是想聊聊跟游戏内过场动画相关的事情,也算帮朋友们整理下思路。
这篇文章会讨论使用引擎播放的过场动画(Real time in-game cutscene)的管线设计(Pipeline)和项目管理(Production)。为什么要聊管线设计和项目管理呢?原因有三。
首先,In-game cutscene(本文内名词会用英文,加中文翻译,有些我也不太确认国内研发的常用词汇,也请业内读者朋友指正)的重点是In-game。是用游戏引擎来实时播放的过场动画,而不是Pre-rendered cutscene(预渲染过场动画)。加上实时和引擎这两个要素之后,这一块算是AAA游戏开发中管理最复杂的内容之一,不光涉及开发组内各个部门的协同,也会涉及到外部团队,对项目管理者自身能力和经验的要求会比较高。
第二,很少人聊。正因为其复杂难聊,关于AAA游戏的In-game cutscene的各种讲座和资料为了吸引观众,都停留在有趣易读好看的层面,比如展示Storyboard(故事板或者分镜),讲讲Pre-visualization(预视化)和Animatic(动态分镜),秀秀有意思的Performance Capture(表演捕捉),或者具体讲解某一个技术方案,而不会真的企图为外人来梳理晦涩的Pipeline和Production上的坑。全局流程和管理层面的资料就更少了,AAA大厂很少真的分享。
第三,避免掉坑里的实用性。过去若干年,国内游戏研发的质量和流程在不断接近海外。比如海外美术外包工作的经验提升了游戏模型贴图的技术;引入商业引擎所提高了管线流程管理;大家对Tech Artist(技术美术)也愈发渴求。但是,因为In-game cutscene是一个又复杂又狂烧钱的领域,在之前国内游戏研发的环境下并非必须,国内厂商鲜有尝试,所以也很难有机会试错和积累经验。
友情提示,本文的阅读指数:
趣味性:1 / 5
易读性:3 / 5
实用性:5 / 5 (适用人群ONLY)
稀缺性:5 / 5
IN-GAME CINEMATIC PIPELINE(游戏引擎过场动画的管线设计)
Real time in-game cutscene,也可以称Real time in-engine cutscene,是指使用游戏引擎来制作在游戏过程中实时播放的过场动画。
你可能会问,为什么不用Pre-rendered(预渲染)的方式来制作过场动画呢?这样在游戏里直接播片,效果赶超好莱坞,团队也就不用考虑什么技术、管线这些头疼的事情啦。每个项目的想法当然都不同,但大体有几个关键原因:
玩家可自定义角色
希望实际游戏画面和过场动画的质量尽量保持一致
复用游戏内已有内容,尽可能节约成本
在玩家自定义角色普遍流行的当下,就算不捏脸,大多数游戏也提供了很多可穿戴的服饰和装备,所以Real time in-game cutscene越来越多的成为唯一的选择。当然,还有另外一个很明智的选择,就是不做过场动画……
先看一下In-game cinematic pipeline的workflow图,我故意做了个缩略图,不需要看清每个节点是什么,只需要感受一下即可。
毫无头绪?那就从头说起吧。
作为Cinematic模块的管理者,我们要回答几个关键问题:
- 我做什么
- 我需要什么
- 我产出什么
我做什么
我要做In-game cutscene,对的。那么In-game cutscene由哪些必须的内容(Asset,也常被称为资产)组成呢?
- 演员
- 道具
- 场景
- 镜头
- 灯光
- UI
- 特效(VFX)
- 音效
- 配乐
每个商业引擎或者自研引擎都应该支持这些独立元素,而你的部门要做的事情,是把这些内容组合在一起,形成一个真正的Cutscene。
而组合这些内容,往往都需要普通游戏研发所不需要的一些编辑器来支持,可以把这个统称为Cinematic Editor(过场动画编辑器),这是Cinematic Pipeline的中心枢纽。
我需要什么
首先你需要Script(剧本)。听上去这简直是废话,但是殊不知多少项目在剧本上耽误了宝贵时间导致后期赶工等一系列连锁效应。
如果把剧本比做一份图纸,那Cinematic pipeline就像是一个按照图纸来组装的工厂。既然是组装,你就需要各种零件。
其中,大多数零件来自研发团队其他部门所生产的内容(Asset),比如角色部门所负责的人物模型,场景部门负责的室内室外场景,道具部门负责的车辆和枪械等。这里就体现了In-game cutscene的一大优势:尽可能的复用游戏已有内容。
另外,也有很多内容或多或少需要外部公司的支持,比如演员的表演、动作捕捉、配音、配乐等等。
我产出什么
有了图纸,有了零件,工厂的组装车间也准备的差不多了,那产出什么呢?你可能会想,不就是导出过场动画,在游戏中播放么?没那么轻松,在不同的阶段,工厂的组装车间还需要产出不同的半成品。
Storyboard(故事板,也称为分镜)
Pre-Viz(预示化),或者直白一点称之为Animatic(动态分镜)
Mocap preparation asset(为动捕提供的各种文件)
最终过场动画
好了,我们现在对workflow有点整体概念了。
看起来还是比较清晰的,但我们还要再添加一个新的元素:人员。
人员构成
每个项目的研发预算和团队大小都不同,有很多工种的人员往往是兼任的。在这里会按照一个主机AAA开放世界游戏的配置来阐述。
CINEMATIC DIRECTOR
Cinematic Director(也会被称为Cinematic Lead, Cinematic Coordinator)不光要有影视相关的专业知识,更需要具有项目管理能力来承担类似Producer的职责,经验尤其重要。
CINEMATIC ARTIST
虽然项目大小不同,但Cinematic Artist起码也要2到4个才能满足一个AAA开放世界的基本体量需求。Cinematic Artist的核心能力是电影相关的专业知识,这涉及到很多综合能力,例如讲故事、镜头语言、剪接、表演、动画、灯光、后期等等。
在跟国内朋友聊天的时候我发现有一个挺大的认知误区,就是很多在国内做相关工作的人员实际上是 Animator(动画师)来顶替的,两者其实还是很不一样的。国内Cinematic Artist人才的缺乏跟电影领域的教育普及也有关。
TECH ARTIST
除了挂Cinematic名号的人员,还有一个工种的人员必须有,如果缺失,整条pipeline就根本转不起来,那就是现在哪里都缺的Tech Artist,而且还是对动画和影视有一定了解的Tech Artist。
Tech Artist是美术人员和程序人员之间的桥梁,很大部分的工作是将程序实现的各种功能变成可以被美术人员使用的工具。在Cinematic pipeline中Tech Artist的工作有两个部分:
游戏引擎中Cinematic Editor的搭建
将管线中所使用的各种专用软件(Maya、MotionBuilder、3dsMax等等) 接入到整体工作流程中
SUPPORT ROLES
还有一些人员,在很多项目中是共享的。当然如果项目预算足够,并且的确需要,也会专门在Cinematic team里面配置下面的工种。
- Cinematic Animator(影视动画师)
- Lighting Artist(灯光师)
- Effect Artist(特效师)
- Prop Artist(道具美术师)
根据上述,我们再更新下In-game cinematic pipeline的workflow图,这时候你会不会有站在高台俯瞰一座工厂流水线的感觉,稍微有点井井有条了呢?
现在工厂可以开工了?那你就错了,因为我们还有一个至关重要的要素没有加入,那就是 时间 。加入时间要素后,In-game cinematic pipeline和对应的Production schedule(生产计划)会让Producer千头万绪头疼不已,如果没有对应的经验,在时间和预算上掉大坑几乎是肯定的。
IN-GAME CINEMATIC PRODUCTION(游戏引擎过场动画的项目管理)
那么接下来,我们就加入时间这个重要因素,来聊一下Cinematic pipeline在项目不同阶段中的差异。
从In-game cutscene制作过程的角度来看,可以简单分为如下阶段:
- 剧本
- 故事板
- 动态分镜
- 动作捕捉
- 导入游戏
剧本
首先哦,其实剧本不属于Cinematic pipeline的范畴。
AAA的游戏剧本一般都需要在Creative Director引领下由多个编剧人员合作完成,形式上跟好莱坞剧本很相似。很多AAA团队也会请影视编剧过来一起完善剧本。
如果没有剧本,Cinematic相关的所有工作都无法进行。这个原理很简单。不过一旦放到实际的开发环境下,就没那么简单了。
举个我自己经历过的例子,《Red Faction Armageddon》。整个项目的研发周期大概在3年多,进入Production之后不到1年,游戏剧本在母公司介入的压力下推翻重写,硬是加入了整个系列都没有过的异形设定,导致研发将之前所做的所有工作内容都抛弃掉,造成巨大浪费,然后不得不将大量的过场动画外包为Pre-rendered形式了。
所以哦,各位Cinematic Director和Producer,剧本就算控制不了,也要苦谏老板,要不然最后吃不了兜着走……开个玩笑哦。
故事板
在编剧们努力写剧本的时候,Cinematic team往往会聚在一起做风格调研,换句话来说,就是狂看电影,然后思考和总结。最后,大家会形成一份过场动画电影风格指引文档,对过场动画中的镜头、节奏、技巧、表演等做一个方向性的规范。
在剧本完成之后,准确的说是被绿灯通过之后,Cinematic team会收到完整的剧本和人物设定等,接下来比较常见的工作流程就是绘制故事板了。
正常情况下的这个阶段,大多数的游戏内容都没有完成,甚至还未开始,最多只是有些基础设定,比如人物原画、场景氛围图等等。所以Cinematic team有机会根据剧本向其他部门预定一些额外内容,比如特别的车辆和枪械、特殊的场景布局等等。
故事板过时了?
故事板(Storyboard)是一个影视制作中常见的方法,它能相对快速的将文字剧本视觉化,让研发人员直观了解整个故事,明确key shot(关键镜头),同时在绘制的过程中帮助Cinematic Artist梳理整个场景的拍摄思路。这些都是它的优点。
不过故事板有一个致命的缺陷,就是缺少跟时间相关的信息,比如至关重要的Pacing/Timing(节奏)。因此在现代化的游戏制作流程中,故事板的贡献其实越来越低。尤其是近十几年,Pre-Viz(预示化)的盛行,使得越来越多的团队选择跳过故事板这个阶段,直接进入Animatic(动态分镜)的制作。
动态分镜
动态分镜(Animatic),是加入了时间因素动起来的故事板,包含了整个镜头序列关键的节奏。
比较早期的动态分镜实际上就是按时间顺序的故事板,就跟幻灯片一样。如果团队愿意花时间,可以直接自己演自己拍然后做一个粗剪,也可以用乐高或者粘土,用Stop Motion(定格动画)的方式来制作。
随着3D软件和Pre-Viz的流行,在影视制作中有很多专业工具很方便的制作3D的动态分镜。不过在游戏制作中,考虑到成本和Animatic素材后续的使用,往往会使用Maya、MotionBuilder、3ds Max这类在整个游戏美术流程中通用的软件来实现。
PLACEHOLDER
由于在动态分镜阶段,游戏内的大量内容基本都没做好甚至完全没开工,这时候就需要大量的Placeholder(暂时占位内容)。Cinematic Team往往会从其他部门借来他们的过程文件,例如绑定的角色和车辆,甚至有时候也要自己做一些简单的道具,比如枪械。
在所有Placeholder中,场景布局(Environment Layout)非常重要。在这个环节,团队需要跟关卡设计师(Level Designer)密切协调,确认Cutscene发生场景的Layout。关卡设计师往往会提供一个灰盒子(Greybox/Blockout),明确标示地面高低、门的位置等等,甚至会划出一个专用区域给Cutscene然后锁住,以免事后再做改动。尤其是在几百人的团队,如果这一点做得不好,可能等动捕数据回来之后,你会发现主角站立的位置多了个雕塑,甚至整个场景都没了。
临时配音
一般内部会找喜欢表演的Cinematic Artist或者动画师来做临时配音,因为他们在学校上过舞台表演课,会懂很多。
具体工作
除了收集各种Placeholder和临时配音,Cinematic team在这个阶段的主要工作就是根据之前定义的过场动画电影风格指引文档,来确认镜头、节奏、表演等,有的时候还要手动做一些简单的动画,如果条件允许,还可以进行动捕——不过只是为了制作Placeholder,不能作为最终的效果。
虽然在流程图里面列出的所需人员只有Cinematic Director和Cinematic Artist,但如果有条件,最好能让Tech Artist进驻,开始搭建从3D软件到游戏引擎的管线。这样一方面可以开始测试流程,另一方面在3D软件中所制作的内容,在后期也可以被复用,而不是完全扔掉。
动作捕捉
动作捕捉(Motion Capture),在现在这个技术环境下更多是指表演捕捉(Performance Capture)。在很多The making of的电影或者游戏开发揭秘视频里,大家应该都见过满脸贴着小点,穿着紧身衣的演员在做各种夸张动作。从管线的角度,Cutscene的动作捕捉需要几个关键步骤。
- Mocap Studio测试
- 动捕资料准备
- 动捕现场
- 数据清理
本文不是讲怎么做动作捕捉的,所以只会着重和In-game cinematic pipeline相关的内容。
动捕资料准备
准备动捕资料的目的,是确保演员准确的按照Animatic的安排来表演。除了提供给演员的剧本和动态分镜,还需要准备:
- 详细的镜头表
- 详细的场景布局(Layout grid)以及所有关键点的位置
- 提前准备好道具,或者记录好实际尺寸以备现场搭建
- 如果有,最好还有角色模型和场景的3D文件提供给Mocap Studio
所有这一切的目的,就是要在动捕场地,精准的将3D Animatic里的场景布局重构出来。
另外,这里面还涉及到演员和配音的一些问题。比如是通过中介机构来找好莱坞演员,还是找普通的动捕演员;是需要同期配音,还是去录音棚……这些在每次去动捕之前,都需要协调好。
动捕现场
一般AAA体量的游戏,动捕都需要分批多次完成。比如一次拍摄5天,然后分3-4次完成所有过场动画的动捕。
在动捕现场,Cinematic Team要承担类似导演的角色,时间分配大概是这样的:90%的时间坐在休息区喝咖啡,看手机,玩各种仿真枪械道具,等场景设置和设备调制完毕;5%的时间坐在显示器前面看回放;5%的时间给演员说戏。有点夸张,不过大体也是如此。
如果Cinematic Artist愿意,也可以现场拿着摄像机来拍摄,来追求一种实拍的真实性。现在大多数专业动捕公司都可以做到将演员的动画实时映射到一个3D场景内的游戏人物上,对于Cinematic Artist来说,就好像是拿着摄影机在一个虚拟世界内拍摄。比如新战神一镜到底的拍摄,就是用这类在动捕现场手持拍摄的方式来实现的。
因为新冠疫情,现在很多AAA公司都在家办公,连动捕都可以不去现场了。在家里同时显示现场4个角度的视频,然后实时在3D场景内回放,通过Zoom来跟演员说戏。也许以后这会成为常态,还能节省成本。
数据清理
动捕公司每次动捕完毕后,会做基础的清理工作,然后将数据发给研发团队。研发团队则需要花时间整理动画数据,导入3D软件,然后再花大量的时间调整。
这部分除了镜头数据,人物数据往往是由动画师在Cinematic Artist的指导下执行的,因为工作量巨大,只凭3-4个Cinematic Artist完全无法承担。
如果运气好,这时候会有一些完成的游戏内容可以替换原来的Placeholder。在这个阶段,动态分镜会变成包含人物和镜头的完整动画,这时候所有的表演和节奏都已经确定了。
导入游戏阶段
之前的工作基本都是在3D软件中进行的,而这一阶段则跟游戏引擎联系密切,全程都需要Tech Artist的强力支持。
如何设置合理的工具和流程,保持每个环节的灵活性,提高整个导入过程的效率,Tech Artist是这个阶段是关键要素。
PLACEHOLDER替换
这个阶段游戏往往已经开发过半,一部分Placeholder内容的美术应该已经做完,尤其是关键的主角和剧情NPC,而场景美术也开始接手关卡设计师完成的关卡。因此Cinematic Artist和动画师会在Tech Artist的协助下,将大量的Placeholder替换成最新美术内容。
在这个阶段,Tech Artist往往会做出很多便利的工具,力争让美术人员只是做少量的选取,然后点一个导入按键,就让工具自动的替换/导入游戏内容,有些工具甚至可以根据服务器上的内容版本自动更新。考虑到AAA游戏的体量,这种工具几乎是必须的。
这个阶段最理想的状态,是在3D软件中看到整个过场动画的全貌。但在实际项目中,所有的内容都会不停的更新,然后维护,直到项目结束。
最后的佐料
大多数情况下其他部门都是提供内容给Cinematic Team的,不过有几个部门需要在过场动画完成之后才加入最后的佐料,让整道菜色香味俱全。
- 灯光
- 特效(Visual Effects)
- UI效果
- 配乐和音效
- 配音
其中,有些内容是在3D软件中加入,有一些则是在后面提到的过场动画编辑器中加入。
从3D软件导入游戏
这个阶段,Tech Artist需要施展他的魔法,给Cinematic Team一个简单的“Export“按键。
理想情况下,只要在3D软件中设置好所有内容,工具应该就可以将对应的内容分别输出成为游戏引擎可用的文件(场景相关文件、人物动画、镜头动画、特效动画、灯光等等),而且这些文件之间需要相互匹配。
而在实际的研发中,新情况会不断出现,导入游戏的工具和流程会动态更新,引擎内的过场动画编辑器也在同时更新。所以这需要Cinematic Director开展极强的协调能力,配合游戏引擎统筹整个导入过程。
过场动画编辑器
在理想情况下,当所有内容导入游戏之后,一切都应该完美匹配,可以直接播放。但由于游戏开发没有理想情况的,所以我们还是需要一个编辑器,来负责:
确认从3D软件导入的文件正确可用
在游戏内设置各种参数
多角度预览
这个步骤极其关键。因为就算3D软件中的素材再好,如果导入游戏后无法正常同步播放所有内容,那就一切白搭。比如口型与配音可能在3D软件中都很完美,但是到了游戏中可能会因为帧数不稳定而不同步。这些都需要Tech Artist配合程序提供各种解决方案。
过场编辑器也需要让Cinematic Artist可以调整各种游戏内参数,比如天气状况、路人AI等等。这里面可讲的太多了,我会在后面的实战分析中举一些有趣的例子。而在In-game cutscene播放过程中提供暂停和多角度预览功能,也是必不可少的。
到这里,我们总算是聊完了加入时间要素的In-game cinematic pipeline流程。现在你仔细看下面这张图,应该就很清晰了。
管理者的责任
但我需要再明确一个残酷的事实,以上这些繁琐的内容,只是单个过场动画的制作流程。那么一个AAA体量的开放世界游戏会有多少过场动画?我们可以简单计算一下。
整个游戏的开场和结尾
三条关键主线,每条主线12个任务,每个任务一个开场(Intro)一个结尾(Outro)
30个支线任务,每个任务一个开场一个结尾
一共134场过场动画,就算每个过场都很短,平均45秒吧,一共100分钟,这也基本是一个标准好莱坞电影(1个半小时)的长度了。
复杂的管线,协同多个部门,管理长达100分钟的过场动画制作,而且还是需要极强Tech Artist支持的In-game cutscene……这一切对管理者真是很大的考验。
成本评估
这点对于国内研发来讲可能真的很难,因为需要对应经验的积累。
在项目初期,Cinematic Director或者Producer需要根据项目在过场动画上的预期,将每个阶段的工作进行拆分。拆分的越细致,就越容易评估每部分所需的时间和成本。
对于没有实际制作经验的部分,则需要通过快速测试来粗略评估自己的团队做这件小任务所需要的时间。同时,对于需要外部团队(比如Mocap Studio)参与的部分,也需要尽早选定和安排。
最后,在评估之上再加上50%的富余量,才比较稳妥。按照笔者经验,再此评估之上,实际游戏开发过程中再往下砍掉20-30%的内容,会更现实。
项目管理
这部分跟其他模块的项目管理一样,只是一个在理解pipeline做完评估之后的实现过程。
不过特别要说一点:选择一个自由度很高的项目管理软件非常重要。因为在项目管理中,各种Dependency(依赖关系)太多了,总是需要从其他部门更新其他内容的进展。
说起来容易,做起来还是挺难的。Just Cause 4团队在GDC 2019关于In-game cutscene的技术讲座上说过这样一句话:
“ 而实际上,整个过场动画的制作,在游戏开发过半的时候还都没有开始。我们完全没有实际可用的游戏内素材,直到最后压盘前的六个月,喔喔! ”
很难想象吧。一个成熟团队在做同一个游戏做了4代之后,遇到cinematic的需求升级之后,还会在项目管理上犯这么大的错误,而带来成本浪费和降低质量的问题。
我前两天在Reddit上还看到有人问“What's your workflow for in-game 3D cutscenes?”,第一个回答也很有参考意义哦:
“Avoid cutscenes They are hard to do.”
开个玩笑。在这篇文章最后,我会分享一些实际项目中遇到的问题和解决方法,这部分会比较有趣。
本来应该先讲讲有意思的内容给大家提提兴趣,但是不讲清楚pipeline,后面的内容再有趣也对研发没有帮助的,感谢能熬着看到这里的读者。
实战分析 在开放世界游戏中做IN-GAME CUTSCENE
开放世界游戏 + 实时过场动画 = ???
大家都知道,AAA开放世界游戏(GTA类游戏)属于最难开发的品类:投资大、周期长、技术难度高、参与人员多,游戏自由度极高……而自由度高,也就意味不可控,因此In-game cutscene也存在很多风险。
举个例子,大家很肯定在网上看过GTA的搞笑BUG视频,明明是个严肃的过场动画,结果从屏幕外面跑过来几个警察冲主角狂挥拳。这边拳头完全穿透了主角的身体,那边主角却依然一脸严肃的说着台词。
那开放世界游戏的哪些不确定因素,会对In-game cutscene造成影响呢?
- 玩家自定义角色
- 手持道具
- 环境变化
- 行人和车辆
- 变化的天气
- 流逝的时间
- 不同City/Terrain Chunk(区域地图数据)的读取
- 多人游戏
笔者所经历的开放世界游戏项目中,有一部《Saints Row 2》(黑道圣徒2),“不幸”包含了所有这些不确定的因素。接下来我就做一些分享。
结论:开放世界游戏 + 实时过场动画 = &#$^%~*&!!!
玩家自定义角色
现在自定义角色已经成了大多数游戏的标配,就算角色自身不能变化,至少也可以更换服装和饰品。
于是当玩家可以自定义性别、胖瘦、高矮的时候,过场动画也一下子多出了3个维度。
性别
当玩家可以在游戏中扮演不同性别角色的时候,所有动画都需要至少男女各一套;在动捕的时候,也需要男女2位演员分别进行动捕。
在过场动画中,很多情况下玩家角色会跟其他NPC互动。为了减少整体工作量,在动捕的时候,扮演玩家角色的男女演员可以分成一主一次。主演员会跟NPC的演员互动,比如拉手、搏斗等;而次演员则会在旁边几步距离的位置,用自己的表演同步主演员的动作,就好像是一个克隆体一样。这个对动捕演员的要求还挺高的。不过就算同步的再好,也需要在后期修改动画的时候做很多调整,才能让次演员的表演跟剧情角色的互动真的贴切。
胖瘦
玩家角色的胖瘦对过场动画的影响主要是在摄像机的取景上。过胖的玩家角色可能在某些镜头遮挡住关键内容。所以在3D软件和Cinematic Editor里面,需要Tech Artist提供一个胖瘦检查功能,以快速切换最胖和最瘦的角色外观,帮助Cinematic Artist来调整摄像机的取景。
另外需要注意的还有躯干部位跟其他任何内容的接触。比如2个人拥抱的时候,胖的玩家角色会跟NPC身体穿插,而瘦的玩家角色则会被抱空。类似这种问题一般都要通过镜头来避免,比如用中景表现2个人相互拥抱的手臂张开动作,给玩家一个两个人要拥抱的暗示,然后切换到肩膀以上的近景,避免拍摄到容易出问题的躯干部分。
高矮
能够自定义高矮的游戏并不多,因为太麻烦了。因为坐下、拾取物品、进出驾驶舱等动作很难适配不同高度的角色。
很多能自定义高矮的游戏都会采用一个临时缩放的偷懒窍门,比如2米高的角色在坐进车里的时候,会被自动缩到1米8以避免各种穿帮,然后再用镜头来掩盖这个缩放的过程。
而在过场动画中,如果玩家角色的高矮差距过大,最简单的处理方式就是在过场动画中使用标准身高的角色。如果有特别明显的对比,比如跟NPC并排站立的情况,则会在Cinematic Editor里面,单独设置在那个镜头里人物是否保持原有高度。
在项目早期,如果明确知道游戏能够设置人物高矮,最简单有效的办法还是避免这种中远景对比的情况,并在游戏初期的 过场动画电影风格指引文档 里明确说明。
衣服和装饰
主要是指附着在玩家角色身上的各种内容,包括手里拿的、身上穿的、头上戴的、脚下踩的等等。
手持道具
主要是各种武器。一般过场动画里玩家角色所使用的武器都是游戏初期预设的基础武器,比如基础手枪、步枪,从而避免跟玩家实际拥有的武器产生大的偏差。
脱脱穿穿的高跟鞋
在所有服饰中,高跟鞋是女性角色必须有但是很麻烦的东西,因为它能改变人物高度。所以在有些产品里,角色就算穿了高跟鞋也不会增高。
举个例子,玩家角色从桌子上捡起一把枪,需要桌子高度、桌子上平放的枪、人物高度(也就是手的位置)都在动画中匹配。如果动画是按照穿平底鞋的角色来做的,当玩家角色穿上高跟鞋,那人物高度(也就是手的高度)会比桌子上的枪高出一个高跟鞋的高度。
在这种情况下,需要在Cinematic Editor里面对每个镜头提供一个高跟鞋开关,然后根据每个镜头来设置。比如在制作上面这个捡枪镜头的时候,就要把高跟鞋开关关上。而下一个镜头如果是人物拿着枪在地板上走动的远景,则要再把高跟鞋开关给打开。
这时候你肯定要问,如果一个远景镜头可以看到玩家的脚,然后玩家又从地面把枪捡起来,那该怎么处理?答案很简单:别做这样的镜头呀,必须用镜头切换来避免这种情况。
在In-game cutscene里,镜头的选择除了跟电影语言相关,很大程度上也会受到各种技术因素的制约。从这点上看,Cinematic Artist对游戏引擎和技术限制必须有一定的了解。
环境控制
大多数开放世界游戏中的过场动画都是在游戏场景内播放的,所以在过场动画播放的过程中,环境需要被有效控制。
车辆和路人
在室外场景中,角色免不了跟游戏内的车辆和路人产生冲突。所以需要在过场动画的场景范围内,设置一个不可被干扰的区域。在过场动画开始的时候,所有在这个区域内的的车辆和路人都需要被清除掉,而且在过场动画播放中,游戏内由AI控制的车辆和路人也不可以走进这个区域。
这还不算完,在GTA这类游戏中,如果在过场动画播放之前你激怒了警察或者帮派,警察和帮派成员就会来不停围剿你。就算你设置了不可被干扰区域,他们也会在围在整个方形区域外面一直冲你射击。所以,还要将玩家角色设置为无法被定义为攻击目标。
这样的细节设定其实还挺多,它们的原理都很基础,但你还是会在很多AAA游戏中看到这类问题。是因为开发人员想不到么?肯定不是。原因是经验和时间成本。很多团队在项目后期的QA阶段才会发现这种问题,而这时大家都在拼命修更重要的bug,没有时间修这类优先级相对低一些的bug。但如果Cinematic Pipeline的负责人很有经验,在项目初期就可以提前避免这种情况。
天气
跟上面的车辆和路人控制类似,如果一个场景在下瓢泼大雨,但在过场动画中2个角色在瓢泼大雨下跟没事儿人一样的聊天,这就很违和了。但如果在播放过场动画的时候让雨立刻停止,一切又会显得很突兀。
这时我们一般有2种处理方法,要么在过场动画开始的时候,用第一个镜头显示环境而不是人物,让天气有自然变化的时间;要么简单粗暴的加入一个黑屏过渡。
相比进入过场动画,从过场动画回到游戏就简单很多。现在很多游戏都喜欢将最后一个镜头,随着上下Letterbox(宽屏与电影宽屏的影像转成标准尺寸时上下会出现黑边,这被称为“信箱模式”)移出屏幕,缓缓移动到游戏摄像机的位置,让玩家自然的回到游戏本身。
可破坏场景
我曾经做过一个Red Faction系列的开放世界游戏,这个系列的卖点就是基于物理运算的、不可预期的场景破坏,这就给过场动画带来更多的麻烦。
第一种情况是关键建筑是否还存在的问题。比如在过场动画里,玩家和角色站在一座塔上,但这座塔早就在之前的游戏中被撞倒砸烂了,你该怎么办?稳妥的做法,是提早跟游戏设计师和关卡设计师沟通,明确风险。其中最好的办法,是通过游戏流程来避免这种极端情况出现,比如通过各种限制不让玩家提前探索到这个区域。
更常见的情况是,不可预期的场景破坏碎片,会在过场动画中遮挡摄像机、跟人物动画穿插等等。这需要在过场动画开始的时候,将场景里一个区域内的所有碎片都清理掉,然后替换成过场动画提前设置好的碎片,利用这些碎片外形和贴图的相似性来欺骗玩家,让玩家以为过场动画的确是发生在自己刚刚毁坏的场景里。
这里有一个技巧就是尽量使用中近景镜头,把视觉重点放在角色上面,避免展示过多的环境,不然玩家还是很容易产生疑问:“哦,刚才那堵墙不是还剩一半么?现在怎么都倒了?”
灯光系统
不管现在游戏画面进化到多么好,灯光师都是在带着镣铐跳舞,因为在游戏中可用的灯光总是不够用。
因此,Cinematic Editor需要提供一系列功能,让灯光师将有限数量的灯光发挥出最大的作用。下面这4个部分都能让灯光系统更加灵活,不过工作量也会随之暴增。
针对物体的包含(Include)和不包含(Exclude)功能
按镜头来设置灯光
Time of day
玩家自定义角色的肤色
针对物体的包含(INCLUDE)和不包含(EXCLUDE)功能
即提供一系列的选项,让灯光师可以对每一盏灯所影响的物体做选择。
以灯光为中心:
是否影响某类物品,比如人物、车辆、场景、特效等等。
是否影响某个物品,比如只影响人物A,但是不影响人物B。
是否对某类物品产生投影
是否对某个物品产生投影
而这种选择也可以是反相设置的,以物品为中心:
是否能被某盏灯影响
是否对某盏灯会产生投影
是否会接受投影
只有Cinematic Editor具备了这些功能,灯光师才能在有限的灯光和渲染机制下,将画面推向更好。
按镜头来设置灯光
灯光的数量、范围、精致程度、重叠程度都会直接影响帧数。考虑到镜头设置不同,每个镜头所包含的3D内容也有很大不同,因此Cinematic Editor必须支持以镜头为单位来设置灯光。
之前我经历过一个项目,为了保证帧数,每个镜头同时存在的灯光数量不能超过12。所以如何在每个镜头内活用这12盏灯就显得非常重要。如果是人物近景,可以将多数灯光用在人物和道具上;而如果是远景,则需要将多数灯光在场景照明上。这个时候就要考验灯光师对技术限制和艺术追求的平衡了。
笔者做过一个中景镜头,玩家角色扔一串钥匙给NPC,钥匙串体积太小,在中景很难看清楚,于是专门给钥匙串打了一盏灯,增加了足够的亮度和反光,让钥匙串在空中飞的过程更明显的更容易被看到。贴图和Shader上的不足也可以用灯光来弥补。
按镜头来打光,可以极大提高In-game cutscene的视觉效果,但它的工作量也跟镜头数量有关。
TIME OF DAY
这是指很多开放世界游戏会分成清晨、中午、傍晚、深夜等不同的时段,它的画面也会受到时间的影响。
为了让过场动画符合当下的Time of day,室外过场动画的灯光起码要分4组,对应刚才说过的清晨、中午、傍晚和深夜。而Cinematic Editor则会分别提供设置或者继承的功能,方便灯光师操作。
这个事情不是很复杂,但是为了达到跟游戏内统一的感受,工作量直接乘了4倍,很难评价是否值得。有些游戏则会直接做一个时间流逝的画面,比如镜头冲天看天色变换,到了指定时间再才开始做过场动画,这也算是一个不错的“偷懒”办法。
不同人种的皮肤
当玩家可以自定义人种和皮肤颜色的时候,将不同肤色的玩家放到同样的光照环境下总是会有问题,不是浅色皮肤泛白得厉害,就是黑色皮肤过深看不到细节。因此,Cinematic Editor也应该有对应不同肤色的灯光设定功能。
在自由度很高的开放世界游戏里,如果想认真处理过场动画中的灯光,往往要花费(针对物体的Include和Exclude x 镜头数量 x Time of day数量 x 人种肤色数量)这么多倍的工作,才能在多种情况都具备一个基本的水准。
开放世界的动态加载地图
开放世界的一个特色是无缝地图,也就是在第一次loading进入游戏后,很少会再次loading,让玩家在整个世界中不间断的游玩。这是通过动态加载局部地图来实现的。
因此,如果在过场动画中出现地点变化,就需要精心计划地图的动态加载。
多场景切换
举个例子,一个过场动画,在城市北端的火车站外有几个镜头,然后切换到城市的南端的农场再来几个镜头。在这种情况下,需要首先释放在火车站场景看不到的但之前已经加载过的无用局部地图;而且火车站的镜头要足够长,这样后台才能完成农场地图的加载。不然当过场动画切换到农场的时候,玩家会先看到悬空的人物在表演,随后看到局部地图一点一点的在画面上冒出来。
怎么样,这个画面是不是很熟悉?很多AAA开放世界游戏的过场动画或多或少都会出现这种问题,这就是在安排过场动画的时候没考虑到动态地图的加载时间。有的bug可以通过后期优化修复,有的可能就无法修复了。
横穿城市的轻轨列车
再给大家举一个极限例子,也是本人处理过的,最复杂的动态加载地图的过场动画。
这个场景发生在一列横穿3个局部地图(City chunk)的轻轨列车内。这其实是一个室内场景,但它要在3个City Chunks间移动,而且通过车窗可以看到很远的城市背景和海中的小岛。
在处理中,我需要预留第二个和第三个City Chunk的读取时间,而且还不能让镜头看到读取的过程,不然玩家就会发现低清晰度(LODs)的建筑被逐步替换成了高清晰度的建筑。
所以最后整个City Chunk的读取过程,是严格的按照镜头来划分的:从第几个镜头开始释放哪个City Chunk,又需要用几个镜头的时间来读取下下个City Chunk。中途遇到解决不了的地方,则要靠镜头来遮掩。
另外在夜景之下,曲折的轻轨线路两侧还一直有路灯,所以我还需要沿着轻轨路线,对能覆盖车厢本身的路灯开开关关……整个过场就好像是在解决一个puzzle游戏。
支线任务的过场动画
由于In-game cutscene是一个复杂而且需要大量人力和时间来制作的项目。因此在预算和人员有限的情况下,大家大部分的精力会放在主线任务的过场动画上。而对于AAA开放世界游戏中数量众多的支线任务(Side Quest或者Activity),我们会采用一些自动化手段来节省成本和时间。
支线任务过场动画的目的主要是交代任务内容和解释任务结果,大多数是由简单的对话构成,以2、3个人物的演出为多。所以很多AAA游戏会构建一个特别的编辑器,包含基础模版和很多预设内容,来快速的产出支线任务的过场动画。
预设舞台
支线任务过场动画发生的地方都很简单,只要在发生的地点找一块开阔地,再放置基础模版即可。基础模版会包括我们之前提到的各种环境控制。
预设表演
放置好基础模版之后,可以在预定的几个位置上放置玩家角色和NPC,再根据剧情选择合适的预设动画。比如让玩家角色走过来还是跑过来,NPC是坐着还是站着,是生气还是高兴的说话等。
一般模版内会有很多类似的循环动画,它们的表演肯定不如单独动捕的自然,不过也还凑合。很多AAA大作也都是这样来“偷懒”的。
自动镜头切换
设置好了基础的人物位置和动画,就需要设计摄像机了。一般基础模版会包含几十上百个预设机位,可以先自动生成一个镜头序列,然后再挑出不满意的地方,从机位列表中选择更好的机位。
自动生成口型
最后可以根据配音自动生成口型,不过脸部表情很难控制。所以这种用模版生成的支线任务过场动画,一般都很少使用近景镜头,避免人物表情和口型被看的太清楚。
有些AAA游戏的支线任务过场动画人物站桩,表情僵硬,就是因为使用这类方法来制作。但他们错误地使用了近景,一直让摄像机对着说话角色的脸部,结果就放大了弱点。
结语
写到这里,有一种“终于写完了”的感觉。
想将In-game cinematic的pipeline和多个项目的经验浓缩到一篇文章,实则是个不可能的任务,因此很多内容也都没有提及。只希望这篇略显枯燥的专业文章,对国内研发同行有些帮助,能引发些思考,在项目上少趟一些坑,我就很是欣慰了。
能看到此处的读者,想必跟我是一个感觉:休息,休息一下吧。