关于MMORPG开发遇到的困惑

0

我看了BrowserQuest的实现,在WORKER里创建了世界,世界里面的怪物区域采用TIMER进行刷新和AI处理,这个游戏业务逻辑比较简单,玩家也少,如果同时承载大量玩家的话,感觉这个WORKER响应会出现延迟。


现在我想实现一个MMORPG的游戏,用GateWayWoker的模型,如果把怪物也按照BrowserQuest放到一个WORKER里,应该会有很多问题,我想了一种解决方案,请大神帮我评估一下,如果这样做不好,有没有什么更好的方案。


在现有的GateWayWoker基础上,新增几种地图WORKER类型(以下简称MAPWORKER)与GATEWAY异步连接,MAPWORKER根据地图逻辑复杂程度开启相应的进程数量,GATEWAY在第一次收到用户客户端登录消息后根据所处地图的ID绑定对应的MAPWORKER,此后与地图不相关的信息全部转发给BusinessWorker处理,如聊天,仓库等,与地图相关的发送到当前所属地图MAPWORKER,如移动,攻击等,各个MAPWORKER里用TIMER处理地图逻辑,如定时刷怪,AI等并将信息发到GATEWAY发给客户端。


这样做可以把每个进程的业务逻辑延迟降低、也可以分布式提高性能,但是不可避免的会出现共享数据的存储问题,毕竟MMO里需要广播的场景太多,哪怕移动一步,说一句话,都可能导致广播数十乃至数百,如果每次都依靠实时从MEMCAHE或者REDIS之类的拉取,玩家多起来,估计这个地方会有点压力,玩家并发少问题应该不大。

已邀请:

walkor

赞同来自:

我开没啥游戏开发经验。
感觉整体架构应该没啥问题,
1、建议玩家移动、攻击不要走redis存储,而是直接用单进程mapworker存储和计算,然后定频广播给周围的人。如果分多个mapworker进程计算同一个地图场景则需要大量的进程间通讯,有点得不尝失。
2、mapworker广播数据时,要做到尽可能只通知该通知的人,避免频繁的大范围广播通讯。例如移动时利用灯塔只广播坐标给周围的人,比如简单的九宫格算法
3、把地图划分为多个场景,每个场景一个mapworker进程,而不是用一个mapworker处理全地图所有场景的数据。划分后玩家进入到哪个场景就把相关状态数据发到哪个场景的mapworker(可以利用geteway自带的router路由到特定的mapworker),这样能能够很好的利用cpu多核,同时避免了大量的进程间通讯。

要回复问题请先登录注册