简介CocoKnightManager是一款面向Cocos Creator开发者的开源回合制游戏系统设计方案适用于希望快速搭建回合制玩法、提升代码复用性的初中级游戏开发人员。整个包共22个文件压缩包仅216KB以JSON配置文件、TypeScript脚本、PNG资源素材及README说明文档为主结构清晰便于直接套用和学习。设计上强调模块化与数据驱动开发者可通过JSON调整角色属性和战斗规则无需改动核心逻辑即可扩展不同回合制机制同时回合管理器协调行动顺序状态机管理角色状态适合作为独立模块集成到现有项目中。资源包提供完整源码与配套md说明已有834人学习下载对想掌握Cocos Creator回合制架构的开发者而言是兼顾实践与参考价值的开源范例可帮助理解回合流程、行动规则与状态切换的落地实现。1. 回合制游戏为什么需要“系统设计”一次课程设计翻车换来的教训做回合制游戏最容易翻车的地方恰恰不是美术资源不够也不是数值平衡难调而是战斗系统的状态管理。我参与过不少回合制项目的评审见过太多项目一开始功能表上写着“3个角色、6个技能、20关”结果代码写成一个大场景脚本所有技能、AI、结算全都堆在同一个update()循环里。A同学交课程设计时演示到第3关角色放完技能后回合直接卡死整个演示黑屏收场——因为状态机根本没有兜底也没人讲清楚回合数据应该怎么存、怎么恢复。CocoKnightManager这套方案就是冲着这几个问题去的它把所有系统按管理器拆分用事件总线解耦把回合、存档、资源三条主链路做成可复现的工程模板。适合正在做回合制课设或毕设的学生也适合想给项目搭一个可扩展基线的独立开发者。这套系统设计的核心逻辑很简单先让代码结构能说清楚“谁在什么时候做什么”再谈玩法。2. 总体架构设计管理器分层、事件总线与代码目录的三层划分2.1 管理器单例的职责边界八个管理器各自管什么一个典型的回合制战斗场景里同时存在玩家输入、技能动画、伤害结算、敌方AI、相机抖动、UI血条刷新、背景音乐切换这七类行为。如果都塞进场景脚本的update()每加一个新技能就要去改同一个文件改完还会牵动其他逻辑——这是典型的“黑匣子代码”表面上能跑实际上没人敢动。所以第一步是拆把系统按职责拆成八个管理器。管理器职责明确禁止做的事GameManager游戏流程状态开始、暂停、结束不直接操作UI节点不写战斗数值BattleManager回合流转、行动队列、胜负判定不加载资源不做存档读写DataManager存档读写、版本迁移、角色与技能数据表不参与战斗逻辑不管理场景对象UIManager界面开关、血条刷新、弹窗队列不持有战斗状态只读取事件参数AudioManagerBGM切换、音效播放、音量持久化不轮询战斗状态不做资源加载ResourceManager图集与预制体加载释放、引用计数不硬编码resources.load路径PoolManager对象池技能特效、飘字、弹道不复用未重置的对象EventManager事件总线发布与订阅不封装具体业务逻辑这套管理器清单是在实际迭代里固定下来的。早期版本只有BattleManager和UIManager两个类结果BattleManager里混进了存档读写、音效播放和资源加载的代码一个类两千行改一行伤害公式要翻半天文件。后来把职责边界写成注释表挂在GameManager文件头部每次新增功能先看自己属于哪个管理器不越权写代码。这张表还有一个作用评审答辩时有人问“BattleManager和UIManager同时刷新血条怎么办”答案就在表里——BattleManager只负责发battle:action-resolved事件血条刷新是UIManager的事。职责边界一旦模糊两个管理器同时改同一个进度条就会出现你找不到来源的闪跳问题。管理器统一用延迟单例实现。注意这里不用静态类直接定义实例而是用getInstance做延迟初始化// BaseManager.ts export class BaseManager { protected static _instance: any null; static getInstanceT(): T { if (!this._instance) { this._instance new this(); } return this._instance as T; } init(...args: any[]): void { } }为什么不用静态实例字段因为场景脚本在加载阶段就可能访问管理器如果此时管理器构造里依赖了尚未初始化的资源就会出现空引用。延迟初始化把构造时机推迟到第一次真正使用的时候。init是统一入口GameManager在启动场景里只做一件事按固定顺序调用八个管理器的initEventManager事件总线最先后续管理器可以注册监听DataManager读取存档和数据表ResourceManager加载全局资源清单PoolManager预创建常驻对象池AudioManager恢复音量设置UIManager挂载根节点BattleManager最后初始化因为它要依赖事件、数据和资源全部就绪。这个初始化顺序不是拍脑袋定的。BattleManager初始化时要去订阅事件、读数据表、请求资源依赖项必须前置。顺序反了启动场景时就是一连串的空引用报错。2.2 事件总线回合通知与UI刷新的解耦写法UI层和战斗层是典型的解耦场景。战斗结算完了血条要减少、飘字要出现、敌方头像要置灰如果BattleManager直接去拿UIManager的节点引用那BattleManager就依赖了一大堆UI实现细节。我把依赖方向翻转一下让战斗层只发事件UI层自己订阅。Cocos Creator自带的EventTarget可以直接作为事件总线底座// EventManager.ts import { EventTarget } from cc; type EventCallback (...args: any[]) void; export class EventManager { private _target new EventTarget(); private static _ins: EventManager null; static get ins(): EventManager { if (!this._ins) this._ins new EventManager(); return this._ins; } on(event: string, cb: EventCallback, target?: unknown) { this._target.on(event, cb, target); } off(event: string, cb?: EventCallback, target?: unknown) { this._target.off(event, cb, target); } emit(event: string, ...args: any[]) { this._target.emit(event, ...args); } }战斗层发事件时不关心谁在听// BattleManager.ts this._eventMgr.emit(battle:turn-start, { turnNo: this._turnNo, side: player, actorList: this._actorList });UI层订阅事件并在组件销毁时反注册// BattleHud.ts onLoad() { EventManager.ins.on(battle:turn-start, this.onTurnStart, this); EventManager.ins.on(battle:action-resolved, this.onActionResolved, this); } onDestroy() { EventManager.ins.off(battle:turn-start, this.onTurnStart, this); EventManager.ins.off(battle:action-resolved, this.onActionResolved, this); }这里有个细节值得讲清楚onLoad里订阅、onDestroy里off是Cocos Creator里防止事件泄漏的标准写法。如果只订阅不反注册场景切换后旧界面的回调还在事件总线上下一场战斗的事件会把已经销毁的节点再调用一遍报cc.Node空引用。事件命名用模块前缀battle:、save:、ui:避免命名冲突。事件参数尽量用一个对象传这样后续加字段不用改所有订阅方。方案里的事件清单是固定的新增功能时先把事件名列出来再写代码而不是边写边发明否则项目跑三个月之后没有人说得清某个事件是哪里发的。事件总线这套写法定下来之后包括换BGM、弹对话框、刷新属性面板都可以在不碰战斗代码的前提下完成。玩法是玩法表现是表现中间只隔一个事件名。2.3 场景与脚本目录按模块切分代码的命名约定代码目录能直接反映架构水平。如果目录按“场景”来分战斗场景里的脚本一旦切场景就跟着销毁管理器也跟着没了。正确的做法是按模块切场景目录里只放场景文件脚本目录按系统模块组织assets/ ├── scenes/ │ ├── boot.scene # 启动场景初始化管理器链 │ ├── battle.scene # 战斗场景 │ └── main.scene # 主菜单 ├── scripts/ │ ├── managers/ # 八个管理器每个一个文件 │ ├── modules/ │ │ ├── battle/ # 战斗状态机、行动队列、技能 │ │ ├── save/ # 存档序列化、版本迁移 │ │ ├── resource/ # 加载清单、引用计数 │ │ └── ui/ # 界面控制器 │ ├── models/ # 角色、技能、关卡数据结构 │ └── utils/ # 随机数、数学工具、日志 └── resources/ ├── prefabs/ ├── textures/ └── data/ # JSON数据表技能、敌人、关卡配置这套结构要贯彻两条硬规则。第一条场景文件里的脚本只做“组装”把预制体挂到节点上、设置初始参数不写业务逻辑。第二条全项目只能通过EventManager访问管理器的公开事件不允许直接用import去拿另一个管理器的内部属性。这两条做到了新同学接手代码只需要看managers和modules两个目录就能理解整个系统的结构。目录结构对答辩也很有用。评审问“你的代码怎么组织的”你不需要从头讲直接展示目录树然后说“管理器的生命周期在启动场景里统一处理战斗逻辑在modules里按模块分文件资源和数据表都走DataManager和ResourceManager”。这一段话基本就能让评审相信你不是把代码堆出来的而是设计过的。3. 战斗系统实现回合状态机、行动队列与技能结算的完整落法3.1 回合状态机五态流转与超时兜底战斗系统必须做成状态机这是回合制框架的共识但具体实现细节差异很大。最常被误用的是用布尔变量代替状态isPlayerTurn、isResolving各管一段结果技能动画还没播完敌人已经出手了。正确做法是维护一个显式的状态枚举所有行为都通过_switchPhase统一切换// BattlePhase.ts export enum BattlePhase { Idle idle, TurnStart turn_start, // 回合开始广播事件、重置行动点 PlayerAction player_action, // 等待玩家选择技能与目标 Resolve resolve, // 结算按顺序执行行动队列 EnemyAction enemy_action // 敌方AI行动 }流转规则是Idle - TurnStart - PlayerAction玩家点击“回合结束”后进入ResolveResolve里的行动全部结算完进入EnemyAction再回到TurnStart。关键设计点在Resolve阶段——它不是一个循环把行动全部执行完而是每执行一个行动就发一次事件等UI播完动画再回来执行下一个private _switchPhase(next: BattlePhase) { const prev this._phase; this._phase next; this._eventMgr.emit(battle:phase-change, { from: prev, to: next }); }这样做的原因是表现层与逻辑层节奏不同步。如果所有伤害都在一帧内算完再统一播动画就会出现“数字全跳完了血条还在慢慢减”的违和感。逐行动发事件、逐动画等回调既能保证伤害逻辑先行又不会让UI显得迟钝。回合同步推进还需要一个防守手段状态机超时兜底。实际项目里最常见的一种卡死是某个技能动画的回调丢失状态机永远停在Resolve。我的做法是在_switchPhase里记录时间戳在Resolve阶段启动一个5秒的watchdog定时器超时没有收到action-done就强制回退到TurnStart并打印警告日志定位是哪个技能卡住的。这个兜底在验收演示时的价值极大——哪怕有bug演示也不会死在那里而是能继续跑下去给排障留出了时间。3.2 行动队列与技能结算先声明后执行的回放式设计行动队列的核心思路是“先声明、后执行”。玩家每个操作不直接改数值而是先经过合法性校验生成一个行动对象进队列// BattleAction.ts export interface BattleAction { actorId: string; skillId: string; targetIds: string[]; seq: number; }玩家点击技能后BattleManager先校验行动点、距离、技能冷却通过后把BattleAction塞进队列。当玩家点击“回合结束”把队列按seq字段排序然后逐个结算。这样做的好处是战斗过程可以被完整回放把队列里的行动、随机数种子、每步的伤害结果写成结构化日志调试时重跑一遍日志就能还原现场而不是靠打日志猜。伤害计算单独抽一个函数方便做数值调优// DamageCalculator.ts export function calcDamage(attacker: ActorModel, defender: ActorModel, skill: SkillModel): number { // 基础公式技能倍率 × 攻击 / 防御做保底防除以0 const base skill.power * attacker.atk / Math.max(1, defender.def); // 随机浮动范围 0.9 ~ 1.15 const roll RandomManager.ins.next(0.9, 1.15); // 暴击判定暴击倍率1.5 const crit RandomManager.ins.next(0, 1) attacker.critRate ? 1.5 : 1; return Math.floor(base * roll * crit); }参数含义power是技能倍率在数据表里配置atk和def是攻防数值roll是0.9到1.15的浮动段critRate是暴击率。这套方案里的RandomManager不是Math.random()而是带种子的伪随机序列种子存在战斗会话里。同一种子、同一套操作顺序整场战斗的伤害序列完全一致。这是回放排障的前提也方便做自动化测试——可以让AI连续跑100场同样的种子对局验证数值没有溢出。行动结算还涉及“等待表现”的问题。伤害算完后不能直接进下一个行动要等飘字、血条插值播完。这一层我一般用回调推进resolveNextAction() { if (this._actionQueue.length 0) { this._switchPhase(BattlePhase.EnemyAction); return; } const action this._actionQueue.shift(); const result this._executeAction(action); this._eventMgr.emit(battle:action-resolved, { action, result }); // 等UI播完动画后回调调用 resolveNextAction() }注意这里禁止写死setTimeout(1秒)继续因为动画长度会变。正确的是由UI层播完动画后主动调BattleManager.ins.resolveNextAction()逻辑层不关心动画播了多久。3.3 敌方AI与数值校验难度曲线与可调参数敌方AI是回合制项目里最容易写成“一堆if”的地方。我的做法是把AI策略数据化按难度等级拆成三个策略模板保守型只攻击血量最低的目标均衡型优先打属性克制的角色爆发型会连续放技能但下回合会空过。策略模板不写在代码里而是放在JSON数据表里{ enemy_ai: { normal: { target_rule: lowest_hp, skill_order: [attack, attack, guard], retreat_threshold: 0.3 }, hard: { target_rule: attribute_advantage, skill_order: [skill_3, attack, attack], retreat_threshold: 0.5 } } }target_rule决定选目标规则skill_order决定技能顺序retreat_threshold是撤退血量阈值。AI决策同样生成BattleAction走行动队列和玩家共用同一套结算管线。这样敌方AI不会绕过伤害公式、属性克制等规则也天然拥有回放能力。数据表多了以后必须加一层读取校验。每个关卡读取数据时跑一遍完整性校验技能ID在技能表里存在、角色ID存在、技能倍率大于0、目标规则枚举合法。校验失败直接抛错不放着半配置的状态进入战斗。这一步在前期看起来多余但一旦数值表交到策划手里批量改没有校验时出的问题极其难查——你看到的可能只是“一个敌人打我不掉血”实际上是技能ID在表里被改成了另一个不存在的ID属性默认成了0。做数值校验时我一般还会在单元测试里固定几组典型数值组合满级打一级、属性克制、暴击边界确保伤害公式的数学期望符合预期。这是回放之外第二道自动防线。4. 存档与资源管理数据持久化、动态加载与系统开源的工程化设计4.1 存档结构JSON序列化、版本号与迁移策略存档是回合制项目在验收时最容易翻车的模块玩家退出再进进度没保存上或者老存档升级格式后直接崩。这套方案的存档结构分成三层定义// SaveData.ts interface SaveData { version: number; // 存档版本号每次格式变更递增 saveTime: number; // 写入时间戳 player: { level: number; exp: number; team: string[]; }; progress: { chapter: number; unlockedSkills: string[]; }; battleSession?: { seed: number; turnNo: number; enemyAlive: boolean; }; }version是存档格式的唯一标识。每次新增字段、删除字段、修改字段含义版本号必须递增。battleSession是可选的游戏在战斗中途退出时写入下次进游戏弹提示“是否继续上一场战斗”。不要每步操作都写一次全量存档那个开销太大。DataManager维护一个dirty标记每次战斗结算或过关时置dirty在场景切走前做一次序列化写入。写盘用JSON.stringify存储层用sys.localStorage或封装好的文件IO。版本迁移是最容易踩坑的地方因为老存档格式和新代码不兼容。迁移逻辑单独抽一层用纯函数表实现// SaveMigrator.ts const migrators: Recordnumber, (old: any) any { 1: (old) ({ ...old, version: 2, player: { ...old.player, critRate: 0.05 } }), 2: (old) ({ ...old, version: 3, progress: { ...old.progress, unlockedSkills: [] } }) }; export function migrateSave(raw: any): SaveData { let data raw; while (data.version CURRENT_VERSION) { const target data.version 1; data migrators[target] ? migrators[target](data) : { ...data, version: target }; } return data; }迁移函数必须保证是纯函数输入旧数据、返回新数据不依赖全局状态和UI节点。特别注意迁移方向只能向前禁止写“把高版本降回低版本”的逻辑那会破坏数据。读档失败时走异常分支如果JSON解析失败不直接崩溃弹一个“存档损坏”的提示并提供继续新游戏的入口。这个异常分支是验收演示中的加分项评审特别喜欢看“程序对异常有没有处理意识”。4.2 资源管理预加载清单与引用计数释放回合制游戏的资源通常是关卡形式的主城、战斗图、特效图集、UI图集。全部预加载会导致启动白屏很久完全不预加载战斗中又会卡顿。这套方案分成两级加载第一级是启动场景只加载全局公共资源——UI图集、基础音效、公共预制体第二级是进入战斗场景前按关卡配置加载该关卡的图集、BGM、敌方预制体全部加载完成后才切场景。ResourceManager内部维护引用计数// ResourceManager.ts class ResourceEntry { asset: Asset | null null; refCount 0; } loadWithRef(bundle: string, path: string, onComplete: (asset: Asset) void) { // 先查缓存命中则 refCount 直接回调 // 未命中则 loadBundle 加载加载完放入缓存再回调 } release(bundle: string, path: string) { // refCount--归零时释放资源并清出缓存 }引用计数必须和场景生命周期绑死。场景A和场景B在同一个时刻引用了同一张图集refCount是2切走一个场景只降到1不会误杀另一个场景还在用的资源。如果只做“切场景就释放全部资源”图集被释放后再次加载的瞬间就会出现纹理闪一下变白的问题这种玄学问题排查起来最费时间。资源管理的另一个隐蔽问题是对象池与资源释放的配合。技能特效从池里取出播放完回池如果回池时不重置状态下一次取出就会带着上一次的残留。回池要有一个onReset约定清掉节点位置、缩放、透明度、粒子发射器状态。经验做法是特效预制体自带一个“初始状态常量”取出时强制apply一遍而不是靠调用方记得重置。4.3 系统开源的工程化组织从仓库结构到接口文档CocoKnightManager这套设计按“系统开源”的标准组织意味着它不只是“能跑的代码”而是别人拿过去能直接改的工程。开源工程和课程设计代码最大的区别在于它有最小的启动文档和明确的扩展入口。启动文档要回答三个问题环境版本、目录结构、如何跑通第一个示例关卡。仓库里至少要包含README环境与启动步骤、docs架构说明和事件清单、assets完整项目资源、tools数据表校验脚本。代码层面新技能的接入接口要极简新玩法才不会被框架挡住。以技能为例只需要实现一个接口// SkillExecutor.ts export interface SkillExecutor { canExecute(ctx: BattleContext, action: BattleAction): boolean; execute(ctx: BattleContext, action: BattleAction, onDone: () void): void; }新加一个技能就是新建一个文件实现这个接口再在技能数据JSON里加一条记录BattleManager完全不用改。这就是“系统开源的设计价值”——核心框架稳定扩展点开放。数据表也要开源可读。JSON数据表放resources/data目录技能、敌人、关卡配置用统一的id字段关联脚本里不直接写数值全部通过DataManager查表。数值校验脚本在提交代码前跑一遍防止“表里配了个不存在的技能ID”这种问题带到演示现场。评审在答辩时问“第三方或同学想基于你的项目加功能从哪里入手”答案就是README里的“接入新技能”章节照步骤走两分钟就能做出个新技能。5. 常见问题排查回合卡死、资源泄漏、存档丢失的翻车实录5.1 战斗到第三回合突然卡死状态机缺少超时兜底现象玩家点击回合结束界面没有任何响应日志停在“等待技能动画”游戏既不走下一步也不报错。原因某个技能执行时UI动画完成回调没有触发状态机一直卡在Resolve阶段。具体可能是动画监听写在了被销毁的组件上或者回调被重复调用导致推进逻辑只执行了一半。解决状态机每次切换记录时间戳在Resolve阶段启动一个5秒的watchdog定时器超过时限没有收到action-done就强制回退到TurnStart并打印警告日志。同时确保技能动画完成回调只调一次用一个_finishFlag防重入。这套方案把“回合卡死”从演示事故降级成“日志里有条警告”给排障留出了余量。5.2 场景切换后BGM还在响事件总线订阅泄漏现象从战斗场景回到主菜单战斗BGM还在放反复进出战斗场景后UI血条收到多次重复刷新甚至出现空引用报错。原因界面脚本在onLoad里订阅了事件但没在onDestroy里off。场景节点虽然销毁了回调还挂在EventManager上下一场战斗的事件把已销毁节点再调用一遍。解决所有EventManager.on必须在组件onDestroy里off并且UIManager在切场景前统一调一次releaseAll界面清理逻辑。建议把订阅关系整理成一个“订阅清单”在脚本基类里统一管理防止漏写反注册。5.3 技能特效从对象池取出后动画闪跳复用前没重置状态现象同一个技能第二次释放时特效位置不对或粒子残留严重时直接闪现上一帧的敌人位置。原因对象池只做了“移出场景”和“再放入场景”没有重置节点状态。特效预制体上残留了上一次运行时的位置、缩放、透明度或粒子参数。解决回池时统一调onReset接口清空变换和渲染状态取出时由调用方再强制应用一次“初始状态常量”。特效预制体里的组件不要挂持久化的动态数据动态数据全部在重置函数里恢复默认值。5.4 存档经常丢但重进又出现异步写入竞态现象玩家打完一整章退出游戏再进进度回退到一小时前或者崩溃后存档文件损坏无法读取。原因写入是异步的进程退出时写盘还没完成或者write操作做了两步先写临时文件再替换正式文件第二步没跑完就关了进程。解决写盘走串行队列dirty标记在写盘成功后清除退出前加一个同步屏障等待写盘队列清空再关进程。读档时做一次schema校验避免读到半截JSON。存档写入的关键点不是“写快”而是“写完整”。5.5 新机器上所有功能都能跑就是加载极慢资源引用没有预载现象项目打出来的包很大战斗场景打开后放技能前卡一下低端机上特别明显。原因启动时把所有资源全加载了或者战斗关卡的资源清单漏配运行时才临时加载。解决改成“最小启动清单 按场景清单”两级加载战斗前预加载该关卡的图集、BGM、敌方预制体。用ResourceManager的加载进度做切场景的过渡页而不是等场景加载完再放技能。这里有一个经验值战斗场景用到的主要图集最好控制在2到3张内一次性预载超过这个数量说明资源拆分粒度有问题。6. 验收与答辩功能清单、压测数据与演示顺序的五个要点6.1 验收清单功能、性能、异常三条线答辩之前先自己过一遍验收清单这三条线是项目是否“立得住”的判断标准。验收线检查项通过标准功能线战斗主流程、存档恢复、事件驱动UI刷新新游戏到通关10分钟跑完存档后重进进度一致异常线存档损坏、快速连点、战斗中途退出不崩溃有提示或可恢复不出现黑屏性能线启动时间、战斗FPS、内存增量中低端机战斗稳定60帧内存不随关卡数线性上涨功能线要跑通“主线动线”新游戏、打三场战斗、放技能、回合结算、过关、存档、重新进游戏。异常线是答辩的隐藏加分项准备两个故意破坏的case删掉存档字段模拟版本迁移快速连点“结束回合”按钮模拟操作风暴能正确处理这两个case就基本合格。性能线不用测很多项跑一场完整战斗记录FPS曲线就够说明问题。6.2 答辩演示的讲故事顺序先跑主线再讲架构最后展示排障答辩演示最容易犯的错误是上来就讲架构图评审还没见过游戏长什么样就被结构图劝退。推荐顺序是先跑主线让评审看懂玩法闭环再打开目录树用两分钟把八个管理器各管什么讲清楚最后挑一个排障案例讲“遇到了什么问题、怎么定位、怎么解决”。排障案例不用选太复杂的选第5章里任意一条就够。比如状态机卡死演示现场把技能回调注释掉战斗卡住然后展示watchdog如何强制恢复并打印警告日志。这个“现场翻车再修复”的动作比任何PPT都更有说服力它证明的不是“代码没有bug”而是“出bug也能兜住”。演示节奏上主线跑通关控制在10分钟以内架构讲解控制在5分钟排障演示3分钟刚好覆盖一场评审的注意力周期。数字上准备两组包体压缩到目标尺寸中低端机战斗保持60帧。不用多这两组数据就能支撑“这个系统设计是有效的”这个结论。从那以后我每次做回合制项目验收期都强制自己先跑一遍“异常路径手记”再写新功能存档损坏、快速连点、场景反复横跳这三组必测。这套CocoKnightManager也一直保持着“主线10分钟打完、异常3分钟查完”的习惯里面被踩过的坑都已经标在注释里。如果你要参考这套系统设计直接按这个目录搭就行希望能帮到你。本文还有配套的精品资源点击获取