游戏服务器千人同屏的思考

    本文章无代码，干聊对同屏人数的思考

前端的思考

    本人是做服务器，前端不太懂，但是能确定的是在特定的引擎和优化程度下，前端能支持的模型的面数是有限的，所以优化的重点不是怎么承载更多面数。

后端的思考

   这个我就有发言权了，之前做的测试，单场景200机器人战斗，用两种分布策略，一种是大致平均分散到场景个个角落，另一种是200机器人在同一视野内，CPU相差了7、8倍的样子，主要原因是聚堆广播量太大，消息的序列化和申请内存都消耗了很多，内存到产生gc造成cpu压力增大，前端的体验也是巨卡

 

整体思考

    在千人同屏情况下，势必要做玩家模型的隐藏，技能特效的隐藏，在一个角色比较精致的游戏里，同屏显示人数不超过20人，你敢信？大部分游戏都是前端隐藏20人以外的玩家，那么就会有一种浪费，后端明明发了玩家行为的协议，但是被前端过滤了，造成后端CPU的浪费。所以我的方案是后端决定哪些玩家显示给前端，同时后端也能决定消息改发送给谁。

 

围绕两个问题

    哪些人需要隐藏！哪些协议需要过滤

 

哪些人需要隐藏

    这个可根据策划偏好的来设定，比如同队伍优先，同帮派优先，距离近优先，或者混合策略。还有一个就是这里要说的重点是怎么实现。

    首先在玩家上创建两个集合，一个存储我看到了谁： 观察者列表，另一个存储我被谁看到：被观察者列表。

    举个例子吧，A可以看到B和C，B能看到C，重点就在于A看到了B，B的广播消息发送给前端，但是B定看到A，A的广播消息不用发给前端。想想一下如果只有一个观察者列表，A看到了B，A就把产生的广播消息广播给了B，但是对于B来说，A玩家是隐藏的，广播的消息很可能被前端过滤掉，在人多的情况下命中率大大降低。

    观察者列表使用了优化过的优先队列（根据策划提出的玩家过滤需求优化），定时更新或有特殊事件的时候强制刷新，刷新的同时和上一次的观察者列表比较，对于新增的玩家，把自己加入到玩家的被观察者列表，对于减少的玩家，把自己从玩家的被观察列表移除，被观察者列表使用HashSet就可以了。

 

哪些协议需要过滤

    简而言之就是非增量的协议，增量的消息都是下一个协议基于上一个协议，比如移动消息，第一条协议从A移动到B，第二条协议从B移动到C，那么必须给所有玩家发A到B B到C的完整协议，否则突然被加入到观察者列表时会出现位置不同步问题；非增量协议例如释放技能、状态、buff（状态buff量很大并且是增量协议，但是显示上不是很重要，在人多的时候出现buff效果和图标消失也可以忍受，暂时归为增量协议）

 

额外：怪物的广播

   可按照玩家被观察者列表的数量决定是否广播

 

压测

    压测条件：600人较平均分布全场景，同屏最大30人（按手机最高配），不间断战斗

    优化前：消息发送数量7065682次，消息总大小382MB，CPU 500%

    优化后：消息发送数量4624335次，消息总大小292MB，CPU 360%

    理论上人越多，效果会越好，有时间再测