一. 官方提供的 AssetsManager
Cocos 官方提供了一套基于 AssetsManager 的热更新方案, 这套方案大致是这样的:
- 每次构建时配合 version_generator.js 生成清单文件: project.manifest 和 version.manifest
- 将最新构建好的
代码/资源/清单文件
放到服务器上 - 启动游戏时使用 AssetsManager 检查更新, 对比差异, 下载更新, 重启游戏
Cocos 官方提供了一套基于 AssetsManager 的热更新方案, 这套方案大致是这样的:
代码/资源/清单文件
放到服务器上前些日志, 有 G友 为 untp 添加了这么一条 issue:
还是比较有意思的, 早就知道 TexturePacker 提供了加密资源的功能, 但还没有实际使用过, 何不借此机会研究一下 ?
以往的年结大家感兴趣的话可以看这里: 我的年结, 这篇是第五篇了. 今年的年结比去年晚了一些, 客观原因有很多, 但其实还是自己比较懒.
这一年发生了很多事情, 工作上变化是重心慢慢的向团队管理方向偏移, 具体业务逻辑不再过多深度参与. 这个转化怎么说呢, 还是挺愉快的, 一个人的精力是有限的, 再努力也只能涉及几个模块. 抛开这些则能从更宏观的角度去看待整个项目, 能观察到整个团队的缺陷, 更好的服务于团队.
但是过于远离业务逻辑, 如果没有强有力的框架做约束的话, 业务逻辑很容易变质, 而你可能得过很久才能发现, 这时这些变质的代码可能已经腐蚀了很多模块, 修改起来很麻烦.
所以如何权衡这两点就是我接下来所要努力的地方, 下面我还是按照以往的套路来总结下过去的这一年的收获.
最近两个月, 我们一直在用 CocosCreator 做一个休闲游戏, 在享受 Creator 高效的过程中我们也遇到了这样那样的问题. 有些问题是我们的用法不正确, 有些则是引擎和编辑器的 bug, 好在这些问题基本上都解决了.
今天我和大家分享下我们团队在使用 CocosCreaor 遇到的问题及解决方案.
前段时间写过这篇文章将 python 数据转化为 lua 格式, 这段时间因为新项目改用 Creator + TypeScript
的原因, 需要导出 ts 格式的数据.
当然我们可以选择使用 json/yaml 等格式作为数据文件, 这会简单很多, 但是有两个原因, 使得我们一致认为 ts 格式的数据是更好的选择:
之前可能和大家说过我们项目的 UI 编辑器是上古神器 CocosBuilder, 这个编辑器诞生在那个 cocos2d-x 还需手写 ui 代码的年代, 是 cocos 发展史上一个重要转折点. 它标志着触屏手机游戏行业 ui 不再像之前那样只是简单的串联的作用, 而是像端游那样重交互, 可视化编辑的路线.
正如知乎我的这个回答中所说, 我们开始使用 Cocos Creaor 开发新的项目, 所以以后这个博客会陆续开始更新一些 Creator 相关的文章.
我们在项目开发的过程中, 肯定会遇到一些项目间通用的需求, 比如 压缩/加密
之类的, 我们当然可以自己实现一个, 但更好的做法是找找网上有没有别人实现好的库直接拿来用, 今天我们就来看看如何为 Creator 添加添加 js/ts 第三方库支持.
相信大家都会用到 iOS 的自动打包工具, 而不是每次都是通过 XCode 的 Archive 后手动导出的, 那样效率低下不说还增加出错的可能.
我们团队也是如此, 用 Python 搞了一套打包工具, 这套工具的核心是 XCode 附带的命令行工具 xcodebuild
, 网上其他开源的打包工具也都大同小异. 这套工具自诞生以来一直运行的很稳定, 累计为我们打了数百个包, 为团队节省的时间估计也在数千分钟了.
前段时间一个朋友向我咨询播放 spine 动画时遇到的问题:
这个问题我们在很久之前也遇到过, 当时是另个一小伙伴负责的. 当时猜测可能是 spine runtimes
需要升级, 但是升级时遇到了技术问题, 恰好项目比较紧, 便让美术同学重新用老版的 Spine 编辑器重新做了一遍.
有玩家反馈我们的游戏在 Mix 上面无法全屏显示, 上下会有黑边. 搜索了下, 网上还没有绍如何适配的相关文章, 这里介绍下我们是如何做的.
我们可以在看看小米官方对全面屏适配工作的介绍:
这些变化也影响了手机软件的设计,最值得开发者关注的,是以下两点:
- 更大的屏幕高宽比
- 虚拟导航键