一个引擎与一个世界

华沙理工大学十三号宿舍楼的走廊里弥漫着煮土豆和旧书的气味。三〇七室的房门虚掩，门缝里透出显示器屏幕幽蓝的闪烁光。房间里没有人在玩游戏。一台米色外壳的486电脑摆在靠窗的桌子上，机箱盖早已拆掉，散热风扇发出持续的嗡鸣。

三个学生围在屏幕前，其中一人手指在键盘上快速移动，另外两人在纸上记录十六进制地址序列。屏幕上显示的是一种十六进制编辑器的界面，右侧面板是解码后的ASCII字符，左侧是一排排紧凑的数字。他们正在拆解一个文件——《毁灭战士》的WAD资源包。

这一年是1996年。当CD Projekt在华沙的办公室里忙着与BioWare谈判《博德之门》的波兰语本地化授权时，这些年轻人正在做着完全不同的事情。

他们手里的《毁灭战士》光盘来自华沙体育场的盗版摊位，价格大概是三美元。但他们不是在安装游戏。

他们在做的事情，盗版商贩不懂，大部分玩家也不关心：他们在试图理解id Software是如何将那些像素恶魔、地狱走廊、武器动画和音效打包进一张软盘容量的空间里的。那个敲键盘的学生叫克日什托夫。他在华沙理工大学读数学，但过去十八个月里他的主要教育发生在课堂之外。通过反汇编工具和十六进制编辑器，他已经粗略了解了《毁灭战士》的渲染循环结构、BSP树遍历算法和WAD文件格式的内部组织。他从来没有读过计算机图形学的正式教材——那类书在波兰大学图书馆里几乎不存在——但他可以徒手画出程序在4MB内存中分配纹理缓存的方式。

他的两个同学正在记录的，是WAD文件中一个特定纹理集的偏移地址。他们想写一个工具，把《毁灭战士》里的怪物皮肤替换成自制的像素画。

这不是一次孤立事件。在整个波兰，类似的学习行为正在多个城市同时发生。在克拉科夫，几个高中生通过反复修改《英雄无敌》的存档文件学会了十六进制运算和基本的数据结构概念。

在格但斯克，一个十七岁的少年在当地的BBS上发布了《命令与征服》的单位属性修改器——他自学了汇编语言，仅仅是为了弄清楚游戏如何在内存中表示坦克的射速参数。在弗罗茨瓦夫，一个数学系学生为《雷神之锤》编写了波兰语界面补丁，不是出于翻译的需要，而是因为他想通过实践理解QuakeC脚本语言的事件驱动模型。

这些人彼此并不认识——至少在当时还不认识。但他们共享着完全相同的基本条件：无法获得正规的游戏开发教育，无法购买商业开发工具，无法接触引擎授权，甚至无法稳定地连接互联网。1996年，波兰的拨号上网费用按分钟计费，下载一份最新的图形编程文档可能需要花费一个学生三天的午餐费用。

但他们也共享着相同的基本优势。波兰的数学和物理基础教育在社会主义时期被刻意强化，那些在大学入学考试中脱颖而出的学生往往具有出色的抽象思维能力和逻辑训练。

更重要的是，他们拥有一种在匮乏环境中形成的特殊本能：当他们无法通过标准途径获取知识时，他们不会等待，而是直接拆解手头能找到的任何材料。二手市场上可以买到盗版的Borland C++编译器，价格大概是西方面向学生的正版价格的二十分之一。计算机杂志上刊登的编程教程可以充当入门教材。《Bajtek》月刊从1980年代末就开始连载BASIC语言教程，到了1990年代中期，内容已经升级为汇编语言入门、VGA图形模式分析和声霸卡编程接口说明。这些文章的作者用波兰语重述了西方教材中的核心概念，填补了正规课程的空白。《Komputer》杂志更进一步，在游戏编程专栏中直接刊登可运行的代码片段：简单2D物理引擎的实现思路、游戏循环的结构设计、键盘中断的捕获与处理。

但杂志只能提供离散的知识点。真正的系统学习发生在另一个领域。1990年代中期，波兰的demo场景正在经历一个黄金期。

所谓demo场景，是一种起源于1980年代欧洲的地下计算机文化：程序员、图形艺术家和音乐人组成团队，创作称为“demo”的实时图形演示程序。这些程序的核心特征是极端的体积限制——一个包含三分钟音乐同步三维动画的demo，其可执行文件大小可能只有64KB，甚至4KB。达到这种压缩率要求对底层代码、内存布局、数字信号处理和图形硬件特性有近乎偏执的理解。

波兰的demo团队——Tristar & Red Sector、Pulse、Poland——在欧洲竞赛中逐渐获得声誉。一个名叫阿德里安·赫梅拉什的年轻人是Pulse团队的核心成员。他在1994年为一部64KB demo编写了纹理生成模块，该模块在运行时使用数学公式动态生成所有纹理，而非存储预渲染的位图数据。这个技术决定不是为了炫技，而是出于硬约束：64KB的空间必须容纳程序代码、音乐数据和所有视觉资源。传统的纹理存储方式根本不可能满足限制。赫梅拉什没有学过纹理压缩算法。

他自学的方法是在没有任何文档的情况下逐字节分析了几十个西方demo的二进制文件，通过反复试错和模式识别，逐渐推导出了各种压缩策略的实现细节。这种方法——通过拆解成品来理解底层机制——正是波兰早期游戏技术积累的核心方法论。

到1996年，demo场景与游戏修改社群之间的技术边界已经开始模糊。一个擅长优化渲染循环的demo程序员，几乎不需要额外学习就能为一个现有游戏编写性能改进补丁。一个习惯了在4KB约束下工作的纹理艺术家，面对游戏MOD的角色皮肤制作需求时会发现自己的技能严重过剩。事实上，许多波兰程序员同时在两个领域活动——白天为demo竞赛编写效果代码，晚上为《毁灭战士》或《雷神之锤》制作MOD。

《毁灭战士》的MOD社群在1995至1996年间全球爆发，波兰的贡献远远超出了关卡设计的范畴。

西方MOD制作者主要使用id Software官方发布的关卡编辑器来创建新的地图和关卡。波兰的爱好者则直接操作WAD文件格式。

他们编写了提取、替换和重新打包WAD资源的工具，学习文件结构的方法是在十六进制编辑器中逐字节比对修改前后的差异。当他们需要修改渲染行为时——例如改变光照计算方式或调整纹理过滤模式——他们直接在反汇编层面分析引擎的可执行文件。

这就不再是MOD了。这是逆向工程。这种逆向工程的文化根源可以追溯到波兰灰色市场的特殊生态。当正版软件价格超出普通消费者承受能力时，盗版商贩提供的破解版本成为了主要的软件分发渠道。破解行为本身——去除CD检查、绕过序列号验证、剥离区域锁——要求破解者具备相当水平的反汇编和调试技能。在西方，这类技能通常与软件盗版的地下经济联系在一起。在波兰，由于盗版几乎是所有人获取软件的唯一方式，破解技能的道德色彩被大幅度稀释了。

一个为《命令与征服》编写免CD补丁的大学生，不认为自己在从事非法活动——他只是在解决一个实际问题，让他合法购买的硬件能够正常运行他合法购买的光盘。这一区别在后面变得很重要。

当这群人后来进入合法游戏开发产业时，他们带进去的不仅是从逆向工程中获得的技术知识，还有一套对待技术问题的实用主义态度：如果现有工具不能完成工作，就自己动手修改工具；如果一个系统的行为不符合预期，就深入底层找出原因。这种态度在游戏开发中是无价的，但当涉及到软件许可证合规性、第三方代码库的合法使用时，它也会制造冲突。

1996年秋天，波兰的BBS网络开始在技术社群的凝聚中发挥中枢作用。这些BBS站台——华沙的“Galaxy BBS”、波兹南的“Amiga Zone”、罗兹的“Dark Side”——通常运行在志愿者家中的个人电脑上，通过一两根电话线接受拨号连接。由于电话费用昂贵，用户大多在深夜登录，用最快的速度下载新的技术资源，然后离线阅读。论坛不是实时聊天的形式，而是留言板：用户发表问题和回复，其他人几小时或几天后再登录查看。

一个典型的技术讨论线索可能是这样展开的：某用户发布了一个问题，询问如何修改某款游戏的纹理缓存策略以解决在老显卡上的显示错误；两天后，另一个人回复了一个内存地址列表和修改建议；再过一天，第三个人指出第一版修改方案在处理大纹理时会导致内存泄漏，并附上了改进版本。

这种异步协作的速度在今天看来是慢得不可思议的，但它在波兰培育了一种特殊的协作文化：参与者彼此之间很少见面，甚至不知道对方的真实姓名，但通过持续的技术交流建立起了基于能力的信任。多年后，当CD Projekt RED开始招聘时，很多面试官和应聘者第一次见面就能通过“你在BBS上用过什么ID”来迅速确认彼此的技术背景。

是时候谈论这个积累过程的结构性特征了。西方游戏产业的技术能力是在资本充裕的环境中通过正式教育、企业研发和商业竞争逐步建立起来的。

1990年代的id Software能够为《雷神之锤》从头构建一个完整的3D引擎，是因为它拥有一支有经验的核心团队，有来自《毁灭战士》的销售收入支撑，有使用昂贵SGI工作站的开发环境。Epic Games能够开发虚幻引擎，是因为蒂姆·斯维尼在游戏引擎架构上已经积累了近十年的连续经验。

波兰的路径完全相反。它不是在资本充裕的实验室里完成的积累，而是在对西方游戏的拆解、修改和本地化适配中，通过逆向学习建立起来的。

这种路径的最重要特征在于：学习者的知识结构是自下而上构建的。一个用十六进制编辑器修改存档文件的高中生，首先学到的是文件结构的基本概念——头部、数据段、校验和。当他转而试图修改游戏逻辑时，他必须理解内存分配和指针操作。当他尝试优化渲染性能时，他开始接触CPU缓存行、浮点运算成本和GPU的图形管线。每一步学习都是由一个具体的技术挑战驱动的，每一步都建立在上一步积累的底层知识之上。这种学习顺序与正规计算机教育几乎完全相反。

大学课程通常从抽象概念开始——算法复杂度、数据结构、设计模式——然后才触及具体实现。波兰的自学者则从最具体的二进制修改开始，逐层向上抽象。当他们最终接触到面向对象编程或设计模式时——通常是通过盗版的英文编程书籍或从西方BBS抓取的电子文档——他们会瞬间认出这些概念是他们在实践中已经模糊体验过的东西。

这一路径产生了一个具体的技术特征：波兰开发者对引擎底层、资源优化和跨硬件兼容性有着极强的实战能力。他们习惯于在性能远低于西方标准的机器上工作，因此对内存使用效率、CPU周期消耗和磁盘I/O开销有着近乎本能的敏感。他们善于在缺少完整文档的情况下通过实验和推测来理解技术系统，这使他们在面对授权第三方引擎时的学习速度明显快于习惯于完整文档支持的西方开发者。

但这条路径同样产生了结构性的知识缺口。逆向工程可以让你理解一个系统是如何工作的，但它很难教会你如何从零设计一个系统。

一个通过修改《雷神之锤》学会了3D渲染管线的波兰程序员，可能非常熟悉id Software特定版本的渲染循环实现，但他可能从未思考过为什么id Software的架构师选择了这种特定的设计而非其他方案。他更少有机会实践从需求定义开始、经过架构设计、模块划分、接口定义，最终到实现的完整开发流程。

MOD制作强化了这种偏向。制作一个《英雄无敌》MOD涉及到调整数值参数、添加新单位和修改部分游戏逻辑，但它不需要你设计可扩展的数据驱动系统，不需要你规划未来内容更新的技术架构，不需要你处理多语言本地化的资源管理。一个优秀的MOD制作者和一个合格的游戏引擎架构师之间，存在着一整套关于大规模软件工程设计的能力差距。

到1997年时，这些结构性特征已经在波兰技术人才的能力轮廓中清晰可见。几个独立团队开始尝试原创游戏开发，很快遭遇了在MOD制作中很少面对的挑战。“Mortyr”项目是一个典型案例。

这个第一人称射击游戏的原型由华沙的一个小团队从1997年开始开发。团队成员都有丰富的《毁灭公爵3D》MOD制作经验，他们最初的设想很简单：用从《毁灭公爵3D》逆向工程中学到的技术，做一个波兰主题的射击游戏。几个月后，他们撞上了一堵墙。管理一个从零开始的完整代码库远比修改现有引擎复杂得多。内存泄漏、帧率不稳定、不同显卡型号上的渲染差异——这些问题在他们之前制作MOD时很少遇到，因为id Software的工程师已经解决了底层架构的大部分难题。团队的解决策略具有鲜明的波兰特色：他们尝试将自制的游戏逻辑层嫁接在从《毁灭公爵3D》逆向出来的渲染层上。这种做法短期内产出了一个可以运行的原型，但底层的法律风险和稳定性问题使其注定无法成为商业产品。到1999年，Mortyr团队解散。但核心成员并没有离开游戏开发。其中一个人后来进入了CD Projekt RED的早期团队，另一个人成为了People Can Fly的创始成员。

Mortyr的失败不是终点，而是人才分流的节点。People Can Fly本身的故事更清晰地展示了这条技术路径的潜力与局限。这家工作室由阿德里安·赫梅拉什在2002年创立，但其技术积累的时间线要追溯到更早。赫梅拉什从1990年代中期在Pulse团队的demo场景经验中获得了对实时图形编程的深刻理解。当虚幻引擎在1998年发布时，他立即意识到这是一个可以合法获取的、功能完整的3D引擎——与过去只能在逆向工程中间接学习的id Tech引擎不同。接下来的几年里，他带领一个小组系统性地研究了虚幻引擎的底层架构，不是通过反汇编——现在有了合法的SDK——而是通过阅读文档、分析示例和实验。当他们后来开发《斩妖除魔》时，团队对虚幻引擎的理解已经达到了可以对其进行深度修改和扩展的程度，尽管他们仍然没有从零构建自己的引擎。这种模式——深度驾驭西方引擎而非自研——在波兰游戏产业中反复出现。Techland在弗罗茨瓦夫的团队采用了类似的路线。

这家公司成立于1991年，最初从事教育软件开发。到1990年代后期，其程序员团队——许多人是当地大学数学系和物理系的毕业生——通过分析《古墓丽影》的关卡格式学习三维空间管理，通过研究《暗黑破坏神》的程序化生成算法理解随机内容系统。这些非正式学习在2000年代初期凝结为Chrome Engine，一个主要服务于Techland自有游戏的自研引擎。但Chrome Engine的早期版本仍然留下了明显的逆向学习痕迹：其渲染管线的某些设计选择与同时期西方引擎非常相似，不是因为直接复制，而是因为Techland的工程师在长期研究西方引擎的过程中内化了某些“标准”的解决方案。现在必须面对一个看起来矛盾的现象：一方面，波兰的技术积累路径培养出了强大的实战能力；另一方面，它导致的架构知识和工程规范的缺失在原创开发中反复制造困难。这两种效应不是相互抵消的，而是同时成立的。理解这个双重性，是理解后来CD Projekt RED技术冒险的关键。

当CD Projekt RED在2002年选择BioWare的Aurora引擎作为《巫师》的基础时，这个决定在外界看来是务实的——一个小型工作室无力自研引擎。但这个解释掩盖了一个更深层的逻辑：CD Projekt RED初始团队的技术能力恰恰集中在理解和修改现有系统上。十年的逆向工程文化训练出了一批精于拆解、分析和改造的开发者。他们擅长的事情不是白纸上画蓝图，而是在别人的蓝图上重新规划管线。选择Aurora引擎不是妥协，而是对自身能力轮廓的诚实承认。同一个判断可以从另一个角度得到印证：这支团队在驾驭Aurora引擎时展现出了远超行业平均水平的改造能力。《巫师》最终实现的道德选择系统、炼金术机制和动态昼夜循环，都不是Aurora引擎原生支持的功能模块。团队将这些系统嫁接到引擎上的方式——深入底层代码、理解数据流、在最小化冲突的前提下扩展功能——与十年前那些波兰学生在十六进制编辑器中修改WAD文件的工作方式具有明显的基因连续性。

道德选择系统本身是另一个值得注意的问题。这个后来成为CDPR品牌标志的系统设计，其起源与技术限制有直接的因果关系。当你的游戏在视觉表现上无法与西方大作竞争时——Aurora引擎在2002年已经是四年前的技术，不可能在画面上与同期使用虚幻引擎2或id Tech 4的游戏抗衡——你必须在其他维度建立差异化。“我们买不起顶级画面，但我们可以给你真正的选择后果”——这个命题的第一个版本不是市场定位的结果，而是技术约束的创造性转化。现在可以把时间快进到2002年。当伊温斯基和基琴斯基开始为游戏开发部门招募人才时，他们进入的正是这样一个人才市场：几乎没有拥有正规游戏开发经验的专业人士，但存在一个庞大的、通过非正式渠道完成技术训练的潜在候选人池。这些人的简历上写着数学学位、物理学学位，或者干脆没有学位。

但他们能够在面试中详细解释DirectX渲染管线的执行流程，能够讨论内存对齐策略对性能的影响，能够展示他们在BBS上发表的技术分析文章或业余制作的游戏原型。塞巴斯蒂安·杰林斯基是这些候选人中的佼佼者。作为《刺杀希特勒2093-1944》的开发者，他是波兰少数拥有完整商业游戏开发经验的人。但他的技术根基同样来自于1990年代的非正式学习网络。他在大学期间通过破解西方游戏学习了汇编语言，通过参与demo场景的活动磨练了图形编程技能，通过制作MOD理解了游戏系统的设计逻辑。当他加入CD Projekt RED担任首席程序员时，他带来的不只是一个人的技能，还有一整套在匮乏环境中形成的问题解决方法论：遇到未知系统时先拆解而非先读文档，信任实验胜过信任规范，在资源约束中寻找创造性的绕行方案。亚当·巴多夫斯基的轨迹体现了这条路径的另一个面向。

他后来成为CD Projekt RED的联合负责人和《巫师》系列的艺术总监，但在1990年代，他是一个通过修改西方游戏纹理文件来自学数字绘画的年轻人。他没有上过正式的艺术学院——在当时的波兰，数字艺术的正规教育几乎不存在。他的训练场是那些通过盗版渠道获得的游戏，他通过在像素层面分析西方艺术家的作品来理解色彩、构图和材质表现的原理。他的成长过程既体现了波兰技术路径的特征——在实践中学习、通过拆解他人作品来吸收知识——也暴露了其知识结构的偏门：多年后当他需要管理一个涉及复杂生产管线的艺术团队时，那些在正规教育中会被系统讲授的项目管理和流程设计知识，他必须从头自学。当CD Projekt RED在罗兹的阁楼办公室里集结时，团队成员之间存在着一种特殊的默契。他们中的许多人在此之前已经通过BBS论坛、demo聚会或MOD合作项目彼此认识。他们共享着同样的技术语言，同样的工作伦理，同样的信念。

这种文化的迅速成型缩短了通常需要数月才能完成的团队磨合期。但他们也共享着同样的知识缺口。团队中没有人拥有完整设计并实现一个商业游戏引擎的经验。没有人参与过从预研到发布的完整开发周期。没有人管理过需要协调程序员、美术师、设计师和音频工程师的生产管线。这些能力在西方大厂中是层层传递的——初级开发者在有经验的前辈指导下逐步学习工程规范、质量标准和项目节奏。CD Projekt RED的阁楼里没有这些前辈。他们每个人都是自己所在领域中最有经验的人，而那个经验的上限是由十年的逆向工程和业余项目实践所定义的。所以当杰林斯基在那个夏天傍晚说出“我们需要从头设计战斗系统”这句话时，他触碰到的不仅是一个设计决策。这句话将启动一系列现在看来几乎不可能完成的任务：为一个他们无法修改源码的第三方引擎编写一套全新的实时战斗系统；在没有标准动作游戏设计经验的情况下实现连击、闪避、格挡和法印施放的复杂交互；在硬件性能远低于预期的目标平台上维持可接受的帧率。

每一项单独拿出来都是一个严峻的挑战。放在一起，它们构成了一个只有一支具备波兰式技术基因的团队才敢于承担的风险。因为他们已经习惯了在资源不足的情况下工作。因为他们的整个技术生涯都是在不可能的约束中寻找可行解。因为他们从来不知道“标准做法”是什么，所以也不觉得偏离标准是一种风险。屏幕上那个灰色小人一动不动。窗外，罗兹的夜幕已经完全降临。这座工业城市的纺织厂大多已经停产，废弃的厂房在城市的各个角落沉默矗立。经济转型的伤痕尚未愈合，新产业的基础仍在缓慢建设中。在这个国家的这个时刻，十五个人坐在一间租来的阁楼里，准备用他们从盗版光盘和十六进制编辑器中学会的一切，去制作一款属于波兰自己的角色扮演游戏。他们手上的合同赋予了他们对“猎魔人”这一IP的独家游戏改编权。他们为这份合同支付的金额低得连一位西方代理律师的时薪都不够。合同的签字方是那个对电子游戏充满轻蔑的作家安杰伊·萨普科夫斯基，他认为这不可能是任何有价值的东西。灰色小人仍在原地静止。

它没有纹理，没有动画，没有武器，甚至没有一个成形的战斗系统。从技术上讲，它几乎还不能被称为一个角色原型。但它是一个存在。它的存在证明了这支团队已经完成了从拆解到创造的第一步——不是修改别人的游戏，而是开始构建自己的。接下来的两千天将被投入到这个转变中。那些在BBS论坛的深夜讨论中积累的零散知识将在Aurora引擎的框架内被重新组织。那些在demo场景的极限编程中磨砺的优化技能将在《巫师》的资源管理中发挥作用。那些在MOD制作中形成的对游戏系统的直觉将引导道德选择和叙事结构的设计。技术债务同样会显现。当Aurora引擎的架构限制在开发后期频繁引发问题时，团队会意识到补丁式改造的极限。当项目规模的扩张超出任何人的管理经验时，用即兴协作替代正规工程流程的成本会暴涨。

当《巫师》最终在2007年发布时，它携带的技术负担将成为CD Projekt决定自研REDengine的直接动因——而这个自研引擎的冒险，恰恰将暴露波兰技术路径中最大的结构性缺陷：在“拆解”中训练出来的能力，远远不足以应对从零“构建”一个工业级引擎的复杂度。但那些都是后来的事。现在，在这个1996年与2002年的交汇点上——本章所追踪的技术人才流正在从分散的BBS节点和MOD项目汇入这间阁楼——唯一确定的事情是：波兰游戏产业的技术积累已经完成了它的第一个阶段。一个足以支撑商业游戏开发的人才池已经形成。这个人才池的特殊能力（深度驾驭第三方系统、在资源约束中优化、通过逆向分析快速学习）和系统性缺陷（缺乏自研架构经验、缺失正规工程训练、对大规模项目管理陌生）将共同塑造CD Projekt RED接下来长达十年的技术决策。命运在阁楼里安放了一个入口。而那个灰色小人将在随后的岁月里，把这个国家的游戏开发史不可逆转地推向没有人能预见的轨道。