概要
玩法需求:
-
需要在本服某排行榜内拿到一定数量的玩家数据,把他们制成玩家镜像供公会内的玩家PK,数量不够则统一使用配置表指定的机器人数据。
-
玩法一 怪物有数次被击杀的机会,机会由公会内所有人共享,玩法二 怪物几人一组,玩家连续战斗直至把该组最后一员击杀才算成功,中途失败也没关系,怪物血量不会刷新,血量由公会内所有人共享。
-
跨服排行榜,由公会积分做排行榜依据
进程设计
玩家进程
每个玩家独立的进程
玩法进程
玩法进程是每个服一个,用公会的id作为key区分存储每个公会
跨服排行榜进程
排行榜放在跨服节点那所以无论多少个服,分多少组也只有一个跨服排行榜进程,以分组id做key区分每个跨服的排行
注:因为只有一个进程,所以开发时非常需要注意io传输的开销
开发过程
初始化:
当公会有人进入该玩法主界面时才真正开始为这公会的关卡数据做初始化,这样能避免不必要的内存开销,通过排行榜接口获得数据,然后从中拿到相应数据做成玩家镜像
因为关卡数据量庞大,需要和前端合作 把关卡数据单独分页发送给前端
需要注意记录玩过的公会,避免重复初始化的问题
跨服排行榜:
跨服排行榜进程和其他普遍的跨服玩法区别是 首先在process_name上直接以模块名命名,不以组id做区分,因为在这里只做一个跨服进程。
当有公会第一次上排行榜时,玩法进程向跨服排行榜进程发送该公会的积分、头像、名字、分组id等精简信息。
公会已经榜上有名时,且自身信息没有额外变动则只需向跨服排行榜发送只有积分的消息。
跨服排行榜那边收到消息则通过协议调动排名函数,进行名次更迭或存储
需要注意如果跨服节点那边重启了,则需要发消息到每个服,让玩法进程把有玩过该玩法的公会精简信息与积分推上跨服进程
当玩家进程请求跨服排行榜进程看排名时 同样需要以分页的形式请求,避免每次传输过多数据造成堵塞
一些技术知识点
玩家镜像:其实玩家镜像就是把玩家的属性数据存下来,用做战斗接口所需的参数而已。
跨服:
- 因为节点不同,本服的玩法进程或玩家进程直接用跨服排行榜进程的Pid发消息是发不过去的,必须找到它所在的节点,连同节点号和pid一起才能通
- 其次节点间的通信,需要依靠cookie,cookie相同的才能通信,cookie通常会放在env.config这类配置文件里
- 在后台对该玩法参与的区服进行分组、检查这些分组是否开通了跨服类型、是否有添加在跨服数据库里
- 跨服分组的信息必然是在本服留有记录的
小结
万事开头难,在磕磕碰碰中完成的这个玩法,像落下的心头大石,成为知识,通的一声进入了大脑的海洋里,为升高的海平线做出了份贡献