- 博客(179)
- 资源 (4)
- 收藏
- 关注
RSS订阅原创 Unity CullingGroup详解
CullingGroup是Unity提供的高效批量剔除方案，通过包围球代替复杂物体进行视锥剔除，减少函数调用开销。其核心功能包括：批量设置物体包围球、指定检测相机、划分距离带用于LOD决策，并提供状态变化回调。适用于中小规模静态或动态物体，使用时需注意及时释放资源。对于大规模动态物体，可结合JobSystem和NativeArray优化性能。主要局限性在于频繁更新大量动态物体会增加主线程负担。
2025-11-12 20:12:16
972
原创 Unity LODGroup详解
LOD（层次细节）技术通过多精度模型切换优化3D渲染性能，核心是根据物体与摄像机的距离动态选择LOD等级（通常0-4级）。Unity的LODGroup组件以屏幕相对高度为切换依据，支持通过设置参考点、LOD阈值和全局lodBias参数来调节切换策略。高级功能包括CrossFade平滑过渡和HLOD（分层LOD），后者通过将多个对象合并为代理网格来优化大规模场景渲染。技术要点涵盖减面处理、材质适配、多因素动态切换策略，适用于平衡画质与性能的需求场景。
2025-11-05 20:21:12
1018
原创 对泊松过程的理解
摘要：泊松过程描述事件在时间或空间内的发生概率，其核心参数λ表示单位时间内的预期事件数。通过调整时间区间可改变λ值，但需确保单位时间足够小以满足事件独立、低概率的基本假设。实际应用中需根据统计数据验证假设，如交通事故分析中需合理选择时间单位（如分钟而非小时）以符合泊松过程特性。泊松过程与泊松分布具有相同数学形式，区别在于时间尺度的选择。
2025-10-23 20:11:27
654
原创 对伯努利过程的理解
本文介绍了伯努利过程的基本概念和应用。伯努利试验是只有成功(1)和失败(0)两种结果的独立事件。文中阐述了相关的概率分布：二项分布、负二项分布和几何分布，以及伯努利过程的合并方法。以抛硬币为例，说明了在理想情况下每次试验独立且同分布，但在实际应用中可能存在偏差。最后指出，只有当随机事件结果可以被归为两种互斥情况时，才符合伯努利过程的条件。
2025-10-14 20:48:32
689
原创 对随机过程的理解
本文介绍了随机过程的基本概念及其数学描述。随机过程用于建模随时间变化的随机现象，表现为一组依赖参数的随机变量集合。文章区分了离散与连续变量，阐述了期望和方差的统计意义，并讨论了随机性、独立性、分布等关键概念。特别强调了相关、回归与因果关系的区别：相关表示变量间的关联强度，回归能量化这种关系，而因果则明确变量间的直接影响。最后指出，虽然理论模型需简化现实条件，但分布函数仍能为实际应用提供有价值的参考依据。
2025-09-19 20:12:15
1056
原创 技能系统详解（5）——角色数值
文章摘要：本文探讨了游戏角色数值系统的设计与实现，重点分析了数值计算和同步机制。数值系统通过组件化设计（如基础攻击力、装备攻击力等子模块）支持复杂修改操作（固定值、百分比、范围限制等）。代码示例展示了基于Modifier模式的实现方案，采用延迟/即时更新策略处理脏数据。属性系统通过分层编号管理各类实体属性，支持配置化同步策略（方向/对象/时机），并采用差分更新优化网络传输。最后列举了MOBA类游戏的典型角色数值分类（基础/进阶/技能属性），为游戏数值系统开发提供了完整的技术框架。（149字）
2025-09-08 20:49:24
1038
原创 游戏空间划分技术
空间划分技术是优化搜索效率的关键方法。主流方案包括均匀网格（实现简单但效率受密度影响）、四叉树/八叉树（自适应划分但维护成本高）、KD树（高效多维查询但重构成本高）、BVH（基于包围盒适合碰撞检测）、空间哈希（适合高频更新场景）。这些技术通过将全局搜索转为局部搜索降低计算量，各有优缺点：均匀网格易实现但密集时效率低，树形结构能动态适应分布但维护复杂，哈希表适合动态场景但需处理冲突。实际应用中常采用混合结构，如网格+四叉树或BVH+空间哈希，以平衡性能与复杂度。选择方案需考虑场景特性（静态/动态物体分布、更新
2025-08-26 20:44:16
978
原创 技能系统详解（4）——运动表现
本文系统介绍了游戏开发中运动表现系统的实现方案，主要包括运动系统、技能系统和打击系统三大模块。运动系统涵盖基础移动（走、跑、跳等）和地形运动（攀爬、飞行等），技能系统通过动画控制、参数调整等方式实现位移技能，打击系统则定义了击退、击飞等交互效果。文章详细阐述了位移技能的代码实现方案，包括瞬间位移和持续位移的处理逻辑，以及碰撞检测、位置修正等关键技术点。同时分析了动画控制与代码控制两种位移方式的优缺点，提出了混合使用的解决方案，并提供了完整的Unity实现代码框架。
2025-07-22 20:40:31
887
原创 技能系统详解（3）——子弹表现
在游戏中，任何可以投射出去的，能与游戏内其他实体有物体交互表现的，都可以看作是子弹，例如枪械子弹、弓箭、火球、冰锥、石头。例如，技能释放的火球应该看作子弹而不是特效，火焰特效是附着于子弹上的。同特效创建一样，也需要一个BulletManager用于管理所有子弹的创建，此时需要一个单独的数据结构用于子弹运行时数据封装，这和技能的几种数据没有区别。
2025-07-09 12:14:05
1006
原创 技能系统详解（2）——特效表现
摘要：本文介绍了一个特效管理系统EffectManager的设计与实现。系统将特效分为随身特效、表现特效和场景特效三类，分别采用不同的挂载方式和生命周期管理。通过EffectConfigData配置特效参数，包括基础属性、位置参数和存活参数。代码实现包含EffectComponent组件处理特效生命周期，ComponentTick统一管理组件更新。系统支持动态修改参数，并提供Prefab加载、位置偏移、存活时间控制等功能，适用于角色技能等复杂特效场景。
2025-06-23 20:46:38
379
原创 技能系统详解（1）——技能
本文系统探讨了游戏技能系统的设计与实现。文章首先介绍了技能系统与底层系统（如属性、动画、特效等）的依赖关系，指出技能系统通常需要改造已有系统来满足新需求。然后详细阐述了技能生命周期的六个阶段（Init、Check、Enter、Execute/Break、Exit、Destroy）及其对应状态，以及技能数据的三种分类（配置数据、本地/远程运行数据）。在实现层面，作者提出了基于组件化的设计思路，将不同表现抽象为可组合的SkillComponent，并区分了动作驱动与技能驱动两种实现模式。最后以王者荣耀为例，展示
2025-06-17 21:06:25
977
原创 效用系统简介
对于行为：距离、血量、敌人数量、技能等都会对选择什么样的战斗行为有影响，战斗行为分为攻击、防御、闪避、挣脱、辅助等五大类，这些信息是行为的影响因素，每种因素有不同的权重值，通过不同的效用函数累加计算得到最终不同行为的效用值，选择效用值最高的行为。效用(Utility)同有限状态机、行为树一样都属于决策的方式，其核心是给感知到的不同信息以及不同行为赋予不同的效用值(Utility Value)，并选择效用值最高的行为。更进一步的，可以用代价作为效用的另一面，选择代价最小的，或着综合代价和效用做决策。
2025-03-20 20:30:43
421
原创 寻路网格简介
导出的数据可以是一个bytes文件，也可以是类似地形贴图的一张RGB图片，例如（255，255，255）表示可通行，（0，0，0）表示不可通行，（100,100,100)表示沼泽区域等，图片有更多的数据位，能表示更多丰富的情况。最常见的是寻路网格，也即建立一个二维数组，每个坐标表示长宽都为n米的区域可通行的情况，可以用0表示可通行，1表示有障碍不可通行，n的大小根据项目情况确定，一般可以为1，其大小影响内存。更进一步的，为表示角色在不同区域行走的快慢，可以基于不同区域不同的权重。
2025-03-12 21:18:28
425
原创 A*寻路优化
如果起始点和目标点有一定的距离，那么会存在这样一种情况，一个距离目标点较近的Point和一个距离起点较近的Point，可能有相同的cost，这将导致某次选择出的cost的最小的点距离目标点很近，下次选出的点却距离起始点很近，前后两个点有跳变，为此，可以增加一个舍弃距离。当选出的点与之前的点距离较远时，直接将该点舍弃，重新选择。在D Star中，也会寻找cost最小的点，但路障会改变cost，导致最小的cost点发生变化，此时是在多次的搜索中的最下cost，在D Star中被称为k值。
2025-03-10 20:51:39
1008
原创 A*寻路详解
搜索最基本的思路是穷举搜索，例如广度优先和深度优先搜索，但当搜索空间过大，也即可能性太多时，最好可以提供一种方式，对可能性做筛选，减少搜索空间，进而提高搜索效率。常用的说法是cost，从一个点到另外一个点的成本，通常成本就是距离的度量，在机器学习中，还会加上其他因素的度量，寻路算法中只有距离度量。通常来说，搜索是一步步进行的，每一步会将新的可能加入到待处理队列中，如果每一步都从当前可能中选择一个最优的结果，这就是贪心的。游戏中通常需要最快找到该路径（A*算法），而不是找到最短的路径（Dijkstra算法）
2025-02-11 20:42:58
1540
原创 游戏角色战斗行为分析（1）——概述
角色最重要的一类行为就是战斗，战斗行为最为丰富的是动作游戏战斗行为有对应的战斗状态和战斗属性，属性是一种特殊的状态信息战斗行为通常又可以分为攻击、防御、闪避等行为，分别有各自对应的状态和属性，是战斗状态的细分和战斗属性的扩展1.有的游戏（不是动作游戏），攻击方式只有一种，机制是攻击到就击杀2.在1的基础上，引入伤害和血量机制，每次攻击有固定伤害，减少固定血量，血量为0时击杀。该机制引入了基础属性，血量；攻击属性，攻击力；战斗状态：攻击中这时的战斗机制主要是依靠移动来闪避固定的攻击。
2025-01-20 20:22:04
1687
原创 Unity Burst详解
Burst是Unity的编译优化技术，优化了从C#代码编译成Native代码的过程，经过编译优化后代码有更高的运行效率。在Unity中使用Burst很简单，在方法或类前加上[BurstCompile]特性即可。在构建时编译代码的步骤，Burst编译器会识别该特性对方法或类做编译优化。其适用于高性能计算的场景，逻辑复杂的场景不适用。Burst编译的实现得益于已有的SIMD和LLVM技术。
2025-01-08 20:39:16
2590
原创 行为树详解（6）——黑板模式
黑板模式的数据管理本质还是通过键值对的方式，为处理不同的情况，我们需要对每种情况提供不同的Key。因此，在实现动作节点时，属于其他模块的直接调用其他模块的接口或在其他模块内实现，属于角色行为的在动作节点内实现。在黑板中，我们需要根据这些参数生成唯一的Key，这里自然而然的就会需要对参数做封装，用泛型，用对象池。根据行为树ID，节点ID，数据ID，方法ID可以实现不同的数据获取，程序只需实现方法ID即可。同样的，我们需要有这些参数对应的结果，考虑数据类型差异，结果有效性等，自然也需要做封装。
2025-01-06 20:18:22
1585
原创 网络时延与rtt
这个公式可以累积展开，EWMA_n和之前的EWMA_0到WEMA_n-1皆有关系，第n到第0个数据的权重依次是alpha,alpha*(1-alpha),alpha *(1-alpha)^2,......,alpha * (1-alpha)^n。由于网络的复杂性，通过每个数据包计算出来的时延都不相等，为了得到一个确定的时延值，通常的做法是取过去数次的时延平均值作为当前的时延值。例如，在rtt计算中，数据的特征是越近的数据越有效，其权重应该更大，但与较远的数据不能差距过大，函数可以是指数、抛物线等。
2024-12-31 13:05:11
1496
原创 行为树详解（5）——事件驱动
这里要对控制节点做特殊处理，控制节点会控制自身的子节点运行，其状态受子节点影响，当打断存在时，子节点可能不需要再次运行，因此控制节点在控制子节点运行前需要知道当前是否被打断。为了解决该问题，就需要给动作节点引入一些事件，当特定事件发生时，在动作节点内接收该事件，直接结束动作节点的运行，返回失败。需要将打断动作节点及节点的逻辑做成单独的Conditional节点，这些节点接收消息或监听变化，以决定是否打断其子节点。如果行为树的节点很多，那么会存在要经过很多节点才会走到动作节点的情况。显然，性能上不如状态机。
2024-12-28 19:51:47
857
原创 行为树详解（4）——节点参数配置化
节点是通用的，不可能在获取模块A的数据时在Update中调用A方法，在获取模块B的数据时调用B方法，这里需要一个统一的调用方式。比较难解决的是最下层的参数数据，这在很多配置数据中是通用的，其主要问题是参数类型、数量、值等各不相同，如何做一个统一的描述？行为树是否足够灵活强大依赖于足够丰富的各类条件节点和动作节点，在实现这些节点时，不可避免的，节点本身需要有一些参数供配置。我们需要有一个结构来描述行为树的配置数据，这个结构是用于运行时初始化数据的，可以将编辑数据和运行时数据结构分隔开来。
2024-12-11 20:30:29
813
原创 行为树详解（3）——多节点实现
NPC围绕固定的点50米内巡逻，当有多个敌人进入巡逻范围内或者和NPC距离小于20米时，会选择其中距离更近的敌人追击，如果和敌人距离小米3米，释放1技能攻击，如果在追击中距离敌人大于30米，NPC速度提高一倍，距离敌人小于3米，释放2技能攻击，如果和敌人距离大于50米或者距离中心点超过100米，则回到重新开始巡逻。可以更明显的看到，行为逻辑是配置出来的，配置一般由策划负责，相对一般的数值配置来说，行为树的配置增添了逻辑性，更加考验策划。再次，对每个状态下的行为划分优先级，优先级高的行为先判断。
2024-11-27 20:33:45
1267
原创 行为树详解（2）——最简单的行为树
结合具体的实际需求来：假设有这样一个NPC，绕着固定的某个点以半径20米随机巡逻，让主角进入时，开始朝着主角攻击，距离主角3米时，开始攻击主角，如果距离主角超过10米，则重新巡逻。实际上应该有更多的节点来保证逻辑的正常，我们再后面的文章中结合实际来添加更多节点。如何做状态划分是任意的，划分的原则是尽可能让状态更少，这里将NPC的四个行为分成巡逻和追击两个状态。前后对比可以发现：真正的执行动作的代码区别不大，执行时所需参数的来源和之前一样。最后，对每个状态下的行为划分优先级，优先级高的行为先判断。
2024-11-21 20:31:43
1137
原创 行为树详解（1）——与状态机的区别
但是，这两者的能起到的作用有限。状态的概念在行为树中被具体化为行为，一个行为包括动画状态机中的一个或多个状态，也即执行一个行为，会多次调用状态机的状态切换接口。这里的逻辑其实就是NPC行为的逻辑，逻辑本身在于一系列条件的判断，而不在于动作节点（即NPC的动作），动作是动画状态机的。也许你听过OverrideState的概念，包括分层，并发等不同的状态机，但这些都是条件的体现，而不是状态。状态之间的关联使得状态转移过于复杂，新增的状态可能会与已经的众多状态做转移，甚至影响已有的状态之间的转移。
2024-11-11 21:09:38
1309
原创 Unity Job System详解（5）——NativeHashSet/Map源码分析
两者的核心都在HashMapHelper中，数据在HashMapHelper* m_Data，内存分配同样调用Memory.Unmanaged.Allocate，释放调用Memory.Unmanaged.Free，有依赖释放时会自动创建NativeHashMapDisposeJob，逻辑与NativeList完全一致。与UnsafeList不同的是，这里数据类型不同，没用Block，直接调用的Memory.Unmanaged.Allocate。不再贴完整源码，只贴关键部分源码。
2024-11-05 20:42:42
828
原创 Unity Job System详解（3）——NativeList源码分析
查看NativeList源码需要安装Unity的Entities PackageNativeList要实现的基本功能类似C# List，如下：（一些简单的类同NativeArray的不在说明）构造函数、析构函数、取值赋值扩容、添加、移除操作解析步骤包括，基本函数，常用操作，常用属性，接口函数。
2024-11-03 21:50:45
1653
原创 Unity Avatar详解
Avatar用于解决人形动画的复用问题。物理上，两个不同人形角色的骨骼结构整体一致。为其中一个角色制作好动画后，为了避免再次做同样的动画，我们自然而然想到将已经做好的动画迁移到另外一个角色上。但是我们不能直接去使用，例如将角色A的AnimationClip给角色B使用，角色B无任何反应。（角色模型和角色动画数据是可以分离的。因为无法找到骨骼节点对应的曲线数据。AnimationClip中会记录每个曲线对应哪个节点，通过相对根节点的路径作为标识。（运行时为省内存一般会哈希化）
2024-10-24 13:19:44
2859
原创 Unity AnimationClip详解（2）——动画数据的优化
首先要意识到运行时和编辑时的区别，当运行时和编辑时所需的数据相差不大时，我们用同一套数据结构即可，当两者差异较多或者数据量很大时，需要有各自的数据结构，这意味着在打包或构建时需要将编辑时数据转为运行时数据。（所以Unity中的AnimationClip Curve数据不提供给非editor情况下使用）（内存优化把握三个核心方向：一是内存中只存在当前或最近需要的资源及数据；二是需要的资源及数据在内存中仅存在一份；三是简化资源和数据的结构，运行时和编辑时的数据区分是方向1）由前文可知，动画至少有30个骨骼节点，
2024-10-21 21:43:52
1658
原创 数据压缩（5）——上下文转换编码
统计压缩编码基于单个字符，字典编码基于单词；上下文变换基于具有联系的上下文，例如：RLE编码针对重复字符：AAAABCCC可以记为[A,4]B[C,3]
2024-10-18 13:30:40
1028
原创 数据压缩（4）——字典编码
变长编码，统计压缩编码都是基于单个字符的编码，字典编码基于数个连续字符（也叫基于单词），例如ABCABD中AB可以替换成一个新的字符，其可能会减少字符数量，得到的新数据的熵比原来的小，可以对新的数据再用统计编码字典编码的困难之处在于如何选择最佳的单词，其会使得新数据集的熵变得更小。出于性能上的考虑，不可能去遍历整个数据集来寻找最佳的单词，通常会去寻找最长匹配的数据，通过偏移+长度的方式记录匹配数据。因此，字典编码适合有较多重复子串的情况。
2024-10-16 21:31:43
994
原创 数据压缩（3）——统计编码
VLC编码需要数据集中符号概率分布与对应的VLC算法匹配，这限制了其应用范围。而统计编码可以根据数据集符号的概率分布构建出相适应的码字表，尽管在特定数据集上比VLC编码的压缩效果差。哈夫曼编码在分配码字时巧妙利用了二叉树路径唯一的特点，给每个字符分配带有前缀性质的码字。解码就是编码的逆过程：0.83先在[0.4,0.9)，第一个字符为G，又在[0.6,0.85)，第二个字符为G，最后在[0.825,0.85)，第三个字符为B，合起来为GGB。
2024-10-14 20:01:00
1982
原创 Unity AnimationClip详解（1）
前文我们介绍了骨骼动画，在Unity中骨骼动画的部分静态数据存储在SkinedMeshRender中，而另一部分动态的关键帧数据就是存储在AnimationClip中的。
2024-09-09 22:10:46
2995
1
原创 数据压缩（2）——变长编码
变长编码(VLC,variable-length codes)会给出现频率高的字符更短的码字，这样编码后数据集的整体长度就降低。，编码时将码字表写入，再一次写入每个字符的编码。难点在于如何从一个01的stream中区分码字，定长编码每次读取固定长度就行，变长编码不清楚每次需要读取的长度。其核心在于需要通过一套规则，给不同字符合适的码字，以确保频率高的字符有更短的码字，并使得不同码字可以互相区分。如果ASCII表上的大部分字符都出现过了，那么定长编码的压缩方式就很差，需要采用变长编码。
2024-08-28 20:11:02
919
原创 数据压缩（1）——简介
数据压缩存在于计算机、网络的各个地方，是很底层的技术支持，例如歌曲、图像、视频、网页、文本等的保存和传输都是用过数据压缩算法的。总的来说，我们常使用数据压缩来增多硬盘存储的内容、减少网络传输的流量。数据压缩研究的是，在可接受的信息恢复程度下，可以将信息变得有多紧凑。通常有两个思路：减少数据中不同符号的数据量；用更少的位数对更常见的符号进行编码。数据压缩的算法多种多样，没有万能的算法，通用算法能保证数据集经过压缩后会变小，但与数据特征相匹配的算法能将数据集压缩得更小。
2024-08-25 17:50:06
932
原创 程序的自我修养（1）——自测
在开发过程中，每完成一个小地方，测试看看功能是否符合预期，是每个程序都会做的，这一过程也叫做自测。可以说，每个程序都知道并且会自测，然而，实际中却经常有不自测的情况，可能由于程序疏忽、偷懒、被逼等等原因，我们来分析一下。我们将不自测导致的情况分为编译不通过、进入有报错、测试有Bug三类。
2024-08-15 20:09:26
1187
1
原创 UI框架与MVC模式详解（3）——MVC\MVP\MVVM
在MVC中，业务数据直接就是界面所需的交互数据，但在MVVM中，会有一个业务数据和界面数据的映射，例如业务数据中的UserName字段界面数据中可能仍是原样显示，但地区需要从“中国”显示为“China”在MVVM中，View中需要新增一个绑定逻辑，为PanelViewBind,其将V中的组件的数据与VM中的数据绑定，以便于双方中有变化时会自动通知对方取修改值。MVC是整个UI框架层级上的模式，PDI是在已有的UI框架模式下（不一定是MVC）的具体功能上的模式，他们的核心都是实现逻辑和数据的分离。
2024-07-31 21:32:36
1695
1
原创 UI框架与MVC模式详解（2）——数据管理
如果很多，我们要逻辑和数据分离，这里是方法层级的逻辑和数据分离，前文说的是功能层级的逻辑和数据分离。对于不同的数据单位，加载时的逻辑是相同的。加载前的信息和加载后的方法对加载时的逻辑而言都是数据，这是流程的逻辑数据和分离，比之前说的方法的逻辑数据和分离复杂点。有个数据管理的类，初始化时把所有需要的数据加载到内存中，提供不同的Get方法，让同一个界面获取不同的数据或者不同的界面获取相同的数据。数据单位要大而全，因为不同界面需要的显示数据虽然都来自同一个数据单位，但有的显示数据单位中的A，而有的不会.
2024-06-28 19:30:02
1061
1
原创 UI框架与MVC模式详解（1）——逻辑与数据分离
分离的方式是显示的逻辑、获取数据的逻辑（耦合的方式没有该逻辑，其直接就有数据）、数据集合的逻辑，显示的逻辑和数据集合的逻辑不耦合，两者通过获取数据的逻辑关联起来，当新增显示时，显示的逻辑不变、获取数据的逻辑不变，数据集合需要新增数据，一个界面改变引起一处逻辑改变。交互会使得界面显示内容发生变化，交互的数据记录的是界面的状态。耦合的方式将界面显示的逻辑与显示需要的数据耦合在一起，当需要新增显示时，显示逻辑不变，但数据增加，即数据改变，导致需要修改显示逻辑，一个界面改变引起两处逻辑改变。
2024-06-07 20:48:47
1670
原创 Unity构建详解（12）——自动构建
自动构建是指整个构建流程不需要人工操作，只需要输入启动构建指令即可获取构建结果。支持命令行参数启动我们不可能每次构建时都打开Unity去手动点击构建，必须支持通过命令行启动Unity自动执行构建我们每次构建的需求不同，可能构建Debug、Release或者其他特殊需求的应用，因此Unity需要支持识别命令行输入的不同参数支持工程自动检查我们构建时需要保证不会出现错误，否则中途就构建失败了。
2024-05-10 22:34:01
1939
1
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人