码迷,mamicode.com
首页 > 移动开发 > 详细

网页游戏服务端-人物移动广播优化

时间:2014-05-21 17:27:16      阅读:327      评论:0      收藏:0      [点我收藏+]

标签:style   blog   c   http   a   strong   

【本文转自网络http://janeky.iteye.com/blog/1614175

这段时间在处理服务端人物移动广播遇到了问题,记录一下。

 

1.问题

现在的页游都朝着客户端的方向靠齐了,大地图,千人同屏。因此,也给页游的服务端开发带来了不少的挑战。假设一个场景地图是8000*8000大小,同时有1000人在。1秒钟内,每个玩家移动一次。按照最原始的做法,就是给同一个场景的用户广播消息。简单计算一下广播量:1000*1000=1000000的广播量,有点恐怖。

 

2.方案

优化的目标肯定是减少广播量了。我们看到,场景特别大,这对于美术同事来说不是什么好事了,对于服务端来说,未尝是坏事。假设最理想的状态下,用户能够遍布各个角落。那么,我们只想向能看到移动目标的用户广播消息就行了。假设一个屏幕大小为1600*1000,一个屏幕理论上分布了8000*8000/(1600*1000)=25人。还是每秒每个人移动一次,总的广播消息量是:25*25*40 = 25000.哈哈,整整少了40倍的广播量,服务端压力少了,替老板省了不少钱,回去申请加点奖金吧。

 

3.实现

按照上面的思路,实现起来就非常简单了。以前是给场景的每个用户广播,现在只需增加一步筛选的过程,根据坐标选择视范围内能看到移动目标的玩家。方法比较简单,这里就不提供详细的代码实现了,还有不清楚的,可以留言讨论一下。

 

4.优化

做到上面的,基本上已经符合标准了。但是,作为搞技术的,追求完美是无止境的。我们又在想,还能不能进一步优化?好的优化总是在仔细分析问题的基础上产生的。我们相信分析一下广播的内容,加入a移动了,那么在同屏的b,c分别会受到一条广播,内容大致是(a,from,to).同理,b移动了,a,c也是受到这样类型的广播。c在同一个时间段收到了两条广播。这两条广播能否合并呢,变成(a,from,to;b,from,to).这就是优化的灵感了。对于实时性不高的回合制页游(非即使战斗arpg),玩家看到其他玩家的移动,并不要求一定实时。为此,我们可以考虑合并

消息。

 

实现起来非常简单,可以用一种类似生产者-消费者的模型来实现。每次前端发来的位移消息都放入队列。后端有个独立的线程,每隔一段时间,取出来数据,合并消息,广播给相关的用户。上述a,b位移后,c只收到一条消息了

 

5.总结

很多问题的解决是来自对问题的透彻理解。遇到问题,我们应该庆幸,又有折腾了。

网页游戏服务端-人物移动广播优化,布布扣,bubuko.com

网页游戏服务端-人物移动广播优化

标签:style   blog   c   http   a   strong   

原文地址:http://www.cnblogs.com/em-x/p/3740393.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!