游戏知识体系

游戏引擎与 Cocos Creator ​

Category ​

client / Web 前端。节点定位：以 Cocos Creator 为载体讲引擎的工作方式——节点/组件/预制体/适配/构建，这些概念在绝大多数引擎里都有对应物。

Definition ​

引擎解决的是「把渲染、场景、资源、适配这些共性设施组装起来」的工程问题。Web 游戏侧最主流的路线之一是 Cocos Creator：TypeScript 技术栈、对小游戏平台的构建链完善、2D 与轻量 3D 通吃。本页以它为载体讲清引擎的工作方式——这些概念（节点、组件、预制体、适配）在绝大多数引擎里都有对应物。

Problem ​

引擎替你解决渲染、场景、资源、适配、多平台构建的共性设施，但不替你解决模块边界、网络层设计、状态管理与性能预算——那些仍是项目层的事。把引擎当架构，项目会卡在「引擎够用但越来越难改」；构建产物超包体上限、资源分组没在早期定，则是发布期最常见的阻塞。

引擎替你解决什么 ​

对照第 8 章《客户端架构与引擎体系》的结论：引擎是地基与公共设施，不是项目架构。Cocos Creator 这类引擎替你解决渲染器（2D/3D 双管线）、场景与节点管理、资源管线（导入、打包、释放）、UI 系统、屏幕适配、多平台构建；它不替你解决模块边界、网络层设计、状态管理与性能预算——那些仍是项目层的事。

节点、组件与场景 ​

引擎把游戏世界组织成场景树：节点（Node）挂树，组件（Component）提供行为。一个节点可以有渲染组件（精灵、模型）、物理组件、以及任意多个自定义脚本组件。脚本组件有明确的生命周期：

ts
import { _decorator, Component } from 'cc'
const { ccclass, property } = _decorator

@ccclass('Spin')
export class Spin extends Component {
  @property
  speed = 90 // 度/秒，可在编辑器面板调整

  update(deltaTime: number) {
    this.node.angle += this.speed * deltaTime // 2D 旋转
  }
}

把脚本挂到节点上即生效。update 每帧调用、onLoad/start 在初始化阶段调用一次。要点与误区同源：update 是热路径，每帧做节点查找（getChildByName、getComponent）是新手最贵的习惯——查找结果应在 onLoad/start 里缓存成成员。

预制体与对象池 ​

预制体（Prefab）是「配置好的节点子树」的序列化模板：把做好的子弹、敌人、UI 条目存成预制体，运行时实例化。它是资源组织的原子单位，也是对象池的前提——频繁生成销毁的对象（子弹、飘字、列表项）应从池里取、用完还池，避免反复实例化带来的分配与初始化抖动。判断一个预制体设计好不好，看两件事：它是否只依赖自己的配置（而不是场景里的全局查找），以及实例化后是否还需要大量手工补配置（需要，说明模板切分不对）。

屏幕适配 ​

Web 与小游戏平台共同的问题是：你不知道玩家用什么屏幕。适配的三层工具：设计分辨率（按一个基准尺寸做界面，引擎按策略缩放）、适配策略（fitWidth/fitHeight/fitWidthAndHeight，决定裁哪边、留哪边）、Widget 与锚点（把元素钉在父容器的边、角或中心，配合安全区处理刘海屏）。适配的验收标准很硬：最宽与最高的目标设备各过一遍，界面元素不裁切、不重叠、可点击区域不出安全区。

构建到小游戏平台 ​

Cocos Creator 的构建链可以直接产出各小游戏平台工程与 Web 页面。构建阶段发生的事值得了解：资源按规则压缩与分包、脚本编译打包、生成平台适配层。构建产物超包体上限是最常见的发布阻塞，源头通常在未压缩音频与未分组纹理——资源分组（哪些进主包、哪些进远程包）要在项目早期定，而不是发布前补（对照第 8 章 03 页资源系统）。

常见误区 ​

  • 把引擎当架构：所有逻辑堆在几个大组件里，节点树长成意大利面——引擎只给你承载点，分层仍要自己做（见本章 06 页）
  • update 里做查找与分配：热路径三忌——查找、新建、日志
  • 适配只测一种屏幕：开发机屏幕就是全部测试集，上线才发现刘海屏按钮被吃掉
  • 预制体互相依赖场景全局：预制体离开原场景就不能用，说明依赖没收敛到配置与自身子树
  • 用引擎不懂数值：动画、缓动、物理参数全是数值工作，引擎把这些旋钮全暴露出来了——不懂就直接拍脑袋

实战案例：一次「引擎够用，改个活动按钮却要动 23 个文件」的架构缺位排查 ​

案例为教学示例（非摘自真实项目），数字经过取整简化。它把本页「节点、组件与场景」「屏幕适配」「常见误区」用到深水区：功能都做得出来，就是越来越改不动——这是把引擎当架构的归因排查，也是「引擎是地基，不是项目架构」的完整展开。

背景与现象：Cocos Creator 项目推进 9 个月，最大 UI 场景节点 2400 个、树深 14 层；业务逻辑散在 87 个组件里，跨组件直接引用 310 处。一次「改活动按钮位置」的需求牵出 23 个文件、耗时 3 人天；同时刘海屏真机首测发现 17 处界面裁切——开发机从头测到尾，一次真机都没进过。

第一步：现象与口径——把改动半径与适配欠账分开量 ​

改动口径：87 个组件、310 处跨组件直引，一个按钮的位移要顺着节点树摸 14 层；改 23 个文件里 19 个只是「把别人硬编码的坐标改回来」。

热路径口径：主场景每帧 getChildByName/getComponent 查找 620 次——本页说热路径三忌——查找、新建、日志，查找独占一忌。

适配口径：适配测试集只有开发机 1920×1080；真机首测 17 处裁切集中在刘海与手势条两侧，可点击区域出安全区 6 处。

第二步：分层归因——按本页常见误区清单比对 ​

text
改不动归因  占比
  把引擎当架构，逻辑全堆在大组件里        47%
  update 热路径查找，每帧 620 次没缓存    31%
  适配只测开发机一屏，真机欠账后置        22%

逐项比对：节点树长成意大利面、逻辑全在几个大组件里，正中「把引擎当架构：引擎只给你承载点，分层仍要自己做」；每帧 620 次查找正中「update 里做查找与分配」；17 处裁切正中「适配只测一种屏幕：开发机屏幕就是全部测试集」。

第三步：根因——引擎给的是承载点，项目把承载点当成了架构 ​

引擎替你解决渲染、场景、资源、适配、多平台构建的共性设施，但不替你解决模块边界、网络层设计、状态管理与性能预算。项目把「组件能挂」当成了「组件该挂」：模块边界没画，310 处跨组件直引就是边界不存在的证据；预制体设计没收敛，离开原场景就不能复用。改动半径按引用图指数扩散，23 个文件里大半是被动波及——这正是「引擎够用但越来越难改」的标准形态。

第四步：处置与回填——把承载点还给引擎，把架构补回项目 ​

  1. 组件瘦身：业务逻辑收敛到 34 个模块组件，跨组件直引改为事件与显式接口；310 处直引 → 52 处。
  2. 查找缓存：onLoad/start 里把节点与组件引用缓存成成员，每帧查找 620 → 40 次。
  3. 适配清单：按本页验收标准——最宽与最高的目标设备各过一遍，界面元素不裁切、不重叠、可点击区域不出安全区——进冒烟，刘海与手势条两侧各留安全区；17 处裁切 → 0。
  4. 预制体收敛：预制体只依赖自身配置与子树，模板切分不对的 11 个重切。

复核账：改活动按钮 23 个文件 3 人天 → 4 个文件 0.5 人天；每帧查找 620 → 40 次；真机裁切 17 → 0 处；主场景节点 2400 → 900 个。

回填清单：

回填项动作回填处
组件瘦身业务逻辑收敛到模块组件，跨组件走事件与接口节点、组件与场景
查找缓存onLoad 缓存引用，热路径禁查找、新建、日志节点、组件与场景
适配验收最宽与最高设备各过一遍，安全区两侧留够屏幕适配
预制体收敛只依赖自身配置与子树，模板切分重审预制体与对象池

案例的三个教训 ​

  1. 引擎是地基与公共设施，不是项目架构——模块边界不画，组件树替你长成意大利面。
  2. update 是热路径——查找、新建、日志三忌，每帧 620 次查找就是每帧都在还这三忌的债。
  3. 适配的验收标准很硬——最宽与最高的设备各过一遍，开发机全绿不等于任何真机不裁切。

Used By ​

Web 与小游戏项目的引擎选型（Cocos Creator/Laya/Egret 的对比维度）；引擎项目初期的资源分组与构建规划；从零搭项目的节点/组件组织。

关系链：引擎职责 → 节点组件场景 → 预制体与对象池 → 屏幕适配 → 平台构建。上游：WebGL 管线（web/02）。下游：引擎商业模式（engines/01）、客户端技术栈（client/01，引擎之上的责任划分）。

Reference ​

Cocos Creator 以官方文档为准；本页其余为工程经验归纳；页内实战案例为教学示例（数字取整简化）。

游戏知识体系

© 2025 cuihairu