游戏服务架构(二)

这里从游戏 Web 服务开始, 一般都是作为单独部署的服务器, 有的时候会和后台管理服务放置于同台服务器.

作为游戏的 SDK 接入入口, 第三方已经将业务提取好了( 毕竟发展了这么多年, 业务都大同小异 ), 基本上只需要关注第三方 SDK 接口:

Login: 第三方登录接口, 由客户端唤起之后推送到自家游戏登录接口, 我们需要做的就是数据推送给第三方验证, 验证完成就可以写入自家游戏数据库代表用户生成.
PayCallback: 第三方支付回调接口, 基本上客户端唤起生成订单之后第三方会唤起支付宝/微信等方式, 支付完成会回调返回给自家游戏回调接口, 验证完成同时服务端发货即可.

注意: Web端大部分主要交互是客户端

这里游戏接口最基础两个接口( 当然如果不涉及支付可以剔除支付回调 ), 注意这里有个技巧:

# Wechat 登录接口, 推荐这种接口声明方式暴露给客户端, 以 POST 提交 JSON 数据
http://127.0.0.1/v1/wechat/login

# `v1` 代表了SDK版本, 这种方式让你以后接口参数变动的时候直接升级 v2 不要去变动到其他接口
# APP 更新需要这种版本更迭, 因为某些平台版本会出现参数比较多, 游戏某些方面需要用到但是很少, 所以这个可以省略

# `wechat` 代表第三方的SDK, 比如微信登录/支付登录/bilibili/抖音登录等平台接入第三方

# `login` 代表提交数据的行为, 代表需要请求登录

主要立项时候处理个登录接口就行了, 用来给手动账号密码输入即可, 后续等商务谈妥确定 SDK 接入的时候再去切换其他.

# 简单的账号密码登录
请求: http://127.0.0.1/simple/login [参数: username,password]

# 这里响应 data 就是具体的内容, 按照客户端需要返回给需要的数据
响应: { status: 0, message: "SUCCESS", data: { username: "xxx", token: "yyy" } }

在授权登录返回 token 之后就会推送通知给游戏服务端, 等待让目前线上的同个玩家下线退出.

服务器接口

除了必须要账号接口外还有就是服务端接口, 哪怕是单服游戏也要预留好这个接口( 游戏客户端服检测服务器列表只有一个就不需要选服直接默认即可 ).

不要把服务器单服配置写死在客户端连接, 后续服务器迁移和扩展分服会带来很大问题.

# 获取服务器列表
请求: http://127.0.0.1/server/list [参数: token(不一定有)]

# 这里响应 data 就是具体的内容, 具体常见选服有 热门(is_hot), 新服(is_new), 推荐(is_top)
响应: { status: 0, message: "SUCCESS", data: { list: [ server_id: 1, server_name: "广州1服", is_hot: 1, is_new: 0, is_top:1 ],...  } }

这里需要说明下接口是否需要带登录返回 token, 一般来说登录之后才允许选服, 而选服列表处于安全防护问题会要求必须先登录才能获取.

实际上注册个账号抓取接口基本上就能获取到接口内部返回服务器列表, 但是可以有效避免非登录的请求, 就个人而言作用还是有的.

默认进游戏还有个公告弹窗列表接口, 但是这里先不需要赘述, 先保证基础接口从而尽快做好游戏初版功能.

总结说明

主要游戏立项有明确的 deadline, 基本上 3-4 个月 左右出 游戏初版(beta版本), 这个版本不求功能完善但求基础核心框架功能齐备, 基本功能:

客户端 Web 登录和服务端的 Protocol 交互
服务端和客户端的消息/邮件推送
支持推送道具写入到数据库
第三方登录/支付SDK接入
游戏基本玩法实现

对于游戏立项来说, 首当其冲的就是尽快出 beta 版本的 demo 验证游戏玩法可行性, 而不是浪费时间细化那些步骤.

题外话

现在国内的 SDK 接入手续越来越繁琐, 对于个人想试水的成本奇高; 像是微信小程序上线游戏需要先去审批版号提交, 然后才能接入SDK打包跑个测试环境, 其中提交审批和上架游戏耽误的时间一度怀疑人生, 所以如果在立项前期就要同步申请好相关的游戏所需证明等防止耽误时间.

MeteorCat / 游戏服务架构(二)

游戏服务架构(二)

服务器接口

总结说明

题外话