Insomniac Decouples Spider-Man Pipeline to Fix Cascading City Errors

Insomniac解耦《蜘蛛侠》制作管线以解决城市级联错误 当上游资产发生变动时，僵化的程序化依赖会导致整个城市出现故障，这要求开放世界管线放宽放置标准并独立验证各个系统，从而让美术人员在迭代时不会破坏相邻区域。 面对在基础版PlayStation 4硬件上重建6×3平方公里的庞大曼哈顿这一挑战，Insomniac Games采用了一套目标产出80%可用内容的离线程序化管线，让美术师和设计师能够专注于手工打磨细节。该系统管理着包括街道布局、模块化建筑构建、位移遍历标记、行人行为以及动态战斗遭遇在内的多个相互关联的层级。在早期制作阶段，按区域逐个构建城市的设想在垂直切片需求和级联依赖的压力下崩溃，团队随后重构了管线，对各系统进行解耦，建立验证检查机制，并放宽了放置标准。通过清晰的资产标记、注重内存占用的虚假代理（impostors），以及明确何时允许美术人员手动编辑产出内容，团队成功交付了一个密集且具交互性的开放世界。 Insomniac Games凭借约250名开发者的团队规模，利用目标产出80%可用内容的离线程序化生成管线，为《漫威蜘蛛侠》构建了6公里乘3公里的曼哈顿可玩空间。 (5:07) 该游戏从《日落过载》使用的六边形流式传输网格过渡到传统的128米方形网格，以便更好地适应曼哈顿现实世界中的街道网格与纵深垂直度。 (66:04) 程序化依赖在制作中期进行了重构，从僵化的按区域锁定转变为模块化先决条件门禁，防止早期垂直切片需求和微小的道路调整不断破坏下游美术资产。 (38:08) 为了契合基础版PlayStation 4的硬件限制，城市依赖动态光照的低分辨率建筑替代代理（impostors），确保内存中同时最多仅保留12个高分辨率流式传输区域。 (20:53)

To construct Manhattan for Marvel's Spider-Man with a 250-person studio, Insomniac Games utilized an offline procedural generation pipeline targeting 80% automated content delivery, allowing the team to invest remaining production time into manual design polish. The 80% Procedural Generation Strategy and City Scale (5:07) Principal Technical Artist David Santiago explained that constructing a 6 km by 3 km Manhattan across nine districts—comprising 544 roads, 1,202 alleys, and over 8,300 buildings—was impossible to achieve purely by hand with the studio's headcount. Instead of running real-time procedural generators, Insomniac developed an offline toolset aimed at procedurally generating roughly 80% of open-world content early in development. This strategy allowed designers and artists to focus their remaining schedules on manual polish and bespoke gameplay crafting. Ground Networks, Dependency Cascades, and Streaming Grids (8:46) The open world's structural layout relied on a strict dependency chain rooted in road and alley splines, which determined sidewalk dimensions, grey spaces, and perimeter seawalls. To manage performance and streaming on standard PlayStation 4 hardware, the island was partitioned into square 128-meter streaming tiles, dropping the hexagonal layout previously used in Sunset Overdrive to better match New York's native grid. Ground meshes were divided into approximately 16 models per tile to optimize runtime physics calculations. Because world layers were tightly coupled, early production suffered severe pipeline bottlenecks. Shifting an alley or modifying a road curve invalidated block boundaries, which disrupted building footprints, traffic paths, UV maps, dynamic crimes, and baked lighting across up to nine surrounding tiles. Production demands like vertical slices and milestone demos also broke the initial plan to build districts in uniform lockstep, forcing individual tiles ahead while adjacent areas remained primitive. Pipeline Restructuring and Rule Loosening (38:08) To prevent pipeline resets, the team refactored generation rules around modular, preconditions-based execution rather than waiting for entire districts to lock. For example, traffic signals generated as soon as corner vector coordinates stabilized, without waiting for building facades. The team also split compound placement dependencies, separating street-level crime rules from rooftop encounters to eliminate cross-system breakage. Santiago noted that the team intentionally avoided over-defining procedural rules. While rigid criteria frequently produced empty areas that artists had to fill manually, looser rules successfully placed 100% of the planned procedural quota roughly in position. Artists could then nudge assets into exact placement far faster than building them from scratch. Tagged procedural assets could be automatically wiped and regenerated without overwriting manual edits, while validation routines flagged ambiguous asset placements for human review rather than guessing. Runtime Optimization and Impostor Management (20:53) To maintain memory limits on the PS4, Manhattan relied on low-resolution geometric impostors textured via atlas projections of high-resolution edifice prefabs. The engine kept at most twelve zones loaded in high resolution simultaneously, while panoramic vistas and distant horizons were drawn entirely using impostors lit dynamically by ambient environment light probes. Each environment artist worked under strict per-tile memory budgets that were only relaxed for non-negotiable gameplay beats. Turnaround for city-wide rebuilds relied on daily cached asset baselines and overnight generation passes, including an hour-long sparse data pass for district-specific asphalt and sidewalk materials, approximately five hours to regenerate all ground tiles, and 25 minutes for global placement passes. Insomniac exceeded its 80% procedural target, but Santiago emphasized that every hour saved by automation was immediately absorbed by further design iteration and manual polish up until ship, demonstrating that procedural pipelines shift artist effort toward refinement rather than reducing total development time.

在GDC演讲中，Insomniac Games首席技术美术师David Santiago阐述了工作室如何构建离线程序化管线生成《漫威蜘蛛侠》中的庞大曼哈顿，并设定了由算法自动完成80%可用内容、由人工专注最终20%打磨的目标。 管线定位与庞大曼哈顿的体量规划 (5:07) 面对在基础款PlayStation 4硬件上实时运行的要求，以及约250人团队同时兼顾多个项目的现实限制，纯人工铺设约6公里乘3公里的曼哈顿岛成为不可能的任务。该地图涵盖9个核心区域、中央公园以及两座外岛监狱，内含544条道路、1,202条小巷、超过8,300栋建筑（归类为3,250个建筑预制件）与350余种店面配置，并需要承载逾3,000个动态犯罪点和同等数量的环境剧情小景。 三阶段生成流程与连锁依赖挑战 (25:10) 程序化管线以SideFX Houdini与内部引擎算法为核心，划分为三个阶段：阶段一基于道路中线确立路网并生成建筑体量灰盒；阶段二通过美术多边形轮廓线输入模块化建筑套件，并铺设交通、行人、小巷道具及动态遭遇；阶段三聚焦于系统优化与资源锁定。同时，远景替代体（Imposter）与烘焙光照在后台持续运行。该架构遵循严格原则，即美术师与设计师不得直接手工修改程序化输出结果，所有调整必须通过输入参数与多边形轮廓线驱动，以防重新生成时抹消人工修改。 依赖解耦与容错校验机制 (38:08) 原定全岛整齐推进的规划在实际生产中被打破。关卡演示、专属任务以及局部道路和小巷的微调引发了跨区域的多米诺连锁失效，导致大面积的UV、犯罪点排布与交通逻辑崩溃。团队为此对管线进行彻底重组：将庞大的复合规则拆解为独立的条件模块，使诸如红绿灯等物件仅依赖道路向量即可提前生成，无需等待外立面装点完成。同时，系统放弃对100%完美生成的追求，转而采取宽松放置策略，优先保证配额全部入场，并在检测到无法自动修正的低置信度异常时交由人工审查，防止物件悬空或报错。 后期世界状态集成与性能预算管控 (41:06) 在生产后期，管线迅速集成了覆盖区域系统以支持时间、天气及剧情幕次变化，使第三幕呈现出店铺关闭、垃圾遍地及战乱氛围，并为中央公园材质动态注入声学碰撞体。在运行性能方面，全城被划分为128米见方的流式传输区块，运行时最多仅有12个区块处于高精度加载状态，远景则依托环境光探针动态着色的单套替代体几何网格。各区块执行严格且不可相互借用的固定内存预算，全城数据的批量重构则通过Perforce提交版本与夜间全局缓存以并行方式处理，有效避免了文件锁定冲突与协作阻滞。 Santiago总结指出，团队最终超越了80%的程序化可用内容指标，但节省的工时全部被重新投入到了高密度的手工迭代与设计打磨中。制作经验表明，构建开放世界时必须尽早锁定基础几何依赖并拆解复合规则，避免因追求严苛的完美算法而导致管线脆化。

## Background 该视频由 GDC Festival of Gaming 于 2019 年 4 月 15 日发布在 YouTube 平台上。视频记录了在 2019 年 GDC 游戏开发者大会上，来自 Insomniac Games 的首席技术美术师 David Santiago 针对《漫威蜘蛛侠》（Marvel's Spider-Man）开放世界制作管线展开的专题分享，详细拆解了团队如何设计程序化生成系统以支持高频迭代并处理复杂的跨系统依赖。 ## TL;DR 演讲全面复盘了 Insomniac Games 如何利用离线程序化技术与自动化管线搭建出高度精细且可玩性极强的数字曼哈顿。David Santiago 详细拆解了地面路网、建筑轮廓、遍历标记（Traversal Markup）、车辆与行人 AI 以及远景替身（Imposters）等核心系统的生成逻辑，并阐述了团队如何确立“80/20”效率法则来平衡算法铺设与手工打磨。面对中后期因美术微调、剧情推进和多米诺级联依赖导致的管线失控，团队果断重构架构，推行依赖解耦、微模块化分级与置信度验证机制，最终在严格的内存预算与上线节点前成功完成了全城交付。 ## Atmosphere & style 整场演讲呈现出典型工业级技术复盘所特有的硬核、坦率与幽默气质。David Santiago 毫无保留地分享了从立项初期的豪情万丈、中期面对多米诺骨牌式崩溃时的极度焦虑，再到最终攻克难关的完整心理曲线，现场气氛随着对“水坑门”等研发趣事的自嘲而笑声不断。聆听这场分享不仅能让人直观感受到顶级 3A 工作室在面对海量资产时的工程压迫感，更能深刻体会到在冰冷复杂的算法网络与充满温度的人工雕琢之间寻求精妙平衡的研发魅力。 ## Bulletin - [05:07](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=307s) 《漫威蜘蛛侠》的 6km × 3km 曼哈顿包含 544 条主干道、1202 条小巷与 8300 余栋建筑，Insomniac 仅凭约 250 人团队通过程序化生成完成了 80% 的基础内容铺设。 - [08:16](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=496s) 开发团队摒弃了《日落过载》的六边形网格与预制拼图组件，转而采用 128m × 128m 的正方形网格切片（A01 至 X48），以契合曼哈顿实际的棋盘式布局与高程落差。 - [38:05](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=2285s) 管线确立了“100% 内容铺设”优先的保底哲学，宁可由系统全量放置后人工微调低置信度资产，也绝不因生成条件过于严苛而导致漏放内容。 - [54:41](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=3281s) 全城夜间批处理重建可在数小时内完成，其中地面材质与 UV 稀疏数据计算耗时约 1 小时，地面地块生成约 5 小时，全城玩法放置约 25 分钟。 ## Key takeaways - [05:07](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=307s) 程序化系统属于离线内容生成工具而非运行时动态演算，核心目标是输出 80% 可用内容，为美术与策划的手工打磨节省 80% 的时间成本。 - [08:16](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=496s) 道路与巷道是整座城市生成的拓扑源头，路网曲线直接驱动路面生成、防波堤构建以及地面与设计侧修改器区域的派生。 - [12:40](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=760s) 建筑工具内置“仅重新计算标记”模式，在保留手工调整建筑体量的同时，自动提取并优化合并摆荡体积与边缘跑酷标记。 - [14:24](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=864s) 人行与车行交通网络深度绑定信号灯两相位机制，能够自动吸纳手绘曲线、地铁出入口动线，并动态将静态待机 NPC 提拔为巡逻移动状态。 - [18:36](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=1116s) 第三幕的灾后废墟道具散布采用严苛的排他性体积判断，确保满地瓦砾与垃圾视觉密度的同时完全不阻塞各系统的寻路动线。 - [20:53](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=1253s) 远景替身（Imposters）模型通过在资产中内嵌不可见的超低精 LOD 读取生成，并在连续内存空间中按区域排布，支持室内场景即时整块卸载。 - [22:22](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=1342s) 动态玩法遭遇（如喷气背包犯罪）制定了极其苛刻的几何搜寻规则，并反向波及周围多达 9 个地块的道具剔除与光照计算。 - [35:33](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=2133s) 初期规划的“逐区推进”理想流程因跨地块多米诺骨牌效应被打破，团队被迫重构管线，解耦区域依赖并将各资产放置细化拆解为微模块。 - [41:06](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=2466s) 后期引入覆盖区域（Overlay Zones）系统，在不破坏底层数据结构的前提下动态控制昼夜、天气、剧情幕次下的店铺开闭与人群表现。 - [46:56](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=2816s) 资产验证系统引入确定性删除、微调修正与不生成安全挂起机制，防止程序化重新烘焙时摧毁手工打磨细节或遗留悬空孤立物件。 - [58:14](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=3494s) 每个网格瓦片均设定了死磕的固定内存预算，严禁跨地块挪用配额，除非该地块承载了无法转移的核心关键玩法。 - [01:02:25](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=3745s) 多岔复杂路口与立交高架采用编辑器手工绘制加元数据标记的方式，在程序化重新构建中被识别并永久保留手工覆盖结果。 ## Detailed walkthrough ### [00:02](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=2s) 开场介绍与制作背景 Insomniac Games 首席技术美术师（Principal Technical Artist）David Santiago 登台向观众致意，并说明本场演讲将深入探讨《漫威蜘蛛侠》（Marvel's Spider-Man）中程序化生成系统（procedural systems）与制作管线（pipeline）的构建历程。 Santiago 表达了对团队支持的感谢，同时幽默地为工作室展台招募人才打广告，包括当季在两个工作室开放的绑定实习生（rigging intern）职位。在与现场观众互动、确认大部分人都已体验过该作后，他带领大家回顾了项目的起源时刻。 数年前的一次内部会议上，创意总监 Bryan Intihar 正式宣布 Insomniac 将为 PlayStation 4 平台开发下一代作品。当时没有参加该会议的 Santiago 突然得知新项目时惊诧万分，直接反问：“What? What? Why? We're doing Spider-Man? You're kidding!”（“什么？为什么？我们要接《蜘蛛侠》？你在开玩笑吧！”）。然而怀疑很快转为紧迫感——他曾负责过《日落过载》（Sunset Overdrive）中利用程序化技术搭建地面、建筑与标记标记点（markup）的工具，而这次他面临的任务则是将曼哈顿整座城市建立起来，规模和体量呈几何级数放大。 Santiago 仔细研读了 Bryan 的立项规划，其中为各个部门确定的支柱方向与目标展示了极为惊人的内容体量，且必须在极其紧张的时间窗口内交付。2016 年 E3 展会前夕，坊间传闻四起，玩家的期待值被推向顶点。 ```mermaid flowchart TD accTitle: 项目启动与目标确立流程 accDescr: 展示从内部宣布到 E3 亮相期间，项目目标与技术要求的推进路径。 subgraph Phase1["项目确立"] A["创意总监宣布《蜘蛛侠》项目"] --> B["回顾《日落过载》技术经验"] end subgraph Phase2["目标与规格落地"] B --> C["确立全部门内容基准与支柱"] C --> D["2016 年 E3 实时演示实机闭环"] end subgraph Phase3["管线考验"] D --> E["树立全行业与玩家画质标杆"] E --> F["原初规划不足以支撑后续两年研发"] end ``` ### [02:45](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=165s) 2016 年 E3 首曝与质量基准的确立 在 2016 年 E3 游戏展的首发宣传片中，镜头自城市俯瞰平滑切入车水马龙的街头，展现拥挤的车流、往来的行人和热狗摊，最后聚焦于那张令全场轰动的片尾标志。在回顾这段经历时，Santiago 特别致谢了漫威游戏（Marvel Games）、索尼互动娱乐（SIE），以及所有开发成员背后默默奉献的家庭。 当 E3 预告片切入蜘蛛侠在摩天大楼间纵横穿梭、大幅摆荡的镜头时，全场掌声雷动，而这也意味着 Insomniac 团队再无退路，底线标准被彻底钉死。开发团队从一开始就强制要求所有演示切片必须在 PS4 原生硬件上实现实时运行，绝不采用离线预渲染作弊。虽然既定管线顺利支撑团队完成了 2016 年 E3 的公开亮相，但 Santiago 清醒地意识到，旧有规划根本不足以抵御未来两年高压制作期中翻江倒海的技术挑战。为了向现场观众直观展现最终的游戏动态效果，他还在现场克服了 PPT 视频播放故障，演示了蜘蛛侠在曼哈顿街区高速荡荡的最终画面。 - **实机运行底线**：演示素材全程在 PS4 实机硬件上实时运算呈现，不依赖离线渲染。 - **后续连带分享**：创意总监 Bryan Intihar 于当天 11:30 在 South Hall 紧接举行另一场针对本作核心设计的专题演讲。 ### [05:07](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=307s) 开放世界的规模与程序化内容指标 在梳理曼哈顿岛的制作全貌前，Santiago 逐一列出了支撑整个开放世界可玩体验的精确资产与内容规模。设计团队打造的曼哈顿包含大约 6 公里长、3 公里宽的实际可玩空间，涵盖九大主要行政与特色区域，以及外围高风险岛屿与大型公共绿地。 面对如此浩瀚的地图资产，Insomniac 在《漫威蜘蛛侠》研发周期内总员工数仅有约 250 人，且常年需要兼顾多个项目的并线研发，完全依赖人工手工铺设是绝对不可能完成的任务。因此，团队从一开始就定下了高度依赖自动化（宏、脚本）与离线程序化内容生成（procedural content authoring）的技术路线。Santiago 澄清道，这里的程序化并非游戏运行时的动态生成，而是由数据流根据指定参数、属性与各类输入，在离线端经由一系列算法运算批量生产美术与设计资产的流水线。 虽然极度依赖算法，但 Insomniac 核心仍将“手工打磨（hand-crafting）”奉为灵魂法则。Santiago 强调：“Pan crafting is very important at Insomniac Games; designers and artists handcraft the game experience as much as possible throughout the entire game, and procedural systems are a tool to help author a lot of content quickly and give the artists and designers a big head start.”（“在 Insomniac Games，手工打造至关重要；设计师和美术师在整款游戏中尽可能亲手打磨游戏体验，而程序化系统只是一种快速生产海量内容的工具，好让美术和策划能赢在起跑线上。”） | 内容维度 | 对应数量 / 详细规范 | |:--- |:--- | | **可玩空间尺寸** | 约 6 km × 3 km | | **涵盖核心区域** | 哈莱姆区（Harlem）、上东区（Upper East Side）、上西区（Upper West Side）、地狱厨房（Hell's Kitchen）、中城区（Midtown）、唐人街（Chinatown）、格林威治（Greenwich）、金融区（Financial District），外加孤岛监狱（The Raft）、雷克斯岛监狱（Rikers Island）及中央公园（Central Park） | | **道路与巷道** | 544 条主干道，1,202 条巷道（绝大多数巷道为游戏虚构，曼哈顿现实中几乎没有） | | **建筑与群楼 Prefab** | 超过 8,300 栋独立建筑，整合进 3,250 个 Edifice 预制件（单街区内相连的整组连体结构建筑） | | **沿街店面** | 超过 350 种不同类型可高度定制的沿街门面（Storefronts） | | **任务与偶发事件** | 3,000 余处犯罪事件标记、3,000 余处环境生活细节小品（Vignettes） | | **程序化内容目标** | 研发早期目标为输出达到 80% 可直接使用的程序化基础内容，将后续大部分时间留给人工打磨 | ### [08:16](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=496s) 原生程序化架构、地面系统与流式切片 在管线构筑初期，技术美术团队从《日落过载》积累的代码资产中汲取了核心底座，但两者的建造逻辑存在巨大鸿沟：《日落过载》的道路建立在起伏不平的地形（terrain）之上，穿行标记与道具数量极少，且建筑物造型风格奇特多变，使用手工拼砌反而比算法套用更高效；但对于《漫威蜘蛛侠》，整个纽约依赖高度严密的模块化与结构层级。 为了便于在宽屏幻灯片中紧凑展示全岛，Santiago 采用了将“东方朝上”（East Up）的地形布局投影。在预制作阶段，规划好的程序化系统涵盖：地面系统（地形、道路、人行道、基础绿化与集成穿行动作标记）、带穿行标记的建筑系统、行人和车辆交通系统，以及针对全局开放世界的第一轮粗暴式高密度道具铺设（propping pass）。在地面系统中，道路与巷道是万物的源头，Santiago 强调道：“Roads and alleys define this city; everything is dependent on their placement, size, and lane configuration.”（“道路与巷道定义了这座城市；一切都取决于它们的位置、尺寸以及车道配置。”）系统依据关卡编辑器中的曲线与折线，算法派生出沥青路面、人行道、灰色过渡区及全岛防波堤（sea wall）。 为了精细调控地面和系统逻辑，管线引入了基于区域的“修改器区（Modifier Zones）”机制： 1. **地面修改器区（Ground Modifier Zones）**：利用特定多边形、体积或额外曲线，对其下方区域的网格进行裁切、形变、重新赋予地表材质或强行叠加入口结构； 2. **设计修改器区（Design Modifier Zones）**：与之平行的设计侧逻辑区，专门用于控制特定地块内犯罪率生成、行人/车辆交通密集度、AI 巡逻机制及寻路网格分布。 在最终渲染和内存流式加载处理上，团队没有生成一个连贯庞大的统一地面模型，而是按照 128 米 × 128 米的规格将整个开放世界严格切割成正方形的流式瓦片区块（streaming regions）。Santiago 强调这一 128 米规格是整套世界加载体系的核心标尺。在早期的调试系统投影中，有些切片边缘出现了双重线，这是由于历史上为适应不同空间边界做过缩放（scaling）与偏移（offset）留下的演变痕迹。由于管线完整保存了这一历史记录，系统可以准确校验各区块内容是否超出了对应的加载区域。在最终成品游戏中，绝大多数缩放切片仅保留在海岸线边缘，目的是在不破坏内容归属的前提下降低边缘地带无谓的瓦片总数。 ```mermaid flowchart LR accTitle: 地面与修改器生成流式瓦片逻辑 accDescr: 展现从路网曲线输入，经过修改器修饰，再切分打包至 128 米流式区块的过程。 subgraph Inputs["基础输入"] A["道路 / 巷道矢量曲线"] B["车道分布与规格"] end subgraph Generation["算法派生"] A & B --> C["生成基础路面 / 人行道 / 防波堤"] D["地面修改器区<br/>(布尔裁切 / 材质覆盖)"] --> C E["设计修改器区<br/>(巡逻 / 犯罪 / 交通配置)"] --> C end subgraph StreamingTile["空间流式划分"] C --> F["128m × 128m 正方形流式切片"] F --> G["海岸边缘特殊缩放校验"] end ``` ### [11:00](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=660s) 地图切片与地面系统的程序化生成 在《漫威蜘蛛侠》的开放世界底层架构中，整座曼哈顿被精细划分为网格化区块，但并非所有区域都参与程序化流式加载。莱克岛（Rikers Island）与拉夫特监狱（The Raft）在最终版本中没有任何程序化生成的内容，它们完全由美术师手工打造，因此不存在程序化流式加载区域。整个地图基于一套切片坐标体系（Tile ID）管理，编号从 A01 延伸到 X48。每个切片都在层级结构中完整包含该区域开放世界所需的所有子区域（zones）。位于地图右上角孤零零的 X48 切片是开发团队的专用测试区，并在整个游戏研发周期中始终保留。 程序化生成的地面系统通常为每个切片分配 16 个网格模型，这种划分方式使单个资产的数据规模能够适配物理引擎及其他子系统的处理负荷。在展示的调试版本地面中，中央公园（Central Park）呈现出与其他区域截然不同的处理方式：为了契合特定公园风貌并在有限空间内实现最佳布局，中央公园的地面最初完全由人工手工绘制；随后，所有手动迭代的地面成果再经由程序化流水线进行统一处理，最终无缝整合进大世界中。 地面系统的收尾环节实际上也是道具装饰系统（Prop System）的起点。程序在此阶段开始添加第一批地表细节，包括道路车道线、人行横道以及不同街区的专属地面材质。同时，系统还会在此阶段快速铺设第一轮街道道具（如井盖）与人行道道具（如红绿灯、路灯、垃圾桶与行道树），以便为关卡设计师构建基础测试环境。正如 David Santiago 幽默调侃设计团队在城市中穿梭测试时的反应：“so when they're swinging through the city up don't hit that tree onto the building system”（当他们在城市里荡蛛丝时，可千万别撞上那棵树）。 - **切片与调试**：切片范围覆盖 A01 至 X48，右上角 X48 为全程保留的隔离测试区域。 - **地面分块规格**：每个切片通常细分为 16 个独立物理模型，以平衡物理系统与渲染性能。 - **中央公园整合**：手工雕刻地形与程序化管线后处理相结合，兼顾设计自由度与系统规范化。 --- ### [12:40](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=760s) 建筑生成系统与遍历标记优化 曼哈顿错综复杂的摩天大楼群始于极度简化的几何基元。关卡设计师使用立方体、圆柱体以及多边形体积（polygonal volumes）来勾勒建筑物各楼层的基本轮廓。随后，程序化建筑系统介入这些粗模（gray block），根据规则从多套建筑组件库（building kits）中提取构件，自动实例化并附着在白模的各个朝向表面。针对屋顶部分，系统支持对通用屋顶资产进行缩放与平铺；若程序化算法无法拼出吻合的造型，系统便会自动生成定制屋顶模型。紧接着，暖通空调机组（HVAC）与标志性的木制水塔等楼顶道具也会在此阶段自动锚定在建筑外立面上。 除了视觉几何体，程序化系统还承担了构建游戏核心跑酷与蛛丝摆荡逻辑的重任。系统会自动生成所有摆荡体积（swinging volumes）与各类边缘路径（ledge paths），为蜘蛛侠的移动遍历（traversal）提供底层标记数据（markups）。然而，城市道路的每次拓宽或微调都会引发连锁反应，迫使建筑形态随之重构。针对这一痛点，开发团队特别为建筑工具设计了“仅重新计算标记”（recalculate markup only）模式。David Santiago 解释道：“our building tool was originally designed with a recalculate markup only mode so if a building was hand modified or if it was complete built from scratch our system could automatically read that edifice prefab generate the markup and that markup was always optimized by joining all segments to minimize the number of curves minimize the markup actors.”（我们的建筑工具最初设计了‘仅重新计算标记’模式，因此无论一栋建筑是经过人工局部修改还是完全从零搭建，系统都能自动读取该建筑预制件并生成标记，且系统始终会通过合并所有线段来优化标记，从而最大程度减少曲线数量并精简标记 Actor 数量。） ```mermaid flowchart TD accTitle: Building and Traversal Procedural Pipeline accDescr: Shows the transformation from basic primitive volumes to detailed buildings with optimized traversal markups. subgraph Geometry["几何生成阶段"] A["白模体量<br/>(盒体/圆柱体/多边形)"] --> B["表面构件实例化<br/>(建筑套件 Kits)"] B --> C["屋顶与道具生成<br/>(平铺屋顶/定制模型/水塔/HVAC)"] end subgraph Traversal["遍历标记生成与优化"] C --> D["遍历标记自动化提取<br/>(摆荡体积 / 边缘路径)"] D --> E["标记段合并优化<br/>(减少曲线数量 & 精简 Actor)"] F["手动调整/从零搭建建筑"] -->|"仅重新计算标记模式"| E end ``` --- ### [14:24](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=864s) 行人与车辆交通系统的程序化布设 依托道路网络，人行与车行交通系统实现了全流程程序化生成。对于人行系统，流水线首先在人行道上布置静态行人分布体量（static pedestrian volumes），根据设定密度填充初始驻留人群，随后系统再将部分静态行人“提拔”（promoted）至动态行走网络中。接着，程序会自动在人行道拐角之间、横穿马路的斑马线之间生成路径网络，并深度吸纳第三方组件的内置路径——例如地铁站出入口与公交候车亭自带的上下楼梯与绕行动线。广场和公园中由设计师手绘的曲线路径同样被自动接合进网络中。 这些路径交织形成底层的行人交通节点（pedestrian traffic nodes），并与十字路口的信号灯相位（traffic phases）强绑定。行人行进至节点时能够根据红绿灯信号判断行止，并在绿灯时过街、红灯时驻足。针对现实行人的行为模拟，David Santiago 调侃道：当绿灯变黄时，行人们通常会加速冲过十字路口，“well except sometimes you know they just stopped”（好吧，除开有时你懂的，他们就直接愣在原地停住了）。开发团队引入了多色调试视图来验证每个链接的相位逻辑，确保行人在每个决策节点能够自主选择是横穿马路还是沿街角转向。 ```mermaid flowchart LR accTitle: Traffic Systems Generation Overview accDescr: High-level data flow for generating procedural pedestrian and vehicular networks. subgraph PedestrianFlow["行人网络生成"] P1["人行道静态体积"] --> P2["拐角/斑马线路径"] P3["手绘路径 & 车站动线"] --> P2 P2 --> P4["行人决策节点<br/>(信号相位绑定)"] end subgraph VehicleFlow["车辆网络生成"] V1["车道模板配置"] --> V2["行驶/转弯合规路径"] V3["车位体积<br/>(排除消防栓/小巷)"] --> V2 V2 --> V4["车行交通节点<br/>(路面标线映射)"] end ``` 车辆系统的逻辑与行人类似，但对道路规整度有着更严苛的约束。系统首先根据街道宽度匹配不同的车道预设模板（涵盖车道数与单向/双向流向），行人系统生成的斑马线则自动转换为路口的车辆停止线。针对路边停车位，程序使用专门的体量进行沿街车辆填充，并自动在公交站、消防栓、小巷出口等禁停区域打断并生成避让区间。小巷（alleys）以受限路径的形式接入主干道网络。对于双向两车道或多车道林荫大道（avenues），系统精准配置了各车道的转弯规则：例如部分车道允许右转或直行，而特定内侧车道在对应交通相位内则被强制限定为单一直行或左转。 - **动态晋升机制**：静态体量中的待机行人可动态升级为遵循路径行进的移动 AI。 - **多源路径融合**：地铁站、公交亭的预制动线与设计师在公园手绘的贝塞尔曲线自动与程序化网格完成对齐焊接。 - **精细转弯拓扑**：车道节点按真实交通规范限制转向自由度，并驱动道具系统自动喷涂路面导向箭头。 --- ### [18:36](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=1116s) 装饰道具系统、第三幕废墟与水坑机制 装饰系统（Decor System）统筹管理了整座城市的道具、贴花（decals）以及复合行人预制件（pedestrian prefabs）。程序化算法负责以最优密度分布街道细节，包括井盖、车辆刹车印、柏油修补补丁，以及人行道上的消火栓、邮箱、街灯、行道树等海量资产。与此同时，包含复杂行为树的行人预制件被放置在特定场景中，例如热狗摊前的食客排队预制件、招揽出租车的行人或街头转广告牌的演员。这些驻留角色同样能无缝融入通用行人逻辑中：“so say people are waiting at a hotdog cart they would wait there and then they could be promoted to walk along the along the path or flee from a crime if necessary”（比方说有人在热狗摊前排队等待，他们可以在那儿待机，但如果有需要，他们就能被激活升级为沿路径散步，或者在发生罪案时仓皇逃窜）。 道具生成管线面临的最严苛考验来自游戏的第三幕（Act 3）。此时曼哈顿陷入混乱，整座岛屿必须呈现出满目疮痍的灾后废墟感。David Santiago 指出该阶段最大的工程矛盾：“The challenge there was to make it look like there is litter and debris everywhere but not block any path needed by vehicles pedestrians crimes vignettes missions etc.”（那里的挑战在于，必须让场景看起来到处堆满了垃圾和残骸，但又绝对不能阻塞车辆、行人、罪案事件、环境小剧场以及主支线任务所需的任何有效路径。）道具工具凭借高精度的排他性体积判断，成功在不破坏各游戏系统寻路逻辑的前提下堆叠出密集的瓦砾效果。 在演讲最后，Santiago 谈及了游戏发售前后引发社区热烈讨论的“水坑缩水门”技术内幕，并展示了视口中密布的程序化水坑调试蓝圈：“those blue circles there procedurally placed puddles if wetness reaches a certain threshold in the material which uses a random seed a puddle is place in the world and active during rainy atmospheres and then it will splash and ripple and such”（画面上那些蓝色圆圈就是程序化放置的水坑。如果材质中的潮湿度在结合随机种子后达到了特定阈值，水坑就会被放置到世界中，并在雨天氛围下激活，进而展现飞溅水花和水波涟漪等效果）。在完成了地面、建筑、交通与环境道具的全套构建后，整个开放世界的视距远景烘焙便顺理成章地进入了下一阶段——冒名替身系统（Impostors）。 - **废墟生成约束**：第三幕的垃圾与瓦砾程序化散布严密遵循避让规则，严禁干涉动态任务触发区与交通动线。 - **水坑触发阈值**：基于地面材质湿度参数与固定随机种子（Random Seed）动态生成，具备专属的雨天物理涟漪响应。 - **预制件状态机切换**：互动商摊的 NPC 兼顾闲置表演、常规巡逻与犯罪遭遇战中的“恐慌逃跑模式”（Flee Mode）。 ### [20:53](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=1253s) 远景伪体（Imposters）系统与最初的“庆祝时刻” 在完成了大量程序化内容生成后，整个曼哈顿的建筑物都会被转化为远景“伪体”（Imposters）。俯瞰全城，每一个建筑结构都有其对应的伪体版本。由于真实几何体极其复杂，管线会从整个建筑预设（edifice prefab）的高模几何体中提取并生成一个简化模型，随后利用这个简单模型进行纹理投影并烘焙出图集（Texture Atlas），再将更新后的伪体填充到对应的伪体分区（Imposter zones）容器中，从而极大优化内存与渲染性能。只要地表结构、材质或光照发生变化，系统就会不断重新生成伪体。在游戏中玩家看到的绝大多数全景，本质上全是由伪体构成的。David Santiago 指出，在运行时同屏最多仅加载 12 个高精度区域（high-res zones），而即便在这 12 个区域中，大多数也仅以最低层级的 LOD 运行，其内容体量非常接近伪体。 在历时不到一年的前期制作（pre-production）中，团队完成并实现了构建开放世界曼哈顿所需的所有底层系统。资产生成、打磨与伪体管线看似全部就绪，Santiago 幽默地回忆当时的轻松心态：“所以到了派对时间了！庆祝的时候到了，我们可以坐下来轻松做游戏了，但是设计团队呢？我怎么在派对上完全没看到设计团队的人影？到底发生什么事了？”（“So it's party time, it's party time! We can just sit back and make the game. But the design team—I don't I don't see the design team at the at the party at all. What what's going on?”） ### [22:22](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=1342s) 设计团队的新需求：动态遭遇、标记与严苛的生成规则 正如环境管线以为一切尽在掌握时，策划和玩法设计团队带来了大量复杂的程序化新需求。首当其冲的是“动态遭遇”（Dynamic Encounters），包括街头犯罪（Crimes）和生活化生活剪影（Vignettes）。设计团队要求在整个开放世界中程序化放置 29 种不同的犯罪事件以及 25 种不同的小型事件剪影，每一种都依赖极其严格且不同的规则集。此外，随着主角蛛丝摆荡新增了大量动作套件，环境上需要增加更多导航标记（Markup），同时机器人民众（Bots）与敌人的 AI 寻路也对地形标记提出了全新要求。 Santiago 以“喷气背包犯罪任务”（Jetpack Crime）为例，详细阐述了规则的复杂程度： - 系统必须在城市中搜寻一处拥有至少 64 平方米可用战斗空间的屋顶。 - 该屋顶必须在 40 米范围内同时存在另外两个同样具有 64 平方米战斗空间的屋顶。 - 这两个相邻屋顶与原始屋顶的垂直高度差必须在上下 20 米之内。 - 三个屋顶之间必须有畅通无阻的路径，以便系统铺设 AI 巡逻导航网格（Navmesh）。 - 每个屋顶还必须有顺畅的导航路径能够直接通往下方的人行道或小巷。 系统会自动遍历整座城市，根据当前世界中的建筑形态筛选出所有符合几何条件的点位，再依据每个街区（District）设定的密度指标批量放置喷气背包犯罪，并自动生成所有专供角色和 AI 使用的标记数据。 ### [24:00](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=1440s) 错综复杂的管线依赖与多部门联动 这些动态遭遇内容并非孤立存在，它们与周围环境深度绑定，形成了牵一发而动全身的网状依赖关系： - 犯罪和小区剪影完全依赖周围的地形与建筑。一旦策划修改了一条道路或巷道，由该道路界定的一整组连续街区（contiguous blocks）及其内部的所有瓦片（Tiles）——包括建筑形态、犯罪事件等——都必须全盘重构。 - 仅仅移动一个犯罪事件的位置，其复杂度就可能波及多达 9 个地块。因为犯罪事件会反向驱动道具（Props）的排布规则，系统必须自动剔除犯罪现场区域原本配置的静态道具。 - 修改一栋建筑，不仅会直接影响蛛丝摆荡穿越（Traversal）路线和犯罪点位，还会彻底打乱预烘焙光照。 - 就连音频团队也提出了强烈的程序化需求：他们需要程序化系统来自动生成全城的混响体积（Reverb Volumes），并在街道特定区域动态散布合适的人群音效（Audiences）。 为了在高度程序化生成的机制下保留手工雕琢（Handcrafted）的高品质，团队意识到必须建立一套分阶段的生产管线，使内容能够循序渐进地迭代、审核并锁定。尽管团队选择 SideFX Houdini 作为核心开发工具，但 Santiago 强调底层算法完全通用，Insomniac 内部拥有大量独立于 Houdini 或任何第三方 DCC 软件的原生程序化生成代码。 ```mermaid flowchart TD accTitle: 三阶段开放世界生成管线 accDescr: 展示从 Phase 1 到 Phase 3 的开放世界程序化构建流程及跨阶段持续生成的数据 subgraph Phase1["Phase 1: 主世界布局 (World Layout)"] A["设计道路曲线 / 导入底图"] --> B["程序化生成地面 & 规则设定"] B --> C["体量化建筑摆放 & 基础建构集"] C --> D["自动提取小巷曲线 & 穿越测试"] end subgraph Phase2["Phase 2: 程序化内容主体构建 (Bulk Generation)"] E["建筑细化与立面装配"] F["动态犯罪 / 剪影 / 道具分布"] G["AI & 英雄动作 Markup 生成"] end subgraph Phase3["Phase 3: 打磨与收尾阶段 (Polish Stage)"] H["精细化艺术手工打磨"] I["管线锁定与最终调优"] end Phase1 --> Phase2 Phase2 --> Phase3 subgraph Continuous["各阶段持续迭代计算"] J["远景伪体 (Imposters)"] K["光照数据 (Lighting)"] L["音频混响 & UI 数据"] end Phase1 -.-> Continuous Phase2 -.-> Continuous Phase3 -.-> Continuous ``` ### [26:47](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=1607s) 阶段一：道路网络、街区生成与通行测试 在 2016 年左右确立的三阶段管线中，**阶段一（Phase 1）**的核心目标是确立主世界布局（Main World Layout）： 1. **道路与街区初始化**：曼哈顿最初的版本源自设计师在 Illustrator 中绘制的一张二维地图。程序化系统读取图像像素，将其转化为编辑器内的矢量曲线与多边形图元，并根据策划标记的颜色数据随机放置矩形体量盒（Box buildings），以此粗略表达不同区域的建筑高度与体量范围。 2. **道路几何与交通规则**：进入关卡编辑器后，策划可以直接调整曲线以定义道路走向、单双向交通、道路宽度（从外侧人行道边缘到对面人行道边缘）以及街宽（从路肩到路肩的 Curb-to-curb 距离）。起初策划仅手动指定主干道（Avenues），其余街道全由程序化系统接管。团队只需输入规则偏好，例如“设定 70% 的道路为单行道，其中 70% 的单行道采用单车道加单侧停车位布局”，系统便会自动推算全城可行的交通动线，并生成真实曼哈顿中常见的交替单行道网络。随着开发推进，策划才针对特定追逐关卡或剧情点手动调整部分道路尺寸与车道分配。 3. **建筑体量与穿越体验验证**：依据道路曲线生成地面后，策划设置建筑边界参数。程序化系统利用基础建筑构件集拼装出建筑的大致轮廓并附带标记。策划此时可以在城中摆荡，验证建筑剪影与天际线是否能引导预期的移动路线，以及各街区密度与形态是否合理。Santiago 特别指出，当时制作阶段非常早期，蜘蛛侠甚至还没有实装完整的蛛丝飞踢（Web Zipping）、跑酷（Parkour）或定点跃出（Point Launching）等招式，团队只能在动作受限的条件下努力验证并签署通过基础布局。 4. **小巷曲线的自适应生成**：在阶段一中，随着独立的建筑逐步填满街区，程序化系统会自动识别建筑物之间的空隙并计算出“小巷曲线”（Alley curves）。之所以必须生成严谨的小巷曲线而不是单纯将缝隙留空，是因为这些小巷在玩法上是可通行的（Drivable）：它们既用于小巷追逐战和犯罪现场，也充当动态交通的备用分流通路——当主街被突发犯罪或生活事件堵死时，普通车辆可以通过小巷曲线绕行绕路。此外，这些曲线还会反哺地表材质替换、垃圾杂物道具排布、专属光照以及音频环境音等后续系统的生成。 一旦阶段一的街道网络与建筑毛坯彻底敲定，管线便推进到**阶段二（Phase 2）**——这是程序化系统承担工作量最大的核心阶段。 Santiago 强调，各个模块之间都存在回溯依赖关系，如果前端发生改动，整个管线必须具备稳定自动重算的能力，以保证开发版本随时可玩。 ### [30:55](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=1855s) 程序化管线的黄金法则与 80/20 完成度目标 在制作流程的这个阶段，团队制定了一条至关重要的铁律。David Santiago 严肃地告诫团队：“这最后一条非常重要，这意味着在这个阶段，美术和策划绝不能手动修改程序化系统生成的任何东西；他们必须通过调整程序化系统的可控参数和输入来促成改变，如果不这么做，他们就有丢失工作成果的风险。”在被称为美术多边形线传递（Art Polyline Pass）的环节中，环境美术师有机会将策划白盒区域中的简单图元替换为多个多边形体量，从而精细雕刻建筑的外形，并为建筑指定具体的建筑资产套件（Architectural sets）。此时美术师也可以调整或删除巷道曲线，表明此处不需要可行车的胡同，程序化系统随后会重新为他们计算地面。 这一阶段（Phase 2）实际上由两个高度相似的环境模块化阶段组成：第一阶段的模块化迭代主要产出最终的建筑布局与体量轮廓，第二阶段或第三阶段则允许更换具体的建筑风格和道具摆放。按照最初设计，在第二阶段的第一轮迭代结束时，系统应当已经精准放置了行人、交通、生活小景（Vignettes）、犯罪事件（Crimes）以及各类道具。程序化系统的核心指标是实现“80% 完成度”——即 80% 的程序化生成内容直接达到可发售水准，或者说整体完成度达到 80%，使得美术和策划仅需承担传统手工流程中最多 20% 的工作量。这意味着原本耗时一周的美术工作缩短为一天，耗时五周的工作缩减为一周。系统依照规则和度量标准快速铺设并大体剔除无效内容，但并不强求达到最终规格，因为后续的手工打磨（Manual polishing passes）会负责最终的微调。进入第三阶段后，在策划与美术最终验收确认的前提下，各团队便可专注手工雕琢各自的细节，而程序化系统则退居二线，转去处理标记（Markup）、远景伪象（Impostors）、光照、音频及性能验证工具。 - **核心原则**：禁止直接手改程序化输出物，所有调整必须通过修改生成参数与输入源完成，否则重新烘焙时手工改动会被彻底覆盖。 - **80/20 效率模型**：程序化系统负责大体对齐和粗略剔除，将原本 1 周的美术工作压缩至 1 天，后续 20% 的精修交由人工完成。 - **阶段分工**：第一阶段确定道路与白盒结构；第二阶段锁定最终体量并铺设生活内容与犯罪事件；第三阶段冻结主干并转入细化打磨与性能优化。 ### [33:05](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=1985s) 理想蓝图：全岛均匀推进与逐区迭代 为了让整套管线高效运转，团队制定了一套严密的生产规划：全岛应当沿着统一的完成度阶段同步演进。在深入任何局部细节之前，必须先锁定粗略的地图布局、路网及整体结构，定义出曼哈顿的关键空间与地标建筑。管线设计的核心设想是“按区域逐步推进（District by District）”，每次专注一个区域，在区域内部沿着上下游依赖关系迭代深化，将其推升至下一个完成度等级。 ```mermaid flowchart TD accTitle: 理想的逐区模块化迭代管线 accDescr: 展示从全岛系统锁定到按区域逐步推进美术与程序化放置的理想流程 subgraph 全岛级系统 ["全岛级基础 (Island-wide Systems)"] A["阶段一：锁定全岛路网与地图布局"] --> B["生成基础地面并定义关键地标"] B --> C["转换为全岛引用的建筑预制件"] end subgraph 逐区递进 ["逐区迭代推进 (District by District)"] C --> D["阶段二第一阶段：区域美术模块化 (确定建筑体量)"] D --> E["运行程序化系统：放置犯罪、小景与道具"] E --> F["区域达到阶段完成度，美术轮转至下一区域"] end ``` 这种设计在理论上极为完美：只要全岛以均匀的打磨水平逐区推进，每个区域在逻辑上都可以被视作一座相对独立的“孤岛”。由于每个区域具备独特的空间属性与明确的边界条件，即便相邻区域之间存在共享的边界地块（Edge tiles），管线也可以通过专门的边界处理逻辑优雅解决。以格林威治区（Greenwich district）为例，当阶段一的全岛路网与粗模剪影锁定并转为引用的预制件（Prefabs）后，负责该社区的美术师便入驻开展第一轮模块化作业以锁定体量。一旦该区域达标，程序化系统便会集中放置该区域的犯罪事件、小景与道具，美术人员随后即可抽身前往下一个区域。 ### [35:33](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=2133s) 现实冲击：连锁多米诺效应与瓦片脱节 然而理想规划迅速被严酷的生产现实击碎。美术师在深入各个街区和区域时发现，为了营造出特定空间的情调与街区特色，他们不得不频繁微调道路和胡同的宽度、走向或位置。致命的是，一个区域内一条小路的位置或方向改变，会直接破坏多个相连区域的交通流向；为了修补交通流，团队不得不联动修改更多道路。这种连锁反应导致了毁灭性的多米诺效应，将开发进度直接踹回流程图的第一步。 更棘手的是，由于主线故事、里程碑演示（Demos）、任务关卡和立体模型（Dioramas）的开发优先级各有不同，不同区域的推进节奏完全脱节。甚至在同一个区域内，紧挨着的两个网格瓦片（Tiles）都处于截然不同的状态——一个还是粗糙白盒，另一个却已经进入精细打磨。而程序化系统放置大部分游戏内容的前提，是对应网格必须完成环境美术的第一轮模块化并取得多项批准。由于上游地块无法统一完成，生产流彻底失衡。Santiago 回忆起这段经历时感叹道：“这引发了超出我们想象的多米诺骨牌效应。”他原本以为这种脱节只会发生在边缘或海岸地块（因为那里游戏玩法少、容易被搁置），但现实中由于一个街区往往跨越多个瓦片，微调一条胡同就会波及周围大片区域的 UV 纹理连续性，乃至彻底打乱道具与犯罪事件的摆放。面对剧情地点的频繁搬迁、中庭与码头等新要素的临时加入，以及随之而来持续变动的英雄与 AI 寻路标记，Santiago 坦言：“我个人当时感到非常焦虑和沮丧，因为大家好像完全没有按照我们辛辛苦苦做出来的管线来走。” - **多米诺骨牌效应**：修改单条道路或胡同会打乱全局交通流，迫使关联道路重构，让开发进度频繁倒退回最开端的路网生成模块。 - **瓦片状态割裂**：里程碑和任务需求导致相邻网格处于不同完成阶段（一侧为白盒，另一侧已打磨），直接卡死了依赖完整地形的程序化内容铺设。 - **边界连锁破坏**：大楼建筑群与街区常横跨多个网格，局部的尺寸微调会撕裂跨瓦片的 UV 贴图连续性，使原本已手工摆放好的资产错位。 ### [38:05](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=2285s) 依赖重构与 100% 铺设的保底哲学 面对濒临失控的开发局面，各部门组长（Leads）迅速集结展开攻坚。经过数周内多场针对不同专项的密集研讨，团队开始痛苦但必要地重构流程。团队必须摸清策划、美术与玩法各方的底线：底层地面和建筑究竟何时才能达到“允许下游系统安全介入”的完成度？地块与区域究竟推进到哪个节点，其后续的美术微调才不会反噬下游的犯罪与任务系统？只有厘清这些节点，系统才能在无惧“回滚到流程图起点”的心理负担下，将数据平稳交接给下一个程序化模块。 ```mermaid flowchart LR accTitle: 基于外部依赖程度的内容分步铺设示例 accDescr: 展现从低依赖的红绿灯到高依赖的邮箱的分模块程序化放置逻辑 subgraph 依赖较少 ["轻度依赖模块"] R["道路走向"] --> TL["交通信号灯"] C["人行道拐角"] --> TL end subgraph 依赖较多 ["深度依赖模块"] TL --> MB["邮箱及复杂街道道具"] A["胡同出口位置"] --> MB B["公交站点"] --> MB CW["斑马线位置"] --> MB end ``` 吸取教训后，团队确立了一套全新的管线哲学：尽可能切断并分支化（Branch）各个网格区域之间的依赖，让每个网格瓦片能够最大程度独立编辑；同时，将所有的程序化生成操作依据其“前置依赖项”进行高度模块化拆解。例如，交通信号灯仅依赖于道路走向和人行道转角，一旦路口几何确定，系统便可立即独立生成信号灯，无需等待其他要素；而像邮箱这类道具，则额外依赖避开胡同口、公交站和斑马线等规则，因此被剥离为更后置的专属模块。 在规则制定上，团队不再苛求程序化生成具备 100% 的绝对精准度，但确立了一条底线原则：**必须确保 100% 规划的程序化内容都被生成并放置进场景中**。Santiago 解释了背后的权衡逻辑：系统优先将全城规划的 160 个犯罪事件全部铺设到位，即便系统对某些摆放位置的置信度不高、需要人工后续去“挪正”，也远好过系统因为条件严苛只生成了 120 个，进而强求策划和美术在庞大的城市里自己去数漏了哪 40 个、再手动到处补齐。系统会通过度量标记标注出那些“位置在粗略范围内但置信度较低”的资产，提示人工介入。这种在生成初期标记并校验置信度的机制，最终演变为了贯穿整个项目后期的大规模内容验证系统（Validation System）。 - **依赖解耦与分支化**：打破区域间死板的全局级联，根据网格独立的几何边界拆分数据，将各阶段操作按前置依赖精细拆分成微模块。 - **100% 内容覆盖原则**：宁可全量铺设后再由人工微调低置信度资产，也绝不因边界情况漏放资产，避免让开发人员陷入排查资产缺口的认知负担。 - **置信度校验系统**：系统自动标出处于合理区域但可能存在冲突的资产，为后续的自动化验证和 BUG 筛查工具奠定了底层逻辑。 ### [41:06](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=2466s) 城市秩序重建与后期管线突发挑战 在推动曼哈顿程序化管线落地的过程中，“为城市带来秩序”（bringing order to the city）的核心在于让所有团队步调一致，并将尽可能多的连续地块（contiguous tiles）推进到新模块化流程所需的完成度。最初团队要求每个行政区必须是一整套连续地块，但在紧迫的工期压力下标准转变为“管它是哪个区，只要给我连在一起的地块就行，这样我们才能把游戏做下去”。新流程将能够保留手动调整的程序化系统与美术、策划的工序深度交错（interleaved）。然而，这种工作流的融合“说起来容易做起来难”（easier said than done）。 紧随其后的是一系列生产后期的突发技术挑战： - **爬墙与边缘标记问题**：新加入的资产（尤其是全新店面 storefronts）破坏了原有的攀爬检测，必须通过程序化系统为特定的建筑套件（building kits）追加边缘路径标记（ledge path markup）以及爬墙碰撞体（wall crawl collision）。 - **幕次系统（Act System）与覆盖区域（Overlay Zones）**：团队很早就知道游戏存在不同幕次、局势和时间变化，但在制作后期才搭建了覆盖区域系统。该系统用于精准控制世界状态（昼夜交替、天气变化、不同剧情幕次）。例如商店在白天开门、夜晚关门、第三幕关闭；街头行人群体根据情境动态切换；第二幕与第三幕中街头遍布垃圾和特定事件小品（vignettes）。该方案于 2017 年 10 月提出，2017 年 12 月完成设计，经历跨年假期后于 2018 年 3 月彻底完工，最终在游戏发售前数月顺利冻结全部内容。 - **任务空间与音频碰撞体重构**：后期的任务空间调整迫使团队在多个区域重新编排开放世界玩法。此外，程序化系统还接管了音频碰撞体的生成——中央公园等大面积自然区域需要自动生成定制的音频碰撞网格，以精确匹配材质展现的视觉纹理。 ```mermaid flowchart TD accTitle: Overlay Zones State Control System accDescr: 覆盖区域系统根据时间、天气与剧情幕次动态控制开放世界实体的状态表现。 subgraph StateInputs ["世界状态输入"] A["时间 / 天气系统"] B["剧情幕次 (Act 1 / 2 / 3)"] end subgraph OverlayCtrl ["覆盖区域系统 (Overlay Zones)"] C["实体行为与环境置换引擎"] end subgraph GameWorldState ["城市表现输出"] D["商铺开闭状态<br/>(白天开放 / 晚间与Act 3关闭)"] E["人群生成与密度分布"] F["动态街道资产<br/>(Act 2/3 垃圾堆与事件小品)"] end A --> C B --> C C --> D C --> E C --> F ``` ### [43:36](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=2616s) 核心经验教训：解耦依赖、层级模块化与避免过度设计 David Santiago 总结了程序化开发中的核心架构准则。尽管严格的工作流最理想，但生产管线必须为不可避免的变更留出足够的弹性。首先，所有程序化生成的元素一旦与依赖项一起冻结，团队就可以彻底翻篇继续推进。其次，必须对程序化生成的内容进行**层级模块化（hierarchically modularize）**。以红绿灯为例，一旦满足其放置依赖，就应将其封装并在该层级生成，随后它又能作为后续道具的依赖输入。若将所有街道道具塞进单个巨型模块，会导致所有潜在依赖相互纠缠、牵一发而动全身。 此外，Santiago 严肃告诫千万不要“过度定义目标”（over-define goals）或追求绝对完美的生成规则： > “首先，制作一个完美的系统需要花费更长的时间——我认为据说制作一个完美的系统需要无限的时间；其次，如果你只按照严苛的条件去放置物体，你根本找不到多少符合条件的地点。”（“First of all, it takes a lot longer to make the perfect system. I think supposedly it takes an infinite amount of time to make the perfect system. And then second, if you only place something with strict criteria, you're not going to find that many locations that meet the criteria.” —— David Santiago） 严苛的规则不仅导致生成率骤降，还迫使美术人员不得不从零手动添加资产，徒增工作量；相反，让系统大致摆放到位，美术只需顺手“微调”（nudge）一下位置，成本要低得多。规则越多，约束与依赖就越多，这与降低阶段依赖的初衷完全背道而驰。 针对复杂逻辑，Santiago 提出了拆分**复合依赖（compound dependencies）**的规则。当单个资产存在多套截然不同的放置规则或大量分支逻辑时（例如街头犯罪事件既能发生在十字路口中央并对齐车流，也能发生在建筑物楼顶），绝对不能把规则写在同一个模块内。应当将其拆分为独立流程：在道路依赖就绪时运行道路犯罪生成，在建筑依赖就绪时运行屋顶犯罪生成，防止复合依赖污染整个网络并拖垮周边节点。 ### [46:56](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=2816s) 资产标记与程序化智能验证机制 在混合手工与程序化生成的世界中，必须对内容进行严密的标签标记（tagging）。Santiago 指出：“了解某样东西是否属于程序化生成，意味着你能够信心十足地反复重新生成它，而不会摧毁任何手工制作的成果。”（“Knowing if something is procedural means you can confidently regenerate it again and again without destroying any manual work.” —— David Santiago） 工作流中的违规操作极易带来隐患：例如美术人员围绕一个程序化摆放的热狗摊进行手工打磨装饰，但新增的零碎物件（苏打水罐、椒盐卷饼）没有挂载在正确的父子层级（hierarchy）之下。一旦程序化系统重新判定附近有更佳点位并将摊位移开，原地就会遗留下诡异悬空在半空中的汽水罐和饼干。 ```mermaid flowchart LR accTitle: Procedural Validation and Fallback Pipeline accDescr: 程序化验证机制对异常资产进行确定性删除、微调修复或置于不生成状态供人工介入。 A["资产指标验证<br/>(如刷怪点陷入实心建筑)"] --> B{"能否完全确定<br/>修复方案?"} B -->|"确信无效"| C["自动删除 (Delete)"] B -->|"可根据规则修正"| D["自动微调位置 (Nudge)"] B -->|"无法百分之百确信"| E["标记异常<br/>置入不生成状态 (No-Spawn)"] E --> F["策划 / 美术手动介入修改"] ``` 为了应对成千上万动态物件的合规性，程序化系统演化出了严格的**自动化验证（procedurally validate）**管线： - **明确无效**：如果生成点（如刷怪点 spawner）陷在没有内部结构的实心建筑内部且彻底无法使用，系统直接执行自动删除。 - **微调修正**：如果移动到建筑外部依然可用，系统按照预设规则知识库自动微调偏移。 - **存疑标记与抑制生成**：当程序化系统对调整方案缺乏把握时，绝不盲目更改，而是将资产置入一种“不构建/不生成”（will not build or spawn）的安全挂起状态，直到策划或美术亲自排查介入。在制作后期，大量犯罪任务中的可破坏物（breakables）和可投掷物（throwables）都由这套智能系统高效处理，极大地解放了人力。 ### [49:11](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=2951s) 成果复盘、交付时间线与现场 Q&A 开启 复盘整个项目，Santiago 透露团队的原始目标是实现 80% 的程序化内容达到发货标准，将美术和设计的常规工作量压缩至原本的 20%。团队不仅超额达成了 80% 的程序化指标，而且挤出来的所有时间并没有变成“休闲时光”（leisure time），而是全部被重新倾注到了更多的迭代、更深入的手工雕琢与极致打磨之中。 Santiago 给出了震撼的时间节点：展示地面依赖脆弱性的道路弯角区域直到 **2018 年 1 月下旬**才正式冻结；而对地表网格进行的最后一次程序化修改，发生在 **2018 年 6 月下旬**——距离游戏正式上架售卖仅剩两个多月。在向索尼互娱、PlayStation、漫威游戏、SideFX 以及技术顾问 Jeff Hannah 和全体 Insomniac 团队致谢后，演讲进入问答环节。 现场第一位提问者来自《少数幸运儿》（*We Happy Few*）团队。该提问者表示他们也使用了一套规模较小但架构类似的程序化系统，但在研发中遇到的巨大痛点是如何向美术人员传达修改手工地块（handmade tile）带来的连锁后果，因为手内地块与周边的程序化生成之间存在复杂的级联依赖，美术人员往往难以凭空预见一个微小的手工变动会在 Houdini 庞大网络中引发怎样的雪崩效应，提问者就此向 Santiago 询问 Insomniac 是如何跨越这一沟通鸿沟的。 ### [51:33](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=3093s) 美术师的转变与程序化管线的学习曲线 在引入这样一套复杂的管线初期，团队内部不可避免地存在阻力。美术师们通常会有一种犹豫心态，不愿意放弃亲手精细搭建每一栋建筑的控制权。然而，态度的转折点来得极快——当美术师们发现自己只需要简单调整一个形状（safe/shape），系统“砰”的一声就能自动完成所有物件的实例化排布时，大家的反应瞬间变成了惊喜：“噢，我喜欢这个！”尽管磨合期难免经历一些小磕绊，但美术师们迅速爱上了这种工作方式：他们只需绘制折线（polyline）确定所需的建筑轮廓，就能立即看到结果并直接放进整条管线中进行测试。 ```mermaid flowchart TD accTitle: 建筑生成与程序化管线交互流程 accDescr: 展示美术师绘制折线到程序化实例化的流转，以及手动覆盖或切断程序化连接的选择。 subgraph Iteration["美术原型迭代"] A["绘制建筑轮廓折线 (Polyline)"] --> B["程序化自动实例化 (Instance)"] B --> C["即时管线测试与验证"] end subgraph Decision["细化与打磨决策"] C --> D{"是否需要精细微调？"} D -->|"常规规则"| E["遵循继承层级与覆盖规则 (Overrides)"] D -->|"完全定制"| F["切断程序化系统关联 (Cut off)"] end ``` 接下来的挑战在于理解管线的数据结构细节。美术师必须通过不断的试错来掌握哪些内容可以修改、哪些绝对不能动、哪些改动会被保留、哪些会被重写，以及如何正确处理手动覆盖（overrides）。数据结构中的依赖关系和层级规则都需要时间来熟悉。得益于负责开放世界的团队规模非常小，让全员步入正轨并没有想象中那么困难。经过数不清的快速迭代，美术师们学会了拿捏程序化生成与手动干预的边界。David Santiago 解释道，当遇到极端特殊的场景需求时，美术师也可以选择彻底脱钩：“Sometimes at some points, they would just say, 'I'm cutting this off from procedural systems at all,' and our system'd say, 'Okay, fine.'” 系统并不强求所有资产都必须死板地绑定在程序化体系中。 - 美术师在初期不愿放弃手工搭建，但看到折线生成与自动实例化带来的速度提升后迅速接受了新流程。 - 团队通过试错掌握了数据依赖关系、覆盖机制（overrides）以及哪些元素可保留的设计准则。 - 由于开放世界制作组规模精简，团队磨合和规则推行的整体阻力相对可控。 - 管线允许美术师在特定建筑上完全切断（cut off）与程序化系统的关联，转为纯手工打磨。 --- ### [53:23](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=3203s) 建筑套件化与替身模型（Imposters）的隐形 LOD 观众提问谈到曼哈顿城中存在海量的建筑砌块，并且随着玩家穿行城市，不同部件会独立切换 LOD，想了解程序化系统如何在性能可控的前提下管理如此庞大的物体量。David Santiago 回应称，程序化系统在最初构建城市时，只使用特定的一组建筑套件（building kits）。每个套件都包含环境美术师设计的一套标准必需组件。美术师整体导出整套套件后，必需组件会被录入程序化系统的资产库中，而多余的辅助装饰件（auxiliary pieces）则留给后续人工打磨时选用。程序化系统本身其实很“单纯”，它只知道不同建筑风格的组件尺寸以及特定的偏移量（offsets），随后根据度量指标（metrics）进行程序化放置；后期美术师完全可以手工快速替换风格或塞入定制模型。 在优化如此庞大的内容体量时，所有模型都严格遵循 LOD 规范，而替身模型（imposter system）更有一项独特的技术黑科技。通常情况下，标准 LOD 存在其精度下限，但对于建筑预制件拼成的复合模型，研发团队在模型的 JAM 文件中埋入了一个对常规渲染完全不可见的特殊 LOD。这个极低精度的几何体专门用来给替身系统读取。当系统需要将一整栋由多个预制件拼成的复杂建筑合并简化为单一模型时，就会提取这些隐藏的极简网格，从而在极远距离生成极致紧凑的单体模型。 - 程序化系统在初始构建阶段仅感知建筑套件的标准组件尺寸与偏移数值，不承载过多复杂的额外逻辑。 - 环境美术师设计并导出一整套 Building Kit，必需件入库供系统自动拼装，辅助件供后期手动雕琢。 - 替身系统（imposter system）可识别模型中内嵌的“不可见 LOD”，利用极简几何体生成更轻量的远景单体合并模型。 --- ### [54:41](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=3281s) 迭代耗时：从单楼实时生成到整城通宵烘焙 关于迭代生成耗时，观众提问关注的是修改一个街区是否能在编辑器中实时预览，还是必须重新加载。David Santiago 介绍说，美术师在编辑器内拥有便捷的局部刷新工具：如果重新画了一条建筑折线，可以直接点击按钮“重新生成该建筑”或“重新生成替身模型”。虽然不是毫秒级的绝对实时，但后台运算处理大约一分钟左右，结果就会在视口中弹出更新。然而，要跑通整套程序化系统，往往需要等待阶段性完工后集中处理，因为资产之间的依赖链极为庞杂，还牵涉到团队资产版本控制中的文件检出（checkout）与权限锁定问题。 ```mermaid flowchart LR accTitle: 全城重烘焙耗时阶段拆解 accDescr: 展示全城通宵生成流程中，地面数据预处理、地块生成与全城玩法放置的时间分布。 subgraph GlobalBake["全城夜间重构建流程"] P1["地面稀疏数据预处理<br/>(~1 小时)"] --> P2["地块数据与模型生成<br/>(每地块数分钟 / 总计 ~5 小时)"] P2 --> P3["全城玩法/犯罪放置通道<br/>(~25 分钟)"] end ``` 在制作早期由于变动极为剧烈，团队实际上可以在夜间（overnight）完成整个开放世界的全量重新生成。整城烘焙的耗时分布非常明确： 1. **地面稀疏数据处理**：耗时约 1 小时。该阶段负责计算全城的 UV 连续性并定义材质归属。David Santiago 幽默地指出，游戏中曼哈顿的每一个街区（district），其沥青路面和人行道地砖都采用了完全不同的独立材质。 2. **地面地块生成**：全城网格划分后，每个地面地块（ground tile）包含约 16 个模型，单个地块的几何生成及后续工序所需关联数据的创建耗时数分钟，整城合并运算耗时大约 5 小时，正好放进夜间自动化批处理中。 3. **全城玩法放置 Pass**：当需要执行全城尺度的特定放置通道（例如犯罪事件放置 pass）时，处理时间大约为 25 分钟。 - 美术师在编辑器内可针对单栋建筑或特定替身进行局部重算，耗时约一分钟。 - 整个开放世界可在夜间完全重新烘焙生成，前期高频变动期依赖此流程保持数据同步。 - 曼哈顿各区域采用独立定制的沥青与人行道材质，前置生成 UV 连续性及材质稀疏数据需约 1 小时。 - 包含 16 个模型的单个地面 Tile 处理耗时数分钟，全城地面累计运算耗时约 5 小时；全城玩法要素（如犯罪点位）放置遍耗时约 25 分钟。 --- ### [58:14](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=3494s) 替身光照、内存紧凑排布与地块固定预算 针对游戏不同章节（Acts）下城市状态变化是否会导致替身模型成倍增加的疑问，David Santiago 澄清替身模型始终只有一套。系统采用远距离光照计算方案，借助抓取的环境光照探针（light probes）实时对远景替身进行着色，从而适应不同的时间与天气。而在内存管理上，替身模型被严格按区域（zones）划片，并紧凑地堆叠在内存的连续地址空间中。这样设计的妙处在于，当玩家进入副本室内时，这些远景替身可以被瞬间整块卸载；而如果玩家身处一个带有巨大落地窗、能眺望市景的室内副本中，引擎则能精确只将窗外可见区域的对应替身分区驻留在内存中。 谈及地块内存预算，David Santiago 证实每个地块（tile）都有极其严格的固定预算指标。到了项目开发后期，美术师们在编辑器里摆放物件时，经常一边紧盯着预算面板一边哀嚎：“噢不，我又超预算了，该删点什么？”程序化系统在后台也会竭尽全力配合压缩，拼命优化网格 LOD 与碰撞体（collision）。面对观众“相邻地块占用少是否能借用预算”的玩笑，David 斩钉截铁地表示团队从不搞邻里匀配那一套规则： > “Every tile has a fixed budget until we break the rules for some reason.” 他进一步解释，打破固定预算上限的唯一正当理由，就是存在强绑定的核心玩法需求：“No, we didn't treat it that way. It's only if this has to be in this tile because a lot of gameplay actually depends on this and the open world has to be in this particular state.” 除非该地块承载了无法转移的关键玩法逻辑，否则铁律绝不能破。 - 远景替身仅保留一套几何数据，依靠环境探针（light probes）进行动态远距离光照匹配。 - 替身数据按区域严格对齐并紧凑存放于连续内存块中，支持室内副本一键完全卸载或按视线可见性选择性加载。 - 每个地面 Tile 均设有死磕的固定内存预算，严禁跨地块挪用或“互相拆借”预算配额。 - 只有在关键游戏玩法（gameplay）对该特定地块有硬性依赖时，才允许破例超出预算上限。 --- ### [01:00:13](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=3613s) 资产协同与文件冲突管理 提问环节转向团队规模扩大时最痛苦的环节：程序化大批量生成与多名美术师手工编辑资产之间的文件签入冲突（file locking）。观众好奇 Insomniac 是否开发了某种高层级的元工具（meta-tool）来调度协调，还是只能靠口头、发消息通知对方“快把那个 Tile 释放掉”。 David Santiago 笑着承认日常沟通中难免会有“发消息催人解锁”的情况，但他强调底层依靠的是严谨的日常数据快照机制。团队会根据整个世界的实时状态，几乎每天定时生成各种全局数据缓存（data caches）。为了保障夜间全自动构建以及第二天全团队的数据基准一致，团队建立了一套日常签入规范：所有团队成员在每天下班回家前，必须将手头修改的内容全部 Check-in 签入版本库，从而确保自动化系统可以在深夜拿到稳定切片进行下一轮的推演和生成。 - 面对多美术师与程序化系统的并发冲突，工作室依靠每日生成的全城状态数据缓存（data caches）作为同步基准。 - 团队严格执行下班前将修改资产全部签入（Check-in）的工作流规范，以确保夜间批处理能够顺利执行。 ### [01:01:19](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=3679s) 地块数据的缓存提取与相邻地块属性继承 在管线依赖管理与版本控制（Perforce）的处理方式上，开发团队并未采用全天候后台监控守护程序（watch daemon）去时刻侦测资源是否就绪，而是依靠明确的时间节点排期。团队按地块（tile）抓取已签入的最新状态并生成缓存数据，频率可以按需设定（例如每日或更高频），从而确保各处理管线拿到所需的状态。在管线末端，系统能够并行处理所有地块，若某个地块发生变动，系统不仅会处理该地块本身，还会重新计算其相邻地块，或者使该地块直接继承邻居地块的属性。通过这种方式，程序化生成系统可以引用相邻地块的信息来进行平滑过渡与融合，避免交界处出现硬切缝隙。 关于团队如何在时间节点与资产依赖之间进行权衡，David Santiago 解释道：“It's just people were supposed to be done at certain amounts of time and then that processing would happen and if they weren't well because at the end of the pipeline we were able to sort of run everything in parallel tiles in parallel then that's how we would treat it.” - 依赖管理机制：依靠规定的提交截止时间点触发批量处理，而非持续轮询依赖项的守护服务。 - 边界平滑：程序化生成系统优先读取相邻地块的属性，以确保跨地块边界的地形与道路资产完美融合。 --- ### [01:02:25](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=3745s) 复杂多岔路口、立交桥与立体交通路径的手动覆盖 现场观众询问系统如何应对非十字路口的极端情况，例如五路交叉口、间距过近的复杂路口，以及立体的高架桥（overpass）和下穿通道（underpass）。David Santiago 坦言，如果放任程序化系统自动处理非标路口，往往会因为无法正确解算路权而出现车辆互相穿透撞穿的滑稽局面。针对这些特殊节点，专门的技术支持人员会在编辑器中进行手动干预（hand authoring），手动删除不合理的左转路径或冲突路线——因为游戏内置的交通信号灯只有东西向和南北向两个相位（two traffic faces），无法支持复杂的冲突转弯逻辑。这种手动编辑生成的路径在被赋予特定命名规范的元数据（metadata）后，系统会识别并永久保留这些手工成果，不再被程序化算法冲掉。 针对立体道路与地势起伏，曼哈顿的交通网络绝非纯二维平面。中央车站（Grand Central Terminal）外围拥有抬高的行车高架桥（raised deck），外围跨河大桥也包含立体车道。美术人员在制作大桥交通时，直接在路面点击绘制上桥线条，车辆便能沿着坡道驶上桥面并在中途掉头返回；甚至连行人系统也具备全三维路径，行人可以沿着阶梯走入地下通道或地铁口，穿过整条街道后从对面的出口重新走到地面。 谈到美术与技术人员对手动修正路径的处理时，David Santiago 指出：“Anything that was like so a crazy intersection where it's like we can't support those right those left turns there because they're gonna cut another traffic we don't have enough we only have two traffic faces right east and east west north and south so is there a way we can make it work alright so we can't we have to exclude this from being happen so we're gonna delete that path and they would also the ones they needed and then you could we knew it was manually authored and that would be preserved and then that's how that stuff happened.” ```mermaid flowchart TD accTitle: 复杂路口与立体交通处理流程 accDescr: 展示程序化生成遇到冲突时如何结合手动编辑与元数据保护机制 subgraph ProceduralPhase ["程序化生成阶段"] A["解析街道拓扑与走向"] --> B{"是否存在复杂路口 / 冲突车道?"} B -- "规则路口 (两相位信号)" --> C["自动生成车辆/行人路径"] B -- "五岔路口 / 立体多层" --> D["系统解算冲突 (车辆穿模)"] end subgraph ManualIntervention ["技术支持与手工覆盖"] D --> E["编辑器手动绘制路径 (Line + Metadata)"] E --> F["剔除冲突左转 / 规划桥梁掉头与地下行人通道"] F --> G["标记为手动编辑 (Manually Authored)"] end subgraph IntegrationPhase ["合并与保护"] C --> H["最终交通网络数据"] G --> H H --> I["程序化迭代时锁死保留手工作品"] end ``` - 信号灯相位限制：曼哈顿交通灯系统仅支持东西、南北两个基础信号相位，促使团队人工剔除造成对冲的左转路径。 - 桥梁与地下路径：大桥车辆采用“上桥-中途掉头-原路折返”的闭环样条线；行人路径完整贯通地铁下穿通道。 --- ### [01:04:42](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=3882s) 美术驱动规则：顶点着色调控水洼与环境光照 在回答美术团队如何掌控全城色彩倾向、区域明暗与色彩多样性时，David Santiago 斩钉截铁地表示，整个生成管线的底层逻辑完全是“美术驱动一切”。地面的积水水洼（puddles）与街道潮湿感（wetness）并非完全随机散布，而是通过预先烘焙到模型中的顶点颜色（vertex colors）来实现基础分布；在此之上，环境美术师可以直接在关卡中使用顶点绘制工具（vertex paint）涂抹额外的颜色层（color cloud）进行精细调节。管线在重新编译街道时，会提取美术师绘制的顶点色彩并合并到最终道路数据中，将最终控制权交还给艺术家。 针对光照分布，除了参考同组同事关于布光的专项分享外，程序化系统在环境细节上也部署了严格遵循美术审美的规则，例如小巷灯光（alley lighting）等装置的摆放逻辑均以氛围营造为核心。 在阐述技术生成与艺术自由度的关系时，David Santiago 总结道：“Yes art drives it all so we had a lot of there's a lot of vertex paint driven stuff and vertex color so like something like the puddle so in the wetness of the streets so that was all built with by building the vertex colors into the models themselves so that was already static but then artists could go through and vertex paint and so create this other cloud of colors that could modify all that.” - 积水与湿度控制：结合静态模型内嵌顶点色与美术师手动顶点涂抹，系统读取并回写至道路资产中。 - 光照部署：程序化布光主要负责小巷灯具等功能性次要光源的位置计算，全局光影遵循美术规则约束。 --- ### [01:06:04](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=3964s) 放弃六边形网格：为何从《落日超驰》回归正方形方格 提问环节的最后一位观众提出，Insomniac Games 在前一年的 GDC 演讲中曾大力推崇使用六边形网格（hex grid）来管理大型开放世界城市的程序化生成与流式加载（streaming），该方案在业内反响热烈，但在《漫威蜘蛛侠》中团队却重新回归了传统的正方形网格（square grid）。 David Santiago 揭示了这一架构变动背后的真实原因：六边形网格最早是为《落日超驰》（Sunset Overdrive）设计的，当时游戏采用了一套预制元件库（puzzle pieces）拼装道路与街区，六边形网格在拼接标准化元件时能提供极高的旋转自由度和组合灵活性。然而在制作《漫威蜘蛛侠》时，曼哈顿存在极其剧烈、复杂的垂直高程变化，根本无法使用固定的预制件去应对全城起伏，所有道路系统必须依靠程序化系统从零自定义动态生成。更为关键的是，真实的纽约曼哈顿本身就是高度规范的棋盘式矩形网格，因此直接采用正方形网格作为流式加载区域（streaming regions）才是顺理成章的选择，六边形网格在现实主义的纽约地形面前反倒失去了立足之地。随后，演讲在工作人员的指引下移步至场外的交流总结室（wrap-up room）。 针对两款游戏在网格架构上的根本转变，David Santiago 明确解释说：“New York sort of built on a grid so using the grid system for streaming regions kind of just made sense that the hexes did not make sense for for doing New York City.” - 拼图组件失效：曼哈顿极端的坡度与落差让预制拼装元件（puzzle pieces）彻底失效，迫使道路全部转为全程序化自定义构建。 - 现实拓扑契合：曼哈顿标志性的横平竖直棋盘式街道布局，使得正方形流式分区在技术与现实层面上完全契合。 ## Notable quotes > [46:56](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=2816s) Knowing if something is procedural means you can confidently regenerate it again and again without destroying any manual work. — David Santiago > [08:16](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=496s) Roads and alleys define this city; everything is dependent on their placement, size, and lane configuration. — David Santiago > [30:55](https://www.youtube.com/watch?v=4aw9uyj9MAE&t=1855s) 美术和策划绝不能手动修改程序化系统生成的任何东西；他们必须通过调整程序化系统的可控参数和输入来促成改变，如果不这么做，他们就有丢失工作成果的风险。 — David Santiago ## Mentioned Marvel's Spider-Man, David Santiago, Bryan Intihar, Jeff Hannah, Insomniac Games, Sony Interactive Entertainment, Marvel Games, SideFX, PlayStation 4, Houdini, Sunset Overdrive, We Happy Few, Perforce ## Video description In this GDC 2019 session, Insomniac Games' David Santiago describes the open world pipeline of 'Marvel's Spider-Man' and how each procedural system was originally designed to support iterations, and dependencies. Register for GDC: https://ubm.io/2yWXW38 Join the GDC mailing list: http://www.gdconf.com/subscribe Follow GDC on Twitter: https://twitter.com/Official_GDC GDC talks cover a range of developmental topics including game design, programming, audio, visual arts, business management, production, online games, and much more. We post a fresh GDC video every day. Subscribe to the channel to stay on top of regular updates, and check out GDC Vault for thousands of more in-depth talks from our archives. [Source](https://www.youtube.com/watch?v=4aw9uyj9MAE)

[46:56] David Santiago: Knowing if something is procedural means you can confidently regenerate it again and again without destroying any manual work. [8:16] David Santiago: Roads and alleys define this city; everything is dependent on their placement, size, and lane configuration. [30:55] David Santiago: 美术和策划绝不能手动修改程序化系统生成的任何东西；他们必须通过调整程序化系统的可控参数和输入来促成改变，如果不这么做，他们就有丢失工作成果的风险。

[46:56] David Santiago: We want to delete, nudge, or modify automatically only when we're absolutely certain of the result. [8:46] David Santiago: Roads and alleys define this city: everything is dependent on their placement, size, and lane configuration. [43:36] David Santiago: If you only place something with strict criteria, you're not going to find that many locations that meet the criteria. [5:07] David Santiago: The goal for Spider-Man was to procedurally generate an open world early in production to give the designers and artists the rest of the remaining of our production time to polish the game and our target was 80% usable procedural content.

[0:02] [Music] [0:04] my name is David Santiago I'm a [0:07] principal technical artist at insomniac [0:09] games working with procedural systems in [0:11] pipeline and there been many talks by [0:14] insomniacs at GDC this year and if you [0:16] missed some of the ones early in the [0:17] week I'm sure they're recorded and I [0:19] will be mentioning some of the upcoming [0:21] talks during my presentation before I [0:23] get started and run out of time I want [0:25] to make sure to thank everyone in [0:26] insomniac games for their support and [0:28] preparing this talk and I want to thank [0:31] in cymet for being such a great place to [0:32] work and insomniac e is hiring so visit [0:35] our booth on the show floor to talk to [0:37] people at openings here are some of the [0:39] current openings I can show this slide [0:41] later and we do I believe still have [0:44] openings for a rigging in turn in both [0:46] studios this summer and I'll be on the [0:49] at the booth on or off the next couple [0:51] days so I'm going to talk about a game [0:54] that some of you might not have platinum [0:56] yet and I might reveal some secrets of [1:00] the game that have already been [1:01] published in every language on the [1:03] online so is show of hands so I do [1:07] really want this information of who [1:09] hasn't seen any spider-man open-world [1:11] content at all okay as well so I will be [1:17] sure to play the video even though it [1:19] stopped working I will just get out and [1:21] play it how many people have not played [1:24] the game alright well that's pretty much [1:29] all the information I need so so if [1:34] everybody else playing the game so how [1:35] did it start and how do we plan on [1:37] making this game let's jump back a few [1:38] years there was a meeting where Brian [1:40] Andujar of creative director revealed [1:42] the next game that insomniac would be [1:44] making for the PlayStation 4 and I [1:47] actually wasn't at that meeting but I [1:49] heard that people freaked out I remember [1:51] the moment I was told you're gonna be [1:54] working on spider-man and I was like [1:57] what what why we're doing spider-man [1:59] you're kidding and it was hard to [2:02] believe but I was very quickly convinced [2:04] that's what we were going to do so I was [2:08] being tasked to help build the cities [2:10] and the technology I first developed on [2:12] Sunset [2:12] overdrive creating ground buildings and [2:14] markup but for Manhattan and now that's [2:17] a little more real estate to cover but [2:19] but I had a plan [2:21] I reviewed Brian's announcement [2:23] presentation which set the game's [2:25] pillars and goals for every department [2:27] and it was a mind-blowing amount of [2:29] content to create in a relatively short [2:31] amount of time and then in 2016 the [2:35] public rumor started that oh there's a [2:37] spider-man game coming and fans started [2:39] sharing their expectations online so III [2:45] 2016 we opened on a shot of the city [2:48] transition to this street with traffic [2:51] and pedestrians and hot dog carts and we [2:55] cut to this card and people got excited [2:57] and while I'm on this card I'm remind to [3:00] thank Marvel games and Sony interactive [3:02] entertainment for their support and most [3:04] importantly I want to thank my family [3:05] and the family of micro families and my [3:08] co-workers for all their support and [3:10] enthusiasm as we threw ourselves into [3:12] making this game so the 2016 III crowd [3:18] they really erupted when we cut to the [3:20] shot of spider-man there and then he [3:22] started swinging down the city but now [3:24] for all of us at insomniac this was real [3:26] and the quality bar the minimum quality [3:29] bar was said so from the start we work [3:32] to make sure that all of our demos ran [3:33] real time on ps4 hardware and from the [3:36] beginning we had a strong plan which [3:38] actually got us to this 2016 III reveal [3:41] but that plan wasn't yet strong enough [3:43] for the challenges of the next two years [3:46] and speaking of that Brian in ihara the [3:49] creative director has a talk pretty much [3:51] right after this 11:30 in the South Hall [3:54] so you might want to catch that but my [3:57] talk today is about the procedural [3:59] systems and how we integrated them into [4:01] the part pipeline as part of that plan [4:03] to meet the challenges so this is that [4:07] video that last week didn't play and [4:10] then it stopped started playing and now [4:15] it's not playing again so let me play [4:17] this real quick if you are able to see [4:20] it do I have to put it over somewhere [4:22] else [4:24] do I need to quit the other presentation [4:28] maybe let's close that alright so since [4:36] it's not so for those of you who hadn't [4:39] seen anything so here is spider-man [4:42] swinging through the open world don't [4:46] need to play too much of this I think he [4:48] Ola you'll get it alright back to the [4:56] presentation [4:57] it's great when with PowerPoint ah [5:02] shift f5 alright so let me give you an [5:07] overview of my talk today so we're gonna [5:09] talk about what the open world planned [5:11] content was just for a procedural [5:13] content what the challenges would be [5:14] I'll give an overview of the procedural [5:16] systems that we mostly ones some of the [5:19] ones we used on spider-man I'll describe [5:21] our original pipeline plan and how the [5:24] project evolved as production happens [5:26] and how we updated the pipeline to [5:28] handle it like I'll mention some late [5:31] additional challenges we met to finish [5:33] the game and then most importantly what [5:35] we learned so here is our marvel island [5:39] of Manhattan but what is spider-man what [5:42] is what is in this game [5:43] so it's an open-world game of [5:45] approximately six kilometers by three [5:47] kilometers of designed playable space [5:49] and we have the nine districts of Harlem [5:52] Upper East Side Upper West Side Hell's [5:55] Kitchen Midtown Chinatown Greenwich [5:57] financial district and the raft and [6:00] Rikers Island prisons and Central Park [6:04] there are 544 roads in 1202 alleys those [6:09] are mostly fictitious alleys either [6:11] actually very few of them in Manhattan [6:13] over 8,300 distinct buildings in 3250 [6:18] edifis prefabs and an edifice it [6:20] contains the contiguous buildings or [6:22] structures within a block more than 350 [6:25] different types of storefronts which are [6:27] uniquely customizable more than 3000 [6:31] crimes more than 3000 vignettes and I [6:34] think there's a story missions and a [6:36] hero [6:38] so how will we do it well to make such a [6:42] large game we new automation and [6:44] procedural systems would be used on a [6:45] really large scale and in some net games [6:48] is not a big company I mean I think [6:50] during spider-man we're about 250 in the [6:52] entire company and we're always working [6:54] on multiple titles so we knew that [6:57] automation would be key using macros [6:58] scripts etc and then procedural systems [7:01] so what are procedural systems they are [7:04] methods for creating content [7:06] algorithmically rather than manually and [7:08] so data flows through a set of [7:10] operations that manipulate the data [7:12] based on parameters attributes and other [7:14] input now this is not real-time [7:17] procedural I mean there's always some [7:19] small real-time procedural systems but [7:22] these are procedural tools to author [7:24] content and our goal is as much as [7:27] possible to ought to procedurally create [7:29] a procedurally authored open world Wow [7:33] it's it's a marble talk you can't have [7:35] to do something like that so and I just [7:39] thought of that like two weeks ago so [7:41] pan crafting is very important at [7:43] insomniac games designers and artists [7:46] handcraft the game experience as much as [7:48] possible throughout the entire game and [7:50] procedural systems are a tool to help [7:53] author a lot of content quickly and give [7:55] the artists and designers a big head [7:57] start so the goal for spire man was to [7:59] procedurally generate an open world [8:01] early in production to give the [8:03] designers and artists the rest of the [8:05] remaining of our production time to [8:07] polish the game and our target was 80% [8:09] useable procedural content and I'll have [8:12] more on that later so we started with a [8:16] foundation of systems and tools from [8:18] sunset overdrive and we had to augment [8:20] that foundation to create the basic [8:22] tools and systems for spider-man sunset [8:25] overdrive we built roads on terrain and [8:27] placed a relatively small set of props [8:29] and traversal markup and there was a [8:32] building system to help block out areas [8:33] of the game but the building Sun sense [8:35] that were so unique that it was just [8:37] more efficient to constructed by hand at [8:38] that time so we had a plan for what the [8:42] main procedural systems we needed so I'm [8:46] going to be using this east up [8:47] orientation for the island throughout [8:49] the presentation so it fits our [8:51] ratio better and so hopefully you get [8:53] used to it it took me a while to get [8:55] used to it because I we weren't working [8:57] this way either so at the time in [9:00] pre-production the planned procedural [9:02] systems included ground system for [9:04] terrain streets sidewalks some decor and [9:08] integrated markup buildings with markup [9:11] the traffic system for pedestrians and [9:14] vehicles and a first pass of propping [9:18] the open worlds really spamming the [9:20] props out there so step one for the [9:23] ground system our roads and alleys roads [9:26] and alleys define this city everything [9:29] is dependent on their placement size and [9:32] lane configuration now a big hint for [9:34] this talk dependency is very important [9:37] so from these lines and curves and [9:39] editor we will generate the streets [9:41] sidewalks grey spaces and the sea wall [9:44] around the island ground modifiers [9:48] affect how the environment is [9:49] constructed so this yellow overlay is [9:52] the contents of our ground modifier zone [9:54] now these are additional curves polygons [9:56] or volumes that cut deform modify add [9:59] materials etc to a particular areas of [10:02] the game [10:04] there was also an analogous design [10:06] modifier zone this is the ground [10:07] modifier zone a design modifier zone to [10:10] affect a design content such as crimes [10:12] traffic BOTS navigation etc so we're not [10:16] going to generate a giant model for the [10:19] ground we're gonna make models for each [10:20] streaming region so our open world is [10:22] cut into square tile streaming regions [10:25] 128 meters on a side I must say it about [10:27] 128 meters on a side no it's a 128 [10:30] meters on a side so if you see here [10:33] there's some double lines I mean they're [10:34] not important but it's an interesting [10:36] detail in our system they indicate a [10:38] history of scaling and offset of [10:40] streaming reasons regions for various [10:42] reasons and we actually preserve that [10:44] history so we could validate content to [10:46] make sure that it was fitting into it's [10:48] appropriate streaming region now there [10:50] are very few actually scaled regions in [10:52] the final game and mostly they're on the [10:54] coastline just to reduce the tile [10:55] account you know just make it a little [10:56] bit bigger we can fit the content into [10:58] there and you'll notice that Rikers [11:00] Island and the raft prison do not have [11:03] streaming regions but that's as far as [11:04] procedural [11:05] Sims are concerned because there is no [11:07] procedural content in their final [11:09] version tile IDs so each region has a [11:14] tile ID which is a map location from a [11:17] o1 to x-48 and each tile hierarchically [11:20] contains all the zones for its [11:21] open-world content for that region and [11:23] you can notice that lonely tile in the [11:25] top right corner there that's X 48 and [11:28] it's our test region that was there [11:30] throughout the entire game so here is a [11:34] procedurally generated ground it's [11:37] typically 16 models per tile so that [11:39] each is a manageable size for physics [11:41] and other systems and this is actually a [11:44] debug version of the ground which is why [11:46] it is not complete in some areas and you [11:49] also see remnants of Rikers and raft up [11:52] on the top there which was later [11:54] completely handcrafted also note that [11:57] Central Park's ground was hand authored [12:00] to fit the character of the park in the [12:02] area allotted so eventually all of those [12:04] manual iterations of Central Park were [12:06] procedurally processed in order to [12:08] integrate them into the game the last [12:12] part of the ground system is kind of [12:14] actually the beginning of the prop [12:15] system it's where we add some ground [12:17] details lane lines crosswalks per [12:19] district materials and such and it's [12:22] also we also do a little first passive [12:24] Street props such as manhole covers and [12:26] sidewalk props such as traffic and [12:28] streetlights and a few things like trash [12:30] cans trees just to fill it out for [12:33] designer testing so when they're [12:35] swinging through the city up don't hit [12:37] that tree onto the building system so [12:42] buildings were constructed from [12:43] primitives such as boxes cylinders and [12:45] polygamy volumes to define the outline [12:48] of the floors of the building and then [12:50] these simple buildings are then [12:51] processed by the procedural system two [12:54] instance assets from several building [12:57] kits onto the faces of the gray block [12:59] and then there were roof models that [13:02] could be sized and tiled to fit a roof [13:04] or a custom roof model would be created [13:07] automatically if the procedural system [13:09] couldn't couldn't make it out of pieces [13:10] and then some rooftop props were [13:13] automatically added to these building [13:15] edifices at this time so things like the [13:17] HVAC s and those water towers [13:20] the Prezi store system also added all [13:22] the markups Winky and volumes and [13:24] various types of ledges ledge paths for [13:26] traversal and then as we were laying out [13:30] all these buildings we notice that [13:31] anytime we change the streets we might [13:33] have to change the buildings some talks [13:37] related to this doug's talk concrete [13:40] jungle gym the building traversal and [13:42] spiderman that is tomorrow morning and [13:44] tomorrow afternoon programming talk [13:48] about our tools our in-house tools [13:50] editing with immutable data by by Ron so [13:56] our building tool was originally [13:58] designed with a recalculate markup only [14:00] mode so if a building was hand modified [14:02] or if it was complete built from scratch [14:05] our system could automatically read that [14:09] edifice prefab generate the markup and [14:11] that markup was always optimized by [14:14] joining all segments to minimize the [14:16] number of curves minimize the markup [14:18] actors so that's pretty much the [14:20] building system and on to traffic system [14:24] so from the road pedestrian and vehicle [14:26] traffic were procedurally generated so [14:29] as far as the pedestrian traffic system [14:31] the first thing we did is we placed [14:32] excuse me static pedestrian volumes on [14:35] sidewalks and so those volumes just [14:38] populated the sidewalk with a certain [14:40] density of pedestrians and they were [14:41] they would just be standing there to [14:43] start with but then they could get [14:44] promoted to the pedestrian system to [14:46] actually walk around so after you placed [14:48] those volumes then we would create a [14:50] network of paths that would connect from [14:51] corner to corner so corner to corner [14:53] along the sidewalks corner to quarter [14:55] across the street then we would [14:57] integrate any paths from other assets [14:59] like bus stops and subways because they [15:01] had their paths that we have to come up [15:03] the stairs and around the subway or [15:04] around the bus stop around the bus [15:06] shelter so those had some built in [15:08] curves they would be integrated into the [15:10] pedestrian system and finally we'd [15:12] integrate any hand authored path so [15:14] there was a lot of hand authoring of [15:15] paths which pretty much just curves [15:17] through parks and plazas and maybe some [15:22] other spaces so those were all [15:23] integrated together and then they would [15:26] generate the pedestrian traffic nodes so [15:28] that the actual gameplay system would [15:30] use and that would include the correct [15:32] traffic phases for each link so that [15:34] when the light turned green they could [15:36] walk across and one day it was red they [15:39] would hopefully stop actually would turn [15:40] yellow and they would speed up and run [15:42] across the intersection [15:43] well except sometimes you know they just [15:45] stopped but so that we had this debug [15:49] with the show with the color all the [15:50] face is to make sure thing was all [15:51] working correctly and the pedestrians as [15:54] they II reached each node they could [15:56] decide on whether they wanted across the [15:57] street or just turn around the corner [15:59] and go down the sidewalk again so now on [16:03] to vehicles it's very similar to the [16:04] pedestrian traffic system so but first [16:07] the parking and driving lanes had to be [16:09] chosen from a variety of the lane [16:11] template templates from each street size [16:13] so each Street would could randomly if [16:15] it wasn't assigned a specific template [16:17] of number of lanes and and in direction [16:20] and then the crosswalks from the [16:22] pedestrian system became the stop lines [16:24] for the traffic at the intercession so [16:26] just like we populated the sidewalks [16:28] with pedestrians of the volume we used [16:30] volumes to populate the parked cars in [16:32] the parking lane the only difference is [16:34] we had to create multiple volumes to [16:36] avoid bus stops hydrants alleys and [16:39] other exclusion areas where you [16:40] shouldn't be parking your car we also [16:43] created a network of the directional [16:45] paths that would take a vehicle from a [16:47] intersection intersection and then at [16:49] the intersections give them the legal or [16:51] desirable turns that they could make [16:53] then we would integrate the alleys as [16:55] limited paths so if it was a drivable [16:57] alley so see it back in the distance [16:59] there there are those magenta lines [17:00] those are alleys and they come a come in [17:03] too and they are integrated and I will [17:05] talk a little more about their their [17:06] limited use later and then we would [17:09] create the traffic nodes with the [17:10] corresponding phases and links to other [17:12] nodes and the lane markings based on the [17:16] traffic pattern would then get get [17:18] applied in the with the prop system so [17:20] here you can see the route choices so [17:22] these are two two well there are two two [17:26] lane one-way streets that are crossing [17:28] each other and that lane on the Left [17:30] which is actually the right lane going [17:31] down I don't know if it's south east or [17:33] whichever way it's going but they have [17:35] the choice of turning right into either [17:37] the lanes or going across the [17:38] intersection and the other lane has no [17:40] choice they're only allowed in this [17:42] traffic situation to go straight across [17:45] the inner [17:45] section now here's a more complex area [17:48] with pedestrian vehicle paths and so [17:52] it's multi Lane streets so these are [17:54] these are avenues and so it gets a [17:56] little more complicated as to what [17:57] people can do if you look at that lower [17:59] intersection in the middle there you can [18:02] see that all the lanes that have the [18:04] green light so they can turn two lanes [18:06] right into that one-way street and the [18:08] other ones can go straight across and [18:10] then when the traffic phase changes that [18:12] left turn lane going from right to left [18:14] they're allowed to turn onto that [18:16] one-way street and then here the same [18:20] the pedestrian traffic for that area you [18:22] can see the hand authored paths through [18:24] that plaza there and yet pretty much all [18:26] they had to do was draw those curves so [18:28] they intersected a procedural path and [18:30] they would automatically be integrated [18:32] into the system so now the dekor system [18:36] which is pretty much props and and [18:39] decals and then and then some ped [18:41] prefabs cosplay explained in a minute so [18:44] we procedurally optimize placement of [18:46] the street props such as manholes skid [18:48] marks tar asphalt patches and such and [18:51] sidewalk props which include street [18:54] lights traffic lights mailboxes hydrants [18:56] trees and on and on and on now also [18:59] pedestrian prefabs were part of the [19:01] system so pedestrian proof shows where [19:02] things were like bus stops subway [19:04] entrances hot dog carts sign spinners [19:06] cab hailers so there were assets with [19:09] integrated actors that could be promoted [19:11] to bed at pedestrian behavior so say [19:14] people are waiting at a hotdog cart they [19:16] would wait there and then they could be [19:17] promoted to walk along the along the [19:19] path or flee from a crime if necessary [19:21] so whenever there was an encounter the [19:23] pedestrians would go into a flee mode [19:26] and then we could also integrate any [19:28] hand place pedestrian prefabs of which [19:30] there were also many they need to be [19:32] integrated into the the pedestrian [19:34] prefab system in order to populate the [19:37] game appropriately at proper times we [19:41] also did a little bit of procedural [19:43] lighting and I'm not going to talk [19:45] anymore about that because today at 2 [19:47] p.m. [19:47] x-ray is going to be talking about our [19:49] procedural lighting tools so also in our [19:55] original design our tools already had [19:57] the sophistication required for the garb [19:59] debris propping of act three maybe I [20:01] should act how many people made it to [20:02] Act II of the game where there's stuff [20:05] everywhere alright so the challenge [20:08] there was to make it look like there is [20:09] litter and debris everywhere but not [20:11] block any path needed by vehicles [20:13] pedestrians crimes vignettes missions [20:16] etc so that was it's a little tricky and [20:19] I know there has been much interest in [20:21] puddles in the last nine months or so [20:24] those blue circles there procedurally [20:27] placed puddles [20:28] if wetness reaches a certain threshold [20:30] in the material which uses a random seed [20:33] a puddle is place in the world and [20:35] active during rainy atmospheres and then [20:37] it will splash and ripple and such so at [20:40] this point we had all the tools to place [20:42] the props now Impostors a fairly early [20:47] in pre-production it was decided that [20:49] impostor generation should be part of [20:51] the procedural systems since we [20:53] generated a lot of the content whether [20:55] it would turn into an imposter so here's [20:57] an overhead view of the imposter version [20:59] in the city and it contains every [21:01] structure now imposters are lower res [21:03] representations of every structure in [21:05] the city and we generate a simplified [21:07] model from the high-res geometry in the [21:09] entire edifice prefab and then we use [21:12] that simple model for our imposter [21:14] generation to project textures and make [21:16] an atlas and then we populate the [21:19] imposter zones with the correct updated [21:20] imposters so that we can put them in the [21:23] right kind of containers for optimizing [21:24] a memory and and such and then we can [21:28] pursue these early regenerate them when [21:30] ground structures materials or lighting [21:32] changes so pretty much we're generating [21:34] imposters over and over again and here [21:38] again are all the imposters and showing [21:40] that the entire city is always present [21:42] whenever you see a shot of the city it's [21:44] pretty much all imposters so at most [21:47] only twelve zones or ever ever loaded [21:49] high-res and even most of those knowns [21:52] are going to be in their lowest LOD [21:54] which is very similar to the content of [21:56] an imposter so that's it we've designed [22:01] and implemented all the systems we need [22:03] to create open world Manhattan in less [22:05] than a year of pre-production and now we [22:07] can generate all the procedural assets [22:09] let the other teams polish it up and [22:11] generate imposters and we're [22:12] so it's party time it's party time we [22:15] can just sit back and make the game but [22:17] the design team I don't I don't see the [22:19] design team at the at the party at all [22:21] what what's going on [22:22] well justice we feel like we were going [22:25] to be able to handle all the challenges [22:27] for the open world the designers wanted [22:29] some procedural system love so we had [22:32] some new challenges the first set of [22:34] challenges were dynamic encounters the [22:37] dynamic encounters are crimes and [22:39] vignettes now we place 29 different [22:42] crimes procedurally throughout the world [22:44] and 25 different vignettes for a [22:46] procedurally placed using different rule [22:48] sets another challenge at that time from [22:52] design and gameplay were additional [22:55] desired markup now that we were getting [22:57] some new hero moves and then bought [22:59] navigation so an example of the rules [23:04] required to place a crime or vignette [23:07] like a jetpack a jetpack mission or [23:10] jetpack crime so what we do is have a [23:13] four jetpack crime and have to find a [23:15] roof in the city with 64 square meters [23:18] of combat space available that was [23:20] within 40 metres of two other rooftops [23:22] with 64 scuitto square meters of combat [23:25] space available which were within 20 [23:27] meters up and down from that original [23:28] rooftop and there was a clear path from [23:31] each roof to each roof so I could put in [23:33] nav and then also so I could put nav [23:35] from each rooftop down to the sidewalk [23:37] or down to the alley below so the system [23:39] would run through the world find all [23:40] those possible places based on the [23:43] buildings that we're currently in the [23:44] game and then based on the density that [23:47] was required or neat or desired for each [23:49] district it would place all of those [23:51] crimes or in this case those jetpack [23:53] crimes and create all that markup for [23:55] the for the actors in the bots so if [24:00] we're going to procedurally author all [24:02] that content with all those dependencies [24:04] and have it be handcrafted we need to [24:06] figure this out and make a pipeline so [24:10] we have to think about that crime in [24:12] vignettes are dependent on the [24:14] environment and changing a road or alley [24:16] will affect contiguous blocks defined by [24:19] those roads and therefore all about [24:21] everything in those tiles so buildings [24:22] crimes etc and even changing moving a [24:25] crime [24:26] effect nine tiles because of its [24:28] depending on its complexity because [24:30] crimes drive prop placement we want to [24:32] avoid props or static props in the world [24:35] where there's going to be a crime and [24:37] then changing building will affect [24:39] traversal crimes again lighting and an [24:41] audio did I did I mention audio audio [24:43] wants procedural help so just to start [24:47] with audio we generate some procedural [24:50] systems to generate the reverb volumes [24:52] for audio and also be able to distribute [24:54] audiences that appropriate locations [24:56] throughout the city and speaking of that [24:58] tomorrow the Otto team designing the [25:01] bustling soundscape so alex and blake [25:02] will be presenting on audio for the game [25:06] now back to our story and all of this [25:10] stuff that's a lot a lot of procedural [25:14] systems a lot of rules a lot of [25:16] dependencies so we need a plan and and [25:19] that is to create a pipeline that [25:20] completes procedural content in phases [25:23] that we can iterate approve and lock [25:25] content for all the handcrafting I mean [25:29] because we're going to go from this to [25:30] this it's just going to be a little more [25:33] complicated so we got Houdini's so [25:37] although Houdini from side effects [25:39] software is our main package of choice [25:41] to develop and manage our procedural [25:42] systems in production the algorithms can [25:45] be implemented in any software package [25:46] and in fact we have plenty of code for [25:49] generating procedural content that is [25:50] independent of Houdini or any other [25:52] third-party DCC software now here is a [25:55] circa 2016 implementation of our open [25:58] world pipeline involving procedural [26:00] systems and it's a very simplified [26:02] diagram without every possible error or [26:04] box because it's just unreadable and [26:07] it's broken the roughly three phases so [26:10] in phase one it's the main world layout [26:12] we're predominantly designers place [26:13] roads rough out buildings to find Park [26:16] areas and mission spaces and so forth [26:18] and then we move on to Phase two where [26:20] the majority of procedural content is [26:22] authored and then finally phase three [26:25] the polished stage where the procedural [26:27] systems will just help finish the game [26:29] and let me quickly point out that [26:31] Impostors and lighting data are being [26:33] calculated during every iteration of [26:35] each phase and during phase two and [26:37] three audio and UI data are [26:39] also being procedurally generated as [26:41] well so the game is always playable in [26:43] its most updated state so here's the [26:47] first phase the first step is designers [26:49] layout curves to define the roads [26:51] well actually the very first version of [26:53] the city was from an illustrator drawing [26:55] of the map for our Manhattan and the [26:57] procedural system could ingest that [26:59] image and then create the curves in [27:01] polygon primatives in our editor the [27:04] procedural system would also randomly [27:06] place a rectangular box buildings in [27:08] different zone to block up to block out [27:10] the city and it would actually read [27:12] color data that the designers put down [27:15] in order to vary the range of building [27:17] sizes for the different areas so once [27:19] they got that to a certain state we were [27:22] just going to work just in the editor so [27:24] the designers would modify curves in the [27:25] editor to redefine the roads and they [27:28] could specify road directions or [27:30] dominate direction if it's a [27:31] multi-directional T Lane bi-directional [27:33] Street Road width and the road width was [27:36] from outside a sidewalk to outside of [27:38] the sidewalk Street width is from curb [27:40] to curb they could alter curb height [27:43] Lane configuration and and so on so [27:46] initially only the main avenues were [27:49] specified and the procedural system [27:52] automatically chose street sizes [27:54] directions and lane loud layouts for all [27:56] the rest of the streets so we just told [27:58] it something like we want 70% of the [28:00] streets to be one-way streets and 70% of [28:02] those should be one traffic lane with [28:04] one parking Lane and then the system [28:06] just went through the city to create [28:08] workable traffic patterns and we got [28:10] those alternating one-way streets as you [28:12] might expect but as time went on the [28:16] designers would specifically choose [28:17] sizes and Lane configurations for many [28:20] the streets to accommodate story and and [28:22] chases and such but I would bet that [28:25] most of the streets sizes and directions [28:27] are determined procedurally so also to [28:31] start we had very few alleys there were [28:33] some blocks that designers knew they [28:35] wanted to break up but until we had [28:37] buildings in place it didn't really make [28:39] sense to try to place alleys so then [28:44] using those road curves just like I kind [28:46] of talked earlier we proceeded you [28:47] generated the ground [28:48] that's just like that [28:50] so then the designers place the [28:52] parameters to define the buildings and [28:54] in this first base [28:55] so the rough elevations and profiles are [28:56] created and procedural systems can [28:58] modular eyes the buildings using those [29:00] basic architectural sets and then it [29:03] would any would apply the markup [29:04] so now designers could swing through the [29:06] city and test out their space so his [29:08] swing traversal possible is desired [29:11] Billa wetson changing urban landscape [29:13] lead you along the desired paths so we [29:16] have the correct variety of density and [29:18] shapes for the different districts and [29:20] neighborhoods so there was another talk [29:21] here at GDC that actually went over all [29:23] those decisions the one thing to keep in [29:26] mind is that this early in production [29:27] spider-man did not have his complete [29:30] move set of web zipping and parkour or [29:32] pork point launching I mean it was some [29:35] pretty basic stuff so we were trying to [29:37] approve this layout with some [29:39] limitations [29:40] so as we litter ated in this first phase [29:43] there obviously should be an arrow back [29:45] to Road curves so as and then as also as [29:50] separate buildings were used to fill the [29:51] block the procedural system would [29:53] automatically create the alley curves in [29:55] between them and you might ask why do we [29:57] actually need the alley curves instead [30:00] of just saying well the space between [30:01] buildings is an alley well again some of [30:04] them are drivable used for crimes and [30:06] chases and they can be even used by [30:08] regular vehicles their Street is is [30:11] blocked by a crime or a vignette so they [30:15] could take a detour down an alley we [30:17] would also use those Kirstin form the [30:19] procedural systems for change in the [30:21] ground surface props lighting audio [30:23] needs etc so after this first phase we [30:27] should have the streets pretty much done [30:28] and the rough buildings can drive our [30:30] next phase phase 2 is where the bulk of [30:34] the work for our procedural systems [30:36] happen and there should be arrows going [30:38] from each block to any previous block [30:40] because any change based on a dependency [30:42] requires some reauthorization Dazz [30:47] possible if nothing is breaking the [30:49] pipeline we will generate everything in [30:51] his face based on all the changes to [30:53] keep the game update updated and [30:55] playable that last bullet is very [30:58] important it means that during this [31:00] phase artists and designers should not [31:03] hand [31:04] anything that a procedural system [31:06] generates they must use the controllable [31:09] parameters and inputs to the procedural [31:11] system to affect change if they don't [31:14] they're at the risk of losing work so [31:18] here is the what we call the art [31:20] polyline pass and that's the opportunity [31:22] for in the environment artists to [31:24] replace the primitives in the designer [31:25] zones with multiple polygonal volumes to [31:28] further define the shape of a building [31:29] and the artifice the artists could also [31:33] specify the architectural sets that they [31:36] were wanted to use for the building in [31:38] this phase the artist could also modify [31:40] or delete the alley curves and saying [31:42] that they didn't want an a drivable [31:44] alley there and then we could [31:46] recalculate the ground for them and in [31:50] reality this diagram this phase two [31:52] represents two almost identical phases [31:55] that we call the two stages of [31:57] environment modulars ation passes now [31:59] iterations of the environment arts first [32:01] modules a modular ization pass would [32:04] yield the structures with their final [32:06] layouts and shapes but the architectural [32:08] styles and propping could change in the [32:10] next stage the next round of phase two [32:12] or phase three now after this face that [32:16] were we should have accurately at the [32:19] end of this phase I guess after the end [32:21] of this first stage of Phase two we [32:23] should have accurately placed and [32:25] approved the pedestrians traffic [32:27] vignettes crimes props and accuracy is [32:29] within the scope of our procedural [32:31] system design so the goal was 80 percent [32:33] completion using procedural systems so [32:37] that means that 80 percent of procedural [32:38] content would be ready to ship or [32:40] completed to 80 percent so that art and [32:43] design would have at most 20 percent of [32:45] the work they would traditionally have [32:47] so that means it's something that used [32:49] to set be a week of artist time should [32:51] be a day of artist time five weeks one [32:54] week so what we're trying to do is [32:56] generate content to rules and metrics [32:57] and cull to Ballpark but not the final [32:59] spec because the manual polishing passes [33:02] would take care of the final adjustments [33:05] so at this point phase three design has [33:09] approved everything and there's arts [33:11] sign-off after the second round of phase [33:12] two and every team is hand crafting [33:15] their parts of the game and the [33:16] procedural systems will just [33:18] date things like markup Impostors [33:19] lighting audio etc and there should be [33:22] plenty of production time to develop [33:24] procedural assistance to add any new [33:26] traversal or markup or crimes or [33:28] vignettes and then we can also start [33:29] working on optimization and validation [33:31] tools to improve performance and help [33:33] find bugs so this pipeline was created [33:38] to work within a specific plan and that [33:40] plan is to develop the island uniformly [33:42] through several stages of completion and [33:44] we need to lock the rough map layout and [33:47] structures and define the key spaces [33:49] before we can work through any detail [33:51] and so we got to start with the [33:53] island-wide systems so again we're gonna [33:56] finalize these roads in the map layout [34:00] so oh this was yeah this was a like a [34:06] little clip showing the changes [34:07] throughout the that the production after [34:11] pre-production but it's okay it's not [34:13] that interesting the so the generated [34:18] cond we then there we do have the [34:20] generated grounds which did find the key [34:22] spaces in landmarks so we're gonna work [34:26] one district at a time adding detail in [34:28] iterating on dependencies within that [34:30] district to bring it to the next level [34:32] of completion and that was fun in our [34:34] pipeline design so as long as we worked [34:37] through the island district by district [34:38] maintaining uniform levels of polish we [34:41] could treat each district kind of as its [34:43] own island and because of the unique [34:45] attributes and establish boundary [34:46] conditions for each district we already [34:48] were handling the shared edge tiles in a [34:50] special way so for example here is [34:55] Greenwich district in phase 2 stage 1 so [34:59] at this point we've gone through phase 1 [35:00] so we finalized the road map and the [35:02] rough buildings defining the silhouettes [35:04] and traversal spaces and they've been [35:06] converted into prefabs of instance [35:07] architecture for the whole city so now [35:10] phase 2 stage 1 art does its modules the [35:13] first module ization pass they finalize [35:15] the shapes of the buildings artists are [35:17] assigned neighborhoods each artist [35:19] assigned a neighborhood they do their [35:20] stuff they work through the district [35:21] then a district is a level completion [35:23] where we can run our procedural systems [35:25] to place the crimes vignettes and props [35:27] and art moves on to the other districts [35:29] to do their first [35:31] one of Phase two but we found as artists [35:35] work through the neighborhoods and [35:36] districts they needed to adjust roads [35:38] and alleys for the character of the [35:40] space so the placement direction or size [35:43] a road or alley in one current district [35:45] will affect traffic flows from multiple [35:47] districts so we might have to change [35:49] even more roads so at least to a domino [35:51] effect of changes and that brings us all [35:53] the way back to block 1 of the flow [35:55] chart also due to different milestone [35:59] missions story development items not [36:02] only were different districts at [36:04] different stages of completion but one [36:06] tile next to another tile one could be [36:09] in rough and one it could be in polish [36:10] and but in order to place our majority [36:13] of our content a tile has to be [36:15] completed in environments Art's first [36:17] module ization Pass and gained several [36:19] approvals and that wasn't happening [36:21] so there was too much work here and not [36:24] enough work here and that smooth [36:26] progression was was upset for our [36:28] development now it's not that the [36:30] procedural systems couldn't regenerate [36:32] the content but manual work could be [36:34] lost so for example ingesting an alley [36:37] just just adjusting the alley width in [36:40] one region could affect many surrounding [36:42] tiles such as the UV continuity around [36:44] the block because a block could span [36:46] many tiles proper placement proper [36:49] proper placement it's a tongue-twister [36:51] proper proper placement and the [36:53] placement of crimes and vignettes in [36:54] that alley or vicinity I never mess that [36:58] up when I was rehearsing so that created [37:02] a domino effect beyond what we imagined [37:04] now honestly we or III expected it to [37:07] happen at edge or coastal piles where [37:09] there was minimal gameplay content and I [37:12] knew those would get neglected and fall [37:13] behind so they were just crazy amount of [37:18] dependencies every every tiles regions [37:21] content is dependent on at least its [37:23] neighbors and best case they're in [37:25] production in parallel so not only are [37:29] districts being developed to the [37:31] different levels of Polish but the [37:32] individual tiles as well and there was [37:34] new content for dioramas missions demos [37:39] and other test areas that we're all over [37:41] the city and so things like adding a [37:44] median [37:45] marinas more roof top features they [37:47] required at least update of additional [37:49] markup for the hero and bot support and [37:53] we also relocated several story related [37:56] locations and I was personally a little [37:59] bit stressed and frustrated that we kind [38:02] of weren't sticking to the pipeline that [38:03] that we worked on ah so what do we do we [38:08] get the leads together and we figure it [38:10] all out [38:11] now it didn't happen in a day several [38:13] meetings on different topics with the [38:15] right team members over several weeks at [38:18] least [38:18] and some growing pains were had by all I [38:21] mean we needed to know the targets and [38:24] goals for art design and gameplay one of [38:27] the main systems the ground buildings [38:29] etc are going to be at a level of [38:30] completion that we can move on to [38:32] everything that all the other processes [38:35] that depend on them and then when it's [38:37] work on a tile neighborhood or district [38:39] gonna be at a stage where additional [38:40] polishing of the art crimes missions etc [38:43] will not affect any downstream processes [38:45] because then we can more confidently [38:47] hand off work to the next procedural [38:49] system with the less fear of having to [38:51] go back up the flowchart and then at [38:54] some point we'll get to our final [38:55] imposters lighting audio and UI and and [38:57] we'll be done [39:00] speaking about more about how we work as [39:03] a team [39:03] Jason our environment lead has a talk [39:06] tomorrow case study and empowering your [39:08] artists so knowing what everyone needs [39:13] to finish their work we make a new plan [39:16] for our procedural systems and where [39:18] possible we branch the dependencies so [39:19] that each tile region can be [39:21] independently edited as much as possible [39:23] then each procedure law ization [39:26] operation should be modularized based on [39:28] its dependencies so for example traffic [39:31] lights traffic lights they're really [39:32] only dependent on the roads and the [39:34] sidewalk corners once we know a [39:36] direction of a road and where the corner [39:38] is we know exactly where to place a [39:40] traffic light so at that point that we [39:42] have all of its dependencies set that's [39:45] when traffic lights or anything with the [39:47] same dependencies should be placed in [39:49] that module mailboxes for example they [39:52] have additional dependencies such as [39:54] avoiding alleys bus stops crosswalks [39:57] things like that so [39:58] anything with those dependencies should [40:00] be its own in its own prop placement [40:03] model better rules so we need to also [40:06] need some better rules to catch the [40:08] corner cases always lots of special [40:10] corner cases we want to get these rules [40:12] so we can definitely exclude the invalid [40:15] content now we don't need to be 100% [40:18] accurate with our placement of content [40:20] since we know there will be handcrafting [40:22] passes but we do want to make sure that [40:24] at least 100 percent of the planned [40:27] procedural content is in the game we [40:29] will placing some metrics and then we'll [40:31] indicate assets that are in the ballpark [40:32] but with which we are less confident of [40:35] their proper placement right because [40:38] it's easier to try to place these a [40:39] hundred and sixty crimes out there and [40:41] know that every people have to adjust [40:43] them and put them in the right spot [40:44] other than just saying oh I can only [40:46] place 120 of them and then relying on [40:48] the artists and designers to count and [40:51] remember that they have 40 more crimes [40:53] they need to place and placing them in [40:56] the appropriate areas so this system for [41:00] verifying confidence of placement it [41:02] morph into a validation system that was [41:04] applied later to a lot more content [41:06] which was whether it was procedurally [41:08] generated or not so bringing order to [41:14] the city bringing order means getting [41:15] the teams on the same page and as many [41:18] contiguous tiles to the appropriate [41:19] level of completion for our new modular [41:21] process so originally each district was [41:24] a set of contiguous tiles one now it's [41:26] like I don't care just give me some [41:28] contiguous tiles so we can work through [41:30] this game and the the new procedural [41:33] processes that preserve additional [41:35] handcrafting would be interleaved with [41:37] the artisan designer work now that's [41:39] easier said than done [41:41] but what we got it done then came a few [41:46] more challenges so we had some wall [41:48] crawl issues and on some new assets [41:51] especially some of the new storefronts [41:53] so we needed some additional ledge path [41:55] markup and wall crawl collision added [41:57] then it had to be added by the [41:59] procedural system because it was [42:00] particular to which buildings kits the [42:02] storefronts were added to also a little [42:06] bit later in production a little bit [42:09] late in production we implemented the [42:10] act system so we knew that [42:12] that Spiderman was gonna have these acts [42:14] and different situations and times of [42:16] day but later what is late in production [42:21] when we created the system of overlay [42:23] zones that would control the state of [42:25] the world at different times of day or [42:26] weather conditions or different acts so [42:30] that way stores could be open in the day [42:32] closed at night closed during act 3 [42:33] there could be different groups of [42:35] people out and about depending on these [42:37] situations and we could modify what was [42:39] in the city and act to and act 3 such as [42:41] all the garbage and in different [42:43] vignettes so that solution was proposed [42:46] in October 2017 we designed it in 2000 [42:50] December 2017 I went on holiday break [42:54] and then with our implementation was [42:57] completed in March of 2018 and then the [43:00] content was complete well before we [43:02] shipped later in the year so there were [43:06] also some late mission space updates [43:08] that required reoffer [43:09] and open-world gameplay in several areas [43:12] and I was pretty happy with how the new [43:15] systems handled it and then did I [43:18] mentioned we did audio so we had to [43:21] generate a bunch of custom audio [43:23] collision models to match the visible [43:25] textures that were being presented by a [43:27] material and that was a significant in [43:30] Central Park so lessons learned [43:36] I've talked really fast so we already [43:40] knew this we're the case a strict [43:42] workflow is best but we need flexibility [43:45] for production we want to lock [43:48] procedurally generated elements with [43:50] their dependencies as soon as possible [43:52] as soon as something's locked [43:54] we're done with it we can move on we [43:56] also want to harka Klee modular eyes the [43:58] procedurally generated content to reduce [44:00] dependencies so that's what I was [44:01] talking about the traffic light once we [44:04] know the the dependencies to place that [44:06] traffic light or any other content that [44:08] has the same dependencies we want to do [44:10] that then we can use that as that might [44:12] be a dependency for other props or other [44:14] content that would come later so [44:16] modularizing it will reduce the number [44:19] of dependencies if you have all those [44:21] all the props in one module then you've [44:24] got every possible dependence [44:25] going in there you don't want to over [44:29] define the goals of our procedural [44:31] system modules now you don't you don't [44:34] need to create the perfect rules to [44:36] place something first a lot it takes a [44:38] lot longer to make the perfect system [44:40] I'm at I think it supposedly takes in an [44:42] infinite amount of time to make the [44:43] perfect system and then second if you if [44:47] you only play something with strict [44:48] criteria you're not going to find that [44:50] many locations that meet the meet the [44:52] criteria so again I was like I was [44:54] saying before it won't be it won't be [44:56] out there in the world to be nudged into [44:57] place it'll be something that will have [44:59] to be hand added later which takes a lot [45:01] more work so it's easy to if something's [45:04] there to say oh I'm going to just nudge [45:05] this to a good location also are the [45:08] perfect rules or are a lot of an overt [45:11] over defining your goals and is [45:13] increased constraints and constraints [45:15] for dependencies and we're always trying [45:16] to reduce dependencies for each stage of [45:18] procedural authoring because we know [45:20] things are gonna change and any time in [45:22] so we want to have a limited number of [45:25] dependencies so it's a limited number of [45:27] changes now we can create procedural [45:31] systems that preserve manual work so [45:33] once authoring hand authoring has begun [45:35] we want to change to a mode where [45:37] procedural ism is a pride applied [45:40] appropriately so whether it just [45:42] maintains the hand authored work or it [45:44] augments it or processes in another way [45:47] also compound dependencies should be [45:50] split into separate processes now [45:53] compound dependency is when a single [45:55] asset has distinct sets of rules of [45:57] replacement or has a significant level [46:00] of branching in its rules so for example [46:02] say today we have a crime that can be [46:04] placed on it needs to be placed or can [46:06] be placed on a road and we want place it [46:08] like in the middle of a block or in an [46:09] intersection and then we just to orient [46:11] it with traffic but then also that same [46:13] crime it can be placed on top of a [46:15] rooftop well we don't want to have all [46:17] the rules for placing that we don't want [46:19] that all the rules for placing that [46:20] crime in one module we should separate [46:22] it out so okay the once we have the road [46:24] dependencies we'll place those crimes [46:26] with that there and then once we get to [46:28] the point where we're the building [46:29] dependencies we'll place that same crime [46:31] based on based on those rules so those [46:33] are the compound dependencies and then [46:36] again compound dependencies they limit [46:38] your options [46:39] for a single asset and will will [46:42] increase dependencies for all the assets [46:44] if you have compound dependencies in you [46:46] this big Network then it's going to [46:49] create unneeded dependencies for for the [46:52] neighbors we want to tag procedural [46:56] content well we want to tied everything [46:58] but knowing if something is procedural [47:00] means you can confidently regenerate it [47:02] again and again without destroying any [47:04] manual work now this can be a little bit [47:06] tricky since an incorrect workflow can [47:09] allow an artist to prop out around a [47:11] procedurally placed an instance without [47:14] creating any indication of the [47:16] dependency so for example an artist can [47:19] augment a procedurally placed vendor [47:21] cart and they put additional items [47:23] better there outside of the proper [47:24] hierarchy so procedural system has no [47:27] knowledge of any of those additions and [47:29] so if it decides oh I'm gonna move this [47:30] vendor over here it's a better location [47:32] well you might end up with floating soda [47:35] cans and pretzels in that spot because [47:37] they're not within the correct hierarchy [47:38] so that particular simple case didn't [47:41] happen but there were some similar cases [47:43] also knowing if something is completely [47:45] procedurally authored means that it [47:48] might benefit from Sam hand crafting so [47:50] it's like oh that's just in its in its [47:51] procedurally generated State let's see [47:53] if I can custom customize it too it's [47:56] it's part of its specific location we [48:02] want to perceive lis validate as much [48:03] content as possible now we want to find [48:08] content that is not placed as metrics [48:10] would dictate so for example a spawn [48:12] point is inside of a building that [48:13] doesn't have an interior so we want to [48:16] delete nudge or modify automatically [48:18] only when we're absolutely certain of [48:19] the result so if that spawner is no [48:22] longer usable in any way we know we can [48:25] delete it but if it could be usable [48:27] outside of the building we'll try to [48:28] adjust its position as defined in our in [48:30] our systems rules knowledge and then if [48:33] we can't be confident of that procedural [48:36] adjustment we need to indicate the [48:38] possible issue for the artists and [48:39] designers so that they can make the [48:41] decision now what we did for many of [48:44] those cases for dynamic elements is we [48:46] put those assets in a state where they [48:48] would not build or spawn unless someone [48:50] got around to Hannah [48:51] and modifying them so ladies later in [48:54] production the procedural system was a [48:56] lot smarter about placing all the [48:57] breakables and throwables for crimes as [48:59] we had to do it over and over and over [49:01] again [49:01] so the procedure assistants were [49:02] actually doing a lot of that work and we [49:04] would put those assets that we couldn't [49:06] find a proper location for in this state [49:11] so we lawn learned a lot of things that [49:16] we can do better and this afternoon [49:19] ilan has a technical post-mortem but [49:22] overall I think we were satisfied so [49:24] repeating myself the original goal was [49:26] 80% of procedural content would be ready [49:29] to ship or completed to 80% so that Art [49:32] and Design would have at most 20% of the [49:34] work they would traditionally have now [49:36] we exceeded those 80% goals but all that [49:39] additional time went into additional [49:40] iterations and additional handcrafting [49:43] of content and polished yeah we did it [49:44] would we didn't have there was no [49:46] leisure time you know trying to get it [49:48] get this out the door so now that you [49:50] know about the dependencies and what has [49:52] to happen when we change the ground I'll [49:54] tell you that that road curve zone was [49:56] locked in late January 2018 and the last [50:00] procedural change to the ground occurred [50:02] in late June 2018 a little over two [50:07] months before you could get the game in [50:08] stores I like to thank you all for [50:12] coming I really talked fast so there'll [50:14] be lots of times for questions [50:15] thanks Sony Interactive Sony Playstation [50:18] Marvel games side effects software Jeff [50:20] Hannah my advisor and everyone at [50:22] insomniac games four have a have making [50:26] it such a great experience a great [50:28] adventure and now I will open it up to [50:31] questions so there's microphones on [50:33] either side [50:40] I can put all those job openings if you [50:49] like hello okay I worked on we happy few [50:54] and we have a procedural system a much [50:57] smaller system it was similar structure [51:00] and one of the problem we met is [51:04] communicating with the artists the [51:06] consequences of a change into a handmade [51:10] tie because they are clearly as you said [51:13] dependencies between handmade child and [51:16] the procedural generation around it it [51:19] was really hard for them to imagine all [51:21] the consequences of simple change and so [51:24] my question is how did you explain what [51:29] could be the possible consequences [51:30] because Houdini is not that simple it's [51:33] a complex pipeline and so well so at [51:38] first you know there's always a little [51:41] hesitancy for the artist to give up this [51:44] generating of you know offering their [51:47] buildings you know they want to make [51:49] their buildings but as soon as they saw [51:50] that they could just change a safe and [51:52] then boom and it would instance all the [51:53] stuff for them they're like oh oh I like [51:55] this I like this so they I mean sure [51:58] they're there some bumps in the road but [52:00] they started liking that they would just [52:02] do their polyline work and get the [52:04] structure they wanted and they could [52:05] instantly our tree they could test it [52:08] that it would could go through the whole [52:11] you know through the whole pipeline and [52:13] then later on I mean it took a little [52:17] bit but they had to they did have to [52:19] learn and and kind of trial and error as [52:22] far as what they could change and what [52:23] they shouldn't change what could be [52:25] preserved and what wouldn't be preserved [52:26] different things about how to it just I [52:30] mean it's particular to your pipeline [52:32] but how you do override so what things [52:34] could be override what things can't be [52:36] overridden just there's all those little [52:38] details of the dependencies and the [52:39] hierarchy in your in your data structure [52:41] it's just it's just things that have to [52:45] learn and I mean we had a small team so [52:47] a really small team so getting everybody [52:51] up to speed [52:52] especially up for the open world it was [52:55] overall not that not not that [52:58] challenging I mean it's we just had lots [53:00] and lots and lots of iterations and and [53:02] they learned when to when they should [53:04] just stick stay with the procedural [53:05] systems and when they're gonna cut it [53:07] off so sometimes it at some points right [53:09] they would just say I'm cutting this off [53:10] from procedural systems at all and I'm [53:12] saying I and our system say okay fine [53:14] and you I mean do you have to do [53:16] everything hmm and that would be fine [53:18] okay thank you there is so much going on [53:23] in that city and I can see from your [53:25] total that used in posters and you use [53:27] lot systems but I've noticed that you're [53:30] building some made of different blocks [53:33] with and as you go to the city they [53:36] change Elodie's yeah like small pieces [53:39] not the whole building or theater [53:41] sometimes yeah and I'm just wondering [53:43] how did you manage having so many [53:46] objects and what are the decisions you [53:48] had to make to make the procedural [53:49] system handle so many objects in a [53:52] performant way well for the procedural [53:55] system every every building there were [53:57] only certain building sets building kits [53:59] that were would be used by the [54:01] procedural system when it was originally [54:02] authoring the city and each of those [54:04] building kits had required pieces right [54:06] and all that stuff that the artists [54:09] environment artists designed the [54:11] building kits and then they would export [54:13] an entire building kit at a time and the [54:16] appropriate pieces would be put into the [54:17] procedurals system library but then they [54:20] had all these auxilary pieces they could [54:21] use later when they wanted to polish it [54:23] so as far as the the procedural system [54:26] it knew about a certain sets of pieces [54:28] with different architectural styles but [54:30] it didn't it had no other knowledge [54:32] other than their dimensions and if there [54:34] were special offsets or things like that [54:36] and then it would just based on metrics [54:38] you know place them on so the the [54:41] procedure system didn't have have that [54:43] much knowledge and then later on when [54:47] they did things by hand they could [54:50] actually kind of they can quickly [54:51] replace architectural styles on their [54:52] own or put custom pieces or things in [54:54] themselves now as far as all the content [54:57] in the game Howie it was a lot of [55:00] content in the game I don't know if [55:02] there's anything else to your question [55:03] about how we managed all those models I [55:05] mean everything [55:06] had L Odie's and that was there's all [55:08] these requirements through how you would [55:09] have to author everything I guess one [55:13] thing with the imposter system so the [55:15] imposter system could actually if could [55:18] actually see an invisible LOD in the [55:20] jamb in the model if it was available so [55:22] if there wasn't a possible lower [55:24] resolution state that we didn't want to [55:26] be in a standard LOD we created a [55:29] special one that the imposter system [55:31] would see so that when we took those [55:33] prefabs of buildings and simplified them [55:35] up to make a single model we would use [55:37] that even more simplified geometry thank [55:41] you hi a great talk great game by the [55:44] way thank you very much I wanted to ask [55:46] about the iteration time and like how [55:49] long did it take to to regenerate all [55:51] the city how did how long did it take to [55:53] regenerate like one one block or one [55:56] area and were you able to do it run time [56:00] for example in the editor generate and [56:03] see immediately change or did you have [56:04] to reload the editorial or the game the [56:06] the artists had tools in the editor that [56:08] they could if they did a pot a new [56:09] polyline of a building they could say [56:11] regenerate this building and regenerate [56:12] the building or regenerate the imposter [56:14] there were some things that they could [56:16] do it wasn't like real time it would you [56:18] know we have to get processed in the [56:19] background then it would pop in for them [56:20] so took a minute or something but most [56:24] of the stuff they would get to a certain [56:25] completion and then it would run through [56:26] the whole procedural system at some [56:28] point just because there are so many [56:29] dependencies you know and then you don't [56:32] know who has what checked out [56:34] so there's and there's a whole thing [56:37] with permissions and when you can run [56:39] changes and when you can check things [56:40] out that's yeah it's what I'm forgetting [56:43] I want to forget about that we could [56:48] actually regenerate the entire open [56:50] world overnight and in the early in [56:53] production we were because there are so [56:56] many rapid changes let's see so the the [57:01] ground system what it would first [57:03] process to create a sparse set of data [57:05] that would actually describe where what [57:07] the UV continuity need to be and where [57:09] the materials were defined I don't know [57:11] if you noticed but every single district [57:13] has different materials for its asphalt [57:15] and for its sidewalks that's fun and [57:19] and so all that stuff there's a [57:22] pre-processing a processing time of [57:25] about an hour to create that sparse set [57:27] of data and then each tile itself each [57:30] about sixteen models per ground tile [57:32] would take just just for doing the [57:35] ground and and and creating the [57:37] Associated data that other steps would [57:39] need took about a couple minutes a tile [57:42] but if we ran it all together so that [57:45] would that's about you know five hours [57:46] of generation or so but overnight it was [57:51] not then all the other processes pretty [57:54] much to process things around the whole [57:55] city would like to do a processing pass [57:57] of saying a crime placement or things [57:59] like that it was twenty five minutes [58:00] good to deal with so every time you [58:03] would do something worldwide I mean I [58:05] would probably everything has all of [58:06] these two pennies so processing the [58:07] whole world for something probably about [58:09] twenty five minutes as far as a [58:10] placement pass okay thank you one of the [58:14] questions is saying sounds good [58:16] and question about your tile states so [58:18] you have probably I mean I'd say you [58:20] have different acts and things like that [58:22] so that could be in different states how [58:25] did you solve it within posters do you [58:26] have like multiple in posters as well [58:28] for your now now it's just one one one [58:31] set of imposters and we had this thing [58:34] that we calculated lighting at a [58:35] distance so there were actually really [58:36] was some lighting out there from turn [58:38] they would light those imposters based [58:40] on based on captured probes and such and [58:45] memory footprints was also taken into [58:47] account when you like please thanks so [58:49] as we as that's the thing the imposters [58:52] were put into the zones in order to [58:53] preserve appropriate memory footprints [58:55] because we were you know guess it gets [58:57] technical we were making sure that we [58:59] were stacking these things tightly next [59:01] to each other in one location in memory [59:02] so we could have them all in then also [59:04] an you go to you know an instance [59:06] interior and they're gone [59:07] or but it's a your an instance interior [59:10] that has a view out the window then [59:11] certain of those imposters zones that [59:13] are visible have to be on right so that [59:15] all that stuff was how we how we packed [59:17] them and when you had a toilet for a [59:19] high lot did you for example had a fixed [59:22] budget of memory you could use for a [59:24] certain tile to place things or [59:27] so yeah every every artist knows their [59:29] tile budget for stuff I mean they can at [59:31] the end of the game they've got it up [59:33] and [59:33] they're doing stuff and they go like oh [59:35] no what am I gonna take out okay but and [59:39] then the procedural systems as I would [59:41] process things I mean we optimize lots [59:43] of things optimizing LEDs optimizing [59:47] collision yeah this is a lot of things [59:51] we try to do so every tile had a fixed [59:52] budget every tile has a fixed budget [59:56] until we break the rules for some reason [59:58] yes because the Nile next to it has a [59:59] little bit less you can take a little [60:00] bit more now now we didn't we didn't [60:03] treat it that way it's only if this has [60:05] to be in this tile because a lot of [60:07] gameplay actually depends on this and [60:09] the open world has to be in this [60:10] particular state okay thank you yeah [60:13] yeah my question was related to [60:17] something that you just brought up in [60:19] the previous question about the file [60:22] locking and working between different [60:24] artists you know kind of run into that [60:27] as soon as you start to scale you have [60:29] these problems between authoring assets [60:31] and then as soon as you introduce a [60:33] process with received generation there [60:35] my head's kind of spinning so just my [60:38] question around that did you have what [60:40] was your process for coordinating all [60:41] that together and are you also on top of [60:45] that do you have kind of like a meta [60:49] tool that is over the top of all these [60:51] processes and tools that you use to [60:55] coordinate between people or was it just [60:57] knowledge of the process I message them [60:59] and say let go of that tile no no no so [61:03] well some there's some of that but but [61:06] no we we generated all sorts of data [61:08] caches based on the state of the world [61:11] at different of pretty much every day so [61:15] people are supposed to check in their [61:16] stuff when they go home and and whether [61:19] they do it or not because we actually [61:21] grab that data per tile we would we've [61:24] just this is the latest state of the [61:25] tile as it's checked in and then we [61:28] would we would create that cache data [61:30] I mean x-rays here but we would create [61:33] that you know we could do it every day [61:35] but as often as we needed to have an [61:37] updated state to run the processes we [61:39] needed so but as far as yeah you know [61:42] perforce and and checking dependencies [61:44] or having watch you know having [61:46] a watch daemon that's checking to see is [61:48] this ready for me to go it's just people [61:52] were supposed to be done at certain [61:53] amounts of time and then that brought [61:54] the processing would happen and if they [61:55] weren't well because at the end of the [61:57] pipeline we were able to sort of run [62:01] everything in parallel tiles in parallel [62:03] then that's how we would treat it so [62:05] then that we that we'd get the that [62:07] updated tile I would process that tile [62:09] and its neighboring tiles or I have that [62:13] tile inherit its neighboring tiles [62:15] properties right so the procedural [62:17] systems would use which neighbors [62:19] instead of what was originally authored [62:21] in that tile just so we're all blend in [62:25] yes does it work yeah hello I have a [62:32] two-part question um first part how did [62:35] you deal if you had to with complex [62:37] intersections like 500 intersections or [62:40] very close together intersections and [62:42] how did you deal with if you had to like [62:45] overpasses and like underpass [62:49] yeah so the system would if if it knew [62:54] about the the street itself it would try [62:57] to figure out a solution so you'd have [62:59] cars going driving right through each [63:00] other and and then we would they were to [63:04] dedicate well it was just when our [63:07] production support guys who did a bunch [63:08] of technical tasks he would go through [63:10] and clean up those intersections so I [63:12] would I mean so it's an it's another [63:14] part of this process that you could just [63:16] go through and kind of hand author in a [63:19] different way in our editor and then it [63:21] would get processes by the system then [63:22] added to this system and then preserved [63:24] so anything that was like so a crazy [63:26] intersection where it's like we can't [63:28] support those right those left turns [63:30] there because they're gonna cut another [63:31] traffic we don't have enough track we [63:32] only have two traffic faces right east [63:34] and east west north and south so is [63:37] there a way we can make it work alright [63:38] so we can't we have to exclude this from [63:40] being happen so we're gonna delete that [63:42] path and they would also the ones they [63:44] needed and then you could we knew it was [63:45] manually authored and that would be [63:46] preserved and then that's how that stuff [63:48] was happened happened and the same thing [63:50] with overpasses so a Grand Central [63:54] Station I mean pretty much to author [63:57] author any path you just draw a line [64:00] and then you give it the little metadata [64:02] which was mostly by naming convention of [64:04] what you want it to be and then my [64:06] system automatically integrated it in [64:08] okay but did you have like roads going [64:11] over each other or was it a hundred [64:12] percent 2d now there were over there the [64:15] grand social station has that raised [64:18] deck and of course we also had the [64:19] bridges where you so for the bridge [64:21] pretty much they authored they clicked [64:23] on the ground here and they drew a line [64:24] they went click growing up the bridge [64:26] and then they clicked and I think made [64:28] it come back the cars go up the bridge [64:30] and then they turn around in the middle [64:31] and they come back okay [64:32] thank you very much the pedestrians [64:34] actually go down the subway they go [64:36] under the street and then they come out [64:37] the other side anyone over here yeah yes [64:42] thank you for the talk so did you have [64:45] any art driven rules for instance in [64:47] terms of color palette color variation [64:50] or illumination of certain parts of the [64:53] town I yes yes art drives at all so we [65:01] had a lot of there was a lot of there's [65:03] a lot of vertex paint driven stuff and [65:06] vertex color so like something like like [65:11] the puddle so in the wetness of the [65:12] streets so that was all built with by [65:16] building the vertex colors into the [65:19] models themselves so that was already [65:20] static but then artists could go through [65:23] and vertex paint and so create this [65:24] other cloud of colors that could modify [65:26] all that and for if it was on something [65:29] on the street the optimum thing to do [65:31] was actually read their vertex paint [65:32] integrate it back into the street so [65:34] they could concurrent control it that [65:36] way as far as lighting and lighting [65:38] directions stuff I mean pretty much I [65:42] mean you can see x-rays talk but pretty [65:44] much the only thing was that was any [65:45] alley alley lighting but pretty much we [65:48] were just placing this stuff out there [65:49] but yeah we're I mean we're always the [65:52] the rules include any artistic artistic [65:56] choices that we could follow oh thank [65:58] you hi hi okay [66:04] in last year's talk of a sunset [66:06] overdrive your colleagues suggested [66:09] hex great for organizing yes and the [66:11] streaming a large procedurally generated [66:14] city but I it's very inspiring and very [66:17] useful to us but I noticed that you go [66:20] back to regular square grids yeah yeah [66:24] tell me the story and the reason behind [66:26] this okay so the hex grids were [66:29] originally designed because our [66:31] procedural system was going to use a a [66:35] premade set of puzzle pieces in order to [66:38] do all the roads in layout but once we [66:40] started having all the crazy elevations [66:41] we it was impossible to have a fixed set [66:46] of pieces to do all the work so we use [66:48] the procedure assistants to make all [66:49] custom custom streets and so the hex [66:51] grid actually allows you a lot of [66:53] flexibility when you're using those [66:54] pre-created pieces I mean New York sort [66:58] of built on a grid so it I'm gonna close [67:02] this New York sort of built on on a grid [67:06] so using the grid system for streaming [67:08] regions kind of just made sense that the [67:10] hexes did not make sense for for doing [67:12] New York City okay thank you so we can [67:16] move to a a wrap-up room and if you [67:19] could tell me where that would be we [67:23] tell everybody where that would be