Merge branch 'master' of https://gitee.com/zzzisfunnyboy/obsidian-notes
# Conflicts: # .obsidian/workspace.json # 1Project/宠物宇宙/bug.md # 1Project/宠物宇宙/地图编辑器/需要支持的地图功能.md
This commit is contained in:
2
1Project/学习/GAS.md
Normal file
2
1Project/学习/GAS.md
Normal file
@@ -0,0 +1,2 @@
|
||||
|
||||
- [ ] 创建一个示例项目
|
||||
@@ -1,8 +1,5 @@
|
||||
|
||||
### GAS优先！！
|
||||
|
||||
- [ ] [焦虑、内耗、爱破防，真的是你的锅吗？硬核心理学让你从此掌控自我！-我要等到什么时候-稍后再看-哔哩哔哩视频](https://www.bilibili.com/list/watchlater?oid=114079968532107&bvid=BV1YM9gYdECb&spm_id_from=333.1007.top_right_bar_window_view_later.content.click)
|
||||
- [ ] [动作游戏框架05.扩展Timeline：使用组合，而非继承，来扩展Timeline的基础功能-我要等到什么时候-稍后再看-哔哩哔哩视频](https://www.bilibili.com/list/watchlater?oid=114522652147889&bvid=BV1HKJAzyEZ5&spm_id_from=333.1007.top_right_bar_window_view_later.content.click)
|
||||
- [ ] https://zhuanlan.zhihu.com/p/28352150798# Unity-SM节点式动画技能编辑器
|
||||
- [ ] [[Log插件]]
|
||||
- [ ] [[UE-CORE-002 TickTaskManager]]
|
||||
- [ ] https://zhuanlan.zhihu.com/p/28352150798# Unity-SM节点式动画技能编辑器
|
||||
40
1Project/宠物宇宙/地图编辑器/需要支持的小功能.md
Normal file
40
1Project/宠物宇宙/地图编辑器/需要支持的小功能.md
Normal file
@@ -0,0 +1,40 @@
|
||||
|
||||
|
||||
> [!important] 优先级 **1**
|
||||
|
||||
|
||||
- [x] 添加RoomComponents
|
||||
- [ ] IExtension
|
||||
- [ ] 生成怪物测试
|
||||
- [ ] id不再自增长
|
||||
- [x] 碰撞盒和标志需要添加自定义功能
|
||||
|
||||
- [ ] 地图地板图片导入 自动修改图片大小
|
||||
- [ ] 添加白膜地图
|
||||
- 创建100*100的地图，宽高跟随Rect大小变化
|
||||
|
||||
- [ ] 将RoomConfig改到==关卡表==里
|
||||
RoomConfig的内容为SpecialRoom
|
||||
- [ ] 碰撞盒需要添加旋转
|
||||
|
||||
|
||||
|
||||
> [!note] 优先级 **2**
|
||||
|
||||
- [ ] 枚举改为英文名
|
||||
- [ ] 瓦片地图
|
||||
- [ ] 优化重构
|
||||
[[需要做的优化]]
|
||||
|
||||
|
||||
> [!note] 优先级 **3**
|
||||
|
||||
- [ ] 提取单个地块编辑
|
||||
|
||||
> [!note] 优先级 **4**
|
||||
|
||||
- [ ] 过关门动画优化
|
||||
- [ ] 地图大背景优化移动方案
|
||||
|
||||
|
||||
|
||||
13
1Project/宠物宇宙/皮肤导入.md
Normal file
13
1Project/宠物宇宙/皮肤导入.md
Normal file
@@ -0,0 +1,13 @@
|
||||
|
||||
- [ ] 皮肤导入
|
||||
- [x] 上海限定 C:\Users\1\Desktop\cache\57015
|
||||
- 游戏中
|
||||
- [x] C:\Users\1\Desktop\cache\红/蓝/绿皮肤7.0
|
||||
- [ ] 胳膊导入
|
||||
- 结算
|
||||
- [x] C:\Users\1\Desktop\cache\角色胜利结算
|
||||
- 卡面
|
||||
- [x] C:\Users\1\Desktop\cache\第三弹裁切输出
|
||||
- UI名字
|
||||
- [ ] C:\Users\1\Desktop\cache\皮肤
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,405 +0,0 @@
|
||||
# 用户卡信息处理系统设计文档
|
||||
|
||||
## 1. 系统概述
|
||||
|
||||
该系统主要由控制器插件、业务插件和游戏端三部分组成，通过TCP通信实现用户卡信息处理和游戏数据收集。
|
||||
|
||||
## 2. 系统架构
|
||||
|
||||
### 字符流程图
|
||||
```
|
||||
+----------------+ +----------------+ +----------------+
|
||||
| 控制器插件 | | 业务插件 | | 游戏端 |
|
||||
| | | | | |
|
||||
| - 扫描用户卡 | | - 处理用户信息 | | - 接收用户信息 |
|
||||
| - 读取卡信息 |--->| - 存储本地数据 |<-->| - 发送游戏信息 |
|
||||
| - 通知业务插件 | | - 网络请求处理 | | - 本地备份处理 |
|
||||
+----------------+ +----------------+ +----------------+
|
||||
| ^
|
||||
v |
|
||||
+-----------------+
|
||||
| 服务器 |
|
||||
| - 用户资料数据库 |
|
||||
| - 游戏数据处理 |
|
||||
+-----------------+
|
||||
```
|
||||
|
||||
### mermaid流程图
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[控制器插件\n- 扫描用户卡\n- 读取卡信息\n- 通知业务插件] --> B[业务插件\n- 处理用户信息\n- 存储本地数据\n- 网络请求处理]
|
||||
B <--> C[游戏端\n- 接收用户信息\n- 发送游戏信息\n- 本地备份处理]
|
||||
B <--> D[服务器\n- 用户资料数据库\n- 游戏数据处理]
|
||||
```
|
||||
|
||||
## 3. 系统详细流程
|
||||
|
||||
### 3.1 用户卡信息处理流程
|
||||
|
||||
#### 流程说明
|
||||
用户卡信息处理流程描述了从控制器插件扫描用户卡到业务插件向游戏端发送用户信息的完整过程。当控制器插件检测到用户卡扫描信息后，会通知业务插件。业务插件根据网络状态决定从服务器请求用户资料或从本地数据库读取用户信息。如果网络可用，业务插件会请求最新的用户信息并存储到本地；如果网络不可用或请求失败，则从本地SQLite数据库读取历史记录；若本地无记录，则构造默认用户信息。最终，业务插件将完整的用户信息通过TCP（12101端口）发送给游戏端。
|
||||
|
||||
#### 字符流程图
|
||||
```
|
||||
+----------------+ +----------------+ +----------------+ +----------------+
|
||||
| 控制器插件 | | 业务插件 | | 网络/本地数据库 | | 游戏端 |
|
||||
+-------+--------+ +-------+--------+ +-------+--------+ +-------+--------+
|
||||
| | | |
|
||||
| 扫描到用户卡 | | |
|
||||
+--------------------->+ | |
|
||||
| | | |
|
||||
| | 检查网络状态 | |
|
||||
| +--------------------->+ |
|
||||
| | | |
|
||||
| | 有网络: 请求用户信息 | |
|
||||
| +--------------------->+ |
|
||||
| | | |
|
||||
| | 返回用户信息 | |
|
||||
| +<---------------------+ |
|
||||
| | | |
|
||||
| | 无网络/请求失败: | |
|
||||
| | 读取本地数据 | |
|
||||
| +--------------------->+ |
|
||||
| | | |
|
||||
| | 返回本地数据 | |
|
||||
| +<---------------------+ |
|
||||
| | | |
|
||||
| | 构造用户信息 | |
|
||||
| +-------------------------------------------------+
|
||||
| | | | |
|
||||
| | TCP(12101)发送用户信息| | |
|
||||
| +--------------------->+--------------------->+ |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | 本地存储用户信息 <---+
|
||||
| | | |
|
||||
+-------+--------+ +-------+--------+ +-------+--------+ +-------+--------+
|
||||
```
|
||||
|
||||
#### mermaid流程图
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant 控制器插件
|
||||
participant 业务插件
|
||||
participant 网络/本地数据库
|
||||
participant 游戏端
|
||||
|
||||
控制器插件->>业务插件: 扫描到用户卡
|
||||
业务插件->>网络/本地数据库: 检查网络状态
|
||||
|
||||
alt 有网络
|
||||
业务插件->>网络/本地数据库: 请求用户信息
|
||||
网络/本地数据库-->>业务插件: 返回用户信息
|
||||
else 无网络/请求失败
|
||||
业务插件->>网络/本地数据库: 读取本地数据
|
||||
网络/本地数据库-->>业务插件: 返回本地数据
|
||||
end
|
||||
|
||||
业务插件->>业务插件: 构造用户信息
|
||||
业务插件->>游戏端: TCP(12101)发送用户信息
|
||||
游戏端->>游戏端: 本地存储用户信息
|
||||
```
|
||||
|
||||
### 3.2 游戏信息收集流程
|
||||
|
||||
#### 流程说明
|
||||
游戏信息收集流程描述了业务插件如何通过TCP监听接收游戏端发送的消息并进行处理的过程。业务插件监听TCP（12103端口）以接收来自游戏端的信息。根据接收到的消息类型（由标识头区分），业务插件会进行不同的处理：如果是游戏结束消息（标识头为"game-over"），业务插件会更新对应Player的状态，之后接收到该Player的游戏信息将不再与用户卡关联；如果是游戏业务信息，业务插件会尝试通过网络将数据发送到服务器，若网络不可用或发送失败，则将数据存储到本地SQLite数据库中以便稍后同步。
|
||||
|
||||
#### 字符流程图
|
||||
```
|
||||
+----------------+ +----------------+ +----------------+
|
||||
| 游戏端 | | 业务插件 | | 服务器/本地存储 |
|
||||
+-------+--------+ +-------+--------+ +-------+--------+
|
||||
| | |
|
||||
| TCP(12103)发送游戏信息| |
|
||||
+--------------------->+ |
|
||||
| | |
|
||||
| | 检查消息类型 |
|
||||
| +-----------------+ |
|
||||
| | | |
|
||||
| | 游戏结束消息 | |
|
||||
| |-----------------+ |
|
||||
| | 更新Player状态 | |
|
||||
| +-----------------+ |
|
||||
| | | |
|
||||
| | 游戏业务信息 | |
|
||||
| |-----------------+ |
|
||||
| | 检查网络状态 | |
|
||||
| +--------------------->+
|
||||
| | |
|
||||
| | 有网络: 发送到服务器 |
|
||||
| +--------------------->+
|
||||
| | |
|
||||
| | 响应结果 |
|
||||
| +<---------------------+
|
||||
| | |
|
||||
| | 无网络/发送失败: |
|
||||
| | 存储到本地SQLite |
|
||||
| +--------------------->+
|
||||
| | |
|
||||
+-------+--------+ +-------+--------+ +-------+--------+
|
||||
```
|
||||
|
||||
#### mermaid流程图
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant 游戏端
|
||||
participant 业务插件
|
||||
participant 服务器/本地存储
|
||||
|
||||
游戏端->>业务插件: TCP(12103)发送游戏信息
|
||||
|
||||
alt 游戏结束消息
|
||||
业务插件->>业务插件: 更新Player状态
|
||||
else 游戏业务信息
|
||||
业务插件->>业务插件: 检查网络状态
|
||||
alt 有网络
|
||||
业务插件->>服务器/本地存储: 发送到服务器
|
||||
服务器/本地存储-->>业务插件: 响应结果
|
||||
else 无网络/发送失败
|
||||
业务插件->>服务器/本地存储: 存储到本地SQLite
|
||||
end
|
||||
end
|
||||
```
|
||||
|
||||
### 3.3 游戏信息发送失败处理流程
|
||||
|
||||
#### 流程说明
|
||||
游戏信息发送失败处理流程描述了当游戏端无法直接将游戏信息发送给业务插件时的备份处理机制。当游戏端向业务插件发送信息超时或无响应时，游戏端会将这些数据存储到特定目录中的文件系统，采用一条数据一个文件的方式。业务插件会定期检查该目录，读取这些文件中的数据，处理（如重新发送到服务器或记录到本地数据库）后再删除这些文件。这种机制确保了即使在业务插件暂时不可用的情况下，游戏数据也不会丢失，提高了系统的可靠性和容错性。
|
||||
|
||||
#### 字符流程图
|
||||
```
|
||||
+----------------+ +----------------+ +----------------+
|
||||
| 游戏端 | | 文件系统 | | 业务插件 |
|
||||
+-------+--------+ +-------+--------+ +-------+--------+
|
||||
| | |
|
||||
| 信息发送超时/无响应 | |
|
||||
+-----------------+ | |
|
||||
| | | |
|
||||
| 创建数据文件 | | |
|
||||
|----------------+ | |
|
||||
| 将数据写入文件 | | |
|
||||
+--------------------->+ |
|
||||
| | |
|
||||
| | 业务插件定期检查目录 |
|
||||
| +<---------------------+
|
||||
| | |
|
||||
| | 读取数据文件 |
|
||||
| +--------------------->+
|
||||
| | |
|
||||
| | 处理数据(重发/记录) |
|
||||
| +<---------------------+
|
||||
| | |
|
||||
| | 处理完成后删除文件 |
|
||||
| +<---------------------+
|
||||
| | |
|
||||
+-------+--------+ +-------+--------+ +-------+--------+
|
||||
```
|
||||
|
||||
#### mermaid流程图
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant 游戏端
|
||||
participant 文件系统
|
||||
participant 业务插件
|
||||
|
||||
游戏端->>游戏端: 信息发送超时/无响应
|
||||
游戏端->>游戏端: 创建数据文件
|
||||
游戏端->>文件系统: 将数据写入文件
|
||||
业务插件->>文件系统: 定期检查目录
|
||||
文件系统->>业务插件: 读取数据文件
|
||||
业务插件->>业务插件: 处理数据(重发/记录)
|
||||
业务插件->>文件系统: 处理完成后删除文件
|
||||
```
|
||||
|
||||
## 4. 信息结构
|
||||
|
||||
### 4.1 发送给游戏的用户信息JSON结构
|
||||
|
||||
```json
|
||||
{
|
||||
"result": true, // 操作结果
|
||||
"errMsg": "", // 错误信息
|
||||
"statusCode": 0, // 状态码（0=成功，1=未绑定，2=无网）
|
||||
"tag": "user-info", // 标识标签，区分不同类型的信息
|
||||
"data": {
|
||||
"playerIndex": 1, // player索引
|
||||
"cardId": "123456", // 卡ID
|
||||
"cardSn": "789012", // 卡序列号
|
||||
"userName": "张三", // 用户名称
|
||||
"userAvatar": "http://example.com/avatar.jpg" // 用户头像
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### 4.1.1 请求服务器查询玩家资料
|
||||
请求写入排行榜
|
||||
```json
|
||||
{
|
||||
"tag": "update-user-info", // 标识标签，区分不同类型的信息
|
||||
"data": {
|
||||
"cardId": "123456", // 卡ID
|
||||
"score": 10000 //积分
|
||||
}
|
||||
}
|
||||
```
|
||||
回复
|
||||
```json
|
||||
{
|
||||
"result": true, // 操作结果
|
||||
"errMsg": "", // 错误信息
|
||||
"statusCode": 0, // 状态码（0=成功，1=未绑定，2=无网）
|
||||
"tag": "", // 标识标签，区分不同类型的信息
|
||||
"data":{}
|
||||
}
|
||||
```
|
||||
|
||||
请求查询玩家信息
|
||||
```json
|
||||
{
|
||||
"tag": "select-user-info", // 标识标签，区分不同类型的信息
|
||||
"data": {
|
||||
"cardId": "123456", // 卡ID
|
||||
}
|
||||
}
|
||||
```
|
||||
回复
|
||||
```json
|
||||
{
|
||||
"result": true, // 操作结果
|
||||
"errMsg": "", // 错误信息
|
||||
"statusCode": 0, // 状态码（0=成功，1=未绑定，2=无网）
|
||||
"tag": "user-info", // 标识标签，区分不同类型的信息
|
||||
"data": {
|
||||
"playerIndex": 1, // player索引
|
||||
"cardId": "123456", // 卡ID
|
||||
"cardSn": "789012", // 卡序列号
|
||||
"userName": "张三", // 用户名称
|
||||
"userAvatar": "http://example.com/avatar.jpg" // 用户头像
|
||||
...
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 4.2 游戏结束消息JSON结构
|
||||
|
||||
```json
|
||||
{
|
||||
"result": true, // 操作结果
|
||||
"errMsg": "", // 错误信息
|
||||
"statusCode": 0, // 状态码（0=成功，非0=失败）
|
||||
"tag": "game-over", // 标识标签
|
||||
"data": {
|
||||
"playerIndex": 1, // player索引
|
||||
"cardId": "123456", // 卡ID
|
||||
"timestamp": 1634567890 // 时间戳
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 4.3 游戏业务信息JSON结构
|
||||
|
||||
```json
|
||||
{
|
||||
"result": true, // 操作结果
|
||||
"errMsg": "", // 错误信息
|
||||
"statusCode": 0, // 状态码（0=成功，非0=失败）
|
||||
"tag": "game-data", // 标识标签
|
||||
"data": {
|
||||
"playerIndex": 1, // player索引
|
||||
"cardId": "123456", // 卡ID
|
||||
"gameData": { // 游戏数据（根据具体业务定义）
|
||||
// 具体业务数据
|
||||
},
|
||||
"timestamp": 1634567890 // 时间戳
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 5. 通信端口说明
|
||||
|
||||
- **12101端口**：游戏端监听，业务端发送消息
|
||||
- **12103端口**：业务端监听，游戏端发送消息
|
||||
|
||||
## 6. 数据持久化
|
||||
|
||||
### 6.1 SQLite数据结构
|
||||
|
||||
#### 用户信息表
|
||||
```sql
|
||||
CREATE TABLE user_info (
|
||||
id INTEGER PRIMARY KEY AUTOINCREMENT,
|
||||
card_id TEXT NOT NULL,
|
||||
card_sn TEXT NOT NULL,
|
||||
user_name TEXT,
|
||||
user_avatar TEXT,
|
||||
last_updated INTEGER,
|
||||
UNIQUE(card_id, card_sn)
|
||||
);
|
||||
```
|
||||
|
||||
#### 游戏数据表
|
||||
```sql
|
||||
CREATE TABLE game_data (
|
||||
id INTEGER PRIMARY KEY AUTOINCREMENT,
|
||||
card_id TEXT NOT NULL,
|
||||
player_index INTEGER NOT NULL,
|
||||
data_type TEXT NOT NULL,
|
||||
data_content TEXT NOT NULL,
|
||||
timestamp INTEGER NOT NULL,
|
||||
is_synced INTEGER DEFAULT 0
|
||||
);
|
||||
```
|
||||
|
||||
### 6.2 文件存储结构
|
||||
|
||||
游戏数据文件命名格式：`game_data_{timestamp}_{playerIndex}_{cardId}.json`
|
||||
|
||||
## 7. 注意事项
|
||||
|
||||
### 7.1 数据安全与隐私
|
||||
|
||||
- 用户卡信息应进行加密存储
|
||||
- 本地数据应设置访问权限限制
|
||||
- 网络传输过程采用HTTPS或加密通道
|
||||
|
||||
### 7.2 数据同步机制
|
||||
|
||||
- 本地数据与服务器数据定期同步机制
|
||||
- 冲突解决策略（以服务器数据为准或采用时间戳）
|
||||
- 同步频率设置（定时/事件触发）
|
||||
|
||||
### 7.3 错误处理与恢复
|
||||
|
||||
- 网络恢复后的数据自动上传机制
|
||||
- 重试策略（指数退避算法）
|
||||
- 错误日志记录与报警机制
|
||||
- 异常情况下的回滚机制
|
||||
|
||||
### 7.4 性能优化
|
||||
|
||||
- SQLite查询优化
|
||||
- 批量数据处理
|
||||
- 队列机制避免并发问题
|
||||
- 异步处理大量数据
|
||||
|
||||
### 7.5 本地存储管理
|
||||
|
||||
- 定期清理过期数据
|
||||
- 存储空间监控
|
||||
- 数据备份机制
|
||||
- 存储空间不足时的处理策略
|
||||
|
||||
### 7.6 监控与日志
|
||||
|
||||
- 关键操作日志记录
|
||||
- 系统状态监控
|
||||
- 异常情况报警机制
|
||||
|
||||
## 8. 系统扩展性考虑
|
||||
|
||||
- 支持多种类型用户卡的可扩展接口
|
||||
- 业务消息类型的可扩展设计
|
||||
- 版本兼容性处理机制
|
||||
- 插件化架构设计
|
||||
- 配置化管理
|
||||
@@ -1,153 +0,0 @@
|
||||
---
|
||||
tags:
|
||||
- Buff
|
||||
---
|
||||
|
||||
source:[(2 封私信 / 4 条消息) 如何实现一个强大的MMO技能系统——BUFF - 知乎](https://zhuanlan.zhihu.com/p/150812545?utm_psn=1894773352150832417)
|
||||
|
||||
---
|
||||
|
||||
## 前言
|
||||
|
||||
Buff模块可以说是技能中最核心又最复杂的系统了。一个优秀的[Buff系统](https://zhida.zhihu.com/search?content_id=121646042&content_type=Article&match_order=1&q=Buff%E7%B3%BB%E7%BB%9F&zhida_source=entity)能够让策划的创意得到最大限度的发挥，大幅增强游戏的战斗深度和可玩性，并且同时也能让开发者轻易的扩展维护，支持更多的效果和功能。本章将为你详细讲述一个强大的Buff系统是如何实现的。（长文预警）
|
||||
|
||||
## 正文
|
||||
|
||||
### 第一节：Buff定义
|
||||
|
||||
首先我们将Buff系统分为三个层次，具体继承关系如下：
|
||||
|
||||
|
||||
|
||||
**Buff：**所有Buff的基类，包含各类成员函数和基本接口。
|
||||
|
||||
**[Modifier](https://zhida.zhihu.com/search?content_id=121646042&content_type=Article&match_order=1&q=Modifier&zhida_source=entity)：**继承于Buff，代表这个Buff是一个修改器，它可以用来修改当前目标的各种属性，状态等等。抽象Modifier这个类的目的是出于性能优化的考虑。因为当Buff修改角色的属性或者状态时，会导致重新计算角色的动态属性， 而在游戏中我们很多的Buff并不需要修改角色的属性状态，仅仅用来提供一段逻辑。那么如果它是一个Buff不是Modifier，就不需要重新计算角色的动态属性。
|
||||
|
||||
**[MotionModifier](https://zhida.zhihu.com/search?content_id=121646042&content_type=Article&match_order=1&q=MotionModifier&zhida_source=entity)：**继承于Modifier，代表此类Buff提供修改玩家运动效果的功能。因为牵涉到与运动组件的交互，所以抽象出一个新的类。
|
||||
|
||||
Buff类层次结构划分了之后，那么Buff需要包含那些成员数据呢？
|
||||
|
||||
我们提供BuffTypeId(Buff类型Id)， **Caster**（Buff施加者），Parent（Buff当前挂载的目标）, **Ability**(Buff由哪个技能创建)，BuffLayer（层数）, BuffLevel（等级）BuffDuration（时长），**BuffTag，BuffImmuneTag（免疫BuffTag）**以及**Context**(Buff创建时的一些相关上下文数据)等等。
|
||||
|
||||
在这里，我将说明一下Caster，Ability以及Context这三个成员，这也可能是我们Buff系统中一些独特的点。
|
||||
|
||||
**Caster代表Buff的施加者**，它有可能为空，也有可能不为空，视具体构造时是否传Caster参数而定。但是Buff有一个配置项bNoCaster（是否强制设置Caster为空）。**如果bNoCaster = true。则Buff的Caster一定为空。**
|
||||
|
||||
为什么要有一个bNoCaster设置呢？那是因为**我们的Caster不仅仅是一个成员项，它还关系到Buff合并问题。**如果存在两个TypeId类型相同的Buff时候，当他们的Caster相同才可以走合并流程（Buff层数增加），如果Caster不同，则不能合并。**当策划有一些玩法需求可以多人给BOSS叠Buff时就可以配置Buff的bNoCaster=true，**这样就不需要开发者在写代码添加Buff的时候小心翼翼的设置Caster参数为空了。另外还有几种情况也需要设置bNoCaster=true，比如存在一个熔岩地图，或者冰雪地图，玩家每秒掉多少血量，这个时候也可以配置bNoCaster=true。再比如说一些活动buff，如双倍经验buff，红名惩罚buff，都可以由策划配置bNoCaster=true。类似于双倍经验，还有红名Buff这种**所有需要存盘的Buff，我们都需要设置bNoCaster=true。**也许会有人有疑问，这样能满足需求吗？完全可以，我会在最后的示例部分举出一个例子来解答这个疑问。
|
||||
|
||||
**Ability代表Buff是由哪个技能创建**，它有可能为空，也有可能不为空，视具体构造时是否传Ability参数而定。通过Ability这个成员类型，我们就将Buff与技能联系起来了，我们能在Buff中取得技能的各种数据，通过获取技能的数据，然后由Buff来实现各种各样的技能效果。
|
||||
|
||||
**BuffTag，BuffImmuneTag由策划配置(基于标记位），标注这个Buff属于那些种类以及免疫哪些种类。**策划可以定义一些Tag如下：
|
||||
|
||||
1. Metal = 1 << 1 （金系）
|
||||
2. Wood = 1 << 2（木系）
|
||||
3. Water = 1 << 3（水系）
|
||||
4. Fire = 1 << 4（火系）
|
||||
5. Earth = 1 << 5（土系）
|
||||
|
||||
当策划配置BuffTag为Meta | Wood时，则代表这个Buff归属为金系和木系Buff。如果策划配置BuffImmuneTag为Wood | Fire时，则代表这个Buff可以免疫所有木系和火系Buff。由于Tag的实际定义由策划控制，策划可以根据他们的需求组合出各种各样的免疫效果。我将在后面的示例里面描述一些基于Tag和ImmuneTag用法的例子来让读者体会Tag和ImmuneTag者两个概念抽象的简洁之美。
|
||||
|
||||
**Context代表Buff创建时候的一些上下文数据**，它是一个不确定的项，通过外部传入各种自定义的数据，然后在Buff逻辑中使用这些自定义数据。
|
||||
|
||||
### 第二节：Buff执行流程
|
||||
|
||||
在Buff从创建到销毁的过程中，我们划分为如下几个阶段：
|
||||
|
||||
1. Buff创建前检查当前Buff是否可创建。一般主要是检测目标身上是否存在免疫该Buff的相关Buff，如果被免疫则不会创建该Buff。
|
||||
2. Buff在实例化之后，生效之前（还未加入到Buff容器中）时会抛出一个**[OnBuffAwake](https://zhida.zhihu.com/search?content_id=121646042&content_type=Article&match_order=1&q=OnBuffAwake&zhida_source=entity)**事件。如果存在某种Buff的效果是：受到负面效果时，驱散当前所有负面效果，并给自己加一个护盾。那么这个时候就需要监听BuffAwake事件了，此时会给自己加护盾，并且把所有负面Buff驱散。**这意味着一个Buff可能还未生效之前即销毁了（小心Buff的生命周期）。**
|
||||
3. 当Buff生效时（加入到Buff容器后），我们提供给策划一个抽象接口**[OnBuffStart](https://zhida.zhihu.com/search?content_id=121646042&content_type=Article&match_order=1&q=OnBuffStart&zhida_source=entity)**，由策划配置具体效果。
|
||||
4. 当Buff添加时存在相同类型且Caster相等的时候，Buff执行刷新流程（更新Buff层数，等级，持续时间等数据）。我们提供给策划一个抽象接口**[OnBuffRefresh](https://zhida.zhihu.com/search?content_id=121646042&content_type=Article&match_order=1&q=OnBuffRefresh&zhida_source=entity)**，由策划配置具体效果。
|
||||
5. 当Buff销毁前（还未从Buff容器中移除），我们提供给策划一个抽象接口**[OnBuffRemove](https://zhida.zhihu.com/search?content_id=121646042&content_type=Article&match_order=1&q=OnBuffRemove&zhida_source=entity)**，由策划配置具体效果。
|
||||
6. 当Buff销毁后（已从Buff容器中移除），我们提供给策划一个抽象接口**[OnBuffDestroy](https://zhida.zhihu.com/search?content_id=121646042&content_type=Article&match_order=1&q=OnBuffDestroy&zhida_source=entity)**，由策划配置具体效果。
|
||||
7. Buff还可以创建定时器，以触发间隔持续效果。通过策划配置时调用**StartIntervalThink**操作，提供**OnIntervalThink**抽象接口供策划配置具体效果。
|
||||
8. Buff还可以通过请求改变运动来触发相关效果。通过策划配置时调用**ApplyMotion**操作，提供**[OnMotionUpdate](https://zhida.zhihu.com/search?content_id=121646042&content_type=Article&match_order=1&q=OnMotionUpdate&zhida_source=entity)**和**[OnMotionInterrupt](https://zhida.zhihu.com/search?content_id=121646042&content_type=Article&match_order=1&q=OnMotionInterrupt&zhida_source=entity)**接口供策划配置具体效果。
|
||||
|
||||
Buff由于其有着生命周期可控，低耦合（通过监听事件修改逻辑），高内聚、易于扩展的特性，因此通过使用Buff来管理逻辑的话，不仅方便处理各种复杂的行为，同时还能有效的减少开发者的维护难度。
|
||||
|
||||
例如延迟触发伤害是游戏中非常常见的需求，在一些开发者的设计中就是直接给角色挂个定时器触发伤害。简单的游戏里这样做没什么大问题，但是如果技能逻辑稍微复杂点，这样就会带来很多问题。例如某天策划提出需求，如果受到控制效果时需要取消该延迟伤害。此时你怎么办，直接干掉timer？结果策划过了两天又提出了个新的需求，还是受到控制效果时，需要这个延迟伤害立即触发，你又怎么办？再又比如说，当角色受到伤害超过1000点时，这个延迟伤害立即触发，你又该怎么做？
|
||||
|
||||
这里就体现出Buff的方便之处了，我们可以直接添加一个持续时间为N秒的Buff。Buff销毁时触发伤害。如果需求变更为受到控制时取消伤害，那么我们就在Buff中检查当前是否包含有Tag为Control的Buff。如果有，则设置Buff.bTriggerDamage=false，同时自我销毁。然后在BuffDestroy触发的时候检查是否触发伤害，如果bTriggerDamage为false则不触发伤害。同理，当需求为Buff监听伤害超过1000点伤害立即触发时，我们只需要通过Buff监听OnTakeDamage事件，检查当前受到的伤害值是否大于1000点，如果是则销毁Buff，此时立即触发BuffDestroy并执行伤害效果。
|
||||
|
||||
从上面的例子我们可以看出整个控制逻辑都是在Buff内部完成的，不需要各种手动开启/取消定时器。只需要Buff扩展下逻辑检查即可，具有非常好的扩展性和高内聚性。
|
||||
|
||||
### 第三节：Buff修改状态（ModifyState)
|
||||
|
||||
Buff可以通过修改状态去影响角色行为逻辑。以下列举一些最常见的状态：
|
||||
|
||||
1. Stun（眩晕状态——目标不再响应任何操控）
|
||||
2. Root（缠绕，又称定身——目标不响应移动请求，但是可以执行某些操作，如施放某些技能）
|
||||
3. Silence （沉默——目标禁止施放技能）
|
||||
4. Invincible (无敌——几乎不受到所有的伤害和效果影响）
|
||||
5. Invisible (隐身——不可被其他人看见）
|
||||
|
||||
这些状态是高度凝练的精华，抽象到极致的代表。**非常多的游戏效果实际上都是这几种状态+运动+动画的组合。**这里很多开发者都会有一个**设计误区**就是**把Buff的状态跟运动和动画耦合在一块**，比如：眩晕状态一定就是播个眩晕动画，然后击退状态就是击退位移+击退动画。这样最后导致的问题就是状态膨胀，而且各种逻辑耦合，Bug频出，最后维护成本大大提高。
|
||||
|
||||
以Stun为例，很多人第一眼看过去就觉得它是个Debuff，是个敌人给我方加的控制Buff。实际上并非如此，Stun可以用到的地方非常多。例如有个技能是野蛮冲撞，释放后2秒内向前移动10米并将敌人推开。那这个Buff的实现就是技能Spell的时候给角色加个Buff，这个Buff会有个Stun状态同时带位移突进效果。挂上这个Buff后，技能施放后角色2秒内就不会响应角色按键移动和释放其他技能的请求了，同时往前突进的效果由Buff控制，将来处理各种位移打断效果也很方便。 再比如说有个技能叫寒冰屏障：你被一道寒冰屏障所笼罩，在十秒内不会受到任何物理和法术伤害，但这期间无法移动、攻击或施法。那这个技能的实现也很简单，就是一个十秒的Buff同时添加了眩晕和无敌这两个状态，如果还需要每秒回血，则StartIntervalThink(interval)，然后OnIntervalThink的时候Heal当前角色即可。
|
||||
|
||||
除了各类战斗效果之外，我们的Buff甚至可以扩展到一些其他场景。比如说打BOSS前有个播过场动画的需求，此时策划希望隐藏Boss和玩家的血条和姓名。那么此时我们完全可以做个Buff，这个Buff扩展个状态HideHpBar，当有这个状态时即隐藏血条和名字就行了。而且我们还可以让这个Buff加上无敌状态，毕竟播过场动画的时候我们不希望玩家或者BOSS真的受到什么伤害。
|
||||
|
||||
总而言之，Buff状态除了上面提到几种高度凝练抽象的状态外，我们还可以根据具体游戏的需求去扩展各种特殊状态，以满足策划的需求，同时方便开发者管理逻辑。
|
||||
|
||||
### 第四节：Buff修改属性(ModifyAttribute)
|
||||
|
||||
在游戏中Buff的添加与移除是一个频繁的过程。而玩家的属性来源有很多，如等级，装备，成就，任务，时装等等各种各样的来源。相比于Buff，这些模块修改属性的频率要远低于Buff，所以我们一般将玩家的属性划分为两层，第一层时Core（核心层），第二层是External（外部层）。Core层是玩家各个其他模块的属性总和，而External层则是Buff修改属性的总和。两者相加既为玩家的实时属性。
|
||||
|
||||
### 第五节：Buff修改运动(ModifyMotion)
|
||||
|
||||
现在的MMO中为了增加动作表现力，经常会有很多位移效果，如突进，翻滚，千斤坠，击退，击飞，拖拽，吸引等等。那么这些效果该如何实现呢？而且有时候会遇到各种复杂的运动打断效果，比如击飞时不能被击退，击飞过程又能被冰冻效果定住，然后又有破冰技能击退冰冻物体并解除冰冻效果。面对这些复杂的情况，我们该如何设计呢？
|
||||
|
||||
在我们的系统中，运动都是统一通过MovementComponent来管理。因此通过使用MotionModifier来与MovementComponent交互。MovementComponent中有一个CustomMotion，用来具体实现各种运动位移。具体运动实现相关细节我们将在后面的运动章节讲述。
|
||||
|
||||
在MotionModifier中，**我们会提供一个接口ApplyMotion(motionTypeId，priority, forceInterrupt)来向运动组件请求运动效果。**同时通过设置回调UpdateBeforeMovement和UpdateAfterMovement来触发运动前和运动后的Buff效果。下面我们初步介绍下ApplyMotion函数的三个参数：
|
||||
|
||||
- motionTypeId：运动类型id，配置项。包含运动位移参数及相关数据。
|
||||
- priority：运动优先级，每个运动都有优先级，低优先级不能打断高优先级。
|
||||
- forceInterrrupt：是否忽略优先级，强制打断当前的Motion。
|
||||
|
||||
通过这三个参数，我们就能实现各类打断需求了。
|
||||
|
||||
比如说击退的运动优先级是100，击飞的运动优先级是200。那么在击飞过程中，施加击退Buff调用ApplyMotion的时候会返回false，这时可以销毁掉这个击退Buff，即击飞时无法击退。如果击飞时被冰冻，且冻在半空中停止不动，那么我们就需要设计一个静止Buff：运动优先级是300，作用效果是速度设置为0，不受重力影响，同时修改Stun状态并挂载冰冻特效。当破冰技消除冰冻效果时，则设置破冰Buff的位移效果为击退，设置运动优先级为100，forceInterrupt为true。此时ApplyMotion强制打断运动，冰冻Buff会触发OnMotionInterrupt回调，在此接口中冰冻Buff自我销毁即可。
|
||||
|
||||
**Buff修改运动仅代表修改运动轨迹。**比如说击退仅仅只是以直线移动一段距离。而击飞是以曲线移动一段距离。同理**轻功的翻滚，突刺其实都与击退是相同的运动轨迹。**他们都是在一定的时间内以直线到达目标地点，且都设置Stun状态。它们不一样的地方其实仅仅只是动画层的表现的不同。（可能策划还会设置不同的Tag和ImmuneTag标记下）
|
||||
|
||||
**我们要牢牢记住，玩家看起来各种花哨的轻功击退击飞等位移效果实际上是State+Motion+Animation的组合。**掌握住了这一点，我们就可以通过简单的组合实现各种丰富的效果了，而不会被各种花哨的效果所迷惑，以为他们都是不一样的效果，导致最后设计出无比庞杂且难以维护的系统了。
|
||||
|
||||
### 第六节：Buff监听事件
|
||||
|
||||
Buff可以通过监听各类事件，执行特定逻辑或者修改事件数据来实现各种效果。
|
||||
|
||||
最常见的事件监听一般有：
|
||||
|
||||
- **OnAbilityExecuted，监听某个主动技能执行成功。**常用于被动技能Buff，比如说角色施法时有10%概率获得30%的攻速提升。那么我们通常是Buff-A监听OnAbilityExcuted事件，然后10%概率添加Buff-B。Buff-B的作用是修改玩家属性，增加30%攻速。
|
||||
- **OnBeforeGiveDamage，OnAfterGiveDamage监听我方给目标造成伤害时触发。**比如说对目标造成的伤害有10%概率无法被闪避，那么这个效果我们就可以通过监听OnBeforeGiveDamage的流程来实现。当执行伤害流程时，在计算伤害前我们抛出一个事件event。event里面有当前伤害数据。Buff在调用OnBeforeGiveDamage(event)时，修改event.Damage.DamageFlag |= DamageFlag_NotMiss，标注该伤害无法被闪避就行了。又或者如果有一个需求是给目标造成伤害后有10%几率触发DOT伤害效果，那么我们在OnAfterGiveDamage的时候取出event.Target并给这个目标加个DOT类Buff即可。
|
||||
- **OnBeforeTakeDamage，OnAfterTakeDamage监听我方受到伤害时触发。**如护盾类Buff通常在OnBeforeTakeDamage的时候修改伤害数据。又或者有某些Buff在受到伤害后可以触发各类效果就可以通过监听OnAfterTakeDamage事件来触发指定逻辑。
|
||||
- **OnBeforeDead，OnAfterDead监听我方死亡时触发。**如免疫致死效果可以通过监听OnBeforeDead事件修改角色当前的Hp>0，从而让角色提前退出死亡流程以避免死亡。死亡后触发额外效果，如爆炸或者召唤其他生物都可以通过监听OnAfterDead事件来执行。
|
||||
- **OnKill事件，监听我方击杀目标时触发。**如当击杀目标后获得治疗效果回复即可通过监听到Kill事件时给自己加一个HOT的Buff来实现。
|
||||
|
||||
开发者可以通过扩展各类事件列表，让Buff通过监听对应事件就能执行任意逻辑。不需要与任何模块耦合，只需要抛出事件，监听事件，执行逻辑即可获得Buff功能上的扩展。
|
||||
|
||||
## 总结
|
||||
|
||||
以上我们通过六个小节讲述了Buff系统主要模块的实现方法。通过这样的设计，我们让Buff的深度和扩展性都能够得到了极大的提升，几乎能实现各种各样的效果。足以让策划的创意得到最大限度的发挥。
|
||||
|
||||
## 示例
|
||||
|
||||
为了让读者便于直观理解，我会提出一些具体实现的例子以供参考：
|
||||
|
||||
- 问：Buff互斥效果也很常见，怎么做？
|
||||
- 答：BuffTag和BuffImmuneTag可轻松实现。比如说火系Buff和水系Buff互斥。无论策划的需求是存在水系Buff的时候无法添加火系Buff，还是存在水系Buff的时候添加火系Buff会驱散水系Buff都可以实现。第一种情况最简单，水系Buff配置Tag 为Water的时候配置ImmuneTag为Fire。此时存在水系Buff的时候即可免疫火系Buff了。第二中情况也好办。配置BuffTag为Water。当OnBuffStart的时候调用驱散接口DispelByTag(Water)，驱散掉所有火系Tag相关Buff即可。
|
||||
|
||||
|
||||
|
||||
- 问：霸体效果怎么实现，而且假如说存在破霸体效果又怎么实现，而且Boss的霸体效果完全不受影响又怎么实现？万一还存在特殊效果可以让Boss受到控制怎么办？
|
||||
- 答：我们可以定义两个BuffTag：WeakControl（弱控制）和StrongControl(强控制），普通霸体效果通过Buff配置ImmuneTag：WeakControl即可免疫控制效果。如果是破霸体效果，我们给这个Buff的Tag标记StrongControl就行，同时Boss的Buff配置ImmuneTag为WeakControl | StrongControl（免疫弱控制和强控制）就满足需求了。如果存在某个特殊的效果能让Boss受到控制效果的话，那这个Buff的Tag不要标记WeakControl和StrongControl就行了，这样它就无法被免疫掉了。看起来复杂的霸体破霸体效果实际实现就这么简单，就这么清晰，不需要引入任何新的系统。
|
||||
|
||||
|
||||
|
||||
- 问：Buff存盘那块如何处理跟施法者相关的属性数据？如施法者可以给目标添加一个强力的毒Buff，具体伤害数值有施法者属性决定，离线后依旧生效，直到Buff时间结束才移除。
|
||||
- 答：这块我们的处理依旧很简单，Buff依然设置bNoCaster=true。但是在Buff创建的Context里面我们设置Context.DamageValue为根据施法者属性计算出来的伤害数值。然后Buff持续造成伤害的时候直接取Context.DamageValue即可。至于说想要玩家离线再上线，Caster离线再上线后，毒的伤害数值还能实时修改的话，这样的需求是不存在的，如果一定要做，当然也能做，只是麻烦一点而且也没有必要。这样的需求一般仅仅存在测试的大脑中，策划是不会有这样的玩法需求了。
|
||||
|
||||
|
||||
|
||||
- 问：常见的基于指定地点延迟触发的AOE效果怎么实现？当技能施法成功后就延迟触发，不会被打断AOE效果。（如果能被打断，我们可以用引导类技能轻松实现）
|
||||
- 答：我们将技能标记为可指定目标地点释放，当技能Spell的时候我们先给自己加一个Buff，这个Buff仅仅用于延迟效果（当然可以有更多的可能性，如监听到某种事件立即结束并触发AOE效果），当Buff持续时间到了的时候在OnBuffDestroy的时候创建AOE效果Buff。这个AOE Buff会调用StartIntervalThink函数，在OnIntervalThink的时候通过Buff:GetAbility():GetCastPosition()为基准位置检查周围的敌方单位是否在AOE半径内，如果是，则施加作用效果。
|
||||
6
1Project/构建新框架/MVVM/扩展其他组件.md
Normal file
6
1Project/构建新框架/MVVM/扩展其他组件.md
Normal file
@@ -0,0 +1,6 @@
|
||||
|
||||
- [ ] 扩展嵌套列表
|
||||
|
||||
- [ ] 类型Switch
|
||||
- Button:
|
||||
- 需要加入OnClicked绑定命令
|
||||
11
1Project/炮弹互攻/RoadMap.md
Normal file
11
1Project/炮弹互攻/RoadMap.md
Normal file
@@ -0,0 +1,11 @@
|
||||
|
||||
- [ ] 玩家控制器
|
||||
- 动画
|
||||
- 炮弹生成
|
||||
- 集中特效
|
||||
- [ ] 敌人生成寻路攻击
|
||||
- 生成点
|
||||
- 寻路运动
|
||||
- 攻击
|
||||
- 毁灭
|
||||
- 动画
|
||||
Reference in New Issue
Block a user