游戏下载和游戏更新，如何让包体“苗条如竹”

游戏下载往往是玩家对游戏的**印象，“人生若只如初见”，重要性不言而喻。

但是陪伴玩家“一生”的可能是更新，毕竟下载只有一次，更新却经常要做，如果不想“何事秋风悲画扇”，做好更新体验也不可忽略。

成年人，不做选择，两者都要。

此次，我们邀请了益达的游戏研发专家风霖来给大家分享。本文会详细介绍如何做好游戏的“**印象“和“长情陪伴”。

这些技术，很多少侠可能还用不到，但是实际项目基本绕不开。其中关键技术其实在很多其他地方也是能用上的，甚至不是游戏开发，比如压缩技术、资源格式设计、贴图压缩等。所以可以就当看个“奇闻”，茶余饭后，嗦一口~

开篇大吉

真是胆大包天，开篇就开始打广告，真的是很腻（n）害（h）【PS:这两个官方页面URL取得可真吉利用心

是的，皮一下就真的很开心】。

少侠们别急，大家看完可以发现，手游已经超过10GB，端游已然超过100GB。

当然，这绝对不是个例，随着硬件一直升级，游戏品质也疯狂迭代升级，包体自然而然就爆炸。所以，益达平台如何设计合理的游戏资源打包机制，以及在游戏上线后，如何对资源进行更新就显得尤为重要。本文将根据《逆水寒》端游实际落地的方案出发，从游戏打包、游戏下载、游戏更新、工具支持四个方面进行介绍。虽然方案是基于PC端的，但是和手机端还是有很多共通之处。文件设计、压缩算法、更新技术、数据监控、实战经验，会尽量涉及到打包、更新的大部分技术，希望对大家能有帮助。

游戏打包

游戏打包主要分打包文件格式设计、文件大小、文件读取、打包加速四个方面进行介绍。

打包文件格式设计

古语有言：不怕“万一”，只怕“一万”。所以，打包的目的就是将一万个文件合成一个，而不让一万个文件分布在游戏各种目录中。

整个游戏所有资源，可能有几十万甚至上百万个文件，通过打包，不仅提高客户端安装速度，同时还能加速资源读取的速度，是必不可少的技术。如下图，是《逆水寒》端游的资源包部分内容，可以看到，很多资源被打包进到后缀为WDF的文件中。每个WDF文件大致在1-3GB（实践证明，当包体为2GB左右时，程序的性能表现会更出色。这是个荒诞的经验值，纯属个人主观感受，别当真经用，所有WDF文件都会严格控制在4GB（为了适应外网可能存在不同的文件系统，可怜可怜FAT吧。市面上也有一些游戏，会将打包文件搞的更小，比如100MB，益达平台根据游戏项目自己决定即可。

单个打包文件设计过程主要考虑文件尽量小，读取尽量快，更新友好。基于这些要求，打包文件的结构设计大致如下，主要由3块内容pack起来：文件头、文件索引信息、文件内容，其中，文件头和文件索引信息比较小，文件内容是大头。这样一来，文件头和文件索引信息可以常驻内存，整体开销也不大，这样需要去判断文件是否存在的常用操作就变得非常高效。

文件头

根据实际需要看是否需要留一些配置信息，比如当前版本号，是否开启特殊功能等。空闲空间标记，主要是为更新设计，一个文件可能在某次更新中会被删除，就会出现空洞，这个释放出来的空间可以给其他新增文件继续使用，所以需要有这么一个标记来标记那块空间是空闲的，方便快速进行文件写入。如果文件头没有完全确定好要存什么信息，可以预留些空间，总是有机会能“亡羊补牢”的。

文件索引信息

每个文件索引指向文件内容的地址和大小，注意这里可能需要设计多个地址功能。比如文件1，**次打包是完全在一起的，但是在更新过程，可能会因为空洞大小不足被切分成多个部分，比如图中就切成了3个部分。在《逆水寒》端游实际测试中，经过一年几十次的更新后，会存在切割成多部分的文件，但是很少会超过4部分的。

文件内容

会将整段空间切分成很多大小相等的Block，比如4kb。Block太大，会导致空洞浪费比较多，比如6MB文件，在block为4MB的时候需要占据2个Block浪费了2MB，当Block为5MB的时候也占据2个Block浪费了4MB。Block太小，会导致需要维护空闲空间的成本增加。所以需要根据项目大部分文件大小找到一个比较合适的数值。

这个结构的设计还有一个好处。就是一开始可以将文件头和文件索引信息下载下来，其他文件可以实现边玩边下。《逆水寒》也支持了一套边玩边下的机制，但是方法有点不同，后面在更新模块会对这块内容进行介绍。

《逆水寒》对于文件内容是支持切分成多个分块的，因为在更新过程中，文件有可能有变化，变大或者缩小，如果不支持切分多块，会导致内部空洞不必要空洞太多。因为单个文件切割成多个部分，会带来多次磁盘寻道，存在数量比较多，会影响资源读取，所以需要定期对打包文件进行整理工作。

文件大小

为了文件尽量小，主要考虑三个因素：压缩算法、文件去重、文件删除。

压缩算法

常见压缩算法有lzma，lz4，zstd等，网上有很多关于这些压缩方法在压缩率、压缩时间、解压时间上的对比，综合考虑下，《逆水寒》压缩算法主要使用压缩率差一些，但是压缩和解压都比较不错的lz4。不过后面，我们又发现unreal使用的一个压缩技术。链接如www.yarongsy.com能对压缩提升10%左右，大包体游戏还是提升很可观的，实际测试下来，对帧率没什么影响，所以oodle的方案也是一个不错的选择。对于上线游戏，这部分替换会比较麻烦，所以还没上线的游戏，可以综合对比后，确认和使用更好的方案。

游戏中大量资源都是贴图，可能会占据整个客户端超过一半的数据量。所以如果能对贴图进行更好的压缩，对于包体的减少是非常可观的。原来逆水寒将美术制作的tga转换成带压缩的dds贴图，有一定程度的贴图减少，但是通过微软官方方式生成的dds使用压缩算法进行二次压缩，压缩比并不好。后面，引入了一个oodle texture技术，也可以将tga贴图转成dds，但是oodle生成的dds对压缩算法非常友好，这个技术有一个叫rdo-lambda的参数会控制压缩后贴图的质量，最终我们选择默认对dds贴图使用rdo-lambda=90进行压缩，整体贴图压缩比大概在40-50%之间，而且效果虽然单纯贴图对比可以看出，但是实际放到游戏中，不管场景还是角色，美术的接受度都比较高。之前有一篇文章，对这个贴图压缩技术有更详细的介绍，感兴趣的同学可以移步看看：www.yarongsy.com。这都单独发了一个链接，自然是想让大家去使（点）用（赞）的，真的很推荐使用这个技术。

当然，oodle家族的这两个算法，都不是免费的，但是总体价格也并不贵。对于包体减少是非常有意义的，对性能也没有影响，推荐大家可以评估使用。

文件去重

文件去重也是很值得做的。项目初期时候，我们并没有太关注这块内容，直到临近上线，发现包体比较大，还是想尽量控制一下，查一下可优化的地方，苍蝇肉也是肉，去重还是很有必要做的。通过统计发现重复文件主要有两种：1.编译后的shader文件；2.美术资源，如贴图、模型。

1的问题跟逆水寒项目shader编译可能强相关，不一定有借鉴意义。美术资源重复应该是很多项目的共性，毕竟借鉴一下之前做法，准备做修改，后面又没有修改就用了，情况是很容易存在的。所以需要对所有打包文件根据计算的md5值来进行去重。

我们曾经想过，检测到重复文件就提醒美术让他们去掉，但是想到：技术不能成为艺术的绊脚石，忍了忍了。最终我们还是在打包环节对这个进行了处理。对于重复文件，我们只打包一份，其他重复的通过文件重定向来进行文件读取。重定向进行数据处理会导致文件读取需要进行两次硬盘读取，有一定开销，重复数量比较多可能需要从根源上去解决了。

这里需要注意的另外一点是：因为打包大部分会做并行化，就是会有多个进程进行不同文件的打包，彼此之间并不知道其他文件的信息。针对这个情况，一般有两种做法：1.做局部去重，就是单个打包文件内的文件做去重；2.做全局去重，在所有打包结束后，这时候我们得到所有文件的信息，做打包后处理，将重复文件做重定向。

文件删除

游戏上线后，只要稳定运营，包体的增加往往是很快的，真是一年几十GB的增加呀。制作过程也存在一些临时文件并没有被删除也进了打包。基于“存在即合理”的准则，对于不存在的文件，我们最好要删除。

文件删除最好是在项目初期就开始设计考虑并执行，真的到了线上后才来“亡羊补牢”，真的是“长使英雄泪满襟”。不但操作起来很麻烦，很多时候，你都不敢轻易删，因为删错了可能就是一个事故。我们是真的很头铁（毕竟《逆水寒》有铁衣职业），为了尽可能减少包体哪怕一点，我们做了如下的工作：

1. 日常自动化测试中，会对所有资源进行记录，通过几个月记录后发现有资源一直都没被跑到的，我们将这些文件作为待删除资源，记录到一张表格里头。

2. 内网日常开发测试中，判断“待删除资源”是否还会被使用到，如果发现还是有使用记录，就将其从“待删除资源”中进行删除。这个算内部二次检测，这个周期最好留几个月。

3. 通过内部所有测试后的“待删除资源”，已经半年时间过去了。我们将这个列表正式放到外网中。外网会在资源读取的时候监控“待删除资源”是否还被使用到，如果被玩家使用了，就会向我们服务器发送并做记录，我们会从表中删除。这个阶段可能需要持续半年。

4. 通过内网、外网都验证过的“待删除资源”，一年时间可能已经过去了，这个时候我们可能才会真正将这些资源从打包中删除。

大家可以看到，整个过程非常繁琐，甚至你到第4步，都还不是非常确定删除的资源会不会有问题，真是瞎子摸到三岔路口——不知所措。so啊，游戏设计初期不考虑到资源删除问题，长期运营后，包体问题会成为越来越大的问题，所以还是建议在初期做好考量，初期好的设计会减少后期不少麻烦。而且很多时候，不一定是技术上的，也可以是方案上的，比如：1.给所有物品都设计它的生命周期，这样，东西下架后，资源能被删除的时间是很容易监控的；2.给物品设计折旧或者到期变成物料。尤其以时装作为卖点的游戏，时装增长速度是非常恐怖的，我们曾经考虑将外放很久的时装做贴图质量降低来减小包体，但是策划是不能接受的，玩家会反馈说他买的衣服怎么变不好看了。一开始的世界观就决定了很多事情是不好做的，所以在世界观架构的时候，如果能将资源问题考虑进去，很多事会好办很多。谁说时装一定要永久，谁说时装不能变旧变不好看，不过在于玩家是否接受这个设定，做的是否够有趣。比如《逆水寒》手游打出：账号角色会慢慢变老甚至死亡，需要培养自己的孩子来继承自己的产业，就非常有趣，玩家还觉得特别有意思，因为它很贴近真实。好吧，越俎代庖了，收！

文件读取

为了做到读取尽量快，我们做了如下一些事情：

1. 文件压缩往小的做。一般来说，文件变小了，自然读取也会变快。但是如果压缩过猛，也会导致解压费时，所以大小和速度是要同时兼顾的。这块前面已经做了比较详细介绍。

2. 异步读取和cache。游戏资源千千万，随时可能有资源读取可能，所以，整个资源管理方案一定要做到异步读取，条件允许最好还要支持cache，尽量减少短时间再从硬盘中读取。

3. 缓存文件头。判断文件是否存在是游戏经常会使用的逻辑，就算资源不加载，也有这个判断。如果这个数据一直需要从硬盘去读取，会浪费大量时间。因为我们在文件头中已经记录了这些信息，所以可以让这部分数据常驻内存，整体开销也不大。

4. 共用文件相邻打包。打包的时候，肯定会涉及到以怎样的顺序进行打包，比如按字母排序，比如按照目录等。建议同时可能会被使用的资源尽量放在同一个包，并且最好是前后相邻位置，比如也给角色渲染时候可能需要使用多张贴图，这个时候可以将这些贴图放在一起。一定程度上可以减少磁盘寻道带来的开销。

打包加速

虽然说，玩家的体验是最重要的，但是打包速度如果不够快，也会导致开发效率比较低下，毕竟每天都是需要打版本来进行测试的。在优化前，一次完整打包可能需要3-4个小时，效率简直惨不忍睹。我们对打包加速做了很多次优化，主要的操作如下：

1. 硬件升级。SSD、内存大小、CPU性能都对打包有比较大的影响，牺牲空间换时间，直接给打包机上顶配吧，硬件升级带来的提升是非常给力的，强烈推荐。另外，SSD可能用的时间长，性能会有损耗，导致打包速度下降，我们发现过这个情况，如果打包速度有下降，可以考虑SSD更换一波。硬件效果，立竿见影，用钱能解决的事情，就不要往死里薅程序了~

2. 打包并行。打包开启多线程或者多进程，甚至做好分布式系统，在多台机子上进行打包。并行带来的提升也是显而易见的。当然这要求每个打包是相对独立的，对于打包这个功能，大部分互斥，还是容易做到的。

3. 数据提前处理。打包不仅仅只是将数据放在一起，很多时候数据还需要先被处理，比如文本文件转二进制文件，tga贴图转dds贴图，模型合并，模型lod数据生成等等，会有大量的打包前处理工作。这些工作如果都放在打包的时候才做，会消耗大量时间。所以需要将这些工作尽量提前，放到日常中。比如一个tga贴图有修改，监控发现后及时生成一份dds贴图放到一个打包空间中。就是打包相关数据是可以数据有修改的时候就进行操作，不用等到打包的时候才执行。这样，打包的时候这些前处理就都已经做好了，可以大大节省时间。不够这里就是需要准备更多的硬盘空间来对数据进行额外存储。

4. 支持增量打包。每次打包不重新进行打包，而是在上一个打包基础上，把最新的改动加进去。逻辑上其实跟做一次游戏更新很像。就是要处理的逻辑可能会复杂一些。用这个方案，甚至可以将游戏更新包同时就做好了。一举两得的做法，还是值得研究研究的。

益达平台游戏下载

安装器

比较早期，游戏下载会制作独立的下载工具，比如早期比较流行的NSIS方案，《逆水寒》2018年上线的时候，也用NSIS做了一个安装器，玩家下载游戏包解压后，会有类似下面的数据和安装exe。

安装的过程其实就是对压缩包的解压过程。当然NSIS方案还支持一套游戏删除，注册表注册等各种功能。

可是这个方案，首先需要先让玩家下载一个压缩包，然后压缩包解压，解压后，又通过游戏安装器再将数据进行一次解压。假设一个10GB左右的游戏，需要先占用30GB左右的硬盘空间，不仅费时，也特别费硬盘。还好我们是齐桓公的老马——迷途知返，这个NSIS的安装方式，很快就被我们抛弃不再使用。

一个是官方下载器，一个是迅雷下载。这也是现在大部分游戏采取的新办法。官方下载会先下载一个安装器，安装器安装好后，才进行游戏下载，下载过程，是直接将游戏打包后的每个文件从服务器直接下载到本地即可。整个过程，硬盘空间只占据一份，没有文件的解压操作。非常直观友好。这个安装器下载完游戏后，同时也是可以作为游戏的启动器。整个界面如下：

迅雷下载的早期方案也是通过迅雷下载一个游戏压缩包，玩家解压后进行游戏。但是迅雷现在也支持了无压缩包的下载方式，整个下载过程跟官方下载其实是可以一样的。迅雷下载方式点击后，会直接下载免安装版，过程如下：

其实官方安装器中进行游戏下载，也是可以接入类似迅雷SDK来完成下载的。相比直接从CDN上下载，通过迅雷的方案，速度在某些地区可能会更加稳定和快速。当然接入迅雷SDK，是需要付费的，对于游戏包体比较大的，这部分的费用提升的玩家下载体验还是很有价值的，这块可以具体项目具体分析。

因为外网的网络环境比较复杂，最好要设计多套的下载方案，在一个方法网络不通或者下载过慢的时候可以自动或者玩家手动切换到其他线路。

值得一提的是，我们还做了一个线上配置，可以通过修改配置实时调整外网优先推荐的下载渠道以及不同渠道的下载推荐占比。当发现有个下载方案出问题的时候，可以及时对配置修改来处理外网问题，同时，当要接入新的下载方案的时候，也会是很好的测试方法，一开始比例给少点，等稳定后，可以逐步增加。之前没有配置，要做这一套，要么要做下载器更新，要么要做一些特殊标记之类，总之都是非常麻烦的。

下载版本

由于游戏完整版非常大，对于硬件一般、网络不好的玩家并不友好。所以，我们当时做了一个咸鱼版，也就是所谓精简版的游戏客户端。它和标准版的差异就主要在资源上，尤其是贴图资源，我们将贴图资源直接去掉mipmap的前3级打包到精简版里，所以带来的包体减小的收益无疑是非常巨大的。最早我们游戏完整版60GB左右，精简版20GB不到。发展到今天，完整版已经快130GB，精简版也已经快50GB，真是精简版都已经达到了完整版的大小。

但是由于下载版本的增加，就增加了游戏打包的时间，做游戏更新包的时间，也增加了QA测试的工作量，我看市面上，有的游戏也有类似的做法，甚至版本有3个。做版本容易，但是内容回归有不少代价，是否要做多个版本还是需要好好衡量一下利弊。要开多版本，先把QA招聘挂上~

扩展包

如果游戏有做一些尝试性功能，但是可能不是每个人都可以感受到的。这些资源其实就没必要让每个人都下载。我们把这个资源叫做扩展包。比如在《逆水寒》端游中，就有无矩渲染、微光渲染等技术，我们做了独立的精度非常高的场景，对硬件还有一些要求，也就是说不是所有玩家都有条件可以进去感受的。由于画面制作精良，一个小小场景可能就有4-5GB的资源，如果让所有玩家都下载其实是不合理的。所以就有了扩展包的概念。

对于扩展包，进行独立维护，独立版本，独立更新。这样不会和主干有任何牵扯，不容易出现问题。

其实，如果设计初期，在文件结构上如果能做更好的设计，甚至可以将很多资源也按照扩展包的概念进行打包，比如地图资源，有的人进游戏可能很久都不会去玩某些玩法，这些玩法相关资源也根本用不上。还可以用时间进行管理，比如最近一年做的新东西单独管理，如果游戏有明显的体验差异，就可以很好做到边下边玩，比如《魔兽世界》就有类似设计。

微端下载

由于精简版的画质是明显变低的，我们还是希望玩家能体验到更高画质的效果，所以我们做了一个“微端”下载功能，以精简版为基础，玩家在玩法上不会有任何差异，就是资源差异，所以高清资源的下载并没有很高的实时性要求，就让微端进行“按需下载”成为了不影响实际游戏体验的可行方案。

微端基本机制：当启用微端下载功能，我们会启动一个单独的微端进程，它会负责高清资源的下载和管理。游戏客户端和微端通过进程间通讯来传输指令，下载好的资源，通过共享内存提供给游戏使用。整个过程大致如下：

微端下载功能对于游戏多开还有好处，多个客户端一般都会在做同一件事情，所需要资源往往相近，这个时候多个客户端可以访问同一块共享内存，对多开非常友好。

微端数据存储：对于微端数据玩家本地存储，因为里头高清数据目前都是高清贴图，贴图大小总体比较确定，所以我们参照游戏打包WDF的方案，单独做了微端数据存储的方案，主要改动就是将所有文件信息集中到一个单独文件中进行存储，文件分割最多允许分割2次进行存储，空闲空间管理中最小管理空间大小增大。当然，直接复用打包格式，也未尝不可。

微端数据打包：至于高清资源的准备和下载，我们在打包的时候，会将所有高清贴图以最简单的方式前后连接拼在一起，上传到服务器，同时生成一份配置表，包含所有高清资源文件和对应的md5信息。

微端资源更新：每次游戏打包都会为所有高清资源维护一个配置表，里头有资源id和对应的md5值，微端进程启动的时候会下载最新的配置表，当游戏发出高清资源申请，微端进程就会先判断是否有本地数据，如果有还会判断本地数据是否是最新的，如果不是最新的，这个时候才会发起从服务器下载最新文件的请求，也就是完成高清资源的更新。同时为了提高下载效率，当有多个下载请求的时候，会将连续地址的资源一起下载下来，减少对服务器的访问压力。整个下载更新过程如下图：

微端技术做完，其实用处还是比较多的。因为资源天然有打包功能。我们后面还讲这个技术移植到游戏外包编辑器的使用中，希望给外包比较新的编辑器，又不想让他们接触到核心资源，避免外泄。微端的方式就很好。

游戏更新

游戏更新，有两种方式，一种就是每次就下载新文件，这种简单快捷方便，坏处就是需要更新的文件多的时候，跟游戏重下真的没差异了，代价肯定是比价高的。所以，一般游戏更新都会选择另外一种方式，差异化更新。《逆水寒》端游每周都会出一个版本，所以每个月差不多会有4个补丁文件用于做更新，每个补丁大概是1-2GB。

更新方式

早期，我们只支持按照版本，每周更新上来。如果长时间没更新的游戏，下载的补丁数量不亚于重新下载一个游戏了。为了优化体验我们支持了多种更新类型，根据时间不同来进行。

1. 长时间不更新：判断下载补丁大小总和超过游戏客户端的80%，我们会直接触发重新下载游戏功能。玩家感受是在更新，实际本地是进行了游戏重下。

2. 中等时间不更新：我们这里是限制了比如有10个以上补丁没有下载，但是又不满足1的情况，就会触发另一套特殊更新机制，就是直接下载需要更新的文件本身，并不走差异化更新。

3. 保持日常更新：走正常的下补丁、运用补丁的差异化更新方式。

1和3的情况是比较容易理解和操作的。但是2这种情况，怎么能以比较低的代价来实现呢？我们**想法是单独维护一套数据，存储每个版本的打包数据，玩家会根据本地版本信息，直接下载这些数据，代价就是又要维护另一套打包数据，已经看到打包同学提着刀，磨刀霍霍了。后面，我们发现，其实对我们打包WDF文件中的文件按照时间进行重新排序其实就可以做到。原来文件打包顺序比较随意，现在根据时间重新整理成如下图，假设玩家当前版本是11，最新版本是20。我们通过配置表可以获得从版本12到20，在WDF中的offset。获得这个数据后，我们会将这个WDF的这段数据完整下载下来并替换到当前的WDF里头。通过这个方式，我们不需要维护单独的打包数据，只要维护一个配置表，记录每个版本都有哪些文件。可以看到，这个方法，是直接下载原始最新文件，就少了很多应用补丁的过程，在某些情境下，这个方法还是会比差异化更新有更快的速度。

更新操作

使用差异化更新的时候，我们是将前后两个客户端进行差异化制作补丁。对于每个打包文件，我们会对每个单独文件进行补丁制作。比如1.wdf里头有1000个文件，我们会将这1000个文件分别进行补丁制作。更新操作通常有如下几种：

1. 新增。新增文件制作补丁，将新文件数据写到补丁。应用补丁的时候，就将新文件对打包文件做个增加操作。

2. 删除。删除文件，只要将删除信息写入到补丁即可。应用补丁的时候，做个删除，这个时候可能会带来空洞，此时并不进行处理。

3. 修改。修改操作会使用差异化工具生成差异化数据，常用算法有xdelta和bsdiff，目前我们还是主要使用xdelta。如果对补丁大小比较敏感，可以考虑两个算法都进行，最终取差异化数据小的方式作为最终方法。

4. 移动。早期，我们并没有支持这个操作，所以当对某些文件夹的数据进行位置移动，比如从A文件夹移动到B文件夹，如果没有支持移动操作，则会做一次数据的删除，又增加一个数据的新增，导致补丁比较大。数据又没有改动，却让补丁变大，很不划算。后面我们就支持了移动功能，最终和删除操作类似，只在补丁中写入了移动操作，代价很低。

4. 压缩算法。压缩算法一般不轻易修改，如果真的修改，差异化数据也可能比较庞大，所以可以考虑支持在玩家本地进行解压和重新使用新压缩算法压缩的方式来进行，除了时间比较费一点，对补丁大小不会带来太大压力。

有人可能想问，因为打包都会进行数据压缩，使用压缩前还是压缩后的数据来做差异化补丁比较小啊。实测情况，情况无法统一，有时候是压缩前，有时候是压缩后。目前《逆水寒》端游中还是使用压缩后的数据进行差异化数据生成。如果对补丁大小敏感，可以考虑都做，最终选择小的那个。

补丁制作

补丁制作过程，我们会将所有文件分成2类，一种是已经经过打包的，一种是不参与打包的（比如游戏exe文件）。针对这两类文件，需要分别对待，但是本质上呢，没有太大差异，毕竟打包的文件我们也是需要对其中的每个单独文件单独制作补丁的。至于补丁文件结构，没有太多讲究，基本上是文件头加每个文件的补丁数据，补丁数据中会存储文件id，更新类型，更新前md5，更新后md5以及差异化数据，其他数据根据项目需求可以增删。这里需要注意一点是：因为对于打包文件，我们是对打包文件中的每一个文件单独操作应用补丁，而玩家初始下载的游戏版本也不一定相同，打包文件整体的md5值并不会保证一样，所以整个打包文件的md5指值是没有什么对比参考意义的。

补丁应用，肯定会制作一个专门用于更新的exe程序。但是更新器自我更新是一个问题，总不能自己革自己的命，毕竟更新过程，是无法对自己的进程直接下手的。目前我们采用的方法是，更新器在最开始会检测是否需要自我更新，如果需要启动另外一个进程并将自己退出，由另一个进程完成更新器的更新，等更新器自我更新结束，再进行游戏资源更新。

补丁文件格式确定后，尽量不要再修改了，因为我们并不能保证外网玩家对更新器的自我更新操作一定能成功，所以有可能玩家会使用老版本更新器进行游戏更新，对此我们有两个操作：1.对于一定需要新版本的，我们失败提供了手动下载界面，让玩家自己下载替换；2.补丁文件有版本信息，更新器对不同版本操作做好兼容。

如果外网有多个版本的客户端，我们需要制作不同的补丁。另外，内网版本比外网版本要多的多，所以我们要有一个机制去支持内网的更新。早期QA测试的时候，都是每次重新下载游戏，下载加解压的时间往往就要1个小时了，是非常影响工作效率的，后来就全部改成和外网类似的补丁更新机制，速度要快很多。值得一提的是，由于内网存在更新到任意版本的需求，甚至是从新的更新到老的版本，我们还特地支持了回滚补丁。这个更新小工具如下，可以通过选择想要更新的目标版本进行任意更新，实际使用非常提升测试效率，相信我，做了这个功能，QA会给你一个大大的拥抱。

内存patch

每周周版本更新的补丁都比较大，但是我们在日常版本更新中间，如果发现外网崩溃，有时候就需要做一个比较小的补丁。虽然补丁小，但是又不得不做。客户端资源补丁制作过程其实是比较费时间的，玩家还必须退出客户端重启后才能触发，体验并不太好。借鉴我们服务器lua有热更新的机制，我们制作了内存patch功能。

整个思路呢，也挺简单，就是复用lua热更新机制，将数据直接制作成lua补丁发送给玩家。玩家启动游戏或者游戏运行过程中，发现有lua补丁，则会将数据接收，并将对应文件的id和数据存储内存中进行单独管理，每次触发读文件操作时，会先从内存patch管理器中先进行读取，这样来保证内存patch中的数据会被优先使用。

但是内存patch，由于需要将数据通过网络进行传输，不能是太大文件，否则负载容易有问题。

其实我们也做了一个类似的临时patch的功能，也是利用lua热更新机制，但是传送客户端的不是数据本身，而是网络地址，文件从网络地址玩家自己去下，下载后还可以保存到本地，这样下次启动就不用重新再下。相关数据需要在游戏进行正常版本更新的时候进行删除。

两种方式，都可以比较方便处理小补丁需求。

工具支持

游戏修复整理工具

由于硬盘、网络、更新过程错误等各种原因，玩家本地游戏客户端，有可能存在文件错误问题。所以修复工具是必须要做的。

修复工具，可以做的粒度细致一点，避免网络资源浪费：

1. 错误量比较大。这种情况，可以直接进行打包文件的重新下载。

2. 个别文件错误。这种情况，只下载单个文件的资源进行替换。

修复发起的时机，主要是两个，一个是玩家主动或者被引导进行手动操作，一个是游戏运行时如果发现有资源问题，会进行记录，游戏启动器启动前会读取记录情况，发现有错误主动发起修复。

我们将整理工具是一起集成到了修复程序里头。整理主要是指，玩家在更新过程中会产生很多空洞，导致游戏客户端的硬盘占用增大，通过整理，可以将这些空洞去除，达到减少客户端占用的目的。每次游戏启动器启动的时候我们都会扫一遍空洞情况，这个过程是很快的，当空洞存在过多，我们就会提醒用户进行整理。整个整理过程就是数据的读取和重新写入，在SSD硬盘上速度还是比较可以的。

打包文件解压工具

打包文件解压工具主要是为了方便查问题。有时候外网出现了一些资源问题，我们需要对数据进行检查，需要有工具能将我们打包工具进行完全解压和部分解压，还原原始数据情况。由于我们记录在打包文件中的信息并没有文件名字信息，都是转成了id。所以还需要在打包的时候维护一份id和文件路径的对应表。对应表会在解压工具中被自动下载使用。

游戏崩溃收集系统

内部测试再充分，到外网都会有各种奇怪问题。所以崩溃是需要被及时、合理的处理的。Dump文件，会有堆栈信息，日志会记录一些特定信息，这些数据都可以在崩溃的时候上传到服务器。

Dump的收集是必要的，它是发现外网问题的重要路径之一。而对Dump数据进行解析是更加重要的。海量的崩溃，使用起来非常困难，益达平台需要将Dump根据堆栈等信息进行分类，同时监控各种数据随时间的变化，这样就可以知道什么问题是需要紧急进行处理的，什么问题是新增的，更新后结果是否有效。

游戏更新监控系统

类似游戏崩溃，游戏更新也会出现各种错误。这些错误也需要进行合理的监控，这样我们能对外网的更新情况有更好的把控，对于一些新功能的投入也能及时知道外网情况。我们是游戏上线后才开始设计使用这个系统，如果能再项目早期就开始关注和使用，应该会比较好。

外包版编辑器制作

现在美术外包需求越来越大，制作的时候很多时候还需要使用项目引擎来验证会比较好。但是项目开发中，很多资源是比较重要，全给到外包会有巨大泄露风险，另外，就算允许驻公司外包有全部访问权限，资源总量也是头疼问题，随着游戏多年运营和对品质的要求提升，所有资源突破1TB也是越来越可能的。针对这些问题，我们将微端功能进行扩展，由于外包对于数据的实时性没有那么高，是允许存在一定滞后的，我们通过微端，在编辑器中按需下载最新的外网数据，这样对编辑器使用的硬盘门槛也可以比较低，同时也对数据做了比较好的保护。如果项目组对于外包需求比较多，这样一个编辑器意义还是很大的。

Happy Ending

尽管时代的浪潮，“拍”得玩家已经能接受百GB的游戏容量大小，但是一个好的打包、更新方案，是可以让游戏把更优秀的资源放到游戏里，带给玩家更加沉浸的体验，毕竟这个容量大小，玩家下载的时候，都有高品质预期的。老游戏可能在包体大小上可以任性一点，新游戏还得尽可能往小的做，在玩耍过程中再逐渐下载其他资源，别在开头就将玩家劝退了。

倒数第二步，感谢GPT帮我润色了一下文笔，让大家阅读起来可能更加风趣。如果觉得很欠扁，请去锤GPT，本文作者表示“一本正经”。欢迎大家来益达平台一起来锤免费的GPT吧~