一、项目背景介绍
1.1 项目内容
以世界多同屏为技术背景，结合云原生技术，设计并实现一款支持多人交互的高实性游戏后台系统。借助Kubernetes云原生技术将后台系统按照工业界标准进行容器化，使得面临业务时能够灵活的弹性伸缩与动态调度。在实现基础游戏服务框架的基础上，支撑多玩家同屏竞技，对多人竞技的性能问题进行进一步的优化。搭建工业化的流程管线，借助敏捷方法与DevOps思想支持持续迭代和运维自动化，可一键部署到云环境中对外提供可靠服务。
1.2 项目意义
在游戏发展如此迅速的今天，网络游戏越来越频繁地进入人们的视线，但网络游戏的开发和运维中有着一系列的问题也逐渐暴露出来，例如：游戏中数据的同步问题、影响客户端与服务端交互的性能瓶颈问题、最大支持的同屏人数问题、以及在运维过程当中的单点故障等问题。
本课题的目的拟在实现一个部署在云端的游戏后台系统，来实现对多人同屏的支持、单点故障的解决以及对后台服务的更好地维护和管理。在当前游戏产业不断成熟、消费群体不断扩大的大背景下，该后台系统可以为解决上述网络游戏开发的常见问题提供良好的解决方案。
二、软件设计方案
2.1 系统架构
本项目内部系统之间采用微服务架构,微服务架构是由一系列独立的微服务共同组成软件系统的一种架构模式；每个微服务单独部署，跑在自己的进程中，也就是说每个微服务可以有一个自己独立的运行环境和软件堆栈；每个微服务为独立的业务功能开发，一般每个微服务应分解到最小可变产品（MVP），达到功能内聚的理想状态。系统中的各微服务是分布式管理的，各微服务之间非常强调隔离性，互相之间无耦合或者极为松散的耦合，系统通过前端应用或API网关来聚合各微服务完成整体系统的业务功能。
客户端与对战专属服务器之间采用C/S架构(客服-服务器架构)，客户端通过udp协议与对战专属服务器进行通信，服务器为所有客户端提供转发和业务处理服务。
各个模块之间使用grpc进行通信。在客户端进行游戏时，客户端通过与服务器之间维持的一条UDP连接来直接传送帧数据和校验数据。
2.2 接口API列表
由于篇幅有限，下面展示最核心的状态同步接口：
- 游戏实体状态改变广播推送（EntityInfoChangeNotify）由服务器向客户端推送，用于广播对局中玩家实体或者道具实体发生状态改变的推送（比如吃到道具、检测到碰撞、道具消失等）
| 参数名 | 参数描述 | 参数类型 | 是否必须上送 | 是否支持以列表形式上送 |
|---|---|---|---|---|
| entityType | 实体类型（包含道具、玩家等） | int32 | 是 | 否 |
| entityId | 实体唯一标识 | int32 | 是 | 否 |
| playerMsg | 改变后玩家状态 | PlayerMsg | 否 | 否 |
| itemMsg | 改变后物品状态 | ItemMsg | 否 | 否 |
- 游戏全局初始化信息推送（GameGlobalInfoNotify ）由服务器向客户端推送，用于对局开始时向各个玩家推送初始化信息（比如出生位置，道具初始位置，倒计时等）
| 参数名 | 参数描述 | 参数类型 | 是否必须上送 | 是否支持以列表形式上送 |
|---|---|---|---|---|
| playerNumber | 玩家数量 | int32 | 是 | 否 |
| time | 倒计时 | int64 | 是 | 否 |
| playerMsg | 玩家信息列表 | PlayerMsg | 是 | 是 |
| ItemMsg | 道具信息列表 | ItemMsg | 是 | 是 |
| mapMsg | 初始化地图信息 | MapMsg | 是 | 是 |
- 玩家状态改变请求（EntityInfoChangeRequest ）由客户端向服务器发送，用于当状态改变事件（发生碰撞等）触发时，向服务器请求改写状态并广播至其他的客户端
| 参数名 | 参数描述 | 参数类型 | 是否必须上送 | 是否支持以列表形式上送 |
|---|---|---|---|---|
| eventType | 事件类型 | int32 | 是 | 否 |
| playerId | 发生改变的玩家id | int32 | 是 | 否 |
| linkedId | 改变关联实体的id（比如吃道具事件中关联者就是该道具） | int32 | 是 | 否 |
| linkedType | 关联实体类型 | int32 | 是 | 否 |
| playerMsg | 改变后玩家状态 | PlayerMsg | 是 | 否 |
- 玩家状态改变响应（EntityInfoChangeResponse ）由服务器向客户端发送，用于回复客户端发来的玩家状态改变请求，此时服务器要对该玩家进行一系列的合法性校验
| 参数名 | 参数描述 | 参数类型 | 是否必须上送 | 是否支持以列表形式上送 |
|---|---|---|---|---|
| changeResult | 响应结果 | bool | 是 | 否 |
三、软件系统概念原型视图
分解视图
分解是构建软件架构模型的关键步骤，分解视图也是描述软件架构模型的关键视图，一般分解视图呈现为较为明晰的分解结构（breakdown structure）特点。分解视图用软件模块勾划出系统结构，往往会通过不同抽象层级的软件模块形成层次化的结构。本项目的功能分解视图如下：
依赖视图
依赖视图展现了软件模块之间的依赖关系，能有效帮助理清一个软件模块的变更对其他软件模块带来影响范围。本项目依赖视图如下：
执行视图
执行视图展示了系统运行时的时序结构特点，比如流程图、时序图等。执行视图中的每一个执行实体，一般称为组件（Component），都是不同于其他组件的执行实体。本项目的核心业务时序图如下：
部署视图
部署视图是将执行实体和计算机资源建立映射关系，本项目部署在腾讯云中的k8s环境下，部署视图如下：
实现视图
本项目的项目文件结构如下：
|——assets
|——build
|——cmd
|——configs
|——tools
|——apt
|——proto
|——net
|——game
| |——module
| |——battle
| |——handler
|——main.go
四、数据库设计
账户（Account）：用于存储玩家账户信息，主要存储登录凭证以及玩家的等级得分等持久化数据。
玩家（Player）：玩家代表一局游戏中出现的账户实体，相比于账户，玩家是一个更实时性的概念，由于核心数据都持久化存储在账户表中，因而玩家可以随时被创建和销毁，不用担心持久存储的问题。
对局（Game）：对局主要管理单局比赛的数据，包括玩家的创建和销毁，玩家之间的匹配，以及等级和分数的结算等。
道具（Prop）：代表可能出现在对局中的道具，不同的道具有不同的效果和类型，对玩家带来的增益也不同。
蛇（Snake）：对局中玩家操控蛇对象的实际表征数据。
五、技术选型&部署环境
5.1 技术选型
- grpc：基于HTTP/2高性能RPC框架
- kcp-go: 高安全性的kcp的 GO语言实现，包含 UDP会话管理的简单实现，可以作为后续开发的基础库
- mongoDB：基于分布式文件存储的非关系型数据库
5.2 部署环境
- Kubernetes：Google开源的一个容器编排引擎
- Docker：开源的应用容器引擎
- 腾讯云
六、项目概念原型核心工作机制
项目概念原型的核心工作流程为：
- 玩家通过登录、注册等常规操作进入游戏，进入游戏后可以查看到账号的等级、历史最高分等信息
- 玩家点击开始匹配按钮以后可以开始进行多玩家对局匹配，匹配成功以后玩家进入到贪吃蛇对局中，可以通过遥感操控蛇移动与吃道具等游戏操作
- 对局倒计时结束进行所有玩家的分数结算，然后玩家返回到主界面