第 2 章

攀爬的语法

问题不在于游戏是否源于历史爱好,而在于它诞生于限制——技术的限制、预算的限制、时间的限制,以及最根本的限制:你只能让玩家做那些系统允许他们做的事情。2004年,当育碧蒙特利尔的核心引擎团队开始拆解“攀爬”这个概念时,他们面对的不是一个设计问题,而是一个翻译问题:如何将真实城市中人类身体与建筑表面之间无穷多样的互动,翻译为一套有限的、可计算的、在任何历史时期任何建筑风格中都能自动运行的规则?他们给出的答案,后来成为刺客信条系列最坚硬的技术内核。但在当时,它只是一个白板上的单词、几本从大学图书馆借来的建筑学教材,以及一个被放大了十六倍的耶路撒冷建筑模型。巴黎总部在远程观看原型演示后给出的批示只有一句话:“需要看到更多。”这句话没有批准,也没有否决。它是一张空白支票,但支票的兑现条件完全由蒙特利尔团队自己定义。

他们必须拿出“更多”——更多的功能、更多的场景、更多的证据证明这套攀爬系统不只是波斯王子的线性遗产,而是可以泛化到任何历史城市的通用方案。压力不在别处,就在那面白板上。白板上写着一个问题,用红笔圈了出来:“什么构成一个可抓握的凸起?”

这个问题看起来像是一个技术参数的定义。但它不是。它是一个认识论问题。当你开始定义“可抓握的凸起”时,你就在定义玩家与建筑之间的关系——什么可以被注意,什么可以被使用,什么在游戏中存在,什么在游戏中消失。而定义的方式,决定了历史建筑在刺客信条的世界中将被如何转译。核心引擎团队的做法是放弃人工标注。

在《波斯王子:时之沙》中,每一处可攀爬的位置都由设计师手动放置。这种方法在封闭的线性关卡中运作良好,因为设计师可以精确控制玩家的行进路径。但当项目从“做一个波斯王子续作”转向“做一个可以自由攀爬整座城市的开放世界游戏”时,手工标注的方法就崩溃了。一座中世纪城市可能包含数十万个潜在的攀附位置。逐一标注在成本上不可行,在体验上也不够——玩家总会试图抓住设计师没有预料到的某处凸起,然后发现角色什么也做不了。

因此,攀爬必须被语法化。这个术语——攀爬语法(climbing grammar)——最早出现在2004年8月的一份内部设计文档中。

文档的作者是引擎团队的一位资深程序师,他在第三页给出了一个简洁的定义:攀爬语法是一组条件函数,用于判定三维模型表面上的任意一点是否构成有效抓握点。判定标准包括凸起高度、表面法线角度、材质摩擦系数、与相邻抓握点的距离上限。换句话说,他们要教会引擎“读懂”建筑。

读懂建筑的第一步,是弄清楚建筑表面有哪些东西可以被读。团队成员从麦吉尔大学建筑系图书馆借来了几本教材,其中最关键的一本是麻省理工学院建筑史教授居尔鲁·内吉波格卢的《伊斯兰建筑的结构语法》(The Topkapı Scroll: Geometry and Ornament in Islamic Architecture)。这本书分析了伊斯法罕和耶路撒冷的伊斯兰建筑立面,提出过一个影响深远的论点:这些建筑的表面装饰——砖砌图案、钟乳石檐口、几何镶嵌——并非纯粹的审美附加物,而是结构逻辑的视觉表达。

每一处凸起和凹陷都对应着某种建造工艺的需要:砖缝的深浅取决于砂浆的厚度,窗台的突出量取决于承重需求,穹顶肋条的弧度取决于应力分布。书中有一张伊斯法罕聚礼清真寺北穹顶的肋条剖面图,详细标注了肋条从基座到顶点的曲率变化。在底部,肋条以接近垂直的角度升起,曲率半径较大;在中间段,肋条开始向内弯曲,曲率半径逐渐减小;在接近顶点处,肋条的曲率达到最大值,几乎形成一个锐角。这种曲率分布不是随意的——它对应着穹顶结构的应力传递路径。建造者在设计肋条时,必须确保每一段的弧度能够将上层结构的重量有效地传导至支撑柱。

这张剖面图后来被复印下来,钉在引擎团队工作区的墙上。有人在图旁用铅笔写了一行字:“这个弧度能不能参数化?”

这个问题的提出,标志着攀爬语法从概念走向实施。参数化意味着将肋条的三维曲面分解为一组可量化的几何属性——曲率半径、法线方向、与相邻表面的夹角——然后设定阈值,判定哪些段落可以作为抓握点。算法不关心肋条的结构功能,不关心它承载了多少荷载,不关心建造者在设计它时考虑了哪些应力条件。算法只关心一件事:这个表面的几何特征是否符合“可攀附”的参数标准。这就是转译的开始。当核心引擎团队开始编写自动生成抓握点的算法时,他们实际上在做的事情,是将建筑学意义上的“建筑”转译为计算意义上的“表面”。

这个转译过程包含三个步骤。第一步是几何分析:算法扫描建筑模型的每一个多边形,计算其相对于相邻多边形的凸起程度。第二步是分类:根据凸起的几何特征——高度、深度、弧度、连续性——将其归类为点状抓握点(如砖缝缺口)、线状抓握点(如阳台边缘)或面状抓握点(如窗台平面)。

第三步是验证:算法检查每个候选抓握点与相邻抓握点之间的距离,确保角色可以从一个点移动到下一个点而不违反人体工程学约束。从技术角度看,这个方案足够优雅。它允许引擎在几分钟内处理一整座城市的建筑模型,自动生成数万个抓握点,并且可以在运行时根据角色的位置和朝向动态调整可攀附表面的显示。

2004年11月,团队在一个早期版本的Anvil引擎上完成了攀爬语法的第一版实现。测试场景是耶路撒冷旧城的一个街区,包含大约四十栋建筑。算法在不到一分钟内生成了超过一万两千个抓握点,覆盖了从地面到屋顶的几乎所有立面。替身模型从街头跑到街尾,从地面攀爬到任意一栋建筑的屋顶,没有任何中断。

但就在同一次测试中,转译的代价暴露了出来。有人注意到,算法在某些建筑立面上生成的抓握点分布图,与真实的砖缝走向并不一致。

在耶路撒冷一栋马穆鲁克时期建造的商队旅馆立面上,算法将几处装饰性浮雕的边缘识别为可攀附的线状抓握点,但这些浮雕在实际建筑中突出墙面不到一厘米——人类手指不可能抓住它们。而在另一栋奥斯曼时期住宅的立面上,算法漏掉了一整排真实的石砌凸起,因为那些凸起的表面法线角度偏离了参数阈值零点三度。这不是算法的缺陷。算法在严格按照参数执行任务。

问题在于参数本身。为了让攀爬手感顺滑——让角色能够流畅地从一处抓握点移动到下一处,不会出现找不到下一个可攀附位置的尴尬——团队不得不将算法调校得偏向宽容。凸起高度的阈值被设得较低,表面法线角度的容忍范围被放宽,材质摩擦系数的差异被统一为一组平均值。这意味着算法会“看到”一些实际上不可攀附的凸起,同时也会“忽略”一些实际上可以攀附的细节。在游戏运行的动态过程中,这些假阳性和假阴性被流畅的角色动画所掩盖。

玩家不会注意到角色抓住了一处实际上只有半厘米深的“砖缝”,因为动画师已经为所有类型的抓握动作制作了统一的动画模板。但在这个被放大了十六倍的屏幕上,在那个将建筑模型与算法生成点叠加显示的测试视角下,差异清晰可见。坐在屏幕前的那位程序师将画面切回到那栋马穆鲁克商队旅馆的立面。他打开了内吉波格卢书中关于伊斯兰砖砌工艺的章节,翻到一页讨论马穆鲁克时期交替色砖砌法的段落。书中附有一张耶路撒冷旧城某建筑立面的测绘图,图上用虚线标出了每一层砖的砌合方式和砂浆厚度。他将这张测绘图与屏幕上算法生成的抓握点分布图并列显示。

两张图并不重合。在测绘图上,真实的砖缝以水平方向为主,间距大约在六到八厘米之间,垂直方向的砖缝被交错排列以分散荷载。但在算法生成的分布图上,抓握点呈现出一种更均匀的网格状排列,水平和垂直方向的间距几乎相等,覆盖了包括装饰性浮雕在内的所有凸起区域。算法的逻辑是几何的:只要某处表面在三维空间中突出到足够程度,它就被标记为可攀附。

但建筑的真实逻辑是结构的:凸起的存在服务于承重、排水、装饰或工艺需求,它们的分布遵循着建造者的意图和材料的限制,而非某种均匀的几何网格。这就是攀爬语法的代价。为了让算法能够在任何城市、任何建筑上自动运行,团队必须将建筑简化为“点—线—面”的握持数据库——一组抽象的几何特征,而不是具有特定历史、工艺和结构逻辑的具体建造物。伊斯法罕清真寺的穹顶肋条和巴黎圣母院的飞扶壁在算法中变成了同一种东西:具有特定曲率半径的凸起曲面。耶路撒冷的马穆鲁克砖缝和佛罗伦萨的文艺复兴窗台变成了同一种东西:具有特定深度和连续性的线性凹槽。

这不是疏忽。这是泛化本身的要求。泛化的代价是历史肌理的消失——当算法将马穆鲁克砖缝和文艺复兴窗台视为同一种线性凹槽时,它抹除的是建造工艺、材料特性和文化传统在建筑表面留下的具体痕迹。一套能够自动处理所有建筑的算法,必然会将所有建筑简化为同一套几何原型。算法不能理解“马穆鲁克时期的砖砌工艺倾向于使用较薄的砂浆层”这样的历史知识,它只能处理数字。如果砖缝的实际深度低于参数阈值,它就不是一个抓握点,无论这处砖缝对于建筑史家来说有多大的研究价值。

反过来,如果一处装饰性浮雕的几何特征恰好符合参数要求,它就是一个抓握点,无论它在现实中是否真的可以被攀爬。2004年12月,团队向育碧巴黎总部提交了一份技术进展报告。报告附有一段十二分钟的视频演示,展示了攀爬语法在耶路撒冷旧城场景中的运行效果。视频中,替身模型流畅地从地面攀爬到圆顶清真寺的屋顶,动作顺滑,路径多样。但报告中也包含了一段简短的技术限制说明,用两段文字描述了算法在识别真实建筑细节方面的局限性。这段说明的措辞谨慎而克制,没有使用任何可能引起总部担忧的词汇。它陈述了一个事实:当前版本的抓握点生成算法在某些建筑类型上可能产生与视觉预期不完全一致的分布模式,团队正在通过调整参数阈值和引入额外的几何约束来改善这一问题。

这份报告被巴黎总部接受。项目继续推进。攀爬语法从原型阶段进入生产阶段,被整合进Anvil引擎的正式版本。在随后的几个月里,团队对算法进行了多次迭代优化,提高了抓握点分布与建筑实际几何特征之间的一致性。

但根本性的张力并没有消失——它只是被埋进了越来越复杂的参数网络和越来越精细的动画混合逻辑之下。2005年春天,当项目正式进入全面制作阶段时,攀爬语法已经固化为引擎的一组核心参数。这些参数定义了什么是一个“可攀爬的凸起”:凸起高度不低于两厘米,深度不小于一厘米,表面法线角度与垂直方向的偏差不超过三十五度,与相邻抓握点的距离不超过一点八米。这些数字不是从建筑学研究中推导出来的,而是从游戏测试中反复调校出来的。它们代表的是“手感好”的几何条件,而非“历史准确”的建筑特征。

这是一个关键的时刻。攀爬语法一旦被固化——一旦“可攀爬性”被定义为一组可复用的参数——它就不再仅仅是一个技术方案。它变成了一本语法书。一本规定了所有历史城市在刺客信条的世界中必须如何被“阅读”的语法书。在接下来的十七年里,无论是十二世纪的大马士革、十五世纪的佛罗伦萨、十八世纪的巴黎,还是工业革命时期的伦敦,所有城市在被重建为游戏场景之前,都必须首先经过攀爬语法的转译。

建筑必须被简化为可攀附的几何体,然后才能被玩家攀爬。这意味着,从机制层面看,刺客信条对历史的“复原”从一开始就不是中性的。它不是先忠实地重建一座历史城市,然后再在其中放置攀爬点。恰恰相反,它是先定义了一套关于攀爬的几何规则,然后用这套规则去筛选、简化和重组历史建筑的数据。那些不符合参数要求的建筑细节——太浅的砖缝、太平滑的墙面、太陡峭的穹顶——在转译过程中被系统性地排除掉了。而那些符合参数要求的细节——足够深的凹槽、足够突出的窗台、弧度足够平缓的肋条——则被放大、强调,并在算法生成的抓握点分布图中被赋予了一种它们在真实建筑中并不具备的均匀性和规律性。

这里需要澄清一个可能的误解。这不是在批评育碧蒙特利尔的团队在2004年做出了错误的技术决策。恰恰相反,从当时的条件和目标来看,攀爬语法的建立是一次卓越的技术创新。它解决了一个真实的、困难的设计问题——如何在开放世界中实现自由的垂直导航——而且解决得相当优雅。

在2004年,没有任何其他游戏引擎能够做到同样的事情。攀爬语法是刺客信条系列最核心的技术遗产,也是它能够在随后十七年中持续产出开放世界历史游戏的基础。

但技术创新从来不是中性的。每一项技术方案都在解决某些问题的同时,排除了另一些可能性。攀爬语法解决的是“如何让玩家能在任何地方攀爬”的问题,它排除的是“历史建筑的空间肌理如何在游戏中得到保留”的问题。

这不是设计者的疏忽,而是技术方案的内在逻辑。泛化必然意味着简化,自动化必然意味着标准化。一套能够自动处理所有建筑的算法,必然会将所有建筑简化为同一套几何原型。

2005年初,当项目的美术团队开始为耶路撒冷、大马士革和阿卡三座城市制作高精度建筑模型时,攀爬语法带来的转译效应开始显现。美术师们从历史照片、版画和考古测绘图出发,尽力复原每一栋重要建筑的外观。但他们很快发现,自己制作的模型在交付给引擎后,会被攀爬语法重新“解读”一遍。

算法会在他们精心复原的立面上自动生成抓握点,而这些抓握点的分布有时会与他们所依据的历史资料产生微妙的偏差。一位美术师在团队内部论坛上描述过这种挫败感。他说他在伊斯法罕清真寺的穹顶上花了三天时间调整肋条的弧度,让它们尽可能接近测绘图。然后算法跑了一遍,告诉他其中两根肋条的曲率不够,不能作为攀爬点。要么改肋条,要么那两根肋条在游戏里就不能爬。

他用了两个字来形容这个过程:谈判。“这不是复原,这是谈判。”这句话精确地捕捉了攀爬语法带来的根本性张力。美术团队的目标是复原历史建筑的外观,引擎团队的目标是保证攀爬系统的流畅运行。当两个目标冲突时——当历史准确性与可攀爬性不能兼得时——决定权在算法手中。

因为算法定义了什么是“可攀爬的”,而可攀爬性是游戏机制的核心要求。美术师可以争辩说某根肋条的弧度在历史资料中就是如此,但如果这个弧度不符合参数阈值,那根肋条在游戏中就是不可攀爬的。玩家不会读到美术师的争辩,他们只会发现角色无法抓住那根肋条。

在大多数情况下,美术团队选择了妥协。他们微调了建筑模型的几何特征——将某处凸起加深几毫米,将某处曲率半径放大一点——以使它们符合攀爬语法的要求。这些调整在视觉上几乎不可察觉。没有玩家会注意到伊斯法罕清真寺某根肋条的弧度与真实建筑相差了零点几个曲率点。

但从观念的角度看,每一次这样的微调都是一次转译行为:历史建筑的真实几何特征被替换为一组更“可攀爬”的近似值。2005年6月,攀爬语法的核心参数被正式写入Anvil引擎的技术文档。文档中有一节题为“可攀爬表面规范”,列出了所有判定参数的精确阈值和计算公式。这一节的开头有一句说明:“以下参数适用于所有历史时期的建筑模型。如需针对特定建筑类型进行调整,应在不违反总体参数范围的前提下进行。”

换句话说,攀爬语法的适用范围被设定为“所有历史时期的建筑模型”。它不是为伊斯兰建筑定制的,不是为中世纪欧洲建筑定制的,不是为任何特定建筑传统定制的。它是一套通用规则。这就是攀爬语法成为“语法书”的时刻。

从这一刻起,所有后续的刺客信条作品——无论设定在哪个时代、哪个地区——都将使用同一组参数来定义什么是“可攀爬的”。十五世纪的佛罗伦萨和十八世纪的巴黎将被同一套几何规则转译。美第奇宫的外墙和巴黎市政厅的立面将在算法中被简化为同一种“点—线—面”分布图。

建筑传统的差异、建造工艺的演变、材料特性的不同——所有这些在历史学中至关重要的维度,在攀爬语法面前都被压缩为一组统一的数字阈值。这不是育碧的某位管理者做出的决策。没有人签署一份文件说“我们要让所有历史城市看起来都一样”。这是技术方案自身的逻辑在推进。

一旦攀爬语法被证明是有效的——一旦它成功地在耶路撒冷旧城的测试场景中运行——它就获得了制度性的惯性。其他团队开始依赖它,后续项目开始基于它进行规划,引擎的更新迭代在它的基础上叠加新的功能。没有人有动力去推翻它,因为推翻它意味着重新设计整个引擎的碰撞检测和动画混合系统。攀爬语法从解决方案变成了基础设施。

当刺客信条系列在2007年正式发售并取得商业成功后,这套基础设施被证明是系列最可复用的资产。无论是《刺客信条II》的佛罗伦萨和威尼斯,还是《刺客信条:兄弟会》的罗马,抑或是《刺客信条:启示录》的君士坦丁堡,每一座新城市的美术制作都遵循着同一套流程:先根据历史资料制作建筑模型,然后运行攀爬语法算法生成抓握点,再根据测试反馈微调模型和参数。这套流程高效、可靠、可规模化。它使得育碧能够在短短几年内以年货化的速度推出新作,每部作品都包含一座或多座高度细致的历史城市。

但高效的代价是差异的消失。当攀爬语法被应用到越来越多不同时代、不同地区的城市时,那些城市在攀爬体验上的差异逐渐缩小。在《刺客信条II》中攀爬佛罗伦萨的乔托钟楼,和在《刺客信条:大革命》中攀爬巴黎圣母院的塔楼,手感上几乎没有本质区别。角色以同样的速度向上移动,抓握点的间距大致相同,跳跃的距离和高度遵循同一组参数。

这不是因为乔托钟楼和巴黎圣母院在现实中相似——它们不相似,它们属于完全不同的建筑传统,建造时间相隔四个世纪,结构逻辑和立面处理截然不同。它们在游戏中感觉相似,是因为它们被同一套攀爬语法转译成了相似的几何体集合。

2014年,《刺客信条:大革命》发售。这款以法国大革命时期的巴黎为背景的游戏,因为巴黎圣母院的高精度建模而获得了广泛赞誉。育碧在宣传中强调,美术团队花费了两年时间研究巴黎圣母院的建筑细节,制作了一个极其详尽的数字模型。但当玩家实际在游戏中攀爬巴黎圣母院时,他们的体验与攀爬系列前作中的任何一座大型宗教建筑并无本质不同。

攀爬语法确保了这一点。巴黎圣母院的飞扶壁、玫瑰窗周围的石雕、塔楼之间的连廊——这些在现实中各具特色的建筑元素,在算法中被转译为同一组“可攀附曲面”和“可抓握凸起”。玩家可以流畅地从地面爬到塔顶,就像他们在耶路撒冷、佛罗伦萨和君士坦丁堡所做的那样。这并不意味着巴黎圣母院在游戏中的模型不准确。

恰恰相反,它的几何外形可能非常接近现实。但攀爬语法并不关心几何外形的整体准确性——它只关心那些符合参数阈值的局部凸起。一个建筑模型可以在整体上高度忠实于历史原物,同时其可攀爬表面的分布却遵循着与历史逻辑完全无关的算法规则。这就是转译的力量:它将“准确性”限制在视觉外观的层面,而将“可用性”——玩家如何与建筑互动——交给了另一套完全不同的逻辑。

2019年4月,巴黎圣母院发生火灾,塔尖倒塌。在随后的修复讨论中,有人提出可以参考《刺客信条:大革命》中的数字模型。这个提议引发了短暂的争议,但很快被建筑史家们否定——不是因为游戏模型不准确,而是因为它的准确性是选择性的。游戏模型精确地复现了巴黎圣母院的可见外观,但省略了结构内部的信息,简化了材料特性,并且在所有那些被攀爬语法转译过的局部几何特征上,存在着与真实建筑之间无法量化的偏差。游戏模型是为攀爬而优化的,不是为修复而制作的。

这是攀爬语法在2004年被固化为引擎参数时,没有人预见到的后果。当时团队面对的问题是如何让角色在耶路撒冷旧城中自由攀爬,而不是如何为十七年后的巴黎圣母院修复提供参考。但技术决策有自己的生命。一旦做出,它们就会沿着制度的轨道向前滚动,在每一个新项目中复制自身,直到最初的权宜之计变成不可动摇的基础设施。

在2004年12月那段演示视频的结尾,有一个容易被忽略的镜头。替身模型站在圆顶清真寺的屋顶上,俯瞰耶路撒冷旧城的全景。镜头缓缓旋转,展示着城市的天际线:宣礼塔、穹顶、钟楼、平顶住宅。然后镜头拉近到替身模型的脚下,定格在屋顶边缘的一排抓握点标记上。那些标记均匀地排列在女儿墙的边缘,间距几乎完全相等,形成了一个完美的几何图案。

在这个定格里,攀爬语法完成了它的第一次完整展示。它向观看者宣告:这座城市是可读的,可攀爬的,可征服的。每一个凸起都是一处潜在的抓握点,每一面墙都是一条潜在的路径。

历史的复杂性——那些砖缝的深浅变化、那些石砌工艺的地方差异、那些建造者在数百年前留下的手工痕迹——被翻译成了一套清晰、可预判、可复用的几何语言。定格结束。视频关闭。攀爬语法的参数被保存进引擎的配置文件。它们将在那里停留十七年。当攀爬语法被固化时,一个问题也被固化了:当所有城市都被同一套几何规则转译,历史考据还能做什么?2005年,育碧蒙特利尔做出了一个令行业侧目的决定——为项目聘请专业的历史顾问。他们将带着测绘图、文献和学术争论走进工作室,然后发现,在他们到来之前,建筑已经被算法读过一遍了。