游戏资源打包

发表于2016-08-17
评论0 2.9k浏览
  游戏资源打包几乎是一个网络游戏客户端必备的功能。页游和微端根据实际需求可能不打包资源或者使用小包,资源打包有这么几个好处:
1、加快客户端安装时间。拷贝3000个1mb文件所消耗的时间要远大于拷贝一个3g的文件所消耗的时间
2、客户端更加整洁,也可以“稍微”避免游戏资源被他人使用。
3、ios和android上面可以避免文件名大小写不一致造成的文件读取失败。或者说包内可以做到全平台大小写无关
4、压缩资源,如果是大量png等图片资源可能还体现不出来,但是如果有大量文本和未压缩模型资源,那么打包可以有效减小客户端
  
  这里介绍两个开源库,可以非常方便的给客户端加入资源打包功能。
1、StormLib(http://www.zezula.net/en/mpq/stormlib.html),这个就是暴雪MPQ打包格式开源实现版本。通过这个库可以轻易的实现一个PackageManager来加载包内资源
2、ZPack (http://multi-crash.com/?page_id=340)  这个同样是一个开源打包格式实现。对比上面的MPQ,它更精简,当然功能也更弱一些。不过现有的一些功能已经完全能满足我的实际需求了

主要特性:
1、速度
  以文件名hash方式检索,读取效率至上
  删除包内文件时,只删除文件索引,不需要移动包内数据
  在两次flush之间用户可以添加任意多个文件(例如添加整个目录),这期间除了被添加文件数据的写入,没有任何其它多余的文件IO操作
2、尺寸
  添加文件时,优先插入到之前删除文件留下的空闲位置,尽可能利用空间
  用户可以调用countFragmentSize检查当前包内空闲空间字节数,必要的话可以调用defrag进行整理以释放空间
  暂不支持数据压缩,但用户很容易自行添加压缩支持
3、安全/健壮
  严格保证在用户调用flush()之前,包文件的有效性。这样当用户一次添加/删除较多文件的过程中即使发生意外(例如停电,进程被强行终止等),包文件能保持最后一次flush后的逻辑结构,不会发生灾难性后果
  包文件以只读方式打开时,原始的文件名信息不会被加载到内存。也就是说用户可以选择不将原始目录结构和文件名写入包内,包文件仍然能正常读取
4、可扩展/兼容
  从设计上保证当将来需要扩展包文件头或包内文件索引中的数据时,老的代码仍能读取新的数据结构
  当数据包和zpEditor版本不一致时,zpEditor仍可以以只读模式打开数据包
5、工具
  虽然包内文件是以扁平方式组织(以保证检索效率),但zpack另外提供工具类ZpExplorer,让用户可以以树状目录形式浏览和编辑包内文件
  提供命令行工具,接近dos使用习惯
  提供类似windows explorer的编辑器
6、其它
  包文件不受4g大小限制
  核心读取模块仅依赖c++标准库,很容易移植到windows以外的平台,例如Linux,Mac,iPhone等
  代码小巧精简,不提供任何多余接口。zpack核心源代码仅20k左右
  一个打包模块只要能满足这么几个需求就完全够使用了:
1、hash的平铺路径,保证足够的查找效率
2、支持压缩
3、安全,健壮,不会因为一些操作造成包损坏
  最后感慨下,开源世界太丰富了,多了解一些开源项目就可以省去很多自己重新创造所需要的时间了。

如社区发表内容存在侵权行为,您可以点击这里查看侵权投诉指引