侧栏导航

游戏后端引擎应该解决的问题?



游戏后端引擎应该解决的问题?

后端引擎解决的问题

1. 与客户端的交互能力

​ 即网络通信,网络传输协议,这是基础中的基础

  1. 应该具备构建在Tcp/可靠UDP之上传输能力,满足严格的即时或时序要求,
  2. 应该最少具备一种易于二次开发的,与客户端交互的应用层协议,如WebSocket,或者任意二进制包头不定长分帧协议
2. 海量在线的抗压能力

在架构上支持海量用户实时在线,允许4层和7层的负载均衡,如多gateway

3. 数据的生产和消费
  1. 触发器模块,即数据在什么情况下开始生成(如网络连接触发,定时器触发,全局/用户属性变化观察触发或者来源于客户端上报触发?). 后端引擎应该具备有这种增加自定义触发器的能力,在系统的各个节点上增加hook钩子

  2. 业务脚本,即数据的计算,是上面讲的第一点的延续,后端引擎应该具备在触发器中增加自定义逻辑的能力,通常应该是一个脚本文件(Lambda/Fuction as a serveer)

  3. 数据的读写和落地,业务脚本应该有打通外部系统的能力,如引用外部数据库(sql/redis),需要引擎提供内置函数

  4. 另外要说的数据的分级, 这点是应对复杂的业务场景的.举个例子,全服等级排行榜的实现.等级是一个用户个人数据,等级排行榜是一个全局共有数据,通过脚本实现这个排行,需要做到

    1. 创建一个触发器A,响应用户的等级这个用户个人数据变化
      1. 触发器A触发后写排行榜这个全局数据.
    2. 创建一个触发器B,响应客户端读取排行榜的事件
    3. 触发器B触发后读取排行榜数据,返会给客户端

达到上述目的.就需要设计中心数据库和用户数据库两种级别的数据作用域,并允许不同级别数据之间交互,保证其原子性和一致性.

数据的生产和消费其实就是引擎业务拓展能力,

4. 热更新
  1. 第3点3个部分应该能够全量脚本化,达到易使用,易拓展,轻而易举增加新功能 ,足够serverless ,脚本可热更新,日志集中,易调试,配置集中
5. 组件商店
  1. 业务种类变化千千万,足够的埋点,插眼才能方便应对. 既然支持自定义触发器和脚本.应该有一个地方来积累沉淀这些东西,组件商店让引擎用户相互分享,正向促进引擎的生态. 在产品要这个榜单之前,我看到竞品也做了一个,并把组件脚本上传到了组件商店,~!~
6. 高性能,动态扩容可伸缩 ,容灾等其他能力
  1. 引擎核心模块拆分(GateWay/Match/Room/消息队列等),可横向拓展,一致性哈希,动态伸缩.
  2. 如防DDos攻击,这个点更偏重于底层基础能力.可以考虑上公有云,不做过多阐述.

开源游戏后端引擎的开发和实践应用

避免闭门造车,

  1. 会借鉴热血传奇的服务端设计思路(GOM版本),

  2. 在Umsp(https://gitee.com/geliang/Umsp-netty)的基础上,实现这个开源游戏后端引擎.

  3. 客户端也会实现热血传奇的核心交互

  4. (角色移动,装备穿脱,PK打怪升级杀人,NPC商店买卖交互,好友.擂台天梯匹配),

    暂时项目代号为PK (https://gitee.com/geliang/PK)


最后更新于 16th May 2019
微信二维码
在微信上关注我