[Translate] GDC19 – Procedurally Crafting Manhattan for ‘Marvel’s Spider-Man’ | [译]漫威蜘蛛侠中程序化创建曼哈顿

原文为GDC2019中,Insomniac Studio的Principle Technical Artist – David Santiago带来的Talk-Procedurally Crafting Manhattan for ‘Marvel’s Spider-Man’.

David Santiago经历相当传奇,20年的从业经验。早年就读于UTAustin和USC学习EE,之后加入NASA喷气动力实验室。28岁加入特效行业,做过lighting TD,FX TD,CG Superviser等等。

Procedural生成场景方面,之前GDC已经有很多次讲了,比如

GDC2016 – Assassin’s Creed Unity: London Is Not Built In One Day

程序式生成伦敦的房子-也基本是其后procedural房子的基本做法

GDC2017- Procedural Technology in Ghost Recon: Wildlands

幽灵行动的程序化生成场景-笔者所知第一次有人讲到houdini集成进引擎的操作

GDC2018- Procedural World Generation Of ‘Far Cry 5’

远哭5的程序化生成场景-详细介绍了dunia和houdini的集成和一些场景的生成trick

今年也不例外,不过终于不是阿育家了,这次是Insomniac,讲的是曼哈顿。但是内容笔者感觉偏向于管理和pipeline,对技术并没有多开创性和详细介绍。笔者感觉其实procedural到目前已经相当成熟,是3A标配了,这几个引擎的做法也都相当类似。其实曼哈顿阿育当然做过,Tom Clancy’s Division就是纽约背景。Insomniac并没有什么好创新的。就算是道路生成这种其它几个talk没怎么讲过的,笔者相信应该也不新奇,Rockstar肯定有一套inhouse工具的,虽然不一定基于houdini。

这个talk与之前不同之处在于

  • houdini全面集成进开发流程,灯光,音效,gameplay都包含
  • 承认手动布置不可替代,设计pipeline时尊重最后手动的修改
  • 讲述了如何迎接开发中不可避免的新变化

首先这个项目给Procedural的定位就是Headstart,给游戏策划一个快速填充世界的手段,在Pre-production阶段完成80%的劳动,之后再手动polish。

项目的基础是从Sunset Overdrive开始的,是Insomniac上一个项目。当时有简单的地形和道路系统处理,几乎没有道具,房子,markup的布置。

这个项目开始是从道路开始的,一开始的curve是在引擎中通过图片生成的,然后可以用颜色区别房子的尺寸,之后都可以在编辑器里改道路了。另外策划还会布置一些ground modifier,一些design modifier改变crime, traffic等。

这就可以丢进houdini生成了,比如下图中这些生成的方盒子,注意下下张图,是带标点的(talk中叫markup),笔者目测这些markup都是可以引擎中手动拖动修改的。

这里房子装配的方法猜测应该很像Assassin, Division中的房子制作方法,主讲人也就没有深入讲述。

Houdini根据输入的道路线,自动生成道路系统,包括车道转向的可能路径等,
还有行人的路径,这些都可以在引擎中与手动摆放相结合

另外自动布置了一些道具,还有灯光
所有imposter是daily build自动生成的
常驻的那部分模型

到此为止,房子的placeholder,车行人行道,imposter,一年的pre-production就做完了。

团队又有了新的挑战,他们希望以下的东西都可以自动生成

注意到Crimes, Vignettes, Markup这些都是gameplay相关属性。后面也遇到问题了,这些东西的依赖很多(dependency)
Props Ground Buildings, Pedestrian这些是level design和level art相关,也是传统procedural的内容
然后还有lighting和audio,也是procedural生成的。
兼职囊括了很多的部门。

下图是他们设计的pipeline,第一部分生成道路和房子,也就是第一年pre-production完成的

第二部分是主体,procedural生成绝大多数的内容。它还是procedural的,这部分暴露了部分可控性,不是所有都能修改。要修改的话还是修改参数为主,不会完全手动控制,要不然会丢失手动信息。

这部分一个特点是依赖项比较多,上游会影响下游,后面遇到了问题。

第三个阶段就是拥抱传统手动流程了,当然procedural会根据手动修改重新生成一些,并且有自动的优化和检查。

第二步生成了大部分的内容。在操作的时候,先是让一个artist一个区域,做第二阶段的第一步,摆资源。

但是有人会修改道路,导致其他区域的交通量变化,造成多米诺式的修改。
这里一个巨大的问题是依赖(dependency),上游修改会丢失下游修改

另外又出现了新需求,新的设计,新的叙事

-怎么办?

解决方法是定义目标,什么时候某个阶段可以结束,不影响下游阶段了,就可以安全进行下一项了。拆分和定义依赖项,保证不阻塞后面步骤。

把procedural任务设计的更模块化,耦合度更低

比如交通灯只依赖于道路,这样方便分解任务进行
保证能自动化的都自动化

总结:

依赖(dependency)多的尽快确定和锁定
procedural任务层级化,减少依赖

不需创建完美的规则,那增加了开发时间,增加了dependency

手动编辑不破坏程序化
避免复合依赖的物件,比如一个crime依赖于道路和屋顶就要拆分
减少dependency

标记出procedural的东西
-这些可以自动重新生成,不破坏手摆的物件
-这些可以手摆提升

程序化检查
比如一个spawn point位置不对,自动更改位置,或者删除,或者提供手动修改提示

总结:

在procedural场景中,需要遵循几个原则

  • 解耦任务,减小粒度,减少任务dependency,避免重复进行任务
  • 定义“完成”。为防止有依赖关系的上游任务阻碍下游进行,就需要定义完成标准尽快推动下游开始
  • 尊重手动。避免完美的程序化生成降低灵活性,保留手动修改历史。给手动操作留下空间。

这篇打着procedural名义的talk相比于之前GDC中介绍技术的talk,感觉偏向于管理和pipeline。这也是必然,当引进新的制作技术后,必然涉及到各部门合作协调的问题,技术不再是真空中的球形鸡,而必然要拥抱开发中的设计变化,大概也是如此,阿育的TDArt自嘲是pipeline TD。这也是常态,procedural不仅对场景制作有帮助,对其他团队也有帮助,Technical Artist不可能独立完成所有任务,必须要让procedural工具与使用者交互。

仍然回到procedural vs interactive的对立讨论。procedural的太多,灵活性差,不好与其他团队合作。interactive太多,操作太过繁琐。这篇talk不那么procedural,但却对开发很有价值。

参考资料:

GDC2016 – Assassin’s Creed Unity: London Is Not Built In One Day

GDC2017- Procedural Technology in Ghost Recon: Wildlands

GDC2018- Procedural World Generation Of ‘Far Cry 5’

发表评论

电子邮件地址不会被公开。 必填项已用*标注