我的项目是类似贪吃蛇玩法的一款 IO 游戏, 就是几个玩家在游戏界面中可以吃食物, 也可以相互吃, 吃了食物或对方都会变大这样子. 我是在用 cocos creator 做完前端开发的部分后, 开始接入的 Matchvs. 其实在接触 Matchvs 之前, 也了解过国外的一些产品, 比如 photon,proudNet, 不过网络问题和收费是一个现实问题,... 毕竟对于一个人开发者来说技术和资金都比较有限, 这点大家应该都懂得.
虽然 Matchvs 把他们提供的服务官方称为 "一站式服务", 其实在我看来主要就是两个, 一个是接入他们的 SDK, 可以实现联网功能. 二是 gameServer,gameServer 命令行工具用于后端代码本地调试. 后端的代码提交到 Matchvs 为我们提供的 git 仓库, 直接运行在它为我们提供的服务器中.
在 Matchvs 有一些像注册, 登陆, 加入房间, 发送事件这种很通用的功能, 这些不用花太多时间就能基本掌握. 二对我来说, 最大好处还是在于几乎不需要对服务器相关知识有所了解, 只需要关注前端和后端的逻辑编写, 就可以完成一个游戏的开发.
一开始认为, 这些 api 已经可以满足我大部分的需求, 但之后在使用过程中, 我发现了它设计中一些存在改进空间的地方.
以下是我在接入 Matchvs 过程中的部分使用总结:
先说优点吧.
1,api 简洁且覆盖面广.
关于数据收发, sdk 的 api 有 sendEvent,sendEventNotify,sendEventEx;gameServer 的 api 有 pushHander,pushEvent. 游戏的数据交互, 只用调用这几个接口就可以了. 我的项目属 IO 项目, 类似贪吃蛇, 一个玩家给了食物调用 sendEvent, 另一个玩家绑定 sendEventNofity, 数据就从这两个简单的 api 中传递了.
支持多平台, 也可以配合其他游戏引擎使用.
例如: 在 windows 平台, 我使用 cocos creator+matchvs 开发, 按照以下配置, 打包成 web Mobile,Web Desktop,Wechat Game,Android,Windows 等等平台.
- // 以下是伪代码, 调用不用环境的的 sdk
- var engine
- var response = {}
- if (isNative) {
- engine = Matchvs.MatchvsEngine.getInstance()
- } else if (isWeb) {
- var jsMatchvs = require("matchvs.all")
- engine = new jsMatchvs.MatchvsEngine()
- response = new jsMatchvs.MatchvsResponse()
- } else ...
2,gameServer 比较实用.
如果游戏逻辑简单, 简单到只需要客户端运行所有的逻辑代码, 我们就可以不使用 gameServer. 如果游戏逻辑复杂, 可以使用 gameServer 来同一管理所有的客户端.
gameServer+node(gs), 使会 js 的人就可以写后端代码, 开发速度更快.
例如在我的项目里, 由于房主会变化, 客户端中, 用房主来判断游戏是否要开始是很繁琐的. 让 gs 这个大管家来判断的话, 就显得很方便, 客户端不需要太关注房主的改变, 只需要关心是不是要开始游戏, 减少了客户端 if-else 逻辑.
Matchvs 提供了断线重连的功能.
在一些网络差(地铁, 电梯), 已与服务器异常断开的情况, matchvs 会帮助玩家自动连接, 开发者可以设置连接次数和频率, 但只能满足一些基础场景.
例如: 如果掉线重连了, loginResponse 会返回一个 roomId 的参数, 表示是断线重新的, 这时, 客户端可以选择重连和忽略.
多节点服务器部署以及帧同步技术
例如: 我的项目是 IO 游戏, 玩家移动的过程中, 不断的传递当前位置的数据, 画面看上去还是很流畅的, 感觉游戏延迟还挺不错的. 开发者不用担心数据同步的问题, 也不需要对服务器有太多了解, 就可以完成一个游戏. 感觉还是很棒的.
缺点.
目前, Matchvs 主要围绕着'房间'这个概念. 创建, 加入, 获取房间, 房间内各成员数据发送和接受. 所以目前不适用于房间外数据发收的场景.
例如: 客户端中, 需要修改用户名, 这个操作就不能轻松实现.
目前 GS 不支持数据库, 而是使用 hashSet,hashGet, 用起来太麻烦. 如果有数据存取的需求, 开发者需要自己买个数据库服务.
希望后续有数据库支持, 或者改为支持使用官方提供的数据库和自己购买的数据库.
GS 的命令行工具部分不太好用, 存在一些小问题
登陆时密码没有隐藏, 错误提示令人不解.
退出是输入 quit, 而不是习惯的 ctrl+c.
关闭 debug, 断开时间太长, 甚至有时无响应. 有时只好强关.
gs+node 服务使用热更新, 会导致 gs 服务断开等等一些小问题.
官网中, 对应的文档比较难找, 引导性不强. 找个文档需要花不少时间, 跟 Matchvs 团队反馈后是说文档会持续优化, 近期也会改版一次文档中心的结构.
有些接口和方法并没有在官方中说明, 只能通过查看源码或者询问官方了解使用方法.
例如: 在研究 Demo-GS-JS 的时候, 想到一个问题, gameServer 给客户端推送消息的时候, 客户端用什么来监听. 后来, 知道是由 sendEventNotify 来接收的.
我发现文档并没有这个描述. 官网表示, 会尽快补上所有的缺少的说明
回调的写法不科学.
例如: mvs.response.sendEventResponse = callback(msg){} mvs.engine.sendEvent(data) 这种写法是很不科学的, 如果后续代码中也有 sendEventResponse, 在此之前的 sendEventResponse 就会被覆盖.
建议: 回调的方式改成 sendEvent(data, callback(err, msg) { })
特别提示
随机加入和指定加入的房间是相互独立的.
例如: 通过'随机加入'加入的房间, 用户想通过'指定加入', 是加入不了这个房间的.
官方人员解释也是这么一回事. 但是, 官方文档并没有说明, 希望官方人员注意到这一点.
刚收到 joinRoomNotify 通知时, 用户与其他用户不一定能消息通知.
例如: 此时其他人 (客户端) 给加入者发送消息, 这个加入者很大可能不会收到.
官方人员给予了解释: '这时用户已经在房间中了, 但是还没有和其它玩家建立通讯通道. 目前 js-SDK 还不够完善, 应该确定通道建立完成后再发出 joinRoomNotify 通知', 并表示后续版本会修改这个 bug.
我的解决方案: 在上述的加入者 joinRoomResponse 的时候, 发送 isEnter 消息, 告知其他人, 我是真的进来了.
问题与建议差不多就这些了, 不过有一点要说明下, 虽然在之后的使用过程中的确遇到的一些问题, 但这里要特别感谢下官方客服在 Q 群里面耐心解答与卖力优化(可以感觉到这是一个在用心做产品的团队, 现在想起来那个客服八成就是 Matchvs 的产品), 让游戏顺利上线并保持稳定运行.
PS: 听说 Matchvs 最近马上要更新一个大版本优化, 小小期待一下, 希望能越来越好吧.
来源: https://www.cnblogs.com/make123/p/8946321.html