游戏研发(策略+sass+回调模式)

前言

        由于这边需要对接游戏研发后台,基本就是开服,封禁.角色日志等,但是每个游戏提供的接口都是不一样的,所以为了统一处理提前进行sass封装,以便后续可以更好的兼容

        

        同时还涉及了多数据源的问题,因为有些日志太大不可能直接去http调用,会使用直接查询游戏研发的数据库方式这一块依然可以进行封装

        

        这里只讨论开发\封禁\角色日志\聊天记录等,其他的接口和功能都是类似的,这里主要是讨论设计方案

前提设计数据库表

游戏表(核心)

idgame_coderoot_pathapp_key
主键id游戏编码(核心)游戏请求根路径游戏密钥
1zxcGamehttp://192.168.0.1/pathsdfsdfdsfdf

服务器器(sass)

idserver_idgame_idstatus
主键id服务器id关联的游戏id状态 0-闭服 1-开服
110004510

Http设计方案

涉及类图

相关描述

AbstractGameCall:  用于抽象定义,并封装了子类可以通用的方法,比如getGame()

ForestImpactGameCallImpl: 其中一个实现子类, 这里是封装的意义,子类实现自己逻辑即可

ForestImpactHttpUtils: 跟子类相匹配的Http请求类,与游戏具体的对接

GameCallContext:  接口上下文, 客户端只需要跟这个类打交道即可

         

        这样的设计以后如果有其他的游戏对接,只需要提供对应的实现和http实现类即可,项目内部会通过getGameCode()方法获取到具体的实现类,这里是唯一需要匹配的地方,抽象类提供的getGame()也是给子类提供了便利,因为gameCode是唯一值所以是可以这样去做的

sass方面设计

        主要存在于以下的几方面

1:  通过getGameCode便可以实现getGame通用方法,进而在进行http调用时,可以获取到具体的appKey进行加密处理,以及rootPath根请求

2: 假设在进行服务器修改状态时,那么就可以根据服务器绑定的gameId获取到具体的实现类,然后再进行相应的处理,只需要在入库时绑定这个关联即可

3: 对外暴露接口时需要对方传递一个固定的gameId参数,那么就可以把接口根据不同游戏来查询数据进行返回,以及解密也可以通过这个来进行自动的匹配

4: 以上几点保证了后续如果有新游戏只需要对提供实现类即可,底层的逻辑是不需要进行调整的

可能存在问题

        解设不同游戏有不同参数,那么也可以在调用过程中通过添加参数,然后子类进行相应的处理即可,当然了还可以提供回调函数的方式让不同实现类进行传输,如果没有多余参数不进行涉及即可

多数据源数据设计方案

        其实逻辑跟上面差不多的,只是像角色信息、聊天信息、用户日志等这部分日志过大,不是很适合用http传递过来,一个是数据量过大,一个是这边也没有那么多的磁盘来存储数据

       

        所以这个就需要依赖对方提供数据库,然后我们这边到不同的数据库中进行数据的获取了,但是仍然可以复用sass的功能对gameId区分然后进行处理

        大概结构也是差不多的,到时看看有时间就补上来一下,待定

结语

        其实用了很多设计模式后发现很多时候都跟抽象类、策略、模板等基本模式脱不了关系,个人认为设计模式绝对是有利于编码的,因为在思考的过程中会自然的把一些可以通用的逻辑封装起来,比如getGame(), 以及appKey和rootPath的获取

       

        如果有合适的场景,也建议大家可以考虑一下如何进行设计,在以后的开发中会带来比较大的变化,比如在下一个游戏的对接,只需要实现子类即可了

  • 10
    点赞
  • 18
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值