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

引言

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

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

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

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

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

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

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

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

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

今天项目A要上传到服务器，明天项目B也要上传到服务器。

如果每个项目都单独写一套上传按钮、分支前缀、预览地址配置，后面维护起来就会很麻烦。

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

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

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

全局插件放在哪里？

这里非常重要。

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

项目目录/extensions

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

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

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

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

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

如何让全局插件生效？

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

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

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

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

npmrun 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文件。

执行构建命令：

npminstallnpmrun 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年游戏行业经验的主程。在游戏开发中，希望能给到您帮助，也希望通过您能帮助到大家。

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

推荐文章：

亿元Cocos小游戏实战合集2.0

亿元Cocos小游戏实战合集1.0

老板说最近这款游戏很火让我抄，可是我连玩都玩不明白…

这款值68亿的游戏，你不实战一下吗？安排！

小伙伴说我的拼图游戏用Mask不能合批…

俄罗斯方块谁不会做…啊？流沙版？

最近很火的一个拼图游戏，老板让我用Cocos3.8做一个…

老板说拼图游戏太卷了，让我用Cocos做个3d版本的…

敢不敢挑战用Cocos3.8复刻曾经很火的割绳子游戏？