迪克心，西木造：《银翼杀手》游戏版20周年（上）

16位色的2019年

　　在2000年的一次演讲中，Castle对外宣称，《银翼杀手》是公司历史上Production Value最高的游戏。

　　Production Value是电影行业的概念术语，后来因为互动娱乐艺术在各方面都越来越接近电影，所以这个概念也被引入了游戏行业。通俗点说，这个概念在游戏和电影制作中很大程度上体现了从业者的态度和“良心”。从业者做出的产品不论销量与口碑好坏，游戏本身的美术和技术上的投入、最终呈现出的质量，这些创造出来的真正“价值”都是客观存在的，具有一定的绝对价值，而不需要外部主观评说就能自证的固有属性。

　　重现电影中的关键场景，是Castle向“伙伴”做出的承诺，也是让这个游戏紧扣电影气氛的至关重要手段。在前文的那些道具师的提示下，Castle得到灵感，他觉得游戏中用来重建电影场景的3D场景建模也能用到这种思路，便让3D美术从现有的各种3D模型库里随便挑选素材，给他们下死命令：只能把现有3D素材变形、切割、缩放、上新材质，但不许从零开始设计。没想到这么做的最后成果让所有人都赞叹不已：3D模型搭建的场景效果几乎可以乱真电影场景。

　　为了避免重复劳动，也为了让制作流程更顺畅，Westwood学着好莱坞的布景制作理念，建立了一个3D和2D素材的资料库，以便能够在场景制作中重复使用那些素材。从每一个体积光锥动画，到每一把带霓虹灯伞骨的雨伞的一切元素，都被收纳进了这个资料库。通过它，所有3D美术师都可以方便地录入模型和元素，然后在需要是快速调出，做修改后放进需要的场景中。由Eric Chadwick负责的Mondo Media外包团队在后来的大量3D预渲染场景制作中立下汗马功劳，他们自然是这个素材库的最大受益者。当然，这也导致了一些小问题，因为抽调素材过于便利，导致某些场景过于臃肿，进而引发连锁的渲染问题。

　　电影拍摄中实际用到的布景是有限的，布景师可以随意重新布局改造然后重复使用，甚至同一个布景用不同角度拍摄都能让人=观众以为是另一个地方，最后创造出电影中五花八门的场景。可游戏里的每一个布景却都是需要3D软件扎扎实实做出来的，有上百个场景允许玩家自由探索，而每个场景的丰富度和密度都意味着数百万个多边形。正如他们向“伙伴公司”保证的那样，场景制作根据电影布景为蓝本，使用3D软件最终制作并预渲染出了史上最精美丰富的冒险游戏场景。

　　1995年项目启动之初，Westwood的计划是采用640x480全屏分辨率， 每秒15帧的256色画面输出，因为当时多数同类游戏都是这个规格。可他们几乎立刻发现，要让设想的无处不在的雾气和烟雾特效看起来逼真，就连16位色（65536种颜色）都无法达到他们想要的效果，无奈必须转向24位（16位色的256倍，1766万种颜色）色，也就是当年游戏玩家追求的“真彩色”。

　　事实上，即便是1998年都没有多少显卡能让640x480的24位色画面稳定跑到每秒15帧，更不用说加入大量的音频和特效之后了。他们辛苦制作出来的预渲染场景，平均每一个场景都有8-10秒的循环，而每秒是15帧画面，每一帧都是24位色。在所有场景预渲染完成后，全部场景的原始文件以及后文要提到的角色原始文件加起来多达249个G的天文数字。因此压缩成了个巨大挑战。

　　压缩的任务是把每一帧的色彩压缩到100万色以内，同时还不能让游戏超过16位色，因为当时根本没有显卡能负担这么大的压力。所以他们借鉴了矢量量化(vector quantization)技术的原理，将画面切割成无数“小块”，并计算判断哪些小块的颜色是视频播放最常出现的。 为了让游戏能维持在10-15帧的帧数下，当你所想要显示的颜色在16位色板中不存在时，这种压缩技术就会自动用16位色的小块去替换那些过于丰富的颜色，而下一帧时这个小块又快速被另一个看似接近的16位颜色所替换，这样从全局来看，每一帧的色彩都是不会超过16位色的，可当这种不易察觉的替换持续不断地以帧为单位进行时，帧与帧之间的高速交替会给人眼带来一种丰富程度近似24位色的错觉。

　　最后，压缩的动态场景成了类似NTSC制式电视机播放的视频，如果你暂停视频，会看起来很粗糙，但如果持续播放，那么看起来就会好许多，动画的色彩会比每一帧单独看时丰富得多。

体素的故事

　　有了如此精美的3D预渲染动态场景，可游戏角色该怎么办？当时最好的显卡每帧只能负担几百个多边形，即便是最高端的显卡，仅是处理一个角色都需要长得令人发指的时间，而又即便能忍受这么长的时间，那些角色看起来就像是个折纸小人。给个同年的高规格游戏《星球大战之绝地武士：黑暗原力2》（Star Wars Jedi Knight: Dark Forces II）做例子：

　　这种惨不忍睹的多边形效果完全不可能满足Westwood对自己产品哪怕最低的要求。不过绝望之中的Westwood愣是想出了办法。他们基于游戏开发史上的一个奇葩——体素（Voxel）创造了一种全新的技术。这种技术后来还被Westwood充分运用在了《命令与征服2：泰伯利亚之日》中作战单位的缩放和旋转上。在90年代中期，任何一个游戏胆敢尝试做1000个动态捕捉序列都会被视为荒唐又危险的尝试，而他们的《银翼杀手》，需要做2万多个。

　　核心程序工程师James McNeill带着手下尝试了多种引擎概念：直接用纯粹的体素（最后使用在了《命令与征服：泰伯利亚之日》中）、高氏着色三角形，以及最后使用在游戏中的“切片模型”。McNeill在1996年刚入职Westwood时，正赶上公司从DOS系统的3D Studio升级到Windows平台的3D Studio Max 1.0版本，他立刻进入状态，小试牛刀，给3DS Max编写了一套自定义渲染器插件来生成那些角色和物件模型。可当时Autodesk公司为自定义渲染器插件API接口做的说明文档还非常不完善，为此McNeil还特地跑了好几次Autodesk公司的总部索取资料和沟通技术问题。

　　在制作刚启动时工作室就很清楚，一定会遇到数不胜数的不确定性因素。为了防范于未然，他们提前罗列了能想象得到的一切风险和困难，等开发进行到一定程度后，许多预料到的问题都会在这个过程中逐渐化解。当时团队一直想采用动作捕捉技术，然后用3DS Max软件处理。可当时并没有现成的技术能将Vicon系统捕捉到的动作信息直接在角色骨架上起作用，3D美术师David Austin回忆，项目组里的几名程序员又专门写了个通用插件来使得3DS Max能识别收到贴在动作捕捉目标上的记号信息。这个程序有一些瑕疵，但整体效果还是非常不错的。

　　McCoy作为主人公，自然必须是游戏中看上去最细腻的角色。大多数场景中，只要处于站立情况下，他就有最高的精细度——由20000个体素组成。每秒处理20万个多边形是不可能的，但要是每秒处理20万个像素就没那么难了。问题是，以当时的图形技术，仅仅要“看到”那些模型是没问题的，可如果要对那些体素模型做任何处理和调整就不可能了，所以如果要实现动画，他们只能把每一个体素模型序列转换成图片序列来处理，可这么干的后果，就是对游戏的视觉效果造成了比其他任何不利因素都要严重的破坏。

　　不过，破坏的原因其实并不是因为它们不好看，而是因为这对整个制作流程产生了巨大负担：游戏一共有26000个动态捕捉序列，而这对人手有限的工作室是个天文数字，当时只有极少数的体育游戏达到过3000个序列的水平，所以他们根本没有时间和人力来优化这个数量，可如果不减少序列数，游戏容量就成问题了。他们面临的唯一选择，就是缩小角色序列图片的尺寸了。

　　这么做的间接后果就是导致角色，尤其是近景时自动拉伸的角色身上的马赛克特别严重。当时许多人以为这是为了性能考虑才把角色拉伸成那样，可实际上并非如此。角色的每一帧都是2D，而显卡绘制一个2D角色是和图片实际分辨率无关的，因为当2D图片被拉伸到需要的尺寸后，显卡依然要绘制那么大一张“马赛克”角色图片。因此，这一切都只是因为序列数量巨大，导致容量过大。当时工作室估计，如果在保持画质不降低的情况下，仅仅只做一个人物的行走循环动画，可能会占用高达50兆字节的容量。

　　就这样，容量问题居然成了这个游戏最大的敌人：在DVD载体诞生之前，即便计划是整整4张CD，这点容量对当前的游戏规模来也已捉襟见肘。更让人恼火的是，1997年的主流个人电脑硬盘容量还不到3个G，玩家固然可以选择最小化安装，可撇开游戏过程中频繁切换CD的麻烦不说，要读取如此巨大的数据量，对玩家的光驱也是严峻的考验。对一款非FMV冒险游戏来说，《银翼杀手》已经破当年游戏的容量纪录了，却依然很难在每个角色“清晰度令人满意”和“容量不能太大”之间的博弈中找到那个平衡点。Westwood在这场博弈中做出了一个最艰难的选择，丢卒保车，将把除了McCoy以外的所有角色都严重马赛克化。

　　后来常有人问Castle为什么当时不直接使用全3D画面。其实这对现在的游戏开发来说当然是更简单的选择，同样的一个游戏放到今天，任何人都会选择用全3D来制作。但在当时，并没有像现在那么方便的3D渲染管线和着色器，有些顶点着色的多边形和材质贴图在许多款显卡上连显示都不准确。不过，Castle当年大胆预言，体素和光线追迹这样的技术早晚会重新回到主流游戏开发的舞台上，因为如今的图形渲染管线实在过于复杂繁琐，以至于我们不得不折返到考验计算负荷的逐像素分辨率这条路上。“三十年河东，三十年河西”。