1
This commit is contained in:
3
.obsidian/app.json
vendored
3
.obsidian/app.json
vendored
@@ -1,5 +1,6 @@
|
||||
{
|
||||
"promptDelete": false,
|
||||
"attachmentFolderPath": "渲染/软渲染/图片",
|
||||
"alwaysUpdateLinks": true
|
||||
"alwaysUpdateLinks": true,
|
||||
"showLineNumber": false
|
||||
}
|
||||
91
.obsidian/workspace.json
vendored
91
.obsidian/workspace.json
vendored
@@ -4,11 +4,25 @@
|
||||
"type": "split",
|
||||
"children": [
|
||||
{
|
||||
"id": "f8022c29023d2af6",
|
||||
"id": "1890c7ad64a39d65",
|
||||
"type": "tabs",
|
||||
"children": [
|
||||
{
|
||||
"id": "efa82152d99167ff",
|
||||
"id": "3e6f0931816b44e6",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "markdown",
|
||||
"state": {
|
||||
"file": "1Project/开发文章/将开发文章阅读并分类.md",
|
||||
"mode": "source",
|
||||
"source": false
|
||||
},
|
||||
"icon": "lucide-file",
|
||||
"title": "将开发文章阅读并分类"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "e0316e2f70484fe5",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "markdown",
|
||||
@@ -21,7 +35,8 @@
|
||||
"title": "需要做的优化"
|
||||
}
|
||||
}
|
||||
]
|
||||
],
|
||||
"currentTab": 1
|
||||
}
|
||||
],
|
||||
"direction": "vertical"
|
||||
@@ -214,48 +229,50 @@
|
||||
"copilot:Open Copilot Chat": false
|
||||
}
|
||||
},
|
||||
"active": "3e6f0931816b44e6",
|
||||
"active": "e0316e2f70484fe5",
|
||||
"lastOpenFiles": [
|
||||
"1Project/宠物宇宙/地图编辑器/需要支持的小功能.md",
|
||||
"1Project/宠物宇宙/地图编辑器/地图工作流.canvas",
|
||||
"1Project/宠物宇宙/地图编辑器/需要做的优化.md",
|
||||
"1Project/宠物宇宙/皮肤导入.md",
|
||||
"1Project/宠物宇宙/地图编辑器/需要支持的地图功能.md",
|
||||
"1Project/宠物宇宙/版本需求.md",
|
||||
"1Project/开发文章/将开发文章阅读并分类.md",
|
||||
"1Project/战斗编辑器/参考文章/如何实现一个强大的MMO技能系统——BUFF.md",
|
||||
"1Project/战斗编辑器/参考文章",
|
||||
"1Project/战斗编辑器",
|
||||
"3Projects/UE/UE-CORE-002 TickTaskManager.md",
|
||||
"3Projects/Unity/Log插件/Log插件.md",
|
||||
"3Projects/UE",
|
||||
"3Projects/Unity/loxodon/loxodon-framework Public.md",
|
||||
"3Projects/Unity/Log插件",
|
||||
"1Project/宠物宇宙/硬件交互/用户卡及游戏信息处理过程设计文档.md",
|
||||
"1Project/宠物宇宙/硬件交互/业务插件（RTwoGameBusiness）TCP接口设计说明.md",
|
||||
"2Areas/哲学/目的论与原因论.md",
|
||||
"2Areas/哲学/他者贡献.md",
|
||||
"2Areas/健康/运动-拉伸/八段锦/八段锦.md",
|
||||
"2Areas/哲学",
|
||||
"2Areas/习惯养成/规范日常行为.md",
|
||||
"2Areas/如何记录笔记/笔记如何组织.md",
|
||||
"2Areas/如何记录笔记/段落标记.md",
|
||||
"2Areas/如何记录笔记/抓捕生活中的灵感.md",
|
||||
"2Areas/如何记录笔记/如何结束一个项目.md",
|
||||
"2Areas/如何记录笔记/如何开启一个项目.md",
|
||||
"2Areas/如何记录笔记/抓捕生活中的灵感.md",
|
||||
"2Areas/习惯养成",
|
||||
"2Areas/如何记录笔记",
|
||||
"InBox/loxodon-framework.md",
|
||||
"3Projects/Unity/loxodon",
|
||||
"3Projects/Unity",
|
||||
"3Projects",
|
||||
"InBox/网络同步.md",
|
||||
"InBox/obsidian右键扩展.md",
|
||||
"InBox/接口与抽象类区别.md",
|
||||
"InBox/【Unity插件 - 图标轮廓渲染插件 SDF Image - Quality UI Outlines and Shadow-哔哩哔哩】.md",
|
||||
"InBox/资源/资源导入.md",
|
||||
"InBox/编辑器/时间轴编辑器/Timeline TODO.canvas",
|
||||
"1Project/开发文章/将开发文章阅读并分类.md",
|
||||
"4Archives/宠物宇宙/用户卡及游戏信息处理过程设计文档.md",
|
||||
"2Areas/健康/运动-拉伸/八段锦",
|
||||
"4Archives/All in hole/查看UIGame代码.md",
|
||||
"4Archives/All in hole/还原材质球.md",
|
||||
"4Archives/All in hole/玩法.md",
|
||||
"InBox/编辑器/图片/Pasted image 20221025121100.png",
|
||||
"InBox/GAS",
|
||||
"1Project/宠物宇宙/bug.md",
|
||||
"4Archives/All in hole/编辑器.md",
|
||||
"1Project/宠物宇宙/未命名 1",
|
||||
"渲染/软渲染/图片/业务插件（RTwoGameBusiness）TCP接口设计说明.md",
|
||||
"InBox/网络/封装可扩展网络请求框架.md",
|
||||
"2Areas/提升效率/未命名.md",
|
||||
"渲染/软渲染/图片/img_v3_02n6_ff40a1a4-d813-45f7-b132-6f14a74cfd7g.jpg",
|
||||
"InBox/自动化生成文档/uml.md",
|
||||
"InBox/自动化生成文档/docfx.md",
|
||||
"InBox/战斗/输入框架/游戏输入框架的设计(基于Unity).md",
|
||||
"InBox/TODO.canvas",
|
||||
"渲染/软渲染/图片/Pasted image 20250609171235.png",
|
||||
"InBox/AI for Obsidian/20250315 - 测试 Obsidian+ AI 的能力边界/第五个用法｜成为插件助手/Dataview 插件/测试用文档/项目复盘会议.md",
|
||||
"InBox/AI for Obsidian/20250315 - 测试 Obsidian+ AI 的能力边界/第五个用法｜成为插件助手/Dataview 插件/测试用文档/项目A计划.md",
|
||||
"InBox/AI for Obsidian/20250315 - 测试 Obsidian+ AI 的能力边界/第五个用法｜成为插件助手/Dataview 插件/测试用文档/财务季度报告.md",
|
||||
"InBox/AI for Obsidian/20250315 - 测试 Obsidian+ AI 的能力边界/第五个用法｜成为插件助手/Dataview 插件/测试用文档/简易待办事项.md",
|
||||
"InBox/AI for Obsidian/20250315 - 测试 Obsidian+ AI 的能力边界/第五个用法｜成为插件助手/Dataview 插件/测试用文档/用户反馈分析.md",
|
||||
"InBox/AI for Obsidian/20250315 - 测试 Obsidian+ AI 的能力边界/第五个用法｜成为插件助手/Dataview 插件/测试用文档/每周例会记录.md",
|
||||
"InBox/AI for Obsidian/20250315 - 测试 Obsidian+ AI 的能力边界/第五个用法｜成为插件助手/Dataview 插件/测试用文档/技术架构设计.md",
|
||||
"InBox/AI for Obsidian/20250315 - 测试 Obsidian+ AI 的能力边界/第五个用法｜成为插件助手/Dataview 插件/测试用文档",
|
||||
"InBox/AI for Obsidian/20250315 - 测试 Obsidian+ AI 的能力边界/第四个用法｜成为对弈的棋手/正方观点/观点9.md.edtz",
|
||||
"InBox/AI for Obsidian/20250315 - 测试 Obsidian+ AI 的能力边界/第四个用法｜成为对弈的棋手/正方观点/观点8.md.edtz",
|
||||
"InBox/AI for Obsidian/20250315 - 测试 Obsidian+ AI 的能力边界/第四个用法｜成为对弈的棋手/正方观点/观点7.md.edtz",
|
||||
"InBox/AI for Obsidian/20250315 - 测试 Obsidian+ AI 的能力边界/第四个用法｜成为对弈的棋手/正方观点/观点6.md.edtz",
|
||||
"InBox/AI for Obsidian/20250315 - 测试 Obsidian+ AI 的能力边界/第四个用法｜成为对弈的棋手/正方观点/观点5.md.edtz",
|
||||
"InBox/渲染/软渲染/图片/Pasted image 20230613102109.png",
|
||||
"InBox/战斗/动作时间轴 随想.canvas",
|
||||
"InBox/渲染/GPU/Pasted image 20230413163234.png",
|
||||
"InBox/Mesh/图片/Pasted image 20221021171104.png",
|
||||
"InBox/渲染/软渲染/图片/Pasted image 20230613102109.png",
|
||||
|
||||
@@ -47,4 +47,3 @@
|
||||
二者相互引用且耦合
|
||||
|
||||
###### 先抽象工作流，在开始构建管道
|
||||
|
||||
|
||||
@@ -10,8 +10,8 @@
|
||||
- ![[img_v3_02n6_ff40a1a4-d813-45f7-b132-6f14a74cfd7g.jpg]]
|
||||
- [x] 松鼠异常
|
||||
|
||||
- [ ] 地图地板图片导入 自动修改图片大小
|
||||
- [ ] 添加白膜地图
|
||||
- [x] 地图地板图片导入 自动修改图片大小
|
||||
- [x] 添加白膜地图
|
||||
- 创建100 - 100的地图，宽高跟随Rect大小变化
|
||||
|
||||
- [x] 碰撞盒需要添加旋转
|
||||
|
||||
@@ -13,11 +13,13 @@
|
||||
- [x] C:\Users\1\Desktop\cache\第三弹裁切输出
|
||||
- UI名字
|
||||
- [x] C:\Users\1\Desktop\cache\皮肤
|
||||
- [ ] 枪械宠物UI导入
|
||||
- [x] 枪械宠物UI导入
|
||||
- [ ] 测试网络点数 开机检测
|
||||
- [ ] 地图编辑器 [[需要支持的地图功能]]
|
||||
- [ ] Boss立绘
|
||||
- [ ] C:\Users\1\Desktop\cache\雷鸟血条UI
|
||||
- [x] 地图编辑器 [[需要支持的地图功能]]
|
||||
- [x] Boss立绘
|
||||
- [x] C:\Users\1\Desktop\cache\雷鸟血条UI
|
||||
- [ ] 积分系统
|
||||
- [ ]
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -3,4 +3,6 @@
|
||||
|
||||
- [ ] [焦虑、内耗、爱破防，真的是你的锅吗？硬核心理学让你从此掌控自我！-我要等到什么时候-稍后再看-哔哩哔哩视频](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节点式动画技能编辑器
|
||||
- [ ] https://zhuanlan.zhihu.com/p/28352150798# Unity-SM节点式动画技能编辑器
|
||||
- [ ] [[Log插件]]
|
||||
- [ ] [[UE-CORE-002 TickTaskManager]]
|
||||
153
1Project/战斗编辑器/参考文章/如何实现一个强大的MMO技能系统——BUFF.md
Normal file
153
1Project/战斗编辑器/参考文章/如何实现一个强大的MMO技能系统——BUFF.md
Normal file
@@ -0,0 +1,153 @@
|
||||
---
|
||||
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半径内，如果是，则施加作用效果。
|
||||
1949
3Projects/UE/UE-CORE-002 TickTaskManager.md
Normal file
1949
3Projects/UE/UE-CORE-002 TickTaskManager.md
Normal file
File diff suppressed because it is too large
Load Diff
153
3Projects/Unity/Log插件/Log插件.md
Normal file
153
3Projects/Unity/Log插件/Log插件.md
Normal file
@@ -0,0 +1,153 @@
|
||||
|
||||
source:[加Log就卡？不加Log就瞎？”——这个插件治好了我的精神内耗](https://mp.weixin.qq.com/s/Nii4fC15eKoNN8MOAzrmDQ)
|
||||
|
||||
---
|
||||
|
||||
|
||||
#
|
||||
|
||||
- 1 现有日志打印情况
|
||||
|
||||
|
||||
- 1 日志阻塞
|
||||
|
||||
- 2 从调试到生产，日志策略的抉择
|
||||
|
||||
|
||||
- 2 问题出现原因
|
||||
|
||||
|
||||
- 2.1 日志打印原理分析
|
||||
|
||||
- 2.2 log4j2 Disruptor 的初始化
|
||||
|
||||
- 2.3 队列满导致日志阻塞
|
||||
|
||||
- 2.4 产生的根本原因
|
||||
|
||||
|
||||
- 3 应对方案
|
||||
|
||||
|
||||
- 3.1 方案选择
|
||||
|
||||
- 3.2 技术选择
|
||||
|
||||
- 3.3 落地实现
|
||||
|
||||
|
||||
- 4 总结
|
||||
|
||||
|
||||
|
||||
|
||||
## 1 现有日志打印情况
|
||||
|
||||
日志作为软件工程实践中的重要基础设施，在系统监控、异常诊断及行为追溯等关键环节发挥着不可替代的作用。Apache Log4j2作为当前主流的日志框架，凭借其模块化架构和高度可扩展的特性，为开发者提供了灵活的多维度日志管理方案。然而若未能深入理解其异步日志机制、缓冲区策略等核心原理，或存在配置参数与业务场景匹配度不足等问题，则可能导致日志I/O阻塞、内存资源过度消耗等负面效应，甚至引发严重的服务性能瓶颈。因此，在实际工程实践中需遵循科学合理的使用准则，通过日志分级管理、输出格式优化、滚动策略定制等手段，方能充分发挥其技术优势，有效规避潜在风险。
|
||||
|
||||
### 1 日志阻塞
|
||||
|
||||
日志导致线程Block的问题，相信你或许已经遇到过，对此应该深有体会；或许你还没遇到过，但不代表没有问题，只是可能还没有触发而已。常见的现象是出现大量的block线程，查看jstack常常是下图现象：
|
||||
|
||||
### 2 从调试到生产，日志策略的抉择
|
||||
|
||||
在软件项目的全生命周期中，从开发阶段到生产环境的演进过程中，日志管理往往面临着微妙的平衡。开发阶段我们倾向于采用详尽的日志策略：业务接口的入参出参被完整记录，跨系统的调用链路被清晰标注，甚至非核心逻辑的辅助性信息也得以留存——这些详实的日志如同开发者的双目，为联调排障与功能验证提供了不可或缺的洞察。
|
||||
|
||||
然而当服务迈向生产环境时，过度日志带来的问题便逐渐显现。冗余的调试信息不仅会影响系统性能，更可能淹没真正关键的业务轨迹。尽管我们尝试在上线前进行日志裁剪，但总存在令人踌躇的灰色地带：某些开发期辅助日志是否暗含未来的诊断价值？那些看似非核心的流程记录会否在某个异常场景下成为关键线索？这种取舍的困境，本质上反映了我们对系统可观测性与运行效能之间永续的权衡。
|
||||
|
||||
## 2 问题出现原因
|
||||
|
||||
### 2.1 日志打印原理分析
|
||||
|
||||
在我们使用的log4j的应用中采用的是异步日志配置，简单的说明一下一条日志打印在log4j中的处理流程如下图所示： 简单点来说，就是多线程通过 log4j2 的门面类进行日志的打印，日志经过一系列的处理（过滤，包装）后放入到Disruptor的环形 buffer 中，在服务器的消费端会单启一个线程进行这些日志的消费，最终放入到我们指定的文件中。
|
||||
|
||||
### 2.2 log4j2 Disruptor 的初始化
|
||||
|
||||
当LoggerContext启动时，所有AsyncLoggerConfig会通过start()方法初始化其Disruptor： 其中Disruptor 是一个环形 buffer，官方做了很多的性能优化，这里有兴趣的可以了解其实现原理，这里不进行深入的讨论，其中在我们的应用log4j.xml配置中，没对RingBuffer进行自定义的配置，使用的是默认的大小256K。
|
||||
|
||||
### 2.3 队列满导致日志阻塞
|
||||
|
||||
Disruptor 的 RingBuffer 是一个固定大小的环形队列，其发布逻辑：
|
||||
|
||||
队列满时的默认行为：AsyncLoggerConfig.SynchronizeEnqueueWhenQueueFull=true，此时会等待着消费出下一个可以生产的环形 buffer 槽；此时所有打印日志的线程会尝试获取全局锁。此时会阻塞线程，也就是我们上述堆栈中看到的异常。
|
||||
|
||||
### 2.4 产生的根本原因
|
||||
|
||||
生产者速度 > 消费者速度：
|
||||
|
||||
AsyncAppender 的后台线程从队列中取出事件并交给实际 Appender（如 FileAppender）处理，如果实际 Appender 的写入速度慢（如磁盘 I/O 高），消费者线程无法及时清空队列，导致队列积压。其实log4j消费时会调用多次 flush，这些flush的调用根本在文件写入的 native 调用，当这种native调用太多时，系统写入不过来。
|
||||
|
||||
## 3 应对方案
|
||||
|
||||
### 3.1 方案选择
|
||||
|
||||
上述问题情况解决，大致分成两个方向：生产者方向&消费者方向，具体行为如下图简述： 在应对日志管理的挑战时，除了调整日志队列容量等基础优化（需警惕OOM风险），更核心的问题在于如何平衡日志的详实性与系统稳定性。开发者往往陷入两难：若详尽记录日志，可能引发阻塞风险；若过度精简，则排查问题时如盲人摸象，难溯根源。
|
||||
|
||||
为此，可考虑将日志划分为两类：
|
||||
|
||||
功能日志（必须）：如埋点数据、核心流程记录，确保业务可观测性；
|
||||
|
||||
业务排查日志（非必须）：如RPC入参/出参、调试断点等，按需动态启停；
|
||||
|
||||
通过这种分层策略，既能在高并发场景下保障核心日志的稳定输出，又能灵活控制辅助日志的打印量，使系统整体具备更强的适应性与可控性。如此，我们既能从容应对生产环境的严苛要求，又能在需要时快速激活详尽的诊断信息，实现运维效率与系统性能的兼得。
|
||||
|
||||
### 3.2 技术选择
|
||||
|
||||
在日志打印的精细化控制中，核心在于灵活性与精准度的平衡。传统的全局级别过滤（如INFO/WARN/ERROR）虽能粗放管理，却难以适配复杂多变的业务场景。理想的方案应突破层级限制，实现行级细粒度控制——无论是核心链路的关键节点，还是特定业务场景的临时调试，均可针对单行日志动态启停。
|
||||
|
||||
这种设计赋予开发者更高的自主权：业务视角：按需捕获特定模块的完整上下文；链路视角：精准聚焦某次调用的全生命周期轨迹；应急场景：即时激活深层诊断日志，无需重启或改码。
|
||||
|
||||
通过将控制粒度细化至代码行，我们既能维持生产环境的日志精简，又能随时按业务诉求“点亮”关键路径，使系统可观测性兼具严谨与弹性。
|
||||
|
||||
#### 3.2.1 区分必要日志和非必要日志打印：
|
||||
|
||||
自定义封装日志打印的方式如下图所示：
|
||||
|
||||
#### 3.2.2 如何对非必要日志进行行级别控制
|
||||
|
||||
1、自定义Appender中的filter：
|
||||
|
||||
在实现行级日志控制时，若需精确控制特定代码行（如第133行）的日志输出，采用自定义Appender过滤机制是一种可行方案。其核心思路在于：通过解析日志调用的堆栈信息，动态判断当前行号是否符合预设的打印条件，若不符合则直接过滤。
|
||||
|
||||
然而，该方案存在若干固有局限： 堆栈解析的可靠性问题：Lambda表达式中的日志调用往往难以准确获取行号信息，即使通过堆栈缓存优化，仍存在定位失准的风险；性能损耗隐患：频繁的堆栈遍历操作会引入不可忽视的性能开销，在高并发场景下可能成为新的瓶颈；分类管理缺失：该机制难以与既有的日志分级体系（必需/非必需日志）形成有机协同，增加了运维复杂度。
|
||||
|
||||
2、在打印日志前获取日志的行信息：
|
||||
|
||||
最简单的方式是人工的形式，在写日志的时候同时将日志的行信息写入进去，比如：这种方式在可扩展性和可观测性维度存在设计缺陷。
|
||||
|
||||
3、在编译的时候获取日志的行信息：
|
||||
|
||||
我们想使用LogUtils.debug(()->log.info("业务日志"));这种方式，但是我们不会在代码中明显的写入，可以在代码编译期间将行信息获取到后使用字节码修改这行代码，利用Java的重写。将它转变成 LogUtils.debug("类+行",()->log.info("业务日志")); 然后再这个方法执行中进行条件判断。
|
||||
|
||||
字节码技术选择：
|
||||
 在本次实现中需要更灵活的方式操作字节码，还要考虑性能的问题，以及对应用框架的支持， 我们选择ASM的形式。
|
||||
|
||||
4、如何随心控制开启和关闭：
|
||||
|
||||
这里我们采用的是ider插件的方式，有idea插件上报我们的对这行日志的控制行为，如下图所示：
|
||||
|
||||
### 3.3 落地实现
|
||||
|
||||
#### 3.3.1 Maven编译插件
|
||||
|
||||
目的：获取日志所在的类和行信息。
|
||||
|
||||
运行时获取的方式：在 Logger 配置中启用 includeLocation，代码从 LogEvent通过堆栈分析获取行号。这种方式存在很大的弊端，堆栈跟踪生成开销很大，每次调用 getStackTrace() 时，JVM 需要遍历当前线程的调用栈，生成完整的堆栈信息，这是一个 同步且耗时 的操作（尤其在深调用链中），如果每秒有数万次日志调用，频繁生成堆栈跟踪可能导致 CPU 使用率飙升，直接影响吞吐量。
|
||||
|
||||
Maven的process-classes阶段获取：通过Maven编译之后获取到字节码文件时，对字节码文件进行修改，存放日志的类和行信息。对运行期间无额外消耗。处理逻辑如下图所示：
|
||||
|
||||
#### 3.3.2 Idea插件
|
||||
|
||||
目的：精准的控制某一行日志是否进行打印。
|
||||
|
||||
利用Idea的插件能力，将我们对某一行日志的开启和关闭状态进行上报，整个过程不阻塞主线程，保持Idea操作流畅性。提供定时能力，保障线上我们可以更灵活的控制日志是否打印的状态。处理逻辑如下图所示；
|
||||
|
||||
#### 3.3.3 整体流程
|
||||
|
||||
使用方式：通过在项目中使用上述Maven插件对项目进行编译部署，使用Idea插件对目标日志的是否开启打印状态进行上报，存储状态采用的Apollo的能力，通过自定义打印工具类中对Apollo配置内容的分析，进一步做判断逻辑，最终将日志进行打印或者不打印。处理逻辑如下图所示：
|
||||
|
||||
## 4 总结
|
||||
|
||||
在分布式系统日益复杂的今天，日志管理已从简单的信息记录演进为系统可观测性的核心支柱。本文揭示的日志阻塞与策略困境，折射出现代化服务在稳定性与可维护性之间的深层博弈。通过剖析Log4j2异步日志机制的内在原理，我们识别出队列积压导致线程阻塞的关键症结，并由此展开对日志治理体系的深度重构。
|
||||
|
||||
本次优化方案突破传统日志分级思维的桎梏，创新性地提出双轨制日志管理体系：将日志划分为功能型与诊断型两类，前者确保核心业务脉络的持续可见，后者实现按需动态管控。通过编译期字节码增强技术，我们实现代码行级别的精准控制，配合IDE插件的可视化操作，使开发人员能够像调试断点般自由启停日志输出。这种"外科手术式"的日志管理，既避免了传统方案"一刀切"的弊端，又赋予系统在高负载场景下的弹性适应能力。
|
||||
@@ -3,3 +3,20 @@
|
||||
Source:[loxodon-framework/Loxodon.Framework.TextUGUI at master · vovgou/loxodon-framework · GitHub](https://github.com/vovgou/loxodon-framework/tree/master/Loxodon.Framework.TextUGUI)
|
||||
|
||||
---
|
||||
|
||||
|
||||
单向绑定
|
||||
``` csharp
|
||||
[OnValueChanged(viewModel=>viewModel.hp, value=>string.Format("{0:D4}"))]
|
||||
CustomText text;
|
||||
|
||||
public class CustomText
|
||||
{
|
||||
public Text text;
|
||||
public void SetText(string str)
|
||||
{
|
||||
text.text = str;
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
@@ -1 +0,0 @@
|
||||
[(2 封私信 / 4 条消息) UML类图太难画？试试这5款AI工具，一键搞定！ - 知乎](https://zhuanlan.zhihu.com/p/1905656789493580115)
|
||||
Reference in New Issue
Block a user