网页H5小游戏需求分析作者：093

weixin_43793768 2021-12-21 18:34:53

网页H5小游戏需求分析作者：093

1.概述

要求

使用Unity或者其他工具，实现一个简易版小游戏，游戏类型不限。支持与局域网内另一玩家对战。需要使用QUIC协议，连接保持(4G/WIFI切换)。采用人机对战方式，支持游戏断开链接后，重新连接游戏并进行对局。保障前端安全性，防止用户篡改前端数据，伪造数据提交。

详细说明

由于没有限定游戏的类型，我们计划做一个简化版的《弹弹堂》小游戏：

1.一次两个玩家，回合制。

2.每个玩家在回合内可以进行移动，也可以发射炮弹。炮弹可以给玩家体力值造成伤害，也可以破坏地形。

3.当玩家发射炮弹，或者回合内的倒计时归零时，回合结束，转移控制权。

4.当一方玩家体力值归零时，游戏结束，归零的一方失败。

其详细的流程如下图所示：

游戏的截图如下所示

注：

本次工程实践是小组内多人一同开发，主要分为客户端和服务端部分，每个人分工不同。客户端采用Unity工具，服务端采用Go语言实现。

我负责服务器部分的开发，所以接下来的内容不会涉及到客户端开发的部分，只会针对服务端进行。

2.用例建模

从服务端的角度来看，用户会用到的功能如下。

用户功能	开始状态	终止状态
注册	用户点击注册开始填写信息	用户收到了注册成功或者失败的反馈
登录	用户输入登录信息并发送	用户收到了登录成功或者失败的反馈
匹配	用户点击“联机”按钮	成功匹配到其他玩家
游戏	匹配到玩家并游戏开始	分出胜负游戏结束

3.时序图

从用户的角度，我们来看看从用户登录开始到成功完成一局游戏。用户，客户端，服务器，数据库的时序。

对于用户来说，只能看到客户端，服务端和数据库对其是透明的。并且也可以从中看出，服务端并不负责客户端的游戏状态转换，只是负责转发，且十分相信客户端（胜负的结算信息是由客户端主动发送的），这对前端安全来说也是一个挑战。

3.房间

当然，作为一个服务器，不可能只为两个玩家服务。对于每一场游戏，都有一个专门的房间进行维护。两个玩家的游戏在房间中进行。房间与房间互不影响。

对于每一个房间，其创建到结束的流程图如下：

4.类

对于服务端来说，主要有三个类：用户，登录用户列表，房间。

数据库中只存储用户表，属性包括：id，密码，总游戏场数，胜利游戏场数。后两项主要用于在匹配时可以匹配到势均力敌的敌人，从而不会因为双方等级差距太大破坏游戏体验；登录用户列表用于存放已经登录的用户信息，主要包括用户id，用户的通信channel（这是go语言的特性）和用户的ip：端口号以方便通信；房间用于维护对局实现双方玩家的通信交流。

登录用户列表和房间都在内存中，不会持久化到数据库。

三者的类图如下所示：