90%的Cocos开发者不知道,插件还能这么玩!

引言

哈喽大家好，我是亿元程序员，一位有着8年游戏行业经验的主程。

很多Cocos开发者平时都会用插件，但真正自己写过全局插件的小伙伴，可能并不多。

普通插件一般跟着项目走，只服务当前项目。

全局插件就不一样了，它安装在Cocos Creator的全局扩展目录中，只要你打开编辑器，不管切换到哪个项目，都可以使用同一套工具。

这就非常适合沉淀一些通用能力。

比如打开项目目录、启动本地工具、资源检查、Prefab批处理、构建辅助、小游戏包体分析等等。

举个例子，像下面这种发布辅助能力，就非常适合放到全局插件里：

为什么这个例子适合做成全局插件？

因为它不是某个游戏玩法里的业务逻辑，而是很多项目都可能用到的发布流程能力。

今天项目A要上传到服务器，明天项目B也要上传到服务器。
如果每个项目都单独写一套上传按钮、分支前缀、预览地址配置，后面维护起来就会很麻烦。

但如果把它做成全局插件，就可以在所有Cocos项目中复用同一套上传逻辑。

这就是全局插件最有价值的地方：把重复流程做成编辑器能力。

言归正传，本期我们手把手看下一个Cocos全局插件是怎么跑起来的，估计90%的小伙伴都不知道~。

全局插件放在哪里？

这里非常重要。

如果是项目插件，一般放在当前项目的：

项目目录/extensions

但如果是全局插件，就不能只放在某个项目里，而是要放到Cocos Creator的全局扩展目录。

以当前实战为例，它所在的位置是：

这是Cocos Creator的全局扩展目录之一。

放在这里的插件，不绑定某一个游戏项目，而是跟着当前Cocos Creator编辑器环境走。

也就是说，只要这个全局插件启用了，你打开任意Cocos项目，都可以在编辑器里看到它。

如何让全局插件生效？

放对目录后，插件没问题的话，自动就会生效。

如果插件加载成功，就可以在顶部菜单的扩展菜单里看到对应入口（本实战工程）。

甚至可以在扩展管理器的内置扩展找到我们的自定义全局插件：

如果修改了TypeScript代码，还需要重新编译：

npm run build

最后回到Cocos Creator里重新加载插件，我们可以在Load中加入输出，如果启动项目有输出，说明插件加载成功：

很多小伙伴插件没生效，不是代码写错了，而是放错目录，或者改完忘记重新编译。

实战工程结构

实战工程是一个Cocos Creator 3.8.7的全局扩展示例，主要结构如下：

globalext├─ package.json├─ tsconfig.json├─ src│  └─ main.ts├─ panels│  └─ default│     └─ index.ts└─ dist

这几个文件分别负责不同事情：

package.json：声明插件信息、菜单、面板和消息。
src/main.ts：插件主入口，真正执行功能逻辑。
panels/default/index.ts：编辑器面板代码。
dist：TypeScript编译后的运行代码。

第一步：声明这是一个插件

首先看 package.json。

实战工程里有几个关键配置：

这里重点看两个字段：

name：插件名，这里叫 globalext。
main：插件入口，指向编译后的 ./dist/src/main.js。

因为这是TypeScript工程，所以我们平时写的是src/main.ts，真正被Cocos Creator 加载的是编译后的JS文件。

执行构建命令：

npm installnpm run build

编译完成后，dist 目录里就会生成编辑器实际加载的代码。

第二步：给全局插件加菜单

插件通常用起来，最直接的方式就是加菜单。

实战工程在 package.json 里通过 contributions.menu 注册了多个菜单项：

这段配置的意思是：

在Cocos Creator顶部菜单的扩展菜单下，放一个 Happy Tools 分组。
菜单显示文字是“打开面板”。
点击菜单后，发送一条 open-panel 消息。

注意，菜单本身不负责执行逻辑，只发送消息，小伙伴们，这是什么模式？

第三步：把菜单消息绑定到方法

同样在 package.json 中，可以看到消息映射：

这里的意思是：

收到open-panel 消息，就调用 openPanel 方法。
收到open-assets 消息，就调用 openAssets 方法。
收到print-project-path 消息，就调用 printProjectPath 方法。

这就是Cocos 插件里非常核心的一条链路：

菜单点击 -> 发送 message -> 调用 main.ts 里的 methods 方法

理解这条链路后，大部分编辑器插件功能都能写出来。

第四步：编写插件主入口

接下来看src/main.ts。

当前工程里导出了一个 methods 对象：

就是具体的方法实现，举例几个方法：

openPanel：打开插件面板。
openAssets：打开当前项目的 assets 目录。
printProjectPath：打印当前Cocos项目的路径。

第五步：做一个自定义面板

只有菜单还不够直观，所以实战工程还做了一个自定义面板。

面板声明在 package.json 里：

这里说明插件有一个默认面板：

标题是 Happy Tools。
类型是 dockable，可以停靠在编辑器里。
入口是 ./dist/panels/default。

然后在 panels/default/index.ts 里定义界面：

第六步：面板按钮调用主入口

和菜单一样，面板本身也不直接处理复杂逻辑。

它通过Editor.Message.request 去调用主入口里的方法：

这里的 globalext 就是插件名。

完整调用链路是：

点击面板按钮
Editor.Message.request("globalext", "open-assets")
package.json 找到 open-assets
调用 main.ts 里的 openAssets
打开当前项目 assets 目录

到这里，一个完整的全局插件功能就跑通了。

第七步：常用功能

其实我们用全局插件的目的，就是为了把经常用到的功能更加容易使用。

例如：

一键启动Cocos MCP Server(前提是要先安装Cocos Mcp)。
用Codex打开当前项目。
构建完成后上传到服务器。
自动生成线上预览地址等等。

全局插件 + 外部命令，其实就能把很多零散工具都收进Cocos编辑器。

更进一步

基于这个工程，后续可以继续扩展很多功能。

比如：

扫描所有Prefab ，检查Label字体是否正确。
扫描assets目录，统计图片、音频、字体大小。
打包前检查主包资源是否超标。
一键打开项目的配置表目录。
一键压缩资源。
一键精简字库。

这些功能如果写在单个项目里，只能服务一个项目。

但如果写在全局插件里，就可以服务你所有的符合版本的Cocos项目。

这就是全局插件最大的价值：

把一次经验，变成长期工具。

结语

本文最主要的目的不是带大家回归古法编程，而是分享给大家经验。

毕竟在AI时代，经验可能比技术更重要。

小伙伴们觉得对吗？可在评论区分享你的看法~

本文实例工程可通过私信发送“全局插件”获取。

我是"亿元程序员"，一位有着8年游戏行业经验的主程。在游戏开发中，希望能给到您帮助，也希望通过您能帮助到大家。

实不相瞒，想要个赞和爱心！请把该文章分享给你觉得有需要的其他小伙伴。谢谢！