【引擎选择】
我最开始使用的引擎是Unity国行版的Tuanjie引擎，其本身和Unity几乎没有区别。只是集成了微信小游戏的SDK和一些Unity推出的CDN、资源热更新相关的服务。
但我在使用过程中出现了Unity版SDK和Tuanjie版SDK不通用，导致自动更新后无法发布。发布后部分资源加载有问题等等疑难杂症，于是失去Debug耐心的我果断切换了引擎。（在文章发布时，Tuanjie似乎已经处理了SDK版本不通用的问题，可以自己选择。）
得益于前段时间做了一阵子网页，我无缝切换到了编辑器结构与Unity基本相似，语言使用TypeScript的Cocos引擎。现在看来相较于Unity，cocos引擎在修改脚本后不会有令人烦躁的编译读条，接入各类小游戏也不用对开发脚本进行漫长的编译发布。尽管没有Unity那么多的插件生态，但开发小游戏也不太用得到，真是舒适很多。
【资源分包】
对于微信小游戏以及类似的各种XX小游戏，一般会对小游戏发布的包体有大小限制，以微信小游戏为例是4MB。其余游戏资源则需要我们的游戏客户端在需要时自己从网络加载。显然发布一个4MB以内的游戏对于大部分现代开发人员是不太现实的，我们必须对Cocos作分包处理。
unity和cocos的基础分包逻辑相似，大致会有这些包体：
- resources文件夹中的内容会被打包为resources包(这个包内的素材可以通过Resource.load相关Api动态调用)。
- 游戏的开始场景相关资源和脚本会被打入一个主包。
- 引擎自带一些功能包（如Unity中的Packages文件夹下内容或是Cocos中的Internal文件夹下内容）也会构建成一引擎包。
- 其他由我们自己设置构建的资源包。
resources包、主包和引擎包一般就构成了我们游戏程序启动的基础。
后续操作以cocos引擎中的操作为例。
看下图，其中start场景是游戏的开始场景，里面只有一些封面图片和文本。而游戏主要玩法内容都放在game场景中，其场景文件本身被分配在了game资源包内。那么在打包过程中，start场景相关依赖将会被打包在主包内，game场景相关依赖将会被打包在game资源包内。
（注意：引擎在打包过程中会根据场景引用，将其他位置的引用资源也打入包内，因此我们没必要将对应资源都放在包文件夹下，除非我们需要通过脚本动态加载。同理，若非需要动态加载的资源，我们也没有必要都放在resources文件夹中，这样能避免未被使用的资源被一起打包进Resources包中，无意义的加大游戏整体的大小。）
接着在Bundle设置中，勾选对应发布平台的远程包选项。
在发布时填写下载地址（各类平台会对下载地址做限制，一般必须是ICP备案过的域名不能是ip地址。因此除非自己有合适的域名和服务器，还是找一家CDN服务部署资源包吧。）
在构建发布后目录的remote文件夹下可以看到各个包体，将我们需要远程加载的game资源包体从中剪切到我们的下载服务器上。
接下来就能够通过assetManager相关api加载包体了，如以下StartManager可以挂在开始场景中，在远程加载完game资源包后就能开始游戏了。
@ccclass('StartManager')
export class StartManager extends Component {
@property({ type: Node })
private loadTitle :Node;
start() {
assetManager.loadBundle("game",(err,bundle:AssetManager.Bundle)=>{
director.loadScene("game");
});
tween(this.loadTitle).to(3.7,{scale: v3(1.3,1.3,1.3)}).then(tween(this.loadTitle).to(1.3,{scale: Vec3.ONE})).repeat(30).start();
}
}以上是我个人在开发过程中的操作方案，只经过了粗浅理解简单实现了分包功能。事实上在各类更新和动态加载需求的要求下，包体管理已经变得非常繁杂。诸如将代码作为资源的一部分实现游戏逻辑的热更新，或是定义合适的包体结构以提供给玩家作为mod开发的接口。如果你对我的理解存在疑议，或是有相关技术分享欢迎评论指出！
感谢你阅读至此，最近在重新回到游戏开发的状态，如果有意向合作交流欢迎联系我！QQ：2763686216
暂无关于此日志的评论。