某页游erlang服务端广播算法效率好差,应该算是一个bug了吧

偶然得到一份erlang网页服务端的代码

不得不说写的非常优雅,文档也非常不错,但我看到他的场景管理中的广播算法,不得不说写的很漂亮,但效率非常低。

每次都全局遍历全部在线玩家在某个场景的玩具ID,这样的算法,我不知道一个服能撑起多少人,优化一下,场景服务管理在他服务中的玩家,NPC,MON,效率会提升好几倍,只是代码会稍微复杂一点,没他写的优雅了!!

%%  获取要广播的范围用户ID
get_broadcast_id(Q, X0, Y0) ->
    AllUser = ets:match(?ETS_ONLINE, #ets_online{id = '$1',x = '$2', y='$3', scene = Q, _='_'}),<span style="color:#ff6666;"> %% 这句代码效率会很差的,而去执行的次数又多</span>
    XY2 = lib_scene:get_xy(X0, Y0),
    get_broadcast_id_loop(AllUser, XY2, []).

get_broadcast_id_loop([], _XY2, D) ->
    D;
get_broadcast_id_loop([[Id, X, Y]|T], XY2, D) ->
    XY = lib_scene:get_xy(X, Y),
    if
        XY == XY2 orelse XY == XY2 + 1 orelse XY == XY2 -1 orelse XY == XY2 -8 orelse XY == XY2 +8 orelse XY == XY2 -9 orelse XY == XY2 +9 orelse XY == XY2 -7  orelse XY == XY2+7 ->
            get_broadcast_id_loop(T, XY2, D++[Id]);
        true->
            get_broadcast_id_loop(T, XY2, D)
    end.
时间: 2024-08-05 12:14:44

某页游erlang服务端广播算法效率好差,应该算是一个bug了吧的相关文章

手游页游和端游的服务端的架构与区别

转自:http://www.gameres.com/336666.html 手游页游和端游的服务端本质上没区别,区别的是游戏类型. 类型1:卡牌.跑酷等弱交互服务端 卡牌跑酷类因为交互弱,玩家和玩家之间不需要实时面对面PK,打一下对方的离线数据,计算下排行榜,买卖下道具即可,所以实现往往使用简单的 HTTP服务器: 登录时可以使用非对称加密(RSA, DH),服务器根据客户端uid,当前时间戳还有服务端私钥,计算哈希得到的加密 key 并发送给客户端.之后双方都用 HTTP通信,并用那个key进

(2)小项目----建立erlang服务端

原本打算在window下在quick里面嵌入protobuf,发现错误很多.研究一天都没搞好.只能休息下搞下erlang服务端,先将服务端搞好再回头嵌入protobuf到quick. 在window下不能用rebar,只能自己管理.erlang 是自己弱项.做个简单的服务端基于OTP框架,是一个标准的实现,以后再慢慢扩张吧. (1).建立好目录doc,ebin,include,priv,src,testClient (2).在ebin目录下加入元数据server.app,用来启动applicat

还等什么 是页游进军移动端的饭点了

上点新鲜菜,HTML5游戏给页游进军手游圈做好了科普,不仅仅远景上能够将页游积累的经验和庞大的游戏资源借助HTML5平移到移动端上,更关键的是近景上,玩家对玩法的渴望,给了玩法越来越新奇特的页游们机会. 文/张书乐 <围住神经猫>的流行告诉我们什么?是极简小游戏再次掀起现象级风暴吗?错,这不过是表面.神经猫的流行映射出两个未来的游戏趋势,其一是HTML5技术支撑的游戏将在手机屏幕上越来越多,其二是手机上的HTML5游戏根本就是页游移动版,原来我们一直误解了移动游戏,它的近亲不是端游,而是页游.

页游大佬烧端游冷灶 不是说都没落了吗?

反其道行之,走端游路线,却可在众巨头无暇顾及之时,取得意想不到的效果,亦能将在页游平台上的经验,顺利转移过来. 文/张书乐 当业内大多把目光投向日趋红海的移动游戏之时,2014年的客户端网游注定是落寞的.一个有趣的新闻点是,象征着中国游戏行业至高荣誉之战的2014金翎奖评选中,共收到各游戏企业提交的合格参评产品300余款,其中手机游戏类奖项竞争最为激烈,200余款手机游戏产品角逐6个相关奖项. 可在业界几乎一致看衰端游之时,借助平台之力而成为页游大佬的奇虎360却出人意料的宣布和炫美食杰首款刀塔

游戏服务端中使用Servlet和Java注解的一个好设计

SNS类游戏基本都是使用HTTP短连接,用Java来开发服务端时可以使用Servlet+Tomcat很轻松的架构起服务端来.在这里介绍一种使用Servlet比较好的一种设计,我也见过很多基于HTTP请求的游戏服务端使用Struts.Spring.Hibernate等等,其实我感觉对于游戏来说使用这些东西很繁琐,若是开发Java Web应用使用SSH倒是合情合理. 使用Servlet时,我们可以只创建一个Servlet左游戏中所有请求的入口,然后使用注解来标识方法,在程序启动时使用反射去收集注解的

SignalR 教程二 服务端广播

转帖官方教程:Tutorial: Server Broadcast with SignalR 2 http://www.asp.net/signalr/overview/getting-started/tutorial-server-broadcast-with-signalr This tutorial shows how to create a web application that uses ASP.NET SignalR 2 to provide server broadcast fu

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

[本文转自网络http://janeky.iteye.com/blog/1614175] 这段时间在处理服务端人物移动广播遇到了问题,记录一下. 1.问题 现在的页游都朝着客户端的方向靠齐了,大地图,千人同屏.因此,也给页游的服务端开发带来了不少的挑战.假设一个场景地图是8000*8000大小,同时有1000人在.1秒钟内,每个玩家移动一次.按照最原始的做法,就是给同一个场景的用户广播消息.简单计算一下广播量:1000*1000=1000000的广播量,有点恐怖. 2.方案 优化的目标肯定是减少

手游、页游和端游服务端的架构与区别

GameRes游资网发布, 文 / 韦易笑 手游页游和端游的服务端本质上没区别,区别的是游戏类型. 类型1:卡牌.跑酷等弱交互服务端 卡牌跑酷类因为交互弱,玩家和玩家之间不需要实时面对面PK,打一下对方的离线数据,计算下排行榜,买卖下道具即可,所以实现往往使用简单的 HTTP服务器: 登录时可以使用非对称加密(RSA, DH),服务器根据客户端uid,当前时间戳还有服务端私钥,计算哈希得到的加密 key 并发送给客户端.之后双方都用 HTTP通信,并用那个key进行RC4加密.客户端收到key和

端游及手游服务端的常用架构

这篇文章还是讲的不错的: http://www.cocoachina.com/game/20150924/13545.html <开发者详解:端游及手游服务端的常用架构> 整理自知乎,文/韦易笑 开始的部分讲的比较简略.讲到后面大型MMO以及战网游戏,就比较入流了. 开宗明义,手游页游和端游的服务端本质上没区别,区别的是游戏类型. 类型1:卡牌.跑酷等弱交互服务端 卡牌跑酷类因为交互弱,玩家和玩家之间不需要实时面对面PK,打一下对方的离线数据,计算下排行榜,买卖下道具即可,所以实现往往使用简单