关于MMORPG开发遇到的困惑
我看了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之类的拉取，玩家多起来，估计这个地方会有点压力，玩家并发少问题应该不大。
4055 1 1
1个回答
相似问题
年代过于久远，无法发表回答
我开没啥游戏开发经验。
感觉整体架构应该没啥问题，
1、建议玩家移动、攻击不要走redis存储，而是直接用单进程mapworker存储和计算，然后定频广播给周围的人。如果分多个mapworker进程计算同一个地图场景则需要大量的进程间通讯，有点得不尝失。
2、mapworker广播数据时，要做到尽可能只通知该通知的人，避免频繁的大范围广播通讯。例如移动时利用灯塔只广播坐标给周围的人，比如简单的九宫格算法
3、把地图划分为多个场景，每个场景一个mapworker进程，而不是用一个mapworker处理全地图所有场景的数据。划分后玩家进入到哪个场景就把相关状态数据发到哪个场景的mapworker（可以利用geteway自带的router路由到特定的mapworker），这样能能够很好的利用cpu多核，同时避免了大量的进程间通讯。
非常感谢你无私的奉献。