类幸存者游戏开发实战：用QFramework搭建可上架级架构

1. 为什么类幸存者游戏是练手QFramework的最佳选择

类幸存者这个品类，从《吸血鬼幸存者》爆火之后，一直是独立游戏圈里性价比极高的练手方向。它的核心循环足够简单——移动、自动攻击、拾取经验、升级选词条、活过一波又一波——但底层架构却一点都不简单。怪物的批量生成与回收、伤害数字的频繁弹出、技能词条的动态叠加、局内数值的实时结算，这些东西如果全靠MonoBehaviour硬写，项目稍微大一点就会变成一团乱麻。我见过太多人做类幸存者，做到三四个技能之后代码就彻底失控，改一个数值要翻五六个脚本，最后只能弃坑。

QFramework恰好就是解决这个问题的。它是一套轻量级的Unity框架，核心是MVC分层加事件机制，配合一套非常顺手的UI管理工具和资源加载方案。你不需要一上来就理解它所有的设计哲学，只要跟着一个完整的项目走一遍，就能体会到“代码有地方放”的爽感。这套教程面向的是已经会Unity基础操作、能写简单C#脚本、但项目经验还停留在“一个场景几个脚本”阶段的开发者。如果你做过打砖块、Flappy Bird这类小Demo，想往商业级项目迈一步，那这个内容就是给你准备的。

我先把话说在前面：类幸存者看起来简单，但它对对象池、事件解耦、数据驱动这三件事的要求非常高。你如果只是想随便做个能跑的东西，不用框架也能凑合；但如果你想做出一个“上架级别”的、后续能持续加内容的作品，那从一开始就把架构搭对，比后面重构省十倍的力气。这篇内容会从整体设计思路讲到具体实现，再到踩坑排查，尽量把每个决策背后的原因都说清楚，让你不只是抄代码，而是真的理解为什么这么写。

2. 项目整体架构与QFramework核心思路拆解

2.1 类幸存者的核心系统拆解

在动手写第一行代码之前，我习惯先把游戏拆成几个独立的系统，每个系统只负责一件事。类幸存者这个品类，拆下来大概是这么几块：

• 玩家系统：移动、血量、经验、等级、拾取范围
• 武器系统：自动攻击、冷却计时、伤害结算、弹道或范围判定
• 敌人系统：生成、寻路、受击、死亡、掉落
• 词条系统：升级时三选一、词条效果叠加、数值修正
• UI系统：血条、经验条、计时器、升级面板、结算界面
• 关卡系统：波次配置、难度曲线、Boss刷新

这六个系统之间如果直接互相引用，代码会迅速变成蜘蛛网。比如武器要读玩家的攻击力加成，敌人死亡要通知经验系统加经验，升级面板要暂停游戏并读取当前词条池——这些交互如果全用GetComponent和直接调用，改一处崩三处。QFramework的价值就在这里：它用事件机制把这些系统之间的通信变成“发消息”和“收消息”，谁也不用认识谁。

2.2 为什么选QFramework而不是自己搭架构

有人会问，事件系统我自己写一个静态事件中心不就行了，为什么要用框架？我一开始也是这么想的，直到项目里出现了这些问题：事件发出去没人收，排查半天发现是订阅时机不对；UI打开关闭时事件重复订阅导致一次触发执行三遍；场景切换后旧的事件引用没清干净，内存泄漏。QFramework帮你处理了这些脏活，它的TypeEventSystem有明确的注册和注销规范，配合IController的生命周期，能很大程度上避免这类问题。

更重要的是QFramework的分层思想。它把代码分成Controller（逻辑）、System（数据与规则）、Model（纯数据）几层，虽然小项目不一定严格照搬，但这个思路能逼着你思考“这段代码到底该放哪”。比如玩家的血量，它属于数据，应该放Model；扣血的规则，属于逻辑，放System；而UI上血条的更新，属于表现，放Controller去监听事件。想清楚这一层，你的项目就不会出现“血条脚本里直接改玩家血量”这种反向依赖。

2.3 目录结构与命名规范的前期约定

我强烈建议在项目一开始就把目录结构定好，不然后面文件一多，找东西全靠搜索。我自己的习惯是这样的：

Assets/ _Project/ Scripts/ Controllers/ // 各系统的Controller Systems/ // 纯逻辑规则 Models/ // 数据结构 Events/ // 事件定义 Configs/ // ScriptableObject配置 Utils/ // 工具类 Prefabs/ Art/ Scenes/ Resources/

命名上，事件统一用XxxEvent结尾，比如PlayerHurtEvent、EnemyDeadEvent；配置类统一用XxxConfig；Controller统一用XxxController。这个约定看起来是小事，但当你有五十个脚本的时候，一眼就能从名字判断出它的职责，效率完全不一样。

提示：QFramework的ViewController和IController不要混用。UI相关的用UIPanel继承体系，纯逻辑的用IController注册到架构里，两者职责分清，后面维护会轻松很多。

3. 核心系统实现细节与实操要点

3.1 玩家移动与输入处理

玩家移动看起来简单，但类幸存者的移动有个特点：它是八方向自由移动，而且通常要支持手柄和键盘同时输入。我用的方案是读Input.GetAxisRaw拿到原始输入向量，然后归一化再乘以速度。这里有个细节，如果你直接用GetAxis（不带Raw），会有平滑过渡，手感会发飘，类幸存者需要的是干脆的即时响应，所以必须用Raw版本。

Vector2 input = new Vector2(Input.GetAxisRaw("Horizontal"), Input.GetAxisRaw("Vertical")); if (input.sqrMagnitude > 1f) input = input.normalized; transform.position += (Vector3)(input * moveSpeed * Time.deltaTime);

移动逻辑我放在PlayerController里，但速度这个数值来自PlayerModel。为什么要绕这一层？因为后面词条系统要加移速，如果速度写死在Controller里，词条就没法改它。正确做法是Controller每帧从Model读当前速度，词条系统改的是Model里的数值，两边通过数据解耦。

3.2 武器自动攻击与冷却机制

自动攻击的核心是冷却计时器。我的做法是每个武器维护一个currentCooldown，每帧减去Time.deltaTime，小于等于零就触发一次攻击并把冷却重置为配置值。这里有个坑：如果你用InvokeRepeating或者协程来做，攻速词条一改就会出问题，因为已经启动的计时器不会自动适应新数值。用帧驱动的计时器，每帧读最新的冷却配置，词条改了立刻生效。

攻击目标的选择也有讲究。类幸存者的武器通常分两类：最近敌人和随机敌人。最近敌人需要遍历当前所有存活敌人算距离，敌人多了会有性能压力。我的优化是维护一个敌人列表，只在敌人生成和死亡时更新，攻击时遍历这个列表而不是FindObjectsOfType。这个列表放在EnemySystem里统一管理，武器通过事件或者直接查询System来获取。

3.3 敌人对象池与批量生成

对象池是类幸存者的生命线。一局游戏里敌人可能生成几千个，如果每次都Instantiate和Destroy，GC会把帧率拖垮。QFramework本身没有强制你用什么池，我推荐用Unity自带的ObjectPool或者自己写一个简单的泛型池。

public class EnemyPool : MonoBehaviour { private Queue<Enemy> pool = new Queue<Enemy>(); public Enemy Get(Enemy prefab) { Enemy e = pool.Count > 0 ? pool.Dequeue() : Instantiate(prefab); e.gameObject.SetActive(true); return e; } public void Return(Enemy e) { e.gameObject.SetActive(false); pool.Enqueue(e); } }

生成逻辑我放在EnemySpawnSystem里，按波次配置从屏幕外圈随机位置生成。这里的关键是生成位置要在摄像机可视范围之外一点点，太远玩家看不到突然冒出来，太近又会显得突兀。我的经验是取屏幕对角线长度的一半再加两三个单位，这个距离刚好。

3.4 伤害结算与飘字系统

伤害结算的流程是：武器命中敌人 → 计算最终伤害（基础伤害 × 各种加成）→ 敌人扣血 → 如果死亡则触发死亡事件 → 弹出伤害数字。这里最容易出问题的是伤害计算顺序。我的建议是统一走一个DamageSystem.CalculateDamage(baseDamage, attackerBuffs, targetDebuffs)，所有加成和减伤都在这里算完，武器和敌人都不自己算，避免两处逻辑不一致。

飘字系统我强烈建议用对象池，因为伤害数字弹出频率极高。数字的动画用简单的上飘加渐隐，用DOTween或者自己写个协程都行。有个细节：多个伤害数字同时弹出会重叠，我的做法是给每个数字加一个随机的水平偏移，看起来更自然。

3.5 升级三选一与词条叠加

升级面板是类幸存者的灵魂。流程是：经验满 → 暂停游戏 → 从词条池随机抽三个 → 玩家选择 → 应用效果 → 恢复游戏。词条池的构建要考虑已满级词条不再出现、前置词条未解锁不出现这些规则。

词条效果的应用方式我推荐用数据修正而不是直接改逻辑。比如“攻击力+10%”，不是去改武器的伤害代码，而是往PlayerModel里加一个attackBonus字段，武器计算伤害时读这个字段。这样词条之间可以叠加，也不会互相干扰。QFramework的事件机制在这里很好用：选择词条后发一个UpgradeSelectedEvent，所有关心这个词条的System去监听并更新自己的数据。

注意：升级面板弹出时一定要暂停游戏，但暂停的方式有讲究。用Time.timeScale = 0会影响到所有用Time.deltaTime的逻辑，包括UI动画。我的做法是游戏逻辑用Time.deltaTime，UI动画用Time.unscaledDeltaTime，这样暂停时UI还能正常动。

4. 完整实操流程与关键环节实现

4.1 环境准备与QFramework导入

先说环境。Unity版本我建议用2021 LTS或2022 LTS，太新的版本有些插件兼容性还没跟上。QFramework可以直接从Asset Store或者GitHub获取，导入后会在菜单栏看到QFramework的选项。

导入之后第一步是初始化架构。QFramework的架构入口是一个继承自Architecture<T>的类，在里面注册Model、System和Utility。

public class GameArchitecture : Architecture<GameArchitecture> { protected override void Init() { RegisterModel<PlayerModel>(new PlayerModel()); RegisterModel<EnemyModel>(new EnemyModel()); RegisterSystem<IDamageSystem>(new DamageSystem()); RegisterSystem<IEnemySpawnSystem>(new EnemySpawnSystem()); } }

这个初始化只做一次，之后任何地方都可以通过GameArchitecture.Interface拿到System和Model。这一步做完，你的项目就有了一个“全局大脑”，后面所有系统都从这里取数据。

4.2 玩家Controller的完整实现

PlayerController继承MonoBehaviour并实现IController，在Awake里注册到架构。它的职责是：读输入、移动、监听受伤事件、更新血量显示。

public class PlayerController : MonoBehaviour, IController { private PlayerModel model; void Awake() { model = this.GetModel<PlayerModel>(); this.RegisterEvent<PlayerHurtEvent>(OnHurt); } void Update() { // 移动逻辑 } void OnHurt(PlayerHurtEvent e) { model.Hp.Value -= e.Damage; if (model.Hp.Value <= 0) this.SendEvent<PlayerDeadEvent>(); } public IArchitecture GetArchitecture() => GameArchitecture.Interface; }

注意this.GetModel和this.RegisterEvent这些扩展方法，都是QFramework提供的，用起来很顺手。OnDestroy里记得注销事件，虽然QFramework在Controller销毁时会自动清理，但手动写一遍更保险。

4.3 敌人AI与寻路简化方案

类幸存者的敌人不需要A*寻路，直接朝玩家方向移动就够了。但直接LookAt加Translate会有个问题：敌人会挤成一团。我的做法是给每个敌人加一个分离力，当检测到附近有其它敌人时，施加一个远离的力。这个用简单的物理检测或者距离判断都能实现。

Vector2 dir = (player.position - transform.position).normalized; Vector2 separation = Vector2.zero; foreach (var other in nearbyEnemies) { separation += (transform.position - other.position).normalized; } dir = (dir + separation * 0.5f).normalized; transform.position += (Vector3)(dir * speed * Time.deltaTime);

这个分离力不用太精确，0.5的权重就够，目的是让敌人不要完全重叠，视觉上好看很多。性能上，附近敌人的检测不要每帧对全部敌人做，用一个空间网格或者每隔几帧检测一次。

4.4 波次配置与难度曲线设计

波次配置我用ScriptableObject来做，每个波次定义：持续时间、生成间隔、敌人类型、敌人数量、血量倍率。难度曲线不是线性的，前期慢后期快，我的经验是前两分钟让玩家轻松建立优势，三到五分钟开始有压力，五分钟之后进入紧张期。

这个表格只是参考，实际要根据你的武器强度来调。调数值的时候我建议用热重载，QFramework配合ScriptableObject可以在运行时改数值立即生效，不用反复重启游戏。

4.5 UI面板与QFramework的UIPanel体系

QFramework有一套自己的UI管理，核心是UIPanel。每个面板继承UIPanel，通过UIKit.OpenPanel<T>()打开。升级面板的实现：

public class UpgradePanel : UIPanel { protected override void OnInit(IUIData data = null) { // 从词条池抽三个，绑定到按钮 } }

UI和逻辑的通信全部走事件。升级面板选择词条后发UpgradeSelectedEvent，词条系统收到后应用效果，然后发UpgradeCompleteEvent，面板收到后关闭自己。这样UI完全不知道词条系统怎么工作，词条系统也不知道UI长什么样，两边可以独立修改。

5. 常见问题与排查技巧实录

5.1 事件发了没反应怎么办

这是新手最常见的问题。排查顺序是：第一，确认订阅方在发送方之前注册了事件，QFramework的事件是即时触发的，订阅晚了就收不到；第二，确认事件类型完全一致，泛型参数不同会被当成两个事件；第三，确认订阅方没有被销毁，OnDestroy里注销了事件但对象还活着的情况很常见。

我的习惯是在事件发送处加一行日志，订阅处也加一行，跑一遍看哪边没打印。这个方法土但有效，比盯着代码猜快得多。

5.2 敌人多了之后帧率暴跌

性能问题基本出在三个地方：Instantiate/Destroy太频繁、每帧遍历全部敌人、伤害数字没有池化。前两个用对象池和列表缓存解决，第三个用飘字池。还有一个容易被忽略的点是碰撞检测，敌人之间如果开了物理碰撞，几百个敌人会直接把物理引擎压垮。类幸存者的敌人之间通常不需要物理碰撞，用前面说的分离力做视觉分离就够了。

5.3 升级后数值没生效

这个问题通常是数据读取时机的问题。如果你的武器在Start里把伤害值缓存到了本地变量，那词条改了Model里的值，武器读的还是旧值。正确做法是每次攻击时实时从Model读，或者监听UpgradeSelectedEvent主动刷新缓存。我倾向于实时读，虽然多几次属性访问，但不会出错。

5.4 游戏暂停后UI动画卡住

前面提过，Time.timeScale = 0会冻结所有用Time.deltaTime的东西。UI动画、粒子特效如果不想被冻结，统一改用Time.unscaledDeltaTime。但要注意，游戏逻辑绝对不能混用unscaled，否则暂停就失效了。我的做法是在项目初期就约定好：Scripts/Controllers下的逻辑用deltaTime，Scripts/UI下的动画用unscaledDeltaTime。

5.5 常见问题速查表

提示：QFramework的this.GetModel和this.GetSystem在Controller外部调用会报错，确保你的类实现了IController或者IBelongToArchitecture接口。

6. 从能跑到上架级别的几个关键提升

6.1 数值配置与热重载

能跑和好玩之间差的是数值调优。我建议把所有可调数值都抽到ScriptableObject里，配合QFramework的BindableProperty，运行时改数值立即生效。这样你调平衡的时候不用反复重启，效率提升非常明显。具体做法是Model里的字段用BindableProperty<T>，UI和逻辑监听它的变化。

6.2 存档与进度系统

上架级别的游戏需要存档。类幸存者的存档主要是：已解锁的角色、已解锁的武器、金币数量、成就进度。QFramework有IStorage接口，可以很方便地做本地存储。存档的时机我建议在每局结算后和退出游戏时各存一次，避免意外退出丢进度。

6.3 音效与打击感

打击感是类幸存者能不能留住玩家的关键。三个要素：受击闪白、屏幕震动、音效反馈。受击闪白用Shader或者简单的颜色叠加，屏幕震动用一个简单的相机偏移协程，音效要注意同时播放多个相同音效时的音量叠加问题，我的做法是限制同一音效的并发数量。

6.4 打包与发布注意事项

打包前记得检查：所有Debug.Log是否清理、Resources文件夹是否过大、图集是否合并、代码是否开启了IL2CPP。移动端还要注意分辨率和安全区域适配。发布AAB格式的话，在Player Settings里勾选对应的选项就行。

我个人在实际操作中的体会是，类幸存者这个品类，架构搭对了后面加内容就是填表格，架构搭错了每加一个武器都是一次折磨。QFramework帮你把最脏的那部分解耦工作做了，剩下的就是专心调手感和数值。这套流程走下来，一个能上架的类幸存者原型大概两到三周就能出来，剩下的时间全花在打磨上。最后再分享一个小技巧：每次加新武器或新词条之前，先想清楚它和现有系统的交互点在哪，如果发现需要改三个以上的系统才能加进去，那说明你的架构还有优化空间。