饱满骑士团队第四次作业—项目系统设计与数据库设计
| 这个作业属于哪个课程 | 2021春软件工程实践S班(福州大学) |
|---|---|
| 这个作业要求在哪里 | 团队作业四——系统设计和数据库设计 |
| 这个作业的目标 | 《系统设计说明书》、《数据库设计说明书》 |
目录:
- 一、开发计划时间安排
- 二、计划分工安排
- 三、系统设计
- 四、功能模块层次图
- 五、类图
- 信息层
- 决策层
- 行为层
- 表现层 - 六、系统安全和权限设计
- 安全设置
- 权限设置 - 七、问题反思及改进
- Q1：场景？有剧本吗？前后有何联系？怎么推动？
- Q2: 类和类之间的关系没有体现 - 八、组员分工
- 工作流程
- 工作量&贡献度 - 九、github链接
一、开发计划时间安排
| 时间 | 目标 |
|---|---|
| 第1周（4.25-5.1） | 实现主角前进、跳跃、冲刺、攻击 |
| 实现怪物状态设计 | |
| 实现音频管理 | |
| 场景ui编写 | |
| 静态数据准备 | |
| 绘制图片 | |
| 第2周（5.2-5.8） | 实现主角技能 |
| 实现怪物状态切换 | |
| 实现主角动画 | |
| 游戏窗口ui编写 | |
| 背包、地图、存档的实现 | |
| 场景搭建 | |
| 第3周（5.9-5.15） | 主角动画接口的调用，动画优化，音频接口调用 |
| 怪物动画接口的调用，动画优化，音频接口调用 | |
| 实现怪物动画 | |
| 场景搭建 | |
| 第4周（5.16-5.22） | 脚本与场景对接 |
| 第5周（5.23-5.29） | 项目测试，对各个接口调试，测试 |
| 第6周（5.30-6.5） | 添加游戏特效，完善游戏细节，数值调整 |
| 第7周（6.6-6.12） | 报告，开发结束 |
二、计划分工安排
| 成员 | 负责部分 |
|---|---|
| 王国志 | 怪物行为 |
| 宋方滐 | 怪物行为 |
| 司维维 | 主角控制 |
| 宋喜仁 | 音频管理、动画 |
| 汪碧桢 | ui（菜单：ui事件、场景切换） |
| 王振南 | 对话、背包、地图、存档、特效 |
| 吴特锦 | 对话、背包、地图、存档 |
| 毛富林 | 美工、场景搭建 |
| 周美婷 | 美工、场景搭建 |
三、系统设计
体系结构设计
- 体系结构概览
该结构分为四层：- 更新世界信息
- 更新决策层（做什么）
- 更新行为层（怎么做）
- 表现层
-
具体信息
-
更新世界信息：
这部分主要分为两个设计：一个是知识池（Knowledge Pool），另一个就是感知器（Sensor）。- 知识池（Knowledge Pool）：
将世界的数据信息搜集起来，通过key-value的方法存储起来；
- 感知器（Sensor）：
即获取数据的方法，可以设置一个感知器来获取地图的信息并将信息存入到知识池中；
我们可以通过遍历所有的感知器来获得所有的世界信息；并且感知器设计时可以设计两种不同的感知器，一种是全局感知器，可以将它看作对整个世界、关卡的抽象，还有一种是个体感知器，通过挂载到主角上来实现视野，听力，主角信息捕获等等。
-
-
更新决策层(做什么)
该层就是用来处理输入，比如当玩家走到怪物攻击范围内时，怪物会产生“做什么”的决策，例如攻击等，而这些“做什么”的决策，会封装到一个“请求”的结构中，然后向下一层传递。
在该部分，我们使用了Unity 的状态机，行为树和神经网络结构。
玩家的输入也属于这一层，因为玩家的输入也是一种决策，这一部分就是通过行为树来进行处理，将玩家输入与AI可以共用：
-
更新行为层（怎么做）：
该层的作用就是用来处理上层的策略，这层的实现同样使用了行为树、状态机，比如在释放一个技能时，我们需要先集气，然后再释放，就可以通过行为树来实现。
在这一层中，会产生一系列的输出，有特效，有动画，还有声音等，然后就是接受运动信息，这部分包括空间信息（位移）和动画信息，在这一层可以进行一些基础的操作，如太过复杂，就需要下一层来实现 -
表现层：
该层展示了游戏的ui界面，接受决策层的决策，显示相应ui。
-
- 设计思路
按照一般的游戏结构层次划分，我们的游戏可以先大体分为核心层（Core），引擎层（Engine），游戏类型层（Game Genre），游戏层（Game）,一般的商用游戏引擎就用到了引擎层和核心层，而引擎使用者一般都是实现游戏层和游戏类型层。这种分层的架构设计就可以帮助我们把复杂的系统进行解构，从而实现每个子系统或者模块的功能单一化。但是在实际使用中，我们组通过这样的思路，按多层次结构设计了一个核心架构，每个层次都可以更加细致的分派不同的人来负责，该架构分为四层，也就是如上所述。
四、功能模块层次图
功能模块设计
- 模块设计
- 算法模块
- 菜单控制
- 界面显示
- 战斗模块
- 设计思路
我们根据界面划分成了控制类界面和一般显示类界面，又因为除了场景界面外非常重要的一个点是战斗体验，所以又把战斗模块提取出来。经探讨，发现其实这款单机游戏较难实现的点是算法模块，于是把算法模块也提取出来，在人物打斗逻辑设计上有很重要的作用，其中怪物发射技能的时间间隔采用定时器算法，也就是指定具体的某一个时间值，怪物到指定的时间点后就可以开启攻击；而怪物采用技能攻击则是通过伪随机算法来实现，怪物是否开启技能攻击是随机发生的；怪物攻击的范围则是通过有限状态机做出响应。
五、类图
类图的设计按照系统体系结构分为四个部分：信息层、决策层、行为层、表现层。信息层包括SceneInitializer、GlobalData、StaticData类，用来获取游戏信息，传递给决策层，包括Player、Magic、Sword等类，负责状态控制，指挥行为层（Controller）行动，控制表现层显示UI界面。
信息层
SceneInitializer 场景初始化器
方法：init（初始化）
GlobalData
属性：map（数据映射对象）GlobalData（全局数据对象）
方法：save（保存）read（读取）
StaticData
属性：map（静态数据映射对象）
方法：getJsonObject（获取数据对象）readFile（读取文件）
决策层
读取键盘/鼠标数据，调用对应的controller进行响应
Player
属性：hp（生命），mp（能量），speed（移动速度），jumpforce（跳跃力）
方法：update 实时读取键盘/鼠标数据并调用controller
Magic
属性：damage（伤害量），spend（消耗能量数量）
方法：wave（远程攻击），remedy（回血）
Sword
属性：damage（伤害量）
方法：attack（攻击）
GameManager
方法：
switchScene（场景切换）
displayUI（UI展示）
Map
方法：显示地图
Bag
方法：显示背包
读取游戏场景上的状态变化改变自己的状态，调用对应的controller进行响应
Monster
属性：hp（生命），speed（移动速度），damage（伤害量）
NPC
属性：transform（位置信息）
SavePoint
属性：transform（位置信息）
行为层
MovementController
属性：transform 玩家信息
方法：jump （跳跃），move （移动），dash （冲刺）
AttackController
方法：attack （攻击）
MagicController
方法：wave（远程攻击），remedy（回血）
MonsterController（接口）
方法
standByStatus（站立状态切换）
alertState（警戒状态切换）
pursuitState（追击状态切换）
returnState（返回状态）
具体怪物实现类 EliteMonsterController，继承MonsterController
PlayerAnimationController
属性:Animator （动画对象）
方法：
attack （播放攻击动画）
idel （播放站立动画）
move（播放移动动画）
dash（播放冲刺动画）
hurt（播放受伤动画）
death（播放死亡动画）
fall（播放坠落动画）
wave（播放远程攻击动画）
remedy（播放回复动画）
MonsterAnimationController
属性:Animator （动画对象）
方法：
attack （播放攻击动画）
idel （播放站立动画）
move（播放移动动画）
hurt（播放受伤动画）
death（播放死亡动画）
AudioController
方法：
attack （播放攻击音效）
wave（播放远程攻击音效）
remedy（播放回复音效）
SaveController
方法：save（保存游戏）load（加载游戏）
DialogController
方法：getDialog （获取对话）
表现层
BeginMenu
方法：
onStart（游戏主菜单加载）
onSetting（选项菜单加载）
onExit（游戏关闭）
SettingMenu
方法：
onUpdate（游戏设置更新）
onBack（返回上级菜单）
StoreMenu
方法：
onStartGame（开始游戏）
onBack（返回上级菜单）
EscMenu
方法
onSetting（选项菜单加载）
onCountue：（继续游戏）
onSaveExit：（保存并退出）
PlayerStateUI
方法
updateHp（更新血条UI）
updateMp（更新能量条UI）
DialogUI
方法
show（显示对话）
StoryPanel
方法
onBack（返回上级页面）
onPage（翻页）
SuccessPanel
方法
display（展示成就页面）
系统安全和权限设计
安全设计：
使用 Unity 引擎开发游戏，易上手，效率高，成本低。Unity 引擎带来便捷和高效的同时，也引入了一些新的安全风险。游戏逆向分析的门槛也被大幅降低，分析人员的差距被拉平，即使没有太多逆向经验的人，也可以开始尝试制作外挂了。相比 C/C++ 游戏，Unity 游戏的安全风险存在分析工具多、破解门槛低、攻击方法通用化等几个特点。
Unity 支持 Mono 和 IL2CPP 两种编译模式。使用 Mono 模式编译的游戏，会将 C# 脚本代码编译为 IL 中间码，发布到游戏客户端。也就是源代码会泄露，这种中间码安全性较低，可以被一键反编译，一键修改。后来基于安全性和执行效率方面的考虑，Unity 支持了 IL2CPP 编译，大大提升了游戏安全性，但还是存在被攻击的风险。
因此我们团队决定使用IL2CPP 模式编译我们的脚本代码，使用 IL2CPP 模式编译，游戏的脚本代码没有了，脚本代码被编译成了 Native 代码发布。很多反编译的工具都失效了，安全性得到了一定的提升。
权限设计：
-
游戏的启动、暂停与退出权限
-
主角操纵权限：玩家可以操纵游戏主角的移动、攻击和发动技能
-
快捷键设置权限：玩家可以根据自己的习惯更改对主角操控的快捷键设置。
-
背景音乐和音效设置权限：玩家可以更换背景音乐和音效
-
查看地图权限：玩家可以查看地图了解自己的位置等信息
-
对话权限：玩家在相应情景下可以和游戏对象进行对话交流以了解闯关相关信息。
-
查看背包栏权限：玩家可以查看背包栏了解自己已经获得的物品。
-
进入存档权限：玩家可以选择一个存在的存档并点击进入。
-
创建存档权限：玩家可以创建一个新的游戏存档。
-
删除存档权限：玩家可以删除一个存在的存档。
-
故事梗概的查看权限：玩家可以打开故事梗概了解大概的故事。
七、问题反思及改进
Q1：场景？有剧本吗？前后有何联系？怎么推动？
反馈：场景主要包括战斗场景和非战斗场景，战斗场景：主要展示的元素有攻击，受击，技能特效，主角和怪物的死亡。非战斗场景：和NPC的交互和解密关卡。
剧本主要体现在非战斗场景中，帮助玩家了解游戏。在战斗场景中玩家的主观因素很大，因此无特定剧本设置于战斗场景。
剧情的推动依赖于玩家和NPC对话，完成关卡后获得的道具，和解锁新地图。
措施：关于场景和剧本的问题，我们的王振南和毛富林已经基本敲定好了剧本，就算之后有改动也只可能是小改动；然后部分组员，如司维维已经写好了几个场景，有注意和剧本的衔接；之后会进一步完善。
Q2：类和类之间的关系没有体现
这次作业恰好有让我们完善类图，所以依据上次的不足，我们完善了类图，完善了类与类之间的依赖和关联关系。
八、组员分工
- 工作流程
- 工作量&贡献度
| 学号 | 工作内容 | 贡献度 |
|---|---|---|
| 221801202 | 《数据的保存与恢复说明书》和数据的结构 | 11% |
| 221801205 | 类图的设计及博客124部分 | 12% |
| 221801211 | 系统体系结构的层次设计，ppt设计 | 12% |
| 221801212 | 部分类图设计 | 8% |
| 221801216 | 功能模块设计编写和博客第3567部分的编写 | 11% |
| 221801228 | 数据库和ER图、数据的获取和传递、讲演报告 | 12% |
| 221801229 | 系统安全和权限设计 | 11% |
| 221801234 | 类图描述，《系统设计说明书》 | 13% |
| 221801339 | 部分类图的设计 | 10% |
