跳至正文

Cocos Creator 中小型游戏架构设计参考

定位:中型2D游戏(包含:关卡、剧情、UI商城、战斗、资源管理、存档、多场景等)
架构思想分层解耦 + 模块隔离 + 数据驱动 + 单例全局服务 + 视图与逻辑分离
目标:无强耦合、易扩展、易维护、适合团队协作与后期迭代。


一、整体五层架构(自上而下)

1. 视图层 View(UI/场景节点/特效/角色表现)
2. 业务层 Logic(玩法、战斗、关卡、任务、弹窗逻辑)
3. 数据层 Data(全局数据、玩家数据、配置表数据)
4. 服务层 Service(全局单例工具服务)
5. 底层基础层 Base(通用基类、事件、工具、常量)

核心原则

  • 视图不写复杂业务,只做显示与点击回调
  • 业务不直接操作节点,只调用视图接口
  • 所有数据统一托管,视图只监听数据变化刷新
  • 严禁到处写 find()getChildByName()

二、目录结构示例

assets/
├── resources/          # 动态加载资源(图集、音效、预制体、配置表)
├── scenes/             # 所有游戏场景
├── prefabs/            # 通用预制体
│   ├── ui/
│   ├── game/
│   ├── effect/
│   └── item/
├── textures/           # 静态贴图、大图
├── atlas/              # 图集打包目录
├── audio/              # 音效、背景音乐
├── script/             # 核心脚本目录
│   ├── base/           # 底层基类
│   │   ├── BaseView.ts        # 所有UI/视图基类
│   │   ├── BaseCtrl.ts        # 控制器基类
│   │   ├── EventMgr.ts        # 全局事件管理器
│   │   ├── PoolMgr.ts         # 通用对象池
│   │   ├── LoadMgr.ts         # 资源加载基类
│   │   └── Utils.ts           # 通用工具
│   ├── service/        # 全局单例服务(常驻内存)
│   │   ├── GameService.ts     # 游戏全局状态
│   │   ├── UserService.ts     # 玩家数据服务
│   │   ├── SaveService.ts     # 本地存档
│   │   ├── AudioService.ts    # 音效管理
│   │   ├── NetService.ts      # 网络请求
│   │   └── ConfigService.ts   # 配置表读取
│   ├── data/           # 数据模型
│   │   ├── UserData.ts
│   │   ├── LevelData.ts
│   │   └── GameConst.ts
│   ├── view/           # 所有视图层
│   │   ├── ui/         # 弹窗、主界面、背包、商城
│   │   ├── gameview/   # 游戏内表现层
│   │   └── tips/       # 飘字、提示、弹窗提示
│   ├── logic/          # 业务逻辑层
│   │   ├── battle/     # 战斗逻辑
│   │   ├── level/      # 关卡逻辑
│   │   ├── task/       # 任务逻辑
│   │   └── shop/       # 商城逻辑
│   └── entry/          # 入口脚本
│       └── GameMain.ts # 游戏入口初始化
├── config/             # Excel导出Json配置表
└── shader/             # 自定义2D着色器

三、五大分层详细设计

1. 底层基础层 Base

(1)全局事件管理器 EventMgr

  • 全局发布订阅,模块之间通信唯一标准
  • 禁止脚本直接互相引用调用
  • A模块发事件,B模块监听解耦
    // 发送
    EventMgr.emit("UPDATE_GOLD", num);
    // 监听
    EventMgr.on("UPDATE_GOLD", this.onGoldChange, this);

(2)通用对象池 PoolMgr

  • 全局统一对象池,管理:子弹、怪物、特效、飘字
  • 统一预创建、复用、回收,解决大量实例化卡顿

(3)资源加载管理器 LoadMgr

  • 封装 resources 加载、分包加载、图集预加载
  • 统一加载进度、失败重试、资源缓存

(4)BaseView 视图基类

所有UI、游戏视图继承此类,统一封装:

  • 显示/隐藏 show() / hide()
  • 动画弹出收起
  • 自动注册/移除事件
  • 统一关闭回调
    杜绝每个UI重复写显隐逻辑

2. 服务层 Service(全局单例,游戏生命周期常驻)

全部使用懒加载单例,全局任意位置调用

UserService.instance
AudioService.instance
SaveService.instance

常用必建服务

  1. UserService
    • 统一存放玩家所有数据:金币、钻石、等级、道具、体力
    • 提供增删改查接口
  2. SaveService
    • 封装 sys.localStorage
    • 自动存档、读档、版本兼容、加密存储
  3. AudioService
    • 统一播放背景音乐、音效、开关音量、静音
  4. ConfigService
    • 预加载所有Json配置表
    • 提供:获取关卡配置、道具配置、怪物配置
  5. GameService
    • 全局游戏状态:游戏暂停、继续、锁屏、全局帧率控制
  6. NetService
    • 统一封装Http、登录、上报、服务器接口

规则:所有全局状态、通用能力全部塞进Service,不散落各处。


3. 数据层 Data

  1. 常量层 GameConst
    固定数值、事件名、路径、枚举全部统一写这里
  2. 数据模型
    纯数据类,只存字段,无任何视图逻辑
    视图监听数据变化自动刷新
  3. 配置表数据
    Excel导出JSON,由ConfigService统一读取,运行时只读不修改

优势:换皮肤、改数值、配关卡只改配置,不动代码。


4. 业务逻辑层 Logic

纯逻辑层,不操作任何Node、Sprite、Button
只做:

  • 数值计算
  • 战斗判定
  • 关卡流程
  • 任务判定
  • 道具合成、消耗判定

逻辑层 → 发事件 → 视图层接收刷新
逻辑与表现彻底分离

示例流程:

点击攻击按钮 → 视图回调 → 调用战斗逻辑 → 计算伤害 → 发送扣血事件 → 血条视图监听刷新


5. 视图层 View

只负责三件事:

  1. 界面初始化、绑定节点
  2. 接收用户点击、滑动输入
  3. 监听全局事件,刷新界面显示

严禁

  • 在UI脚本里写战斗逻辑
  • 在UI里写存档读写
  • 直接跨UI调用函数

四、场景划分规范

  1. 启动场景:加载页、热更、资源预加载
  2. 主主城场景:主界面、功能入口
  3. 战斗/关卡场景:核心游玩场景
  4. 独立小游戏场景:支线玩法
  5. 弹窗全部独立预制体,不塞进场景

场景切换规则

  • 切换前统一暂停所有逻辑、清空临时对象
  • 切换后统一初始化对应模块
  • 常驻UI根节点不随场景销毁

五、UI架构设计

  1. UI根节点分层
    UIRoot
    ├── BottomLayer   底层背景
    ├── GameLayer     游戏主内容
    ├── UILayer       普通UI界面
    ├── PopLayer      弹窗层
    ├── TipLayer      飘字、提示
    └── TopLayer      置顶屏蔽层、引导
  2. 所有弹窗做成预制体,统一由UIMgr管理打开关闭
  3. 弹窗统一栈管理,支持弹窗层级遮挡、一键关闭顶层

六、资源管理架构

  1. 图集规范
    • UI全部打包图集
    • 游戏内角色、道具分开图集
    • 动态头像、远程图单独缓存
  2. 预加载策略
    • 启动预加载:通用UI、背景音乐、常用配置
    • 进入关卡前预加载:关卡资源、怪物、特效
    • 退出场景卸载闲置资源防内存暴涨
  3. 纹理统一规范
    • 统一2次幂尺寸
    • 移动端开启纹理压缩
    • 透明图与非透明图分开设置

七、生命周期与初始化流程

GameMain 入口
1. 初始化全局事件管理器
2. 初始化所有Service单例
3. 读取本地存档
4. 预加载基础配置表
5. 初始化全局对象池
6. 进入启动加载场景
7. 加载完成跳转主城
8. 主城初始化UI模块、玩法模块

八、绝对禁止事项

  1. 禁止全局到处用this.node.find
    全部在视图脚本属性绑定节点
  2. 禁止模块直接互相引用
    一律用全局事件通信
  3. 禁止大量直接instantiate+destroy
    统一走全局对象池
  4. 禁止业务逻辑写在UI脚本
    严格视图/逻辑分层
  5. 禁止零散存档读写
    统一走SaveService
  6. 禁止随意创建全局变量
    全部归入Service / Data

九、最简开发流程

  1. 策划出配置表 → 导出JSON放入项目
  2. 程序在ConfigService注册读取
  3. 建立对应Data数据模型
  4. 编写Logic业务逻辑
  5. 编写View视图界面
  6. 事件串联完成交互
  7. 接入Audio、存档、网络服务
  8. 批量做性能优化:合批、对象池、分帧加载

十、架构优势

  1. 后期加新玩法无需改动旧架构,直接新增模块
  2. 多人开发互不冲突,分层明确
  3. 极易做热更、分包、资源拆分
  4. 性能优化统一入口,方便全局管控
  5. 代码复用率极高,同类界面快速复刻

标签:

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注