热门搜索:  

MMORPG战斗系统随笔(四)、优化客户端游戏性能

   转载请标明出处http://www.cnblogs.com/zblade/

        说到游戏性能,这是一个永恒的话题。在游戏开发的过程中,性能问题一直是我们研发需要关注的一个节点。当然,说句客观话,很多程序员在写代码的时候,是不会过多的在意其代码的性能的。其实这是一种很危险的思想,一个不断进阶的程序员,需要持续的关注自己的代码质量,同时需要借助工具来反查自己编写的代码质量。很多初阶的程序员,在编写代码的时候,是单纯的以完成任务为目标的,其实在写完后,可以没事翻看以前自己的代码,就会有很多不一样的视角。比如,代码的整洁性是否注意,可读性是否有注意,注释是否有相应的标写,这是一个基本的代码规范。

  除了基本代码规范,进一步的需要考虑的是代码的质量,也就是性能是否有消耗,是否写出一些消耗较大的逻辑。对于性能的优化,就需要相应的性能工具来进行计算和统计,不然所谓的性能优化都属于自我安慰,没有数据支持。

  下面我回忆总结一下自己参与的一些性能优化工作,也算一个个人总结吧。

一、对lua导出表的优化

  这是我最早而且持续时间最长的一个优化工作。在我们的游戏中,策划会有大量的配置表,全都配置在excel表中,通过编写导表工具,可以将excel表导出为对应的lua表,用于在游戏中进行lua表的加载和查找。我总结一下优化的几个节点:

        1、最初版本的导表

        最初版本的lua导表,是将excel中对应的key-value值逐一导出,其基本的格式可以表示为:

local skill = {
   {Id = 1, CD = 5, SkillTarget =1,...}    
   {Id = 2, CD = 3, SkillTarget =2,...}    
   {Id = 3, CD = 6, SkillTarget =1,...}    
}

  这种通过在table中插入多个table的方式,每个子table为hash的存储方式。仔细分析一下存储的类型,对于table而言,其基本的存储方式分为hash和array两种方式。hash的存储会有较快的读取操作,但是会带来更多的内存占用,因为其需要申请内存来存储key值,不单单只存储value值。对于array的存储方式,lua在底层的实现的时候,并不是我们常见的采用2的幂次的大小来存储,也就是,不是采用2,4,8,16,32...这种大小的存储,而是实际的根据数组的大小来分配对应的大小数组。这是后面一次优化中,通过实现设置对应大小的数组来分配内存,发现对比并没有对应的优化,后来查看源码才发现其数组的分配规则。

       最初版本的所有lua导出表都采用hash的存储方式,那么可以想象有多大的内存占用~大概在50M左右~这是一个非常可怕的内存占用,如果在游戏加载的过程中,需要加载这么大的配置表,那么游戏加载会有多缓慢,可以体会一下 :D

      2、初次优化的导表

       其实,最开始引起我们关注的并不是其存储方式,而是策划配置的某些excel表过于巨大,某些单一的表就会大到几M的数量级,分析其中的数据,很多数据并不是反复分散变化的,而是集中在较多的几个高频中,这就引申出一种优化的策略:提取高频的配置作为默认配置,少数低频的配置采用对应的配置,这样就可以得到对应的一个内存优化。具体的优化策略可以详见我的这篇文章:table重构index方法优化内存http://www.cnblogs.com/zblade/

       这篇文章的基本思想,就是通过重构和提前高频的方法,缓存高频,每次查找的时候,默认去高频中查找,如果没有,则走自身的查找。可以查看文章中的对比存储方法,写的比较详细。

    采用这种优化方法后,整体的lua导出表得到大大的优化,整体缩减了接近20M左右,可见我们的策划有多喜欢配置同样的配置 Orz

      3、进一步的优化导表

    通过上面的一次优化后,我们大大的优化了游戏的lua表内存占用,整体游戏在加载的时候,lua表统计的内存占用在30M左右。如果我们只满足于这一点,那么就不会有下一步的优化了。后续在第二次的优化上,我还进行了一些特定的优化,但是都没有太过于亮眼的优化,包括前面提到的用array的方式代替hash存储,也研究过设置array的大小,不采用2的幂次大小分配内存,事实的统计显示其实lua本身的内存分配就是采用 按需分配的,不会过多的分配内存。

    最好的优化方法,就是多和别人交流,这是我对自己优化的一个另类总结吧。在上一次的优化后,都没有太大的性能提升,但是这部分的内存占用又一直处于一个比较大的部分,后来在和其他项目组交流的时候,提供了一种静态加载的实现思路。对于lua导出表,可以用一种静态分表加载的方式。特别是对于占用内存比较大的一些表(具体每个表的占用可以做一个内存统计排序),可以分开成多份,这样在最初的游戏加载的时候,加载的是头文件部分,这部分是不包含具体的配置表信息的,具体的配置表信息存放在分表文件夹中。在实际使用的时候,比如将技能表分为part1-20,每个分表大小100,定位要获取id为1001的技能的配置,这时候去加载其对应的分表part11, 加载进来后定位取到1001的技能配置,这样就不会多余的加载part12-20这部分的数据表。

     通过静态分表加载的方式,游戏在最初加载lua表的时候,对于分表实现的lua表大大降低了游戏的内存占用,效率提升非常明显,内存占用缩小到20M左右=。=

       基于这样的实现方式,进一步分析,其实这些lua表并不需要在游戏启动的时候加载,只需要在每次第一次使用相关表的时候加载,再加载进来,同时对于大的内存表进行分块加载,综合这样的实现方式,对lua表的优化最终达到一个可以接受的地步。

二、3D模型的优化

  在3D游戏中,美术在3DMAX中做完游戏模型的相关建模和动画后,会导入到unity中作为游戏资源。通常,这样的美术资源是含有冗余的资源,可以在unity中对这些冗余的资源进行优化,降低美术资源的内存占用。这儿我例举两种美术资源相关的优化:模型UV的优化和动画animation冗余节点的优化。

  1、模型UV的优化

   一半导入unity的角色模型,都含有冗余的多套UV,对于这些对于的UV,我们是可以用一定的方法来实现剔除的。由于u3d中模型的类型为FBX类型,所遇需要采用FBX SDK,结合FBX SDK的API进行UV的剔除。这儿给出一个FBX SDK的官网:FBX SDK官网。

       FBX SDK的官网给出了两种实现方法:C++和python,对应的都有详细的API讲解和例子。我主要采用python的方法,搭建基本的pyhton环境后,就可以查看相关的API接口,从而实现对应的代码编写。具体代码由于保密我就不提供了,我可以给出相关的实现思路:首先是查找到指定文件夹下的所有FBX文件,然后对于这些FBX文件进行读取,获取其下面的所有节点,对于每一个节点,读取其属性,如果属性包含UV,则读取UV的数量,如果数量大于1,则说明有多余的UV,则将其移除,然后保存。

  通过移除多余的UV,可以实现对FBX文件的一次"瘦身",从而降低美术资源对游戏内存的占用。如果有什么需要交流的,可以在下面留言进一步讨论。

      2、动画animation冗余节点的优化

       模型的动画,在美术制作完后,会被导入到unity中,进而可以在animation窗口中查看。其实我们分析模型的animation,我们可以发现,大部分节点的animation在插值过程中,其实质是不会变换的,基本为1。由于每个节点的animation主要修改 rotation/scale/position这三个transform属性,所以对于rotation和scale可以进行一次剔除:如果整体animation的插值都为1,则这样的一条animationCurve是可以剔除的。不知道有没有读者也有相关的优化策略,可以在下面留言进一步的讨论。

  我就说说我用FBX SDK优化animation冗余节点的思路:首先获取到FBX模型,然后获取到对应的FbxAnimStack,也就是animationClip,获取到animationClip后,进一步获取到animationLayer,基于animationLayer,可以获取到每个animationLayer的animationChannels,也就是rotation/scale对应的xyz三个通道,分析这三个通道的通道值,如果都在1的误差允许范围附近,则可以移除这个rotation/scale。

      最后存储修改后的FBX文件,可以发现以前较多的animation经过优化后,都被剔除过滤掉了,这说明很多时候我们的animation其实只是在修改position这一个属性,并不会修改rotation/scale这2个属性,这是可以被优化的。

三、头顶文字描边的优化

  熟悉MMORPG游戏的都知道,在游戏中角色头顶都会有名字,称号等相关的文字信息,实时的反应玩家的信息,便于游戏的交互。在MMO游戏中,会有很多的玩家同时在场,同时也会有较多的怪物NPC等游戏角色的存在,而为了追求游戏体验,都会对玩家头顶的文字进行描边,总结一下对头顶文字描边的优化过程:

  1、4个基准点的描边

  最开始提出要添加头顶文字的描边后,和leader商量了一下,就只是单纯的对玩家头顶文字进行四个点的描边。这里面可能会说一些渲染相关的知识,通常我们在进行渲染描边的时候,我们最开始是需要填入需要渲染的UV三角形的,如果有不是很了解的同学,可以搜查一下渲染的过程,填充完渲染三角形后,CPU才会把这些三角形传递到GPU中,设置渲染状态,从而进行三角形的渲染,得到最后的渲染结果。所以描边要么在CPU中进行,要么在GPU中进行,我选择的是在CPU中进行,在填充三角形的UV的时候,选择扩展这些UV数组。

  基本的实现思想是:原始的UV数组一份,然后分别在左上,右上,左下,右下的四个基准点进行拓展,这样就会得到五个数组,最终描绘出来一个描绘了外轮廓的描边结果,大概结果示意如下图:

                                                           

  2、四方向的描边

  基于四个基准点的UV扩展,是可以实现基本的描边效果,但是仔细推敲就会发现,这其实是对文字的外轮廓进行一个拓展而已,获得的效果其实并不是非常好,如果对描边效果有一定要求,这样的描边并不是很优秀的。果不其然,高层要求优化描边效果。我仔细推想了一下,就把四个基准点的描边变为四个方向的描边,分别为向左,向右,向上,向下的UV扩展,如果用一个文字来表示效果,可以表示为:

                                                                                                              

  读到这儿,我想你也可以自己在头脑中描绘出这样的5份UV,一份为原始的UV,一份为向左偏移一定offset的UV,一份为向右偏移一定offset的UV,一份为向上偏移一定offset的UV,一份为向下偏移一定offset的UV,这5份UV在进过三角形设置后,会传递到GPU中进行三角形描绘,得到的结果就会是比较理想的描边结果,分别描绘了文字的上下左右四个方向。

  这种描边方式有很好的描边效果,带来的消耗,也是可以直接理解的,通过四份UV的复制,而不是简单的四个点的复制,对于内存的占用会更大。可见想要有好的效果,还是需要一定的付出。最后这种描边也被优化掉了,最后采用的是shadow来代替描边,通过动态合批的处理来降低内存占用。不过从这次描边的优化,可以更了解整个渲染的过程,CPU是如何计算UV的,怎么设置UV,最后在GPU上渲染得到对应的效果,都是一个比较直观的过程。

 四、代码的优化

   写到这儿,也提一下对代码质量的优化吧。现在比较主流的热更都会采用lua来实现逻辑,lua这种脚本语言,上手极其容易,但是如果使用不是很仔细,还是会带来一些不必要的问题。table作为Lua的基本构造点,在使用的时候,会有一些可以规避的地方。比如在频繁更新或者使用的代码部分,不要反复申请table,这会使得虚拟机不断的去进行内存分配。我们可以将这些频繁使用的功能相同的table作为一个内部变量存储,在第一次进行申请,当前更新后,将其内部的值赋值为nil,这样下次再使用的时候,是在当前table的基础上进行扩展,这样采取扩展table而不是频繁构建新table的方式,可以避免内存碎片的产生。

  此外在检测代码质量的时候,最好做好相关的工具,进行各种性能统计,我们才能得到实际的性能数据,通过性能数据的分析修改可能存在的问题点。比如对于高频变化的数据,是否采用增删改的方式更能提升性能,对于高频检测的方法,是否通过特殊的规则可以降低检测的次数等等,这些都需要结合实际的应用设计来修改。

  当然,游戏还包含一部分的优化,就是UI部分的优化,这部分可以参考MMO雨松的博客,他主要负责这部分的工作,所以可以参考他的博客,不知道最近他有没有更新博客,哈哈,估计太累了~

       好了,本文也算一个小结,后续我看还有什么需要继续写的,我会再接着写博客,下篇文章见~

当前文章:http://3kjb.watchadopteefilms.com/a/d1417_44.html

发布时间:2017-10-17 19:21:03

我的心没有回程    我的心没有回程  我的心没有回程  我的心没有回程  我的心没有回程  我的心没有回程  我的心没有回程  我的心没有回程  我的心没有回程  

http://www.hnhx.net.cn/57Sp705pm3/201710100395.htmlhttp://www.hnhx.net.cn/F902t5Sp0/201710100139.htmlhttp://www.hnhx.net.cn/9H75j7wB5d/201710100001.htmlhttp://www.hnhx.net.cn/Q1sK9Y7WM5/201710100576.htmlhttp://www.hnhx.net.cn/5B068958d/201710100369.htmlhttp://www.hnhx.net.cn/38B15WnjT3/201710100691.htmlhttp://www.hnhx.net.cn/F902t5Sp0/201710100139.htmlhttp://www.hnhx.net.cn/6x8Y2k0M54/201710100228.htmlhttp://www.hnhx.net.cn/n677167J21/201710100323.htmlhttp://www.hnhx.net.cn/Q1sK9Y7WM5/201710100576.htmlhttp://www.hnhx.net.cn/F902t5Sp0/201710100139.htmlhttp://www.hnhx.net.cn/n677167J21/201710100323.htmlhttp://www.hnhx.net.cn/5B068958d/201710100369.htmlhttp://www.hnhx.net.cn/38B15WnjT3/201710100691.htmlhttp://www.hnhx.net.cn/0577n2486S/201710100281.htmlhttp://www.hnhx.net.cn/8210j97676/201710100705.htmlhttp://www.hnhx.net.cn/7734B06Z6/201710100809.htmlhttp://www.hnhx.net.cn/4047934051/201710100688.htmlhttp://www.hnhx.net.cn/624c6F59C/201710100342.htmlhttp://www.hnhx.net.cn/Tm27D92fqG/201710100264.htmlhttp://www.hnhx.net.cn/F902t5Sp0/201710100139.htmlhttp://www.hnhx.net.cn/8210j97676/201710100705.htmlhttp://www.hnhx.net.cn/38B15WnjT3/201710100691.htmlhttp://www.hnhx.net.cn/57Sp705pm3/201710100395.htmlhttp://www.hnhx.net.cn/Tm27D92fqG/201710100264.htmlhttp://www.hnhx.net.cn/8Xf30982g9/201710100977.htmlhttp://www.hnhx.net.cn/Z94d696264/201710100927.htmlhttp://www.hnhx.net.cn/38B15WnjT3/201710100691.htmlhttp://www.hnhx.net.cn/Q1sK9Y7WM5/201710100576.htmlhttp://www.hnhx.net.cn/624c6F59C/201710100342.htmlhttp://www.hnhx.net.cn/38B15WnjT3/201710100691.htmlhttp://www.hnhx.net.cn/5B068958d/201710100369.htmlhttp://www.hnhx.net.cn/8Xf30982g9/201710100977.htmlhttp://www.hnhx.net.cn/9H75j7wB5d/201710100001.htmlhttp://www.hnhx.net.cn/624c6F59C/201710100342.htmlhttp://www.hnhx.net.cn/Tm27D92fqG/201710100264.htmlhttp://www.hnhx.net.cn/F902t5Sp0/201710100139.htmlhttp://www.hnhx.net.cn/F902t5Sp0/201710100139.htmlhttp://www.hnhx.net.cn/57Sp705pm3/201710100395.htmlhttp://www.hnhx.net.cn/4047934051/201710100688.htmlhttp://www.hnhx.net.cnhttp://www.hnhx.net.cn/Q1sK9Y7WM5/201710100576.htmlhttp://www.hnhx.net.cn/8Xf30982g9/201710100977.htmlhttp://www.hnhx.net.cn/g76wT1409/201710100295.htmlhttp://www.hnhx.net.cn/8210j97676/201710100705.htmlhttp://www.hnhx.net.cn/8210j97676/201710100705.htmlhttp://www.hnhx.net.cn/Tm27D92fqG/201710100264.htmlhttp://www.hnhx.net.cn/38B15WnjT3/201710100691.htmlhttp://www.hnhx.net.cn/0577n2486S/201710100281.htmlhttp://www.hnhx.net.cn/0577n2486S/201710100281.html