MeteorCat

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.

H5游戏服务端(九) 到了这个章节的时候基本已经能够满足网络游戏的需求, 后续就是客户端和策划案的准备不是技术能够主导了, 所以这篇章当作杂谈处理. 相比独立游戏来说, 网络游戏更加推崇分工合作来各司其职, 因为本身之前介绍过涉及方方面面: 运营 运维 策划 客户端 SDK 哪怕是多面手也只能勉强满足以上需求对接, 所以这时候涉足游戏界面开发就比较力不从心. 在兼顾游戏服务端的同时参与游戏客户端开发, 这里工作重点权重分配很难把控 其实大部分服务端都不参与游戏玩法|美术决策, 所以基本上如果想要了解游戏美术设计到玩法落地可能要失望, 这里并不会牵涉到美术玩法相关系列; 美术和玩法才是最贴近玩家的交互, 而服务端则是保证在线游玩的体验, 两者对应方向需要区分. 如果抱着想直接设计游戏美术交互方向参与游戏服务端开发, 可能很快就会意识到 ‘参与游戏开发’ 和理想当中有很大差距 AI兴起 这个是和朋友讨论过关于 AI美术(AI Art) 在游戏应用, 感觉在具体应用方向未来可期 像是在策划方面现在都会先做个初版游戏玩法, 可能是对 活动|玩法 等元素做关键词提取后生成初版 UI 的 Demo, 然后可以给美术参考探讨研究; 这种方式大大加快策划和美术对接效率, 不像以前都要策划每次需要和美术沟通浪费时间. 像是之前网上所说的需求 ‘五彩斑斓的黑’ 这种抽象需求, 可以让策划让 AI 美术生成参考稿之后告诉美术需求方向参考 在简单需求方向上 AI 也给出了不错思考方向, 这也是比较看好的一点; 后续也开始出现 AI 的建模方式, 虽然目前还是难堪大任但还是未来可期. 哪怕是在服务端上面也可以提供代码参考和概念解析等方式, 在某些知识点忘记的时候可以帮助回顾和梳理. 相比有些人对于 AI 的排斥上, 我觉得要更快去掌握了解才能应对 AI 时代浪潮的冲击

H5游戏服务端(八) 结合之前的篇章, 目前已经实现: 网络数据传输 Actor处理模式 数据库异步落地 策划Excel对接 客户端协议对接 网络状态同步和帧同步 Linux系统( 需要分析游戏规模和架构部署游戏服务端, 必须学习项 ) 这里还需要补上最后关于 运营 的部分, 最基本上需要实现以下功能: 给玩家发送资源: 玩家直接发放补偿资源 给单人|全体玩家发送邮件: 玩家单独|全服补偿推送 更新上架|下架活动: 游戏内部活动通知和结束发放 单个|全体玩家下线处理: 游戏维护将玩家下线处理 这里有很多方法处理, 如果但是这里我倾向采用的是 Redis 内存数据库处理, 然后生成单个 Actor 来监听以上相关对运营服务, 这里先引入类库处理: <!-- Redis 数据库组件 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> 配置好 application.properties 的连接配置, 这里不需要采用 redis.lettuce.pool 连接池处理: # Redis 数据库配置 spring.data.redis.host = 127.0.0.1 spring.data.redis.port = 6379 # spring.data.redis.password=xxx # 密码设置 spring.data.redis.database = 2 最后挂起 Actor 服务来监听: /** * 运营商业指令 */ @EnableActor(owner = BusinessLogic.

H5游戏服务端(七) 之前大概粗略处理了策划与客户端的基本对接流程, 回顾下基本流程: 客户端对接: 主要针对协议数据格式推送 策划对接: 主要针对 excel 导出 json 共享 初期这样配置就差不多打通 服务端 - 客户端 - 策划 三端的联调功能, 之后就可以准备以此当网络框架进行网络游戏开发. 这时候你也对 postman 直接调试开始感觉都厌烦了, 没有 GUI 所见即所得从而对开发兴致一下子降低了, 所以这时候需要提振自己信心. 这里可以考虑去找些开源的单机游戏仿品改造成在线版本, 从而测试下功能可行性并且学习下客户端方面的处理方式从而在服务端构建需求时候加入客户端理解. 推荐B站UP主 Hi小胡 做的 土豆兄弟样例 采用 Godot 内部已基本上已经实现具体的客户端相关所有功能, 剩下具体就是需要自己去补充或者挂载在服务端实现逻辑. 直接拉取源码测试下( 注意 Godot 切换成 兼容模式 ): git clone https://gitee.com/hi_xiaohu/brotato-like-teach.git 如果对于 Godot 客户端有兴趣可以去学习怎么构建项目, 这里作为补充附加功能补充, 客户端目前已经完成以下 Scene 功能: bg_map/bg_map.tscn: 游戏战斗界面 ui/game_ui.tscn: 游戏GUI界面 scenes/scene_update/scene_update_tscn: 关卡更新界面 但是在开始之前, 有些概念必须要清楚才能进行有效开发. 游戏同步 先说明下游戏的同步机制方式: 帧同步: 把客户端的 update|_process 之类的更新方法移交到服务端定时执行, 运算全部在服务端执行并返回. 状态同步: 把客户端负责全部运算, 最后场景|关卡结果已经确定, 服务端只需要负责最后结算验证写入玩家信息.

H5游戏服务端(六) 对接完客户端协议之后, 基本上暂时可以没什么需要与客户端对接的; 接下来则是对接策划工具了, 更进一步说是 excel 表导出工具, 用来映射成类表格式, 表格的格式: 第一行: 转化的字段名, 该字段只允许英文字母等特殊符号, 用来给静态类设定名称 第二行: 转化的类型, 用来给强类型数据转化声明, 这里可以采用 JSON 类型风格处理 设定下表格风格如下, 这里以设定场景地图 场景配置#SceneTable.csv 方式: id resource name award 标识 场景 名称 解锁奖励 0 res://Scenes/Login/Main.tscn 登录页面 [] 1 res://Scenes/Home/Main.tscn 玩家首页 [“100_1”,“200_2”] 2 res://Scenes/CityLight/Main.tscn 游戏城镇A [“100_1”,“200_2”] 3 res://Scenes/CityMoon/Main.tscn 游戏城镇B [“100_1”,“200_2”] 这里就是比较简单的配置表工具, 预留前三列作为数据配置转化风格, 注意 id 是 int 类型且唯一存在, 最后转化成 Java 结果类: /** * 场景配置 */ public class SceneTable { /** * 场景配置 - 数据行 */ public static class Row { public int id; public String resource; public String[] award; } /** * 静态数据数据行 */ public static final Map<Integer, Row> Rows = new HashMap<>() {{ put(1, new Row() {{ id = 1; resource = "res://Scenes/Login/Main.

H5游戏服务端(五) 消息通讯功能已经完成了, 现在需要优化对应常量配置保存, 现在重构下之前所需方法: /** * 访问状态常量表 */ public class LogicStatus { /** * 无状态 */ public static final int None = 0; /** * 已授权状态 */ public static final int Authorized = 1; /** * 程序内部传递, 不对外暴露 */ public static final int Program = 2; /** * 游戏中状态 */ public static final int Gaming = 3; } 之前的玩家信息重新构建, 改为状态常量处理: /** * 玩家信息 Actor */ @EnableActor(owner = PlayerLogic.class) public class PlayerLogic extends ActorConfigurer { /// 其他代码, 略 /** * 玩家追加游戏货币 - 用于测试 * 现在这里 state 该有常量处理, 只有登录和游戏中才能被访问 * Example: { "value":302,"args":{ }} * * @param runtime 运行时 * @param session 会话 * @param args 参数 */ @ActorMapping(value = 302, state = {LogicStatus.

H5游戏服务端(四) 之前已经演示出账号挂载体系, 但是没有涉及数据库落地情况, 所以这里单独篇章介绍应该怎么处理数据实体落地. 这里采用 Spring 集成的 ORM(Object Relational Mapping) 处理, 方便将定义的实体写入数据库, 比较常用的 ORM 有: MyBatis: 这个相对国内用的比较多, 比较灵活可以手写 SQL, 更加接近于原生底层处理. JPA: 外国相对用的比较多, 映射类对象更加彻底, 性能方便可能有所损耗但学习方便. 这里采用 JPA 方式, 方便引入数据库驱动相关: <!-- 集成库对象 --> <dependencies> <!-- 其他略 --> <!-- JPA ORM --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-jpa</artifactId> </dependency> <!-- MariaDB 驱动 --> <dependency> <groupId>org.mariadb.jdbc</groupId> <artifactId>mariadb-java-client</artifactId> <version>3.1.4</version> </dependency> <!-- Lombok, 节约编写 getter/setter 时间, 但是有性能损耗 --> <!-- 这里实际上来说看你侧重于开发效率还是性能效率, 如果性能要求高不推荐引入 Lombok --> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <version>1.18.28</version> </dependency> </dependencies> 这里 MariaDB 驱动可以更换成其他比如 mysql|postgresql, Lombok 有性能损耗引入方面需要看自己需求处理

H5游戏服务端(三) 网络游戏和单机游戏差异很大, 除了游戏逻辑代码之外还需要关注服务器状态, 最明显就是要登录授权在线|维护网络请求心跳等情况. 这里先从登录授权开始, 这里需要第三方SDK的配合, 具体流程: HTTP 请求第三方SDK验证授权: SDK服务端发起 OAuth 授权获取 access_token 验证之类信息 第三方授权后在SDK服务器生成账号: SDK服务端拿到 access_token 在数据库生成账号在 Redis 登记凭证, 最后 UID+Token 返回客户端 客户端接收授权码后连接游戏服务端: 客户端拿到 UID+Token 连接提交给游戏服务端, 游戏服务端验证 Redis 授权是否一致 游戏服务端创建玩家服务器数据实体: 读取策划配置的玩家初始化状态写入到游戏数据库之中, 这里和Web端数据库读写有些差异 游戏服务端装载数据实体检测心跳: 把数据实体挂载服务内存当中, 并且检测网络心跳, 这里心跳也算是思考点确定服务端还是客户端发起心跳 游戏客户端监听登录完成事件等待切换场景: 之前只做过 Web 端可能会被影响到认为消息请求后必定响应, 从而等待 Websocket 响应 这里有些关键点会针对说明下, 因为这里面不同人处理方式都不一样, 比如 Redis 和数据库之类并不是必选而是需要自己考虑. 问题1: 为什么游戏服务端不合并SDK服务端功能? 在现代商业化游戏之中, 应用下载平台 和 游戏AD推广 也是关键组成部分, 比如最明显 bilibili 联运平台登录时候会调度登录进入游戏; 在这过程之中第三方通讯会通知返回告诉你已经授权, 游戏服务端集成SDK功能需要提供HTTP服务, 这时候对端口发起 DDOS 会影响游戏服务端; 同时游戏广告服务需要追踪转化, 也就是需要知道玩家在点击广告到最终自己SDK服务器创建账号整体转化流程, 才能按需给广告商切换玩家流量池付费. 游戏服务端尽可能单一, 集成 Web 功能相当于引入未可知问题, 加大被网络攻击风险并拖慢进程效率, 并且SDK服务端需要频繁重启调试追加功能

游戏分工 这个篇章不涉及技术相关内容, 主要说明开发游戏内部分工情况, 约等于开发商业游戏的杂谈: SDK接入: 负责运营后台|第三方接入, 包括后台活动|物品发放|公告发布|授权登录等 游戏服务端: 负责维护游戏网络架构功能, 对接策划|客户端|后台等处理同时, 还有的需要兼任服务器运维部署等相关 服务器运维: 负责管理公司内部云服务器, 有时候需要搭建内网在线版本库和部署测试服|正式服|数据库等 游戏客户端: 负责实现游戏玩法, 有时候需要开发客户端工具给策划验证游戏内部数值等, 同时有时候需要处理安卓/iOS商店上架发包等 产品策划: 负责游戏玩法开发和数值调整防止在线游戏内部投入产出奔溃, 有时候需要和运营协调节日活动促进玩家回流在线等 原画美术: 负责游戏美术和 UI 绘制, 有的公司会本家预留 2|3 个美术人员剩下采用外包美术, 拿到外包美术资源之后由本家美术做资源差分等修改 市场运营: 负责游戏上架之后统计游戏流水和玩家在线分析用户流程, 对接策划分析怎么推出游戏内部活动, 客服收集反馈|BUG移交运营来移交技术解决 法务财务: 目前国内上架游戏需要公司主体用于报税和申请版号, 游戏内购支付SDK主体也只公司不对个人开放, 还有美术版权|和谐|报账等问题 只要做游戏商业化上面都是绕不开的点, 需要清楚知道内部流程和应该负责的要点, 而且游戏公司都是以工作室单位来针对自己产品线独立开发( 也存在互相工作室 ‘外借’ 技术人员帮忙开发 ) 项目管理 如果需要把控项目, 那么需要对整体项目可以没精通所有流程但必须有所涉猎整体, 因为需要把控项目 deadline(最后期限). 这里需要说下之前所在游戏公司项目管理就比较灾难, 那时候公司把控项目由产品经理担任; 不过由于产品经理缺乏经验导致外包美术延误几个星期, 期间产品经理和美术外包扯皮没协调好这个版本服务端/客户端应该做的事, 也由于没穿插时间去申请版号|商户导致整个项目组上线都跌跌撞撞. 项目管理协调是重中之重的事, 而主程要么客户端要么服务端担任要么两者都有各自担任, 只有接触到最前线才能用自身经验解决问题. 项目开发一般分 小版本 和 大版本 发布版本: 小版本: 节日临时活动|限时活动|日常周期赛季奖励发放 大版本: 游戏玩法更新|客户端换皮资源|内核组件更新 小版本更新 常规来说 1-2周(最长3周) 内处理即可, 比如简单临时节日需要让美术更新资源和追加简单可以复用玩法等只需要热更新即可的小补丁.

搭建环境 对于 H5 游戏来说没有太多代码业务热更新的情况, 所以 skynet 挂载 lua 实现业务热更新的场景可以删减; Websocket 协议内部数据发包已经确定好, 每条消息都是获取取用就行( 不需要类似 int32[status] + int32[length] + data[bytes] 二进制消息封包 ). 虽然 Websocket 数据相比于 TCP/UDP 层面来说性能不高( 链接时带上了 HTTPS 头的数据包头信息 ), 但是其方便调试特性可以方便做调试从而所见即所得( 包括现在本地建立 html 文件就能编写客户端, 并且 PostMan 之类调试客户端也支持这种方式 ) 所以采用 H5 作为游戏服务端入门来说相对简单, 不用担心过多繁重概念带来的心智负担就可以出成品( 当然后续进阶则需要从底层开始了解 ). 对于服务端入门来说最好采用 WebSocket + JSON 来负载游戏传输, 虽然业界普遍采用 TCP/UDP + GoogleProtoBuf 二进制传输, 但是二进制序列化数据排错和字节位封包/大小端网络序列处理的困难都是直接劝退掉大部分新人开发. 这里采用 Java11+SpringBoot3 开发, 因为 Java 的库比较成熟可以直接引入调用, Spring 内部也集成容器对象方便管理. 这里先引入 Actor 和 Websocket 库处理: <dependencies> <!-- Websocket 库 --> <dependency> <groupId>org.