原文为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中的房子制作方法,主讲人也就没有深入讲述。
到此为止,房子的placeholder,车行人行道,imposter,一年的pre-production就做完了。
团队又有了新的挑战,他们希望以下的东西都可以自动生成
下图是他们设计的pipeline,第一部分生成道路和房子,也就是第一年pre-production完成的
第二部分是主体,procedural生成绝大多数的内容。它还是procedural的,这部分暴露了部分可控性,不是所有都能修改。要修改的话还是修改参数为主,不会完全手动控制,要不然会丢失手动信息。
这部分一个特点是依赖项比较多,上游会影响下游,后面遇到了问题。
第三个阶段就是拥抱传统手动流程了,当然procedural会根据手动修改重新生成一些,并且有自动的优化和检查。
另外又出现了新需求,新的设计,新的叙事
-怎么办?
解决方法是定义目标,什么时候某个阶段可以结束,不影响下游阶段了,就可以安全进行下一项了。拆分和定义依赖项,保证不阻塞后面步骤。
把procedural任务设计的更模块化,耦合度更低
总结:
不需创建完美的规则,那增加了开发时间,增加了dependency
总结:
在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’
