课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
对于游戏软件来说,游戏更新和打补丁可以说是非常常见的一种程序维护行为了,而今天我们就一起来了解一下,关于游戏开发中的热更新机制的一些基本知识。
Cocos Creator中的热更新机制是依赖与Cocos2D-x的AssetManager,这个功能在Cocos2D-x 3.0时发布,同时发布了Cocos2D-JS 3.0版本中也含有这个功能,之后在Cocos2D-x升级了这个功能,加入了多线程并发实现,之后又在Cocos Creator 1.4.0版本和Cocos2d-x v3.15中经过一次重大重构,系统性解决了热更新过程中的问题。
Cocos2D-JS的设计主要是针对Web平台发布游戏,所以需要考虑浏览器的缓存机制,服务器端保存了完整的一个Web页面内容,浏览器请求一个网页后,就会在浏览器缓存这个网页的资源,当浏览器重新请求这个网页时会查询服务器版本后的修改时间或者是标识,如果不同则下载新的文件来更新缓存,如果相同就使用缓存的文件。
对于市面上的手游,目前比较常有的热更新机制是补丁包机制,即每个版本对应上一个版本生成一个补丁包,每个版本对应一个版本号,在客户端保存一个当前资源的版本号,每次检测热更的时候先和服务器通讯,对比版本号,如果版本号落后于服务器版本号,就开始热更流程,否则正常进入游戏,更新流程就是按顺序下载版本差之间的一个或多个资源包,这样更新的问题是资源包如果由人工整理,很难确保不会出错,而有些项目也尝试使用git上的工具,动态对比资源文件夹下的资源,从而生成不同版本之间的虚拟资源文件包,然而由于不具有足够的灵活性和资源间的可拆解性,这种版本差异“打包”的方式终究不是一个完美的解决方案。
Cocos Creator所采用的更新基本流程是为每个文件制定一个版本号,这样当对比更新文件时,会以每个文件为单位判断是否需要更新,增加了灵活性。
它的更新的基本流程是:
客户端每次启动时发送请求和服务端版本进行比对获得差异列表。
如果差异列表为空,则直接进入游戏,否则从服务端下载所有新版本中有改动的资源文件。
用新下载的资源覆盖旧缓存以及应用包内的文件。
在这种设计思路下,所有资源文件以离散的方式保存在服务器端,更新时会以文件为单位进行更新检查和文件下载。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。