网站建设与品牌策划方案报价,wordpress后台是英文,千万别做网络管理员,九亭微信网站建设关于游戏性能优化的技巧 游戏性能优化对象池Jobs、Burst、多线程间隔处理定时更新全局广播缓存组件缓存常用数据2D残影优化2D骨骼转GPU动画定时器优化DrawCall合批处理优化碰撞层优化粒子特效 游戏性能优化
好久没有在CSDN上面写文章了#xff0c;今天突然看到鬼谷工作室技术… 关于游戏性能优化的技巧 游戏性能优化对象池Jobs、Burst、多线程间隔处理定时更新全局广播缓存组件缓存常用数据2D残影优化2D骨骼转GPU动画定时器优化DrawCall合批处理优化碰撞层优化粒子特效 游戏性能优化
好久没有在CSDN上面写文章了今天突然看到鬼谷工作室技术负责人分享的关于游戏性能优化的技巧想梳理一下游戏优化这块的理解这篇文章不会从细节入手针对的是大部分游戏性能瓶颈期和对优化没有完整概念的开发。优化的方法和手段很多如果我说的不详细的地方欢迎大家评论探讨感谢。
对象池
对象池可以重复利用某一些对象避免重复的创建实例化。比如特效使用对象池当特效销毁时可以隐藏起来并添加到对象池中没下次需要创建一样的特效时只需要从对象池中返回特效并从对象池中移除。下次再使用这个对象池的时候就不需要重新实例化了。对象类别还包括游戏中常见的一些怪物模型、特效、音频、血条、飘字等等还有一些辅助单刀的临时节点。我们使用技能的时候会创建很多弹道这些弹道的移动轨迹是通过辅助节点来移动的。这些辅助节点创建的频率频繁如果使用对象池这些节点就不再需要重复创建。但是要注意如果特效中使用了异步的功能在加入到对象池之后记得要关闭否则下次可能会有BUG。 Jobs、Burst、多线程
游戏中一些复杂的逻辑可能都是在主线程下面编写的如果游戏的复杂逻辑比较多就会造成主线程的压力大这个时候就可以使用多线程。但是多线程使用不当可能会导致上下文切换比较频繁或线程锁的问题。使用Jobs就可以安全方便的编写多线程代码最终可以提升上百倍的效率。我们弹道的移动轨迹和复杂公式包括各种大地图上AI的评分都可以使用Jobs来编写但是编写的东西要和主代码脱离否则你可能会有很多模块化之间的交互。如果你的寻路之类使用Jobs写不太方便的话可以直接采用多线程来进行优化。
间隔处理
比如1秒钟内创建了几十个怪物即使有对象池怪物的初始化也是需要时间的这时就可以把怪物分摊到多帧间隔中创建避免同一帧的卡顿。还有声音和特效创建一个弹道可能会发出声音一个技能使用的时候可能会创建几十个弹道这个时候声音是不需要重复创建的可以只创建一个声音。对于特效比如打到怪物上面会有被击效果弹道比较密集此时你的特效可以考虑间隔处理让它达到一定时间才会创建。
定时更新
血量UI、效果图标、技能CD等这些UI是不需要频繁更新的。每一次击打怪物的时候造成广播可能造成1秒钟之内更新几百上千次UI。此时可以做间隔更新比如设置一个最短时间或者定时更新减少更新次数。对于技能上的逻辑比如我们有一个技能场上没存在一把剑影移动速度加10。场上的弹道销毁和创建的频率比较高不能鉴听创建和销毁的广播此时就可以定时检测场上的弹道数量降低检测频率。 全局广播
图中最右边是大招最中间是器灵、法宝、逆天改命和后天气运加起来可能会有200个左右的被动技能。这些被动技能很多是监听即打到人时做什么事情或者使用什么技能做出的事情当然还有一些是一次性加属性的比如近战之后某些技能攻击增加、弹道数量增加。我们监听性效果是比较多的近战可能可以达到上百个监听性的效果。 举个例子最右边图中是刚刚那个技能黄色框的是监听攻击到单位时就造成伤害的提升或释放技能下面的是监听使用技能时场上所有的效果达到一定层数就会额外提升发射弹道。比如黄色的这种如果我们使用监听的方式打到敌人时候判断攻击者是否是自己攻击的技能是否是此技能。那么我们的所有伤害都会被监听到是很浪费效率的可以把广播拆细一点比如指定角色使用了指定技能攻击到敌人此时效果监听只需要把效果、身上挂载的单位和配置表上填写的技能ID组成一个唯一的串来监听这个技能打到的伤害就可以把无效的广播去掉。下面的这个使用技能的广播也一样如果用使用技能的单位和使用的技能来判断会有很多无效判断。那么可以采用和上面一样的逻辑使用指定角色和指定ID组成的一个唯一串来广播只有有效的技能才会收到广播。如果我们技能频率比较高比如1秒钟造成3000次伤害监听很多无效广播来做判断会比较浪费效率。
缓存组件
频繁的获取组件也是不好的。比如子弹发射时每次发射会获取到它的碰撞体来监听碰撞的敌人然后造成伤害。当弹道过多的时每次发射都进行获取是浪费性能的这个时候可以把组件缓存起来。例如对象池中组成的特效类似于右边的那个类里面包含特效的对象包括很多缓存的组件动画、碰撞体等等。这个时候如果要获取组件可以通过这个缓存的组件来获取那么所有组件只有在第一次初始化的时候才会获取一次不需要每次都获取。
缓存常用数据
我们在弹道表中可能会配置一些弹道速度和持续时间如果在弹道类里面每次创建弹道的时候都来读取这个数据是浪费效率的因此可以把这些数据储存到技能上面通过技能传递数据到弹道类中弹道类就不需要来堆配置表了。一般还有两种缓存一种是不需要实时更新的数据比如说角色战力、角色的各种向性评分还有它的喜好评分可以在一段时间内更新一次也可以把这个数据缓存起来通过系统或其他方式来更新。另外一种就是固定的数据比如密集微粒。我们的密集微粒是通过它密集组装的词条来生成的。密集词条越高它的威力就越高这个值是固定的只需要在首次创建的时候把它缓存下次就不需要重新计算了。
2D残影优化
Unity的2D残影方式一般都是实例化模型的当前动画这一帧并把动画速度设置为0来实现。但是就算把动画速度设置为0骨骼还是会继续模拟的所以当场景过多时对性能会有一定影响。优化场景的方法也很简单每次创建残影时不再需要实例化整个模型而是便利模型所有的精灵读取精灵的顶点、UV等数据创建出一个网格通过设置网格的材质来实现残影效果。模型在创建残影时就不需要实例化来创建了并且在创建残影时的网格也可以加到对象池当中复用下一次同一个模型来创建残影时就可以通过对象池来获取数据只需要把当前模型上精灵的顶点、UV等数据复制到那个网格中。但是这个操作比较耗时可以开一个线程来做这样在主线程几乎体会不到性能的消耗。在获取那些精灵的组件时也可以把组件缓存起来下次从缓存的地方来获取。
2D骨骼转GPU动画
先看右边这张图密密麻麻的点就是一个2D角色这个角色不是一个简单的面片每个角色有100多个顶点这里面有10000个角色。2D残影优化说到的骨骼性能问题在这种同屏上有很多2D单位有动画模拟的时候性能是消耗比较高的。优化方法和2D残影差不多就是把CPU的骨骼运动转到GPU上面。GPU的动画优点是可以解决CPU模拟动画时会有的性能消耗问题但缺点是无法使用动画控制器功能如动画过渡动态骨骼也无法绑定。如果模型的顶点数量太多单个动画的时长太长就会导致这张贴图过大。 下面简单讲一下转换的思路。 转换动画的第一步是编写工具来读取骨骼动画上面的顶点数据导出为GPU需要的资源。最左边的这张图包含了所有的动画文件和动画配置。动画配置指的是一些所需数据比如动画时长每个动画的名称、缩影等等。图集就是原来的贴图图集材质就是自定义的一个Shader可以自己控制这个骨骼动画的播放网格就是读取模型上的所有精灵通过这个精灵来生成一个网格。 中间这张图就是转换动画图的思路。动画的帧数一帧帧循环然后读取网格上面的顶点数量把每一个顶点的数据储存到图片上面然后就可以通过Shader来驱动动画的模仿。右边的那张是生成的动画图下面的是每个顶点在图片中的布局。比如第一帧横向的X组成了所有顶点的位置。第二帧放上去就可以组成那些动画的顶点数据了。右边那张图可以看到顶点的数量决定了每张图的X宽度动画的长度决定了图片的高度这意味着模型顶点太多就会影响图片大小包括动画时长。 Shader是如何驱动图片来驱动顶点的呢先看Shader的顶点函数顶点函数中有顶点的ID和它的动画时间动画时间是自己定义的一个参数。有这两个数据后可以对贴图进行采样采样后就能得到每个顶点的位置了。X就是1除以图片宽度可以理解为每个像素的宽度然后乘上顶点ID得到每一个顶点在动画中的位置。例如采样之后可以设置动画的时间动画时间是一个0-1的值0是动画的第一帧1是动画的最后一帧对应的采样中的YX就是顶点ID乘上贴图X图片宽度可以理解为采样第几个顶点。通过采样后的顶点数据可以改变顶点的位置每一帧进行这个操作就能用Shader驱动动画来播放了。 第三步编写自己的动画控制器脚本。脚本中可以提供自己需要的功能比如播放动画、播放指定动画、设置动画的播放速度、从指定时间开始播放上一张动画配置里面记录的数据可以放到这个动画控制器里使用这样就可以操作整个动画的播放了。
定时器
如果游戏中使用了大量的定时器比如延迟一帧或延迟N秒作为一个函数多少秒之后会销毁这个弹道等等那么每秒钟可能会创建上千个定时器。每个定时器都单独处理是比较消耗性能的可以把它们统一管理起来类似于ECS的思想。做法就是做自己的一个定时器把需要的函数传递过去包括延迟时间在定时器里面统一循环到达时间了函数就来执行统一管理后会比单独处理的性能高很多。游戏中如果有一些移动之类的操作都可以使用ECS的思想来统一管理。
优化DrawCall合批处理
DrawCall如果比较高它的帧率是比较低的就会对性能有影响。战斗UI如果比较复杂就必须优化战斗的DrawCall因为战斗UI是常驻的很影响战斗中的体验不能让UI占用太多的性能消耗。如果不在战斗中只打开几个普通UI性能占用就不会太大但是如果像背包这种大量数据的地方就需要注意。UI一般可以采用动态UI和静态UI来分离可以合批处理。例如字体和贴图一般来说不要在一个地方混着可以把它分离出来做合批处理战斗中的特效如被击特效、身上挂的buff以及其他渲染对象尽量保持在同一渲染层就可以做合批处理。
优化碰撞层
如果战斗的物理对象比较多也是比较消耗CPU性能的此时就要优化碰撞层去掉不必要的碰撞检测。比如玩家的子弹不会和玩家碰撞子弹不会和场景脚底的障碍物碰撞此时就要根据自己的项目来设置物理层越简单越好。场景的物理层可以分为地板的、脚底的障碍物、大型障碍物、可破坏的障碍物等。不同层的碰撞是不会相互影响的调整好碰撞层后可以减少物理的消耗。 优化粒子特效
粒子模拟使用的是CPU进行计算当粒子的发射数量比较多时CPU压力就会比较大。我们应该在前期就把粒子的检测工具制作好。比如特效的贴图一般是根据自己项目来制定的上不同的平台贴图的大小就有不一样的规范。另外每种粒子的粒子数量也要有规范如果同屏只有一个仙法或比较大的特效此时它的规范就要宽一点。如果是小特效但在同屏有很多个此时应该有不一样的规范。 可以在工具里面自定义一些规则来检测每个粒子的数量。但是数量在同屏中会出现几个弹道一般有两种情况第一种是比较简单的弹道可以通过配置表获取就能知道同屏会出现几个弹道第二种是像鬼谷一样很多地方都会修改弹道数量这个时候可以制作一个检测器。在内部开发时这个检测器会运行检测同屏中每个弹道的粒子数量以及个数。将检测器获取到的数量上传到本地服务器记录异常特效在优化完特效后就可以将异常特效移除。开发中制作新技能的时候弹道肯定会进行测试通过检测器就能获取到弹道的数量以应对比较复杂的弹道情况。检测器获取粒子数量一样可以使用缓存把特效脚本缓存起来下次获取的时候就不太需要编译了性能影响也是比较小的。 不只是特效所有资源都应该有一个规范。比如音效的格式、场景的贴图大小、怪物角色的顶点数量等等应该都有一个工具来检测它们。还有要尽量在前期考虑好游戏中哪些逻辑是比较影响性能的根据实际情况考虑使用多线程还是Jobs。如果游戏的复杂度比较高也可以考虑使用ECS来制作。 Unity的ECS性能是比较高的。两个程序之间它们可能本地有几十个或者几十万个实体对象在做联机的时候是需要同步这两个实体对象的。我们制作了一个小demo测试了一下几十万的实体对象来同步ECS可以把所有的组件自动生成同步代码同步系统会自动把这些数据同步到两台服务器几十万的实体一帧内只需要几毫秒来运行它的效率是非常夸张的。前期可以把这些项目的规范制定好包括程序是否需要采用DOTS还是GPU的动画这样后期优化的工作就会比较少。
原文连接
