“小”游戏也能亮相时代广场 休闲电竞你不知道的那些坑
2017-05-15 12:34:30游戏日报
今年五月份，巨人网络《球球大作战》BPL职业联赛（春季赛）亮相纽约时代广场，成为首个登上时代广场的移动电竞赛事。加之开赛第一天的央视报道，《球球大作战》已逐渐成为了《王者荣耀》之外的又一款收到广泛关注的移动电竞游戏。
2015年6月12日，《球球大作战》在国内发行，2016年，在移动电竞概念化时期提出休闲电竞理念。从一款休闲娱乐的“小”游戏，到走向职业电竞领域，《球球大作战》在这个过程之中所经历的版本更迭，也遭遇到了不少难题。其中，同步、卡顿、地图是《球球大作战》优化中最主要的三个问题。所以，作为一款随即开始的多人实时对战手游，加之美术方面所带来的压力，如何解决这三方面的问题，也是其他游戏开发者所关注的。
在5月13日刚刚落幕的Unite 2017开发者大会上，巨人网络的资深客户端软件工程师李东旭就《球球大作战》的项目优化经验进行了分享。根据游戏日报的现场了解，在演讲的最后部分，李东旭还特地准备了现场提问时间，解答了一些在场开发者的疑惑。
以下为游戏日报所整理的演讲实录
加快迭代速度，降低创新风险
先来简单介绍一下这个游戏，《球球大作战》是全球首款实时对战的休闲手游，一经推出就受到Iphone、安卓双端推荐，迅速风靡全球，取得众多佳绩，深受玩家喜爱。目前该游戏已在全球100多个国家同步上线，并在苹果Appstore中国区游戏免费榜稳居Top10，日均百万玩家的在线，上亿玩家已投入并热爱了这款游戏。
球球是2015年5月份立项，第一个版本两周后就上线了。这个版本主要是核心玩法，两个人，一个前端一个服务器。因为这个玩法比较新颖，无法预估玩家的情况，所以第一个版本就尽快让它面对玩家，让玩家来评估这个新颖的玩法的接受程度。没想到一推出，玩家发现这个游戏非常好玩，非常新颖，以前在手游上没见过。之后我们就大力地去推进这个项目，你可以看到，下面这些版本，基本都是每隔两周，最后三周就发布一个新版本。我讲这个地方的目的是什么？目的就是告诉大家，我们这个版本推进速度是非常快的。
其实直到现在，就是昨天我们也发了一个新版本，基本这两年，每隔两到三周就发一个新版本。这里跟普通的大型手游有区别，区别就是一般的大型手游，他们的开发时间就耗时比较长，从立项到第一个版本见玩家，基本就已经大半年以上了。这种情况下，如果是有过大型游戏的经验还好，但是对那些没经验的团队来说，这个危险性是非常高的。你不知道你做的这些东西，玩家喜不喜欢，很有可能就失败了，失败程度概率是非常高的。
这里就给大家展示一下，我们的版本的一个迭代体系。我们先有一个需求，有一个需求之后，我们就进行开发，开发完成之后就立马进行测试，OK的话就直接发布了。这个周期就两到三周，两到三周做完之后，发布之后，然后下一个版本也是这样一个循环。这样有一个好处，迭代非常快，在做完一个核心玩法之后，马上发布出去来验证这个玩法到底好不好。这个在游戏前期，效果非常好，但是到后期，你的项目越来越庞大，已经很难做到两到三周了。尤其是测试这一块，测试的工作量越来越大，所以这块我们引入了一个测试服的体系。
我们单独做一个版本，这个版本比我们的现在版本功能要新许多，一些新的东西在里面。这个版本给部分玩家用来测试，测试的话，就需要激活码，这样保证一部分玩家能优先玩到新的功能，然后根据新的功能，我们就根据玩家反馈来继续完善，OK的话就发布。这个地方就跟MI ui的开发版跟稳定版挺像的，有了测试服之后，也不是完全的完美，在后面项目越来越复杂，两到三周也很难达到，我们还是尽量在两到三周之内做完一个版本。
为了更加完善我们的玩法还有需求，我们加入了一个玩家反馈的体系，有了这个体系，我们在功能方面，能更正确地做一些选择。这里的玩家反馈大概有这么多，主要的就是通过QQ群，还有游戏反馈，还有玩家见面会这三个大块来直接面对面跟玩家沟通，取得玩家的建议，尤其是每次版本发完之后，有可能会遇到一些问题或者bug，通过游戏内的反馈，能及时看到一些问题，然后通过更新，可以立刻解决。
第一部分已经讲到这里，接下来我分享一下，在之前那些版本迭代过程中，遇到的一些问题，以及我们怎么解决的。主要是三个问题，第一个问题是同步问题，第二个是卡顿的问题，第三个是我们年初的时候做了一个Lbs的玩法，怎么把那个真实的地图显示在Unity里。
四个方面应对同步问题
我们看第一个问题，同步问题，我们是一个实时对战的手游，在同步这块肯定免不了，我们也在一些同步的机制上、模式上，也做了一些选择，然后根据我们游戏的特性，选择合理的同步方案。看一下我们的游戏特性，球球这个游戏主要是球跟球之间的关系，它们的关系规则简单，可以用公式来概括。用的最多就是一些物理的公式，这些比较简单，我们就很容易做出来。
第二个就是快速游戏，这个游戏中途可以随意加入退出，而且我们的进入游戏是没有载入时间，直接点击按纽，就直接进去了。
还有一个就是实时观战，我们的玩家可以观战其他玩家，在这种情况下，客户端是没有任何操作的，全靠服务器把数据发过来。但是这种特性，我们也做了一些选择，最终的方案是状态同步的一个机制模式。这个模式有一些好处，就是开发效率比较高，这个开发效率是相对而言，可能对别的游戏状态同步比较麻烦，但是对我们游戏这种机制，其实开发效率是非常高的。
然后客户端的计算量大大降低，方便性能优化，就是客户端的一些球跟球之间的逻辑，因为是用公式来概括的。而且球跟球之间的计算，因为球很多，所以计算量非常大，这块客户端是不需要计算的，直接通过服务器计算，然后把结果发过来。因为是在服务器上算，这块反外挂也比较简单。
第四个就是断线重连，因为计算都在服务器，所有信息都在服务器，一旦断线，就可以立马连上去，恢复当前的状态。传输协议，我们现在用的是TCP，TCP这块，其实我们现在用的是，大部分情况下还好，主要在延迟情况下，TCP比UDP要更差一点，之后的话会逐步替代成UDP，或者是TCP和UDP共存的情况。
我们看一下服务器逻辑，其实第一个版本我们服务器是不参与计算的，就是P2P的模式，客户端跟其他客户端相互连接，服务器只负责转发客户端之间的消息。这种情况下发现延迟非常高，因为手机跟手机之间，还有网络跟网络之间都是不一样的，大多数情况下你看到一个球，另一个玩家就没看到，然后他被吃了，他不知道怎么回事。所以第二个版本就把计算全部挪到服务器上。服务器这块也是模拟一个流程，就是50帧每秒的刷新，模拟一个真实的环境，发给客户端的话，就是10次每秒，主要发一些球的坐标跟速度，还有吃跟被吃，还有删球加球的逻辑。为了优化这个流量，因为这种同步方式对流量要求比较大一点，所以我们对客户端发送的话，只发送客户端视野里的数据。
看一下客户端的逻辑，客户端的话同步方式就用了一个影子追踪的方式，然后只发送操作数据，这块服务器十秒一次地发过来，我要经过转化，然后把它变成一个数据球，然后数据球的话，是不参与渲染的，这个数据球在Updete里面一直在跑，如果网络延迟，这个球还在跑，保证这个数球跟服务器对应的球是同步在运动，不会因为网络的停止而停止移动。渲染球主要跟着这个数据球作为一个插入平滑，一直追着它跑。这样有一个好处就是，当网络波动的时候，数据球可能会抖动，但是渲染球一直在平滑，在玩家看来基本感觉不到。这个其实就是在网络延迟非常大的情况下，还是因为卡顿，就是延迟，玩家可能操作不太流畅，这块我们还在做深入的优化工作。
如何解决因游戏特点所带来的特殊卡顿原因
第二个问题就是卡顿问题，卡顿问题，基本大家都遇到过，然后就是怎么优化，网上做优化的有很多的方案，就相同的优化点，我就不怎么详细说了。主要介绍一下我们这个球球在卡顿这块的一些，因为特殊原因造成的卡顿是怎么优化的。
球球主要卡顿点就在于，因为服务器是十次每秒刷新，因为是十次，不像客户端帧数比较高，所以你发一次的话，这个数据量里面球的数量其实非常大的，就引起了一个问题。问题是发过来这一刻，要处理大量的数据，会造成卡顿。还有就是美术方面的问题，因为我们球上面挂了很多组件，这些组件尤其光环和圣衣这个东西越做越炫，会引起卡顿，而且我们一局游戏，有50多个人，而且中途还会再加入新的玩家，如果提前进这局游戏之前把所有东西都加载到，这个内存是肯定承受不了的。而且我们是没有加载立即进入游戏，这就造成一个问题，我们必须要在玩的过程中来加载美术资源，这样也会引起卡顿。
遇到一个卡顿的话，我们得找这个卡顿在哪里？然后找到的话，我们得分析是由于什么东西造成的。球球这块，刚才也整个介绍了一下，主要就是这两个地方。先看一下球体组件的加载，球体组件的话，我们光环跟圣衣现在已经有几百多个了，有三百多个，最坏的情况下，可能每个玩家用的光环跟圣衣都不一样，这样在一局游戏里面都显示出来的话，对游戏的内存，及其渲染，其实压力非常之大。这个只是一部分，主要是光环。现在玩家审美要求越来越高，我们做的东西也越来越炫，这样造成非常多的卡顿，接下来给大家介绍一下我们是怎么优化这块。美术这块优化，这次没怎么讲，因为网上美术这块怎么优化有很多，我主要讲是怎么加载的。
我们先看一下组件的构成，一个球本体是一个球，这个球其实是一个2D的一个慢视平面的，然后名字，名字这块我们是用自己做的一个，等于是自己写，自己写的好处就是效力比较高，可以走Unity自己的那个合P（音）流程，然后那个国旗也是一个慢视，不是用UI做的。还有光环、拖尾圣衣，还有箭头，这些加载压力都非常大的。我们是怎么优化这块，优化主要用到分帧处理。
分帧处理大家应该多少都了解到就是把一堆大量的计算全部拆开来，分散到到各个帧里面，这样的话帧数就很平稳，不会出现一个大的CPU曲线的波峰。每个球依次进行加载，一个球加载完了，再加载另一个球，有可能球2还没有加载完，就已经被吃掉了。因此，我们就减少了大量的计算，大量的加载。而且玩家看的话也是比较流畅，不会出现突然画面不动，然后又开始动了的那种情况。
然后优化后，我们发现帧数是上来了，但是还是有很大的波动，这块主要原因就是大视野大量球的刷新卡顿。因为我们的游戏视野是不固定的，不像其他游戏视野一直固定的，在同一屏里面看的东西基本不会高的太多，我们游戏就不同了。有可能一个屏幕里面，可能看到成百上千个元素还有物体。而且玩家在玩的过程中，如果玩得好的话，视野是来回变动的，服务器发数据的话，因为只发我们看到的数据，所以我们玩家在来回切换的情况下，服务器发的数据也是很多的，就是大量的球跟添加删除，这样的一个操作对客户端的压力也非常大，所以客户端的话，就需要做一些计算，一些处理，这里就很考验一个场景管理的框架。
这块我们主要是有两个策略，就是双缓冲列表还有分帧添加和删除。分帧这块在组件加载那块已经讲过了，逻辑差不多。双缓冲列表简单来说，就是两种列表。第一个就是添加列表，第二个就是删除列表，有了这个列表，在实际加载球的过程中，我们可以有列表作为缓冲。这个好处就是有了缓冲，如果有重复的球，我们就不需要重复地进行加载，所以在这个列表里面进行合并或者去除。
比如说当一个新加载球要过来的时候，我们如果判断这个，或者判断这个场景里面有这个球，或者这个列表里面有这个球，我们就可以不用处理。如果一个删除的球进来的话，我们判断这个删除列表里面已经有了这个球，我们也可以不用处理。或者就算没有，可以看到如果添加列表里面有，我们可以把添加列表里面要删除的球去掉，这样我们就能省掉很大量的工作。这块的话，又引出了一个问题，因为列表是用List（音），如果要找这个列表很长，可能有几百个元素，用List的话，因为要一个个辨别，效率非常低，我们就把List和字典做了一个结合，既查找得快，也能删除得快。
分帧添加删除这块，跟组件加载不一样的地方每一帧加载或者删除的元素是动态变，可以根据手机帧率，如果手机帧率特别高，可以每帧处理的元素就很多，如果帧率低了，我们就可以动态地减少，这样可以控制手机帧率来回波动的情况。
关于优化的效果，大概是这样的效果，优化后整个波动就比较平缓，大家可以看到，上面有一些小波峰，就是一些处理的结果，但是很难出现那种大的波动，这是一个理想的情况。其实玩的过程中，还是会出现波动情况。因为美术资源那块有一个东西如果非常大的话，也会造成一定的影响。这块美术资源后期我们会做一个低端机型的美术资源包来替换，这样可以保证在低端机上也能流畅玩下去。
借鉴口袋妖怪，将Unity技术运用到高德地图
第三点，我们讲一下地图的一个显示。年初的时候，我们打算做一个BS的玩法，因为之前有口袋妖怪结合了地图和游戏玩法相关的，当时在没研究之前，我是觉得挺简单，就把地图显示进来，后来做的时候发现，其实非常难，难点主要在于你怎么把地图显示进来。因为我们不是专门做地图的，我们没有数据，就算有了数据，我们不知道怎么来画出来，显示出来。当时想到的一个比较完美的方案就是地图就在Unity里面，然后我们可以依托上面，可以做一些复杂的操作，可以放一些模型什么的，这是我们的目标。
实际执行的过程中发现，其实没有现成的方案，就是参考国内的SDK。发现没有专门给Unity做SDK的一个SDK，主要效果就是Unity的渲染跟SDK的渲染，它们是相互独立的。你想看地图得切到SDK那个上面去，这样的话Unity的一些UI就看不见了。如果你要做一些UI操作的话，就必须在底层，SDK那块再写一套，再写一套是可以，因为市面上有一些游戏是这样做过。但是有一个问题，你这样做出来的UI，只能做的非常简单，很难做一些复杂操作。
比如说你在游戏里面其他界面，因为玩家有可能会查看其他网页的信息，这个信息界面又要在游戏里面做一遍？我们玩家的个人主页其实非常复杂，里面有非常多的东西，如果重新做一遍，一个是难度比较高，因为在底层做不好实现。第二个就是时间的话要求也非常紧，可能也做不到。当时看到口袋妖怪，他也是能在Unity里面做的，我们就很好奇他怎么做的，他跟谷歌有深入合作，就是谷歌专门给他做了一套东西，让他在Unity里面显示出来。这块我们询问了大量的SDK的工作人员，好消息就是，我们找到了高德，跟高德深度地合作，我们给他提供Unity的一些技术，他们提供SDK的技术，我们深度合作，通过Unity底层，因为Unity刚好发现了一个底层接口，可以把我们Unity那边的图像传到SDK，这样SDK就不用渲染在页面上，而是渲染在图片上，我们就在SDK里面看到，就实现了可以看到地图。而且是SDK本身在画，所以这个效率非常高的。
因此，我们实现了一个浏览器的功能，可以把地图按照一块一块的图片来加载下来，来显示在Unity里面，这是一个折衷。当时这种方案，有两个问题，第一个问题就是流量比较大，而且有可能某一块地图，可能加载不当，可能就显示不是特别好，而且因为是真正的图片，斜着看，那些字都是斜的，很难有立体的感觉。幸好最后做成这样了一个效果，这样玩法的话，玩家也是非常喜欢的。
在会后，现场的开发者也就如何解决字体斜版的问题向李东旭提出了疑惑，对此，李东旭解释道，由于地图方面是由高德地图做出来的，而高德的内部机制也是一个摄像机在看一个斜的地图，这样的话自己画字，就成了竖版，出来的字就是立体的。
2015年6月12日，《球球大作战》在国内发行，2016年，在移动电竞概念化时期提出休闲电竞理念。从一款休闲娱乐的“小”游戏，到走向职业电竞领域，《球球大作战》在这个过程之中所经历的版本更迭，也遭遇到了不少难题。其中，同步、卡顿、地图是《球球大作战》优化中最主要的三个问题。所以，作为一款随即开始的多人实时对战手游，加之美术方面所带来的压力，如何解决这三方面的问题，也是其他游戏开发者所关注的。
在5月13日刚刚落幕的Unite 2017开发者大会上，巨人网络的资深客户端软件工程师李东旭就《球球大作战》的项目优化经验进行了分享。根据游戏日报的现场了解，在演讲的最后部分，李东旭还特地准备了现场提问时间，解答了一些在场开发者的疑惑。
加快迭代速度，降低创新风险
先来简单介绍一下这个游戏，《球球大作战》是全球首款实时对战的休闲手游，一经推出就受到Iphone、安卓双端推荐，迅速风靡全球，取得众多佳绩，深受玩家喜爱。目前该游戏已在全球100多个国家同步上线，并在苹果Appstore中国区游戏免费榜稳居Top10，日均百万玩家的在线，上亿玩家已投入并热爱了这款游戏。
球球是2015年5月份立项，第一个版本两周后就上线了。这个版本主要是核心玩法，两个人，一个前端一个服务器。因为这个玩法比较新颖，无法预估玩家的情况，所以第一个版本就尽快让它面对玩家，让玩家来评估这个新颖的玩法的接受程度。没想到一推出，玩家发现这个游戏非常好玩，非常新颖，以前在手游上没见过。之后我们就大力地去推进这个项目，你可以看到，下面这些版本，基本都是每隔两周，最后三周就发布一个新版本。我讲这个地方的目的是什么？目的就是告诉大家，我们这个版本推进速度是非常快的。
其实直到现在，就是昨天我们也发了一个新版本，基本这两年，每隔两到三周就发一个新版本。这里跟普通的大型手游有区别，区别就是一般的大型手游，他们的开发时间就耗时比较长，从立项到第一个版本见玩家，基本就已经大半年以上了。这种情况下，如果是有过大型游戏的经验还好，但是对那些没经验的团队来说，这个危险性是非常高的。你不知道你做的这些东西，玩家喜不喜欢，很有可能就失败了，失败程度概率是非常高的。
这里就给大家展示一下，我们的版本的一个迭代体系。我们先有一个需求，有一个需求之后，我们就进行开发，开发完成之后就立马进行测试，OK的话就直接发布了。这个周期就两到三周，两到三周做完之后，发布之后，然后下一个版本也是这样一个循环。这样有一个好处，迭代非常快，在做完一个核心玩法之后，马上发布出去来验证这个玩法到底好不好。这个在游戏前期，效果非常好，但是到后期，你的项目越来越庞大，已经很难做到两到三周了。尤其是测试这一块，测试的工作量越来越大，所以这块我们引入了一个测试服的体系。
我们单独做一个版本，这个版本比我们的现在版本功能要新许多，一些新的东西在里面。这个版本给部分玩家用来测试，测试的话，就需要激活码，这样保证一部分玩家能优先玩到新的功能，然后根据新的功能，我们就根据玩家反馈来继续完善，OK的话就发布。这个地方就跟MI ui的开发版跟稳定版挺像的，有了测试服之后，也不是完全的完美，在后面项目越来越复杂，两到三周也很难达到，我们还是尽量在两到三周之内做完一个版本。
为了更加完善我们的玩法还有需求，我们加入了一个玩家反馈的体系，有了这个体系，我们在功能方面，能更正确地做一些选择。这里的玩家反馈大概有这么多，主要的就是通过QQ群，还有游戏反馈，还有玩家见面会这三个大块来直接面对面跟玩家沟通，取得玩家的建议，尤其是每次版本发完之后，有可能会遇到一些问题或者bug，通过游戏内的反馈，能及时看到一些问题，然后通过更新，可以立刻解决。
第一部分已经讲到这里，接下来我分享一下，在之前那些版本迭代过程中，遇到的一些问题，以及我们怎么解决的。主要是三个问题，第一个问题是同步问题，第二个是卡顿的问题，第三个是我们年初的时候做了一个Lbs的玩法，怎么把那个真实的地图显示在Unity里。
我们看第一个问题，同步问题，我们是一个实时对战的手游，在同步这块肯定免不了，我们也在一些同步的机制上、模式上，也做了一些选择，然后根据我们游戏的特性，选择合理的同步方案。看一下我们的游戏特性，球球这个游戏主要是球跟球之间的关系，它们的关系规则简单，可以用公式来概括。用的最多就是一些物理的公式，这些比较简单，我们就很容易做出来。
第二个就是快速游戏，这个游戏中途可以随意加入退出，而且我们的进入游戏是没有载入时间，直接点击按纽，就直接进去了。
还有一个就是实时观战，我们的玩家可以观战其他玩家，在这种情况下，客户端是没有任何操作的，全靠服务器把数据发过来。但是这种特性，我们也做了一些选择，最终的方案是状态同步的一个机制模式。这个模式有一些好处，就是开发效率比较高，这个开发效率是相对而言，可能对别的游戏状态同步比较麻烦，但是对我们游戏这种机制，其实开发效率是非常高的。
然后客户端的计算量大大降低，方便性能优化，就是客户端的一些球跟球之间的逻辑，因为是用公式来概括的。而且球跟球之间的计算，因为球很多，所以计算量非常大，这块客户端是不需要计算的，直接通过服务器计算，然后把结果发过来。因为是在服务器上算，这块反外挂也比较简单。
第四个就是断线重连，因为计算都在服务器，所有信息都在服务器，一旦断线，就可以立马连上去，恢复当前的状态。传输协议，我们现在用的是TCP，TCP这块，其实我们现在用的是，大部分情况下还好，主要在延迟情况下，TCP比UDP要更差一点，之后的话会逐步替代成UDP，或者是TCP和UDP共存的情况。
我们看一下服务器逻辑，其实第一个版本我们服务器是不参与计算的，就是P2P的模式，客户端跟其他客户端相互连接，服务器只负责转发客户端之间的消息。这种情况下发现延迟非常高，因为手机跟手机之间，还有网络跟网络之间都是不一样的，大多数情况下你看到一个球，另一个玩家就没看到，然后他被吃了，他不知道怎么回事。所以第二个版本就把计算全部挪到服务器上。服务器这块也是模拟一个流程，就是50帧每秒的刷新，模拟一个真实的环境，发给客户端的话，就是10次每秒，主要发一些球的坐标跟速度，还有吃跟被吃，还有删球加球的逻辑。为了优化这个流量，因为这种同步方式对流量要求比较大一点，所以我们对客户端发送的话，只发送客户端视野里的数据。
看一下客户端的逻辑，客户端的话同步方式就用了一个影子追踪的方式，然后只发送操作数据，这块服务器十秒一次地发过来，我要经过转化，然后把它变成一个数据球，然后数据球的话，是不参与渲染的，这个数据球在Updete里面一直在跑，如果网络延迟，这个球还在跑，保证这个数球跟服务器对应的球是同步在运动，不会因为网络的停止而停止移动。渲染球主要跟着这个数据球作为一个插入平滑，一直追着它跑。这样有一个好处就是，当网络波动的时候，数据球可能会抖动，但是渲染球一直在平滑，在玩家看来基本感觉不到。这个其实就是在网络延迟非常大的情况下，还是因为卡顿，就是延迟，玩家可能操作不太流畅，这块我们还在做深入的优化工作。
如何解决因游戏特点所带来的特殊卡顿原因
第二个问题就是卡顿问题，卡顿问题，基本大家都遇到过，然后就是怎么优化，网上做优化的有很多的方案，就相同的优化点，我就不怎么详细说了。主要介绍一下我们这个球球在卡顿这块的一些，因为特殊原因造成的卡顿是怎么优化的。
球球主要卡顿点就在于，因为服务器是十次每秒刷新，因为是十次，不像客户端帧数比较高，所以你发一次的话，这个数据量里面球的数量其实非常大的，就引起了一个问题。问题是发过来这一刻，要处理大量的数据，会造成卡顿。还有就是美术方面的问题，因为我们球上面挂了很多组件，这些组件尤其光环和圣衣这个东西越做越炫，会引起卡顿，而且我们一局游戏，有50多个人，而且中途还会再加入新的玩家，如果提前进这局游戏之前把所有东西都加载到，这个内存是肯定承受不了的。而且我们是没有加载立即进入游戏，这就造成一个问题，我们必须要在玩的过程中来加载美术资源，这样也会引起卡顿。
遇到一个卡顿的话，我们得找这个卡顿在哪里？然后找到的话，我们得分析是由于什么东西造成的。球球这块，刚才也整个介绍了一下，主要就是这两个地方。先看一下球体组件的加载，球体组件的话，我们光环跟圣衣现在已经有几百多个了，有三百多个，最坏的情况下，可能每个玩家用的光环跟圣衣都不一样，这样在一局游戏里面都显示出来的话，对游戏的内存，及其渲染，其实压力非常之大。这个只是一部分，主要是光环。现在玩家审美要求越来越高，我们做的东西也越来越炫，这样造成非常多的卡顿，接下来给大家介绍一下我们是怎么优化这块。美术这块优化，这次没怎么讲，因为网上美术这块怎么优化有很多，我主要讲是怎么加载的。
我们先看一下组件的构成，一个球本体是一个球，这个球其实是一个2D的一个慢视平面的，然后名字，名字这块我们是用自己做的一个，等于是自己写，自己写的好处就是效力比较高，可以走Unity自己的那个合P（音）流程，然后那个国旗也是一个慢视，不是用UI做的。还有光环、拖尾圣衣，还有箭头，这些加载压力都非常大的。我们是怎么优化这块，优化主要用到分帧处理。
分帧处理大家应该多少都了解到就是把一堆大量的计算全部拆开来，分散到到各个帧里面，这样的话帧数就很平稳，不会出现一个大的CPU曲线的波峰。每个球依次进行加载，一个球加载完了，再加载另一个球，有可能球2还没有加载完，就已经被吃掉了。因此，我们就减少了大量的计算，大量的加载。而且玩家看的话也是比较流畅，不会出现突然画面不动，然后又开始动了的那种情况。
然后优化后，我们发现帧数是上来了，但是还是有很大的波动，这块主要原因就是大视野大量球的刷新卡顿。因为我们的游戏视野是不固定的，不像其他游戏视野一直固定的，在同一屏里面看的东西基本不会高的太多，我们游戏就不同了。有可能一个屏幕里面，可能看到成百上千个元素还有物体。而且玩家在玩的过程中，如果玩得好的话，视野是来回变动的，服务器发数据的话，因为只发我们看到的数据，所以我们玩家在来回切换的情况下，服务器发的数据也是很多的，就是大量的球跟添加删除，这样的一个操作对客户端的压力也非常大，所以客户端的话，就需要做一些计算，一些处理，这里就很考验一个场景管理的框架。
这块我们主要是有两个策略，就是双缓冲列表还有分帧添加和删除。分帧这块在组件加载那块已经讲过了，逻辑差不多。双缓冲列表简单来说，就是两种列表。第一个就是添加列表，第二个就是删除列表，有了这个列表，在实际加载球的过程中，我们可以有列表作为缓冲。这个好处就是有了缓冲，如果有重复的球，我们就不需要重复地进行加载，所以在这个列表里面进行合并或者去除。
比如说当一个新加载球要过来的时候，我们如果判断这个，或者判断这个场景里面有这个球，或者这个列表里面有这个球，我们就可以不用处理。如果一个删除的球进来的话，我们判断这个删除列表里面已经有了这个球，我们也可以不用处理。或者就算没有，可以看到如果添加列表里面有，我们可以把添加列表里面要删除的球去掉，这样我们就能省掉很大量的工作。这块的话，又引出了一个问题，因为列表是用List（音），如果要找这个列表很长，可能有几百个元素，用List的话，因为要一个个辨别，效率非常低，我们就把List和字典做了一个结合，既查找得快，也能删除得快。
分帧添加删除这块，跟组件加载不一样的地方每一帧加载或者删除的元素是动态变，可以根据手机帧率，如果手机帧率特别高，可以每帧处理的元素就很多，如果帧率低了，我们就可以动态地减少，这样可以控制手机帧率来回波动的情况。
关于优化的效果，大概是这样的效果，优化后整个波动就比较平缓，大家可以看到，上面有一些小波峰，就是一些处理的结果，但是很难出现那种大的波动，这是一个理想的情况。其实玩的过程中，还是会出现波动情况。因为美术资源那块有一个东西如果非常大的话，也会造成一定的影响。这块美术资源后期我们会做一个低端机型的美术资源包来替换，这样可以保证在低端机上也能流畅玩下去。
第三点，我们讲一下地图的一个显示。年初的时候，我们打算做一个BS的玩法，因为之前有口袋妖怪结合了地图和游戏玩法相关的，当时在没研究之前，我是觉得挺简单，就把地图显示进来，后来做的时候发现，其实非常难，难点主要在于你怎么把地图显示进来。因为我们不是专门做地图的，我们没有数据，就算有了数据，我们不知道怎么来画出来，显示出来。当时想到的一个比较完美的方案就是地图就在Unity里面，然后我们可以依托上面，可以做一些复杂的操作，可以放一些模型什么的，这是我们的目标。
实际执行的过程中发现，其实没有现成的方案，就是参考国内的SDK。发现没有专门给Unity做SDK的一个SDK，主要效果就是Unity的渲染跟SDK的渲染，它们是相互独立的。你想看地图得切到SDK那个上面去，这样的话Unity的一些UI就看不见了。如果你要做一些UI操作的话，就必须在底层，SDK那块再写一套，再写一套是可以，因为市面上有一些游戏是这样做过。但是有一个问题，你这样做出来的UI，只能做的非常简单，很难做一些复杂操作。
比如说你在游戏里面其他界面，因为玩家有可能会查看其他网页的信息，这个信息界面又要在游戏里面做一遍？我们玩家的个人主页其实非常复杂，里面有非常多的东西，如果重新做一遍，一个是难度比较高，因为在底层做不好实现。第二个就是时间的话要求也非常紧，可能也做不到。当时看到口袋妖怪，他也是能在Unity里面做的，我们就很好奇他怎么做的，他跟谷歌有深入合作，就是谷歌专门给他做了一套东西，让他在Unity里面显示出来。这块我们询问了大量的SDK的工作人员，好消息就是，我们找到了高德，跟高德深度地合作，我们给他提供Unity的一些技术，他们提供SDK的技术，我们深度合作，通过Unity底层，因为Unity刚好发现了一个底层接口，可以把我们Unity那边的图像传到SDK，这样SDK就不用渲染在页面上，而是渲染在图片上，我们就在SDK里面看到，就实现了可以看到地图。而且是SDK本身在画，所以这个效率非常高的。
因此，我们实现了一个浏览器的功能，可以把地图按照一块一块的图片来加载下来，来显示在Unity里面，这是一个折衷。当时这种方案，有两个问题，第一个问题就是流量比较大，而且有可能某一块地图，可能加载不当，可能就显示不是特别好，而且因为是真正的图片，斜着看，那些字都是斜的，很难有立体的感觉。幸好最后做成这样了一个效果，这样玩法的话，玩家也是非常喜欢的。
在会后，现场的开发者也就如何解决字体斜版的问题向李东旭提出了疑惑，对此，李东旭解释道，由于地图方面是由高德地图做出来的，而高德的内部机制也是一个摄像机在看一个斜的地图，这样的话自己画字，就成了竖版，出来的字就是立体的。