现在的位置: 首页 > 综合 > 正文

游戏资源打包

2012年12月30日 ⁄ 综合 ⁄ 共 1327字 ⁄ 字号 评论关闭

游戏资源打包几乎是一个网络游戏客户端必备的功能。页游和微端根据实际需求可能不打包资源或者使用小包。

资源打包有这么几个好处:

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,它更精简,当然功能也更弱一些。不过现有的一些功能已经完全能满足我的实际需求了

 

主要特性:

  • 速度

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

一个打包模块只要能满足这么几个需求就完全够使用了:

1、hash的平铺路径,保证足够的查找效率

2、支持压缩

3、安全,健壮,不会因为一些操作造成包损坏

最后感慨下,开源世界太丰富了,多了解一些开源项目就可以省去很多自己重新创造所需要的时间了。

抱歉!评论已关闭.