H5游戏服务端(十)
到了这里基本上可以回过头总结游戏开发基本流程, 后续如果采用 skyent|netty 等网络框架开发基本上都能了解.
主要是 Actor 机制实现和异步数据对接的情况, 如果对内存有强需求可以自己从 C 裸写集成 lua|python 业务脚本,
而对开发工具链和开发效率有要求可以采用 netty 自己研究 Java 游戏服务端相关系列.
而对于传输协议 H5 相关不需要对游戏服务端进行数据封包|解包操作, 所以只需要确认数据就行了;
而 TCP 数据传输之流则需要自定义封包协议, 虽然 TCP 数据是流没有 粘包 问题, 但还是需要对流进行切分:
# 将数据以二进制数据流编码
# [ value(int32) ] [ length(int32) ] [ data(byte[]) ]
# 采用单个int32字节 采用单个int32字节 二进制数据
# 标识转发的协议id 标识后续二进制长度 具体传输的数据
TCP 传输就像绳子一样, 把获取玩家数据比喻成 ‘切绳子’, 你需要多条 3 米的绳子必然是从 1-3(1,2,3),4-6(4,5,6) 开始切:
# 以下为伪代码
# 假设 SOCKET 获取到数据:
var socket = socket();
# 首先读取首位 int, 用来判断是否存在该协议号
var value = socket.read_int();
if value.exists(): # 不存在协议号直接跳过
pass
# 其次读取次位的 int, 确认服务端需要给他初始化多大的数据缓冲区
var length = socket.read_int();
var buffer = new byte[length];
# 剩下就是读出指定长度的字节流, 填充进初始化的缓冲区
# 注意这里最后读取长度需要和最终长度匹配
var data_length = socket.read_byte(&buffer,length)
if data_length != length: # 长度不匹配的时候可能直接中断或者跳过
pass
# 最后就是转发协议数据到自己的 Actor对象中
actor.forward(value,buffer,length)
以上伪代码就是描述 TCP 协议数据所需要转发到具体对象的流程, 这也是后续作为游戏服务端进阶的必须理解的.
SDK对接UML:
常规来说商业游戏会接入第三方授权账号体系, 甚至于自己本身都有带的账号密码登录体系, 这里最好抽离出来和服务器列表|公告列表单独做系统服务.
第三方账号验证体系不要加在游戏服务端, 有时候第三方SDK会频繁更新需要重启或者断点日志等情况
协议对接
注意通讯协议并不是服务端独有, 通讯协议是 服务端和客户端 共同维护处理.
协议最好独立版本库让客户端和服务端一起维护, 可以直接建立 GIT|SVN 库来另外同步推送通知
策划对接
注意: 策划基本上不接触代码的, 所以尽可能避免让其接触命令行处理, 最多让其用
Python处理.
能够界面化处理的事情不要用命令行处理, 策划大部分只需要关注游戏数值配置, 所以 Excel 才是策划和程序对接手段.
策划配置表基本是另外处理的版本库, 常规都是 SVN 提交上同步分发给策划, 客户端和服务端三方共享
一般来说策划和程序开会确定版本要求功能, 常规来说会得出以下结果:
- 版本号和版本上线时间: 假设上线所需一周则需要调用美术|程序|外包等流程保证开发不会突然停滞
- 需要上线的功能: 一般需要准备上线的游戏玩法和活动等信息, 用于协调美术和客户端游玩逻辑
- 需要配置的策划表: 设计定义出玩法收益数值表和奖励配置表, 用于给客户端和服务端读取加载
最后说明
至此初版游戏服务端已经完成, 后续都是服务端进阶和客户端相关设计功能了; 其实相比较来说, 在整个游戏开发方面, 游戏服务端功能起到的作用相对比较小; 游戏更多侧重在客户端和美术, 因为他们是和玩家交互最临近的, 游戏好不好玩最终还是以玩家最后意愿为主.
如果你以为游戏服务端能够开发十分炫酷的界面效果和游戏玩法, 那么最后你的入行之后就会感受到很大落差
剩下的基本游戏服务端代码库 也提交到 Github 上, 只实现了数据异步落地和授权方面, 可以自己扩展思考设计: