网页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:端口号以方便通信;房间用于维护对局实现双方玩家的通信交流。

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

三者的类图如下所示:

 

文章作者:093 

 

...全文
197 回复 打赏 收藏 转发到动态 举报
写回复
用AI写文章
回复
切换为时间正序
请发表友善的回复…
发表回复

571

社区成员

发帖
与我相关
我的任务
社区描述
软件工程教学新范式,强化专项技能训练+基于项目的学习PBL。Git仓库:https://gitee.com/mengning997/se
软件工程 高校
社区管理员
  • 码农孟宁
加入社区
  • 近7日
  • 近30日
  • 至今

试试用AI创作助手写篇文章吧