目的不同， cc可以支持一个组件挂重复的脚本， 用MAP就没办法了。

嗯，确实目的不同
这个ec主要是用在局内战斗，我倒是没碰到过需要挂重复脚本的需求

太强了，牛逼。

就喜欢开源的东西，楼主多发！好看、爱看、喜欢看~

就喜欢开源的东西，楼主多发！好看、爱看、喜欢看~

大家去跟帖支持下吧~

倒是很少用到频繁切换预制体的情况，不过确实也有这需求

新增条件显示节点，配合fgui（用来处理游戏中的提示红点信息）
主要是解耦用

定义条件

// 定义条件类型枚举
enum ConditionType {
  condition1,
  condition2,
  condition3,
}

// 定义条件
@conditionClass(ConditionType.condition1)
export class Condition1 extends kunpo.ConditionBase {
    protected onInit(): void {
      // 监听条件发生变化, 则调用一次 this.tryUpdate();
        kunpo.GlobalEvent.add("condition1", () => {
            this.tryUpdate();
        }, this);
    }

    protected evaluate(): boolean {
      	//TODO:: 根据条件数据，返回true or false
        return true;
    }
}

节点关联条件

/** 任意一个满足 显示节点 */
new kunpo.ConditionAnyNode(fgui.GObject, ConditionType.condition1, ConditionType.condition2);

/** 所有条件都满足 显示节点 */
new kunpo.ConditionAllNode(fgui.GObject, ConditionType.Condition1, ConditionType.Condition2, ConditionType.Condition3);

赞！已经给 github star 了

顺便咨询下这个宫爆小游戏是个人开发的还是帮公司开发的呢？应该是帮公司开发的对么？（毕竟个人开发者没法给游戏开通充值服务）

感谢给star
游戏是公司开发的，现在的环境下，毕竟个人开发游戏不太合适了

单纯防止重复脚本会报错吧， unity也是如此， 在重复的脚本挂上去， 不会报错，会执行两个组件， cc估计是照搬过来了

报错不知道。。。

1. 首先我从来没有这方面的需求
2. 我现在的框架中，基本上也不需要node挂脚本

以下内容是AI的答案

fairygui在Creator 2.4.x中的优势

fairygui在Cocos Creator 2.4.x中使用时，相比原生Creator UI系统有以下几个明显优势：

1. 独立的UI编辑器

fairygui提供了专门的UI编辑器，可以让美术和策划直接参与UI制作，而不需要依赖程序。这种工作流程分离让团队协作更高效，美术可以独立完成UI设计和调整。

2. 更强大的组件系统

fairygui的组件系统比Creator原生UI更加丰富和灵活：

• 更完善的列表控件，支持虚拟列表和各种复杂布局

• 更强大的文本控件，支持更丰富的富文本效果

• 树形控件、可折叠面板等高级组件

3. 更完善的动画系统

fairygui内置了专业的UI动画编辑器，可以直接在编辑器中创建和预览复杂的UI动画，而不需要通过代码或时间轴来实现。

4. 更好的性能优化

对于复杂UI界面，fairygui通常有更好的性能表现：

• 更高效的对象池管理

• 更优化的渲染批次处理

• 虚拟列表技术减少大量列表项的内存占用

5. 更灵活的布局系统

虽然Creator也有布局组件，但fairygui的布局系统更加灵活，支持更多布局方式和嵌套布局。

6. 更好的热更新支持

fairygui的资源是完全独立的，更容易进行热更新，可以单独更新UI而不影响其他游戏内容。

7. 更好的多分辨率适配

fairygui提供了更完善的多分辨率适配方案，能更好地处理不同屏幕尺寸和比例。

8. 更低的学习成本（对美术人员）

对于美术人员来说，fairygui的编辑器更直观，学习曲线更平缓。

9. 跨引擎复用

如果项目未来需要迁移到其他引擎，使用fairygui可以更容易地复用UI资源和代码。

对于中小型项目，Creator原生UI可能已经足够。但对于UI复杂、交互丰富的大型项目，特别是MMO、RPG等类型游戏，fairygui的优势会更加明显。

顶+mark

用过一次fgui，开发了一款重度卡牌，个人觉得除了跨引擎和能导出ui绑定的代码其他的没感觉多好用,除了这两项其他的在creator编辑器里也有甚至这两项社区插件也能实现，最后fgui和creator还有兼容性的问题，也可能是我姿势不对，他的动画系统很不好用啊！

有没有可能是习惯问题？
我用习惯后，界面做起来比creator快多了

动画系统也还好吧，实现一些简单的UI动画问题不大

嗯，赞同，用了一段时间积累了一些公共常用组件效率肯定有提升，但是这是放之四海而皆准的用啥工具都是这样，最后还有兼容性问题和没有跨引擎需求所以我最后放弃fgui了

嗯，最终还是适合自己的才是最好的

添加UI包资源自动加载，使用请参考demo

github demo地址
gitee demo地址

项目配置

1. 新建项目，创建首场景文件

2. 编写入口脚本

   import { _decorator } from "cc";
   /** 引入kunpocc入口 */
   import { CocosEntry, log } from "kunpocc";
   
   const { ccclass, property, menu } = _decorator;
   @ccclass("GameEntry")
   @menu("kunpo/GameEntry")
   export class GameEntry extends CocosEntry {
       @property(cc.Node)
       private root: cc.Node = null;
       onInit(): void {
           log("GameEntry onInit");
       }
   }
   

3. 创建入口节点GameEntry，创建UI模块节点 UI 、UI容器节点window， 并关联对应的脚本

   

   image-202502131023090471344×860 307 KB

4. 配置完毕