全平台同步的工程地狱

工程部的白板上第一次出现“四端同步”这个词，是在2017年初夏。白板摆在普天信息产业园那间没有窗户的会议室里，左上角还残留着上一轮《崩坏3》活动策划的擦痕。有人用蓝色马克笔写下三个词：PC、移动端、主机。三个词被画进同一个圆，中间写着“数据互通”。写完之后，会议室里安静了几秒。

没有人讨论这个圆能不能画成，因为所有人都在想另一个问题：如果真按这个圆去做，现有的自研引擎，基本等于没有。这是当时米哈游内部最清楚也最不愿承认的事实。他们用来做《崩坏3》的那套管线和引擎，在移动端上跑得足够好，在模拟器和PC端也能应付。但那是在单平台交付的前提下。一旦要求同一个版本在不同算力、不同内存、不同输入方式的设备上同时跑通，引擎底层就露出大量无法掩盖的洞。资源格式不通用，着色器路径不统一，场景加载逻辑只针对手机内存做过优化。摇杆、触屏、键鼠的输入接口根本不存在。

最要命的是，这套系统的设计前提是单端运行，它从需求上就不考虑在服务器端同步角色数据、任务状态、场景交互和实时位置。全平台数据互通，意味着服务端必须成为唯一的逻辑核心，而所有终端都只是不同分辨率的窗口。这个由三个词构成的圆形，看起来是发布策略，实际上是技术路线。

真正意识到这个工程规模的人不多。蔡浩宇是其中之一。在《原神》预研项目的早期会议里，他很少直接说“全平台”三个字，而是把它拆成一个个必须验证的具体问题。他说移动端的内存预算是硬约束，主机端的时间预算是硬约束，PC端的分辨率适配是硬约束。三个硬约束互相打架的时候，如果没有一套统一的渲染管线和资源管线，就只能靠穷举人手在四个平台上分别修。结果必然是四个版本从第二个版本开始分叉，最后变成四个不同的游戏。

这个判断没有争议。争议在于怎么避免。一种意见是先用移动端做出可玩的原型，再考虑向其他平台扩展。这种做法的优势显而易见：团队熟悉手机开发，风险低，周期短。

但它的代价也摆在眼前：一旦移动端版本在资源格式、光照模型和场景精度上定型，再向主机端和PC端迁移，就相当于把做好的房子拆掉一半重盖。

另一种意见是反过来，先以主机端为基准做高规格版本，再向下裁剪适配移动端。这样做的好处是上限高，坏处是移动端可能永远裁不下来。2017年的手机芯片远不足以承受主机级别的场景复杂度，如果裁剪失败，项目就会卡死在技术验证阶段，连上线都谈不上。

关于这两条路线的争论，持续了很长时间。没有完整的会议记录留下来，但有一个结果后来被反复提及：米哈游选择了第三条路。

引擎同时生产两个层级的资产，一套高精度资源用于PC和主机，一套低精度资源用于移动端，但两者共享同一套场景逻辑与角色数据。这意味着引擎需要支持自动化的资产转换，需要维护两套渲染路径，需要让光照、材质、动画在不同精度下保持视觉上的一致性。换句话说，他们不是在做一款游戏，而是在做一条能同时产出多个规格的生产线。

这个目标的提出本身，就是对现有团队能力的一次越级挑战。这种“一次开发、多端同步”的架构，在当时的游戏行业里几乎找不到现成样本。主机游戏厂商习惯先做单一平台，再委托第三方工作室做移植。手游厂商则几乎不考虑主机端，因为主机平台的开发套件、审核流程和用户预期都与移动端完全不同。米哈游要把这件事一次做掉，而且是用自己的引擎做掉。工程团队没有外部参照，只能从底层开始写。

项目启动后的头几个月，大量精力花在资源格式的统一上。模型、贴图、骨骼、动画、材质、特效，每一类资源都要定义一套跨平台的本体格式，再为每个平台写出对应的导入器和运行时加载器。这个阶段的工作量像在修地基，地上看不到任何东西，但一旦地基形状不对，上面的建筑就会一路歪下去。

《崩坏3》团队被抽血的实际影响，也在这个阶段开始显现。预研项目从《崩坏3》相关研发序列中抽走了一批核心工程师和美术，这些人原本负责的是已经上线、正在稳定盈利的产品。

他们离开后，原本的版本节奏没有立刻崩掉，因为《崩坏3》已经跑顺了一套流程，剩下的人还能顶住日常更新。但“顶住”和“做好”是两回事。一些需要长期投入的优化和内容储备被放缓，部分功能的排期被拉长。《崩坏3》的玩家不会在一周内察觉到变化，但内部看板上的任务完成速度变慢了。

更隐蔽的影响在人的状态上。被抽去新项目的人，手里同时挂着旧项目的维护任务和新项目的验证任务。白天在旧引擎里改一个角色皮肤的材质参数，晚上在新引擎里调同一角色的资源管线，两套系统逻辑完全不同，切换得多了，人会不断犯低级错误。这些错误大部分在测试阶段被拦下来，但每次返工都在消耗本就不足的时间。

新项目不叫《原神》。在内部，它只有一个代号。参与早期预研的人被要求不对外透露项目内容，甚至连项目代号都不允许写进公开文档。保密的要求本身也加重了工作的隔阂。留在《崩坏3》团队的人不知道被抽走的同事去了哪，被抽走的人也不能说自己在做什么。同一栋楼里，两个团队之间的信息交换变得谨慎。

原本可以公开讨论的技术问题，现在只能在特定会议室里关起门说。这种保密有商业上的必要，但它在组织内部制造了一道不易察觉的墙。墙里的人在对抗一个从未被验证过的技术目标，墙外的人在维持公司唯一的现金流产品。两边都清楚自己在为同一家公司工作，却不知道对方具体的处境。

光照系统最早撞上了这面墙。开放世界场景里，光不是静态贴图，而是随时间变化的动态系统。太阳角度一动，所有阴影、反射、明暗过渡都要跟着变。团队最初尝试把《崩坏3》的光照方案直接扩展成开放世界版本，结果在移动端测试机上跑起来，帧率掉到了个位数。

第一套方案被否掉之后，他们改为在主机端用实时全局光照，在移动端用预烘焙加简化的动态光。但两者切换时，场景有明显跳变，同一片草地在不同平台上颜色不一样，同一个角色的脸部阴影也不一致。视觉团队无法接受，工程团队无法解决。方案被推倒。第二次、第三次、第四次，问题从全局光照扩散到材质球、后处理、阴影层级。

每一次推倒都会牵连已经做好的场景和角色资产，所有下游环节都要跟着返工。这种返工的成本不是纸面时间表能反映出来的。场景组做好的地图，因为光照方案变更，需要重新调整植被密度和建筑摆位；角色组做好的模型，因为材质规范变了，需要重新拆分UV和贴图；特效组做的技能表现，因为后处理管线换了，需要重新测试每一种天气下的观感。

项目没有大规模扩招之前，这些工作压在同一批人身上。他们白天做《崩坏3》的日常版本，晚上和周末做新项目。没有人公开抱怨，但出勤记录不会骗人。普天信息产业园那栋楼的物业后来知道，深夜常亮的那几间办公室，集中在同一层。保洁员早上六点进楼，经常能看到有人趴在工位上睡着，手边是空的能量饮料罐。

光照方案的推倒重来不止一次。到了第五次，蔡浩宇下了一个判断：不要再去兼容《崩坏3》那套旧管线了。旧的着色器模型、旧的材质规范、旧的光照思路，全部推倒。重新写一套面向开放世界和跨平台的渲染系统，哪怕再花半年。

这个决定让很多人沉默，因为它等于承认过去两年积累的技术资产大部分作废。但也正是从第五次推倒开始，团队才真正跳出了手机游戏的惯性。

新的渲染系统按平台分级设计，同一套场景在高端平台和移动端走不同的路径，但共享同一套物理世界参数。第六次重构解决了移动端帧率问题，第七次重构解决了主机端画面统一问题。没有哪个版本被称为“最终版”，因为上线前的每一个月都在改。

与光照系统并行的是联机模块。这个模块的初衷是让不同平台的玩家能够在同一个世界里相遇。技术上，这意味着服务器要处理不同客户端版本之间的状态同步。移动端的网络波动、主机端的联网策略、PC端的防火墙设置，差异极大。

早期联机方案参照了当时主流手游玩法，把多人部分做成独立房间，和开放世界主体分离。这个方案测试下来，房间进出正常，但玩家在大世界中看不到其他玩家。产品侧认为这样不够，因为开放世界的沉浸感会被割裂。工程侧认为这样最稳，因为独立房间不会影响大世界的性能。两边僵持不下。

问题在2018年上半年彻底暴露。一次内部测试中，几名测试人员同时进入大世界，做了最简单的动作：一个人向前跑，一个人站在山坡上看。结果在移动端设备上，站在山坡上的玩家看到跑动者每隔几秒瞬移一次，位置信息滞后明显。

延迟不是网络波动造成的，而是服务端同步逻辑和客户端资源加载不同步。跑动者进入新区域时，服务端已经更新了位置，但客户端还没有完成场景加载。一旦加载完成，角色会突然跳到最新位置。

这个看着不大的问题，牵出了整个联机架构的根本缺陷：开放世界不像房间制，场景大、对象多、交互频繁，不能靠简单的状态推送来同步。项目组试图在现有架构上打补丁，增加位置预测和延迟补偿，但在移动端帧率不稳的情况下，补丁越多，越不可控。最终，联机模块被整体废弃重建。新的架构抛弃了独立房间思路，改为大世界无缝组队。服务器不再只是中转站，而要根据玩家之间的距离和视野实时决策哪些信息需要同步、哪些可以忽略。

这套逻辑需要在四端上都保持公平，不能因为移动端的加载慢就被主机玩家看到瞬移，也不能因为主机的网络好就获得额外优势。重建花了三个多月，废弃掉的代码超过十万行。三个多月里，项目的联机进度从对外看起来没有任何进展。只有内部看板上的任务卡片在变，红色的延期标记一天比一天多。

到2018年底，移动端的发热和帧率问题几乎压垮整个项目。那段时间的测试记录后来被整理成表格，每一行都写着设备型号、芯片温度、帧率曲线、场景名称。表格里的数字很有说服力：地图边缘区域的平均帧率在二十四帧上下，战斗场景最低掉到十二帧；部分安卓设备运行十五分钟后芯片温度突破四十二摄氏度，再高就开始降频，降频后画面变成幻灯片。测试团队每天拉一批设备进实验室，下班时再抬出来放进散热柜。有人开玩笑说，实验室不像做游戏，像做手机评测。这个玩笑没人接。因为当时公司已经为这个项目投入了远超以往任何产品的预算，如果移动端跑不动，项目就没有存在的理由。

2018年12月，一次内部评审会上，移动端表现被直接拿到台面上讨论。当时投影上放着一张对比图：同一场景在主机开发套件上是四十八帧，在旗舰手机上只有二十帧。差距不是优化能补的，是设计目标超出了硬件能力。会议开了几个小时，没有人说“取消”，但“暂停”“降级”“重新定义”这些词反复出现。

刘伟在那个阶段需要做另一件事，就是向董事会和外部合作方说明，这个项目还在轨道上。他手里拿着的进度和数据，远不如工程团队看到的那么难看。但难看的部分，最终还是传出了项目组。

真正让项目活下来的，是一次方向性调整：不再追求在移动端上完整呈现主机端的所有细节，而是接受移动端作为降级版本，只保证核心体验和核心画面风格。这个调整看似妥协，实际上重新划定了工程边界。以前团队试图让四端完全一致，结果每一端都要处理最坏情况。

现在改成“同一种体验，不同精度”，移动端可以牺牲远景密度、阴影精度、水面反射，但只要玩家在手机上看到的提瓦特大陆，和主机上的提瓦特大陆是同一个世界，就算成功。这个标准仍然很难，但它可以度量，可以测试，可以分工。团队的精力从“全部一致”转向“关键一致”，发热和帧率问题也才第一次有了可操作的解决路径。

与内部工程同步推进的，是外部的平台谈判。米哈游想把《原神》同时发到PC、主机、移动端，并且允许玩家在不同设备间使用同一个账号。这在当时几乎没有先例，尤其是主机平台方对账号体系、内容更新、支付接口有严格规定。主机平台方习惯的是封闭生态，发行商提交版本，平台审核，审核通过后上架。版本更新也要经过审核。移动端则习惯周更、月更、热修复。

要让主机端和移动端同步更新，意味着要么主机平台给米哈游更灵活的更新权限，要么移动端版本等待主机审核周期，无法快速响应玩家问题。两种做法都触碰平台规则。谈判的重点在存档互通和内容同步上。

存档互通不只是技术问题，还涉及平台方对用户数据的边界认定。主机平台一向保护自己的账号体系，第三方游戏厂商只能通过平台账号接口进行登录。如果允许玩家在手机端登录同一账号并在主机端继续进度，那么服务端就必须跨平台保存用户数据。这个数据到底属于谁，谁有权访问，谁有权删除，都需要在合同里写明。

米哈游的诉求很明确：所有核心数据都在自有服务器上，平台账号只做登录认证。主机平台方的顾虑是：如果数据离开平台生态，后续的支付、客服、行为规范都会脱离控制。这种谈判不会一次完成，往往是一个条款接一个条款地磨。双方都清楚，这不是单纯的商务问题，而是对玩家关系的长期争夺。

与移动应用平台的谈判则集中在分成比例和审核节奏上。移动平台方有成熟的分成规则和推荐机制，但全球同步发行意味着米哈游要在不同地区的应用商店同时上线。不同地区的审核标准、内容政策、税务规则都有差异。一个版本在某个地区被要求修改，其他地区是否也一起改？如果要改，全球同步就有被拖慢的风险；

如果不改，合规风险由谁承担？这些问题看似操作细节，但在一个要求全球同步的项目里，每一处都可能变成卡点。米哈游的商务团队在与平台方沟通时，反复强调“同步”是第一优先级。平台方需要的不是承诺，而是流程。米哈游需要提供稳定的版本规划、合规预审机制和响应时间表。这些文档当时大多还不存在，团队一边谈一边补。

索尼的态度后来被证明是关键。主机平台在亚太地区拥有大量用户，但通常不向中小型开发团队开放开发套件和技术支持。《原神》要上主机，就意味着米哈游必须拿到主机平台的开发授权，并且通过其严格的版本审核。米哈游为此提供了技术演示、项目规划、商业预期等多种材料。

谈判并不是一次妥协，而是一连串小规模验证。平台方关注的是游戏能否在其硬件上稳定运行，米哈游关注的是开发和更新能否保持自己的节奏。双方在技术标准条款上争议最久。

一个具体问题：当移动端版本进行热修复时，主机端是否需要同步提交补丁？如果不同步，联机时版本差异如何校验？

如果同步，热修复的响应速度会被平台审核周期拉平。最后条款的落法，不能从公开文档里找到完整原文，但从后来上线后的运营模式看，主机端对更新前端的兼容做了更严格的版本窗口管理。

开发团队为这种同步付出的代价，是持续不断的多端回归测试。外部谈判的压力传导到内部，变成了对项目进度的额外约束。平台方提出的技术标准，很多是工程团队从没接触过的。主机平台对存储封装、网络接口、崩溃日志都有专门规范。移动端不需要的认证流程，主机端必须逐项完成。每一次平台审核前的准备，都是一轮高强度改代码周期。

团队最先崩溃的，不是体力，而是对时间预期的信心。原定的里程碑一次次往后推。起初是2018年第三季度公开测试，后来推到第四季度，再推到2019年春季。每推一次，内部看板上的日期就被覆盖一次，覆盖到后来，没人再相信上面的数字。

2019年初，项目组做过一次内部时间线比对。原计划里的开放世界框架，已经基本建成；光照系统在第七版之后趋于稳定；

联机模块的重建版本跑通了小规模测试；移动端经过裁剪后，在中高端机型上可以维持在三十帧左右。

这些进展放在任何一家正常开发公司，都算得上阶段性胜利。但在米哈游，它们只是让项目从“不可能”回到了“可能”。

真正面向玩家的内容，包括主线剧情、角色关系、任务链、生态循环、卡池系统，大部分还在制作中。工程团队刚刚把路铺好，路上的建筑还没有盖全。而对外公开的压力已经逼近。

在这种内外夹击下，公司做了一个决定：先做一支宣传视频。当时的考虑不是市场预热，而是用一次公开亮相来倒逼内部节奏，同时向合作方证明产品状态。

宣传视频的制作抽调了美术和动画团队的一部分人力，在工程进度已经很紧的情况下，这几乎是一种冒险。视频里展示的场景和角色，大部分来自当时已经完成的版本，少部分需要为了镜头效果单独打磨。参与制作的人后来回忆，那段时间的画面渲染排期和游戏优化排期是冲突的，机器资源被两边争抢。

与索尼的谈判在存档互通条款上卡了最久。不是卡在技术能不能实现，而是卡在“谁拥有用户数据”这个看似抽象、实则寸土不让的问题上。

主机平台方的法务团队坚持一个逻辑：用户通过主机账号登录游戏，其游戏进度、角色数据、充值记录就属于平台生态的一部分。平台有权对这些数据进行保护，也有权在用户发生纠纷时依据平台规则处理。

米哈游的法务和商务团队则坚持另一个逻辑：游戏数据由自有服务器生成和存储，平台账号只承担认证功能，不应延伸至数据所有权。双方在合同草案上来回修改了十几版，每一版都在“数据控制者”的定义上挪动几个词。

主机平台方一度提出，如果用户在主机端充值，退款和客服流程必须走平台通道，米哈游不得直接介入。米哈游的回应是，如果同一个账号在移动端充值、在主机端消费，退款时如何切割？如果无法切割，是否意味着主机平台可以单方面冻结跨平台账号的全部资产？这个问题抛出来之后，电话会议沉默了将近半分钟。

不是某一方被问住了，而是双方都意识到，这不是一个可以靠模糊条款绕过去的技术细节。它牵涉到全球不同地区消费者保护法的差异，牵涉到平台方与应用开发方之间的权责边界，牵涉到一个从未被大规模验证过的跨平台运营模型到底由谁来兜底。

最终条款的落法没有公开，但从后来上线后的实际运营看，米哈游守住了自有服务器对核心数据的控制权，代价是在主机端接受了更严格的版本同步窗口和更复杂的客服协同流程。这意味着工程团队在每次更新前，必须为主机端单独准备一份经过平台预审的版本包，同时保留移动端热修复的灵活性。两条更新节奏在服务器端汇合，任何一边出错，都会导致联机时的版本校验失败。这个代价在谈判桌上只是一个条款，在工程实现上是一整套持续运转的额外管线。

类似的拉锯也发生在移动应用平台。移动平台方对全球同步发行的顾虑不在数据所有权，而在审核节奏。

一个版本要在全球多个地区的应用商店同时上线，意味着同一份代码要同时通过不同地区的合规审查。某些地区对虚拟物品概率公示有额外要求，某些地区对未成年人消费有时段限制，某些地区对特定视觉元素有内容规范。米哈游的商务团队在沟通中反复被问到同一个问题：如果某个地区要求修改，你们是改全球版本还是只改地区版本？如果改全球版本，其他地区的上线时间是否推迟？如果只改地区版本，后续联机时不同地区的客户端版本如何保持一致？

这些问题没有现成答案，因为在此之前，几乎没有手游厂商尝试过真正意义上的全球同步发行。大多数厂商的做法是先在一个地区上线，跑通之后再逐步铺开。

米哈游要一步到位，就必须在第一次提交前，把所有地区的合规要求预审一遍，把可能冲突的条款提前消化。商务团队为此拉了一张巨大的表格，每一行是一个地区，每一列是一条合规项，颜色标记从绿到红。

绿色代表已确认无风险，红色代表存在明确冲突。2018年下半年的那张表上，红色格子一度占了将近三分之一。

有人通宵赶镜头，有人在旁边等着跑游戏测试，两个团队在同一个区域里互相等，互相催。

2019年6月，宣传视频发布。画面精致，音乐完整，镜头穿过草原、森林、雪地和城市，角色从空中俯冲而下，元素技能在开阔场景里炸开。

视频在极短时间内被大量转发，随后引发激烈争议。争议的内容不是视觉质量，而是关于原创性、平台选择和商业模式的不同判断。这些声音把米哈游推上了全球游戏舆论的前台。

而在公司内部，视频发布后的那个下午，没有太多人庆祝。项目负责人看完评论区后，关掉页面，继续处理当天未完成的多端回归测试。接下来要解决的问题，不再只是画面不一致或帧率太低，而是全世界玩家都盯着这支视频，期待它变成可以下载的游戏。

那套花了两年多建成的跨平台管线，成了米哈游此后几年最重要的资产。它让一个团队可以在不同硬件上维护同一个世界，也让后来的出海者不得不面对一个现实：全球同步不是翻译几个语言包，而是从引擎底层开始重新设计产品。

但在这套管线建成的时候，最初的兴奋感已经消耗得差不多。留下的是疲惫。疲惫不是某一个人的状态，而是一个组织在长期自我否定之后形成的低烧。项目还要继续往前走，但能推动它的人，都已经在很久之前用掉了最能回血的力气。