近期发布微信小游戏的流程与心得：引擎选择、资源分包、软著申请、SDK接入及审核流程

引擎选择

我最开始使用的引擎是 Unity 国行版的 Tuanjie 引擎，其本身和 Unity 几乎没有区别，只是集成了微信小游戏的 SDK 和一些 Unity 推出的CDN、资源热更新相关的服务。

但使用过程中，出现了 Unity 版 SDK 和 Tuanjie 版 SDK 不通用，导致自动更新后无法发布，以及发布后部分资源加载不正常等疑难问题。于是，失去 Debug 耐心的我果断切换了引擎（在文章发布时，Tuanjie 似乎已经解决了 SDK 版本不通用的问题，大家可以自行选择）。

得益于前段时间做了一阵子网页，我无缝切换到了编辑器结构与 Unity 基本相似，使用 Type 语言的 Cocos 引擎。现在看来，相较于 Unity，Cocos 引擎在修改脚本后不会有令人烦躁的编译读条，接入各类小游戏也不用对开发脚本进行漫长的编译发布。尽管它没有 Unity 那么丰富的插件生态，但开发小游戏也不太用得到，实际使用起来舒适很多。

资源分包

微信小游戏以及类似的各种平台不同形式的小游戏，一般会对发布包体有大小限制，如微信小游戏是 4MB。其余游戏资源则需要我们的客户端在必要时自行从网络加载。显然，发布一个 4MB 以内的游戏对于大部分现代开发人员是不太现实的，我们必须对 Cocos 作分包处理。

Unity 和 Cocos 的基础分包逻辑相似，大致会有这些包体：

1. resources 文件夹中的内容会被打包为 resources 包（这个包内的素材可以通过 Resource.load 相关 Api 动态调用）。

2. 游戏的开始场景相关资源和脚本会被打入一个 主包。

3. 引擎自带一些功能包（如 Unity 中 Packages 文件夹下的内容或是 Cocos 中 Internal 文件夹下的内容）也会构建成一个 引擎包。

4. 其它由我们自己设置构建的 资源包。

resources 包、主包和引擎包一般就构成了我们的游戏程序启动的基础。

后续以 Cocos 引擎中的操作为例。

如下图，其中 start 场景是游戏的 开始场景，里面只有一些封面图片和文本。而游戏主要玩法内容都放在 game 场景中，其场景文件本身被分配在了 game 资源包内。那么在打包过程中，start 场景相关依赖将会被打包在 主包内， game 场景相关依赖将会被打包在 game 资源包内。

（注意：引擎在打包过程中会根据场景引用，将其它位置的引用资源也打入包内，因此，我们没必要将对应资源都放在包文件夹下，除非需要通过脚本动态加载。同理，若非需要动态加载的资源，我们也没有必要都放在 resources 文件夹中，这样能避免未被使用的资源被一起打包进 resources 包，无意义地加大游戏整体的大小。）

接着在 Bundle 设置中，勾选对应发布平台的远程包选项。

在构建发布时填写下载地址（各类平台会对下载地址做限制，一般必须是 ICP 备案过的域名，不能是 IP 地址。因此，除非自己有合适的域名和服务器，还是找一家 CDN 服务部署资源包吧）。

构建发布后目录的 remote 文件夹下，可以看到各个包体，将需要远程加载的 game 资源包体剪切到我们的下载服务器上。

接下来就能够通过 assetManager 相关 API 加载包体了，如以下 StartManager 可以挂在开始场景中，远程加载完 game 资源包后即可开始游戏。

@ccclass('StartManager')

exportclassStartManagerextendsComponent{

@property({type :Node})

privateloadTitle :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 开发的接口等。

如果对我前面的理解存在疑议，或是有相关技术分享，欢迎评论指出！

软著申请

以下整个流程（软著申请、SDK 接入、发布审核）的材料准备和细节比较繁琐，但这是作为一位“创作者”发布自己“出版物”的必由之路。为了让自己的作品能在公共平台上问世，请尽量保持高效的行动力。整个发布流程并没有多少难点，最关键的就是不要害怕繁琐。

尽管在平台发布流程中，似乎并不一定要求必须有软著（申请），但为了避免后续可能出现的潜在问题、保护创作者权益，在发布任何游戏时都有必要进行这一步。现在申请软著已经可以通过国家版权保护中心全程在线办理。

办理软著的主要流程如下：

1. 注册账号并完成个人或企业认证；

2. 填写软件的基础信息；

3. 准备软件源码与软件描述等细节文档；

4. 提交表单，等待行政审批单位的处理，有表单问题及时修改。

具体的一些细节内容，比如小游戏所属的软件品类、源码以及介绍文档的格式细节可以参考《从 0 到 1 上线微信小游戏》第九节 个人申请国家软件著作证书详细流程。这篇文章十分详细，但部分信息已过时，如最后的邮寄环节已经不需要了，所有表单和文档都可以在线提交。

如果你实在怕麻烦，想节约一些时间，也可以直接寻求代办服务。小游戏相关的代办服务价格似乎在几百到上千元不等，相比于横跨数月自行在线办理，效率会更高一些。不过，对于个人开发者，我建议还是自己尝试办理，办理流程本身也是了解国内版权保护的一个好机会。

平台 SDK 接入

为了方便开发者获取玩家基础信息、接入特殊功能，小游戏平台会提供 SDK 方便开发者接入。大体格式在不同平台大差不差。但要注意，不同的游戏引擎接入 SDK 的方式不尽相同，需要具体参考对应平台的文档。这里以微信小游戏的官方文档为例。

对于 Unity 引擎，需要下载对应的 SDK 插件来调用，具体可直接查阅《Unity/团结快适配方案》这个文档，而近年推出的 Tuanjie 引擎可以说就是比 Unity 多集成了这类平台发布插件。

而对于 Cocos 这种脚本本身就是 java 的系统，可以通过直接调用 WX 功能类来使用，以下代码是一个登录功能的大概实现。

publicLogin

{

//记录玩家的逻辑编号

//判断平台是否为微信小游戏

if(sys .platform ===sys .Platform.WECHAT_GAME ){

//调用 SDK 的 login 接口，从而获取玩家的登录 CODE

window ["wx"].login ({

success (res ){

if(res .code ){

code =res .code ;

}else{

GlobalManager.Instance.ShowTipPanel('登录失败！'+res .errMsg );

return

}

}

})

}

//在客户端获得登录 CODE 后，发送给服务端，由服务端再调用平台登录获取玩家信息

let loginUrl :string=GameManager.ServerAddress+"api/Login?code="+code ;

this.SendMessage(

loginUrl ,

(res )=>{

GameManager.GameData=res ;

LoginSuccess=true;

});

}

请注意，接入的 SDK 功能在游戏引擎的编辑器环境下是无法使用的，因此，有必要做好当前运行平台的判断，方便调试。想要测试 SDK 功能，只能将游戏做打包发布后，在对应平台的开发者工具中调试。如果对接口功能了解有限，每次修改后都需要重新发布到另一个工具中调试。笔者最早使用 Tuanjie 引擎发布，由于对接口知之甚少，需要反复微调试错，其间，每次发布都要花费 5 分钟以上，整个过程真是痛苦万分。

最后是后端介绍。对于大多数简单的小游戏来说，并没有什么需要复杂服务端提供信息的需求，但发布到小游戏平台后，还是需要一个后端服务来实现登录验证和玩家游戏数据留存。对于后端发布，一般有三种方案推荐：

1. 自己编写一个后端服务，准备好云服务器，通过云服务器开放后端访问（注意：有些平台会要求小游戏访问的远程地址必须是备案过的域名，因此，如果只有公网地址可能无法和客户端通信）。

2. 自己编写一个后端服务，部署在提供云服务部署的云端平台，比如微信云托管。这种方式本质上和第一项一样，但避开了服务器域名需求。

3. 通过一些云函数平台发布后端服务。这一方式不需要自行编写整个后端服务程序，而是在平台框架内编写云函数，实现后端功能，比如 Unity 的 UOS，微信云开发等。

对于很多独立开发者来说，后端程序是有些陌生的领域，但其本质并不复杂，几大核心内容是 通信方式、数据库、数据处理。对概念有初步了解后很容易就能上手，后续有机会我会写一些相关日志。

审核流程

最后就是审核流程了。以微信小程序为例，你需要登录微信公众平台，来添加一个小游戏项目，其后的大致流程如下：

1. 填写小游戏的基础信息（名称、介绍、图标等）；

2. 验证小游戏的推荐年龄分级和游戏类目；

3. 提交行政部门审核，包括开发者资质、游戏内容评审、游戏发布备案（这一流程涉及行政单位审核，有许多繁琐的介绍内容、游戏截图等需要填写，还是那句话，保持行动力，尽量仔细地填完。审核流程很可能需要两个月，如果填写内容不合规被退回，会拖得更久）；

4. 提交游戏版本，经过版本代码审核后，就能将过审的游戏版本正式发布了；

5. 微信认证，也就是对发布者个人微信的资质认证，需要花费 30 元，通过就能让你的小游戏能够被搜索到。

流程中的步骤没有严格的先后顺序，尽可能都了解且尝试一下，并行推进能大幅节省审核时间。一些具体内容的填写，可以参考《从 0 到 1 上线微信小游戏》第十节 上线微信小游戏步骤。前文也引用了同系列文章，如果你在初步了解后有兴趣，也可以跟随这位作者的日志，从零开始试试发布一款小游戏。

后续关注

审核流程可能会持续数月之久，但到这里，游戏的整个发布周期也只走到了第二步。接下来的一步才是一款游戏产品的生死关键——宣发！这一步对于个人开发者可说困难异常，在当下这个时间节点，手游和小游戏市场是买量投放的天下，从近几年很多游戏公司逐渐转变为买量投流的游戏投资公司就能看出。买量投放对于个人或者小开发团队是没有意义的，如果没有对这方面的深刻认知，请千万不要投入资金成本（笔者稍做过尝试，但转化率几乎为 0，水太深啦！）。所以，笔者能想到的，推广自己的小游戏恐怕只能从社交媒体和网络社区出发了。以下是个人的一些浅薄认识：

1. 在开发过程中就顺便制作游戏的各类宣传物料，图片、视频都可以；

2. 在发布宣传物料或填写游戏信息时，找到并使用容易触发搜索的内容和关键字；

3. 积极关注各类平台的帮扶措施，如新游启动企划等。

以上就是我本次小游戏发布过程中的一些心得和经验，但愿能帮助你对小游戏发布有一个框架认识。

* 本文为用户投稿，不代表 indienova 观点。