目录

0 任务

1 仓库和文件链接

仓库链接

码农生产队_系统设计说明书

码农生产队_数据库设计说明书

码农生产队_系统设计和数据库设计答辩PPT

2 系统和数据库设计

2.1 系统设计

2.1.1体系结构设计图

设计思路：在本次的体系结构设计中我们选择了分层架构的设计模式，系统中有四层结构，分别是表现层、控制层、游戏逻辑层和数据层。表现层负责游戏界面的展示与更新，确保玩家的操作能够在界面上及时反映；控制层负责接收表现层玩家输入的信息并且进行处理，再传递到游戏逻辑层调用相应模块；游戏逻辑层是整个系统的核心，存放了主要玩法的逻辑运算，处理来自玩家的操作指令，结果反馈给表现层或数据层；数据层负责管理和加载游戏资源，对游戏进度进行缓存和持久化存储。

2.1.2 功能模块层次图

设计思路：功能模块的划分从可扩展性和可维护性的角度出发，将功能独立的模块划分出来，每个模块独立运作，降低模块之间的耦合度，来提高系统的可维护性和可测试性。此外，采取这样的划分，有利于团队依照不同的模块功能分工进行开发，避免开发时互相影响，实现并行开发。

2.2 数据库设计

2.2.1 ER图设计

2.2.2 表结构设计

• 角色表

  名	类型	长度	小数点	不是null	自动递增	主键	注释
  角色ID	INTEGER			是		是
  角色名称	TEXT

• 存档表

  名	类型	长度	小数点	不是null	自动递增	主键	注释
  存档ID	INTEGER			是		是
  存档名称	TEXT
  存档时间	TIME
  金钱	TEXT

• 道具表

  名	类型	长度	小数点	不是null	自动递增	主键	注释
  道具ID	INTEGER			是		是
  道具名称	TEXT	20
  描述	TEXT	255
  重量	TEXT
  品质	TEXT
  出售价格	INTEGER

• 作物表

  名	类型	长度	小数点	不是null	自动递增	主键	注释
  作物ID	INTEGER			是		是
  作物名称	TEXT	20
  生长时间周期	INTEGER

• 耕地表

  名	类型	长度	小数点	不是null	自动递增	主键	注释
  存档ID	INTEGER			是		是
  位置x	INTEGER			是		是
  位置y	INTEGER			是		是
  土地样式	TEXT
  土地状态	TEXT

• 技能表

  名	类型	长度	小数点	不是null	自动递增	主键	注释
  技能ID	INTEGER			是		是
  技能名称	TEXT

• npc表

  名	类型	长度	小数点	不是null	自动递增	主键	注释
  npcID	INTEGER			是		是
  npc名称	TEXT
  性格	TEXT

• 对话表

  名	类型	长度	小数点	不是null	自动递增	主键	注释
  对话ID	INTEGER			是		是
  内容	TEXT

• npc_对话表

  名	类型	长度	小数点	不是null	自动递增	主键	注释
  npcID	INTEGER					是
  对话ID	TEXT					是
  发生时间	TIME
  对话ID和npcID分别为对话表和npc表中的对应字段的外键，删除和更新时都是级联关系。

• 存档_技能表

  名	类型	长度	小数点	不是null	自动递增	主键	注释
  存档ID	INTEGER			是		是
  技能ID	INTEGER
  等级	INTEGER
  经验	TEXT

• 存档_道具表

  名	类型	长度	小数点	不是null	自动递增	主键	注释
  存档ID	INTEGER			是		是
  格子ID	INTEGER
  道具ID	TEXT			是		是
  背包位置	TEXT

• 存档_作物表

  名	类型	长度	小数点	不是null	自动递增	主键	注释
  存档ID	INTEGER			是		是
  作物ID	INTEGER			是		是
  位置x	INTEGER
  位置y	INTEGER
  距离收获时间	INTEGER

2.2.3 设计思路

• 明确业务需求：满足游戏内地图资源的载入，游戏道具，玩家状态信息等游戏状态的多份数据保存，实现备忘录设计的存档效果。
• 确认核心实体：存档，道具，作物，耕地，npc，根据核心实体建表，根据核心实体之间的联系完善ER图，进一步修改各个表，更具需求选择字段数据类型，完善字段的划分。
• 表关系设计
  根据如下原则进一步完善表
  一对一关系：将两个实体合并到一个表，或者使用外键进行关联。
  一对多关系：在多的一方设置外键，关联到一的一方的主键。
  多对多关系：引入中间表，该表包含两个外键分别指向关联的两个实体。
• 根据联系添加必须的外键等字段，并注意主键与外键可能的部分依赖，并尽可能的避免，例如道具表通过存档id，背包格子id，道具id确定。存档id和道具id分别是存档表和道具表的外键。这样子父表与两个联系表均无部分依赖，范式等级达到3NF以上。
• 约束设计
  主键约束：对于每个表设为主键的id字段，设置主键约束，如角色id，
  非空约束：对于主键和一些不允许为空的字段进行非空约束，如存档id，
  长度约束：对于一些长度需要有限制的字段设置长度，如道具id
• 设计过程中遵循的准则：
  ①字段的原子性：每个字段都做到了不可分割，如土地位置（x,y）被改为土地x轴坐标，土地y轴坐标从而实现不可分割
  ②字段长度：对于长度可以确定范围的字段进行长度约束，如道具名称
  ③资源存储：数据库不存储任何资源文件，比如照片/视频/网站
  ④与主键相关：所有非主属性均可以由主属性唯一确定
  ⑤关系映射：对于一对多的关系,通过id建立关系（在耕地中使用土地x，y轴作为主键，避免新增主键造成的部分依赖）

  2.2.4 命名规范

• 表名和字段名字均采用中文或部分英文缩写（id,npc等）来命名。
• 关联表使用“实体名_实体名”来命名

2.3 接口设计

2.3.1 外部接口

2.3.1.1用户输入接口

• 描述：负责处理玩家输入，包含键盘、鼠标、手柄等控制，玩家可以通过这些设备控制游戏中的角色移动、物品排序、菜单操作等。
• 输入：控制设备输入
• 输出：对应的游戏响应
• 错误处理：对于无效输入，不做处理。忽略非法按键

2.3.2 内部接口

2.3.2.1耕地模块：

• 接口功能：
  耕地模块负责管理耕地的状态，包括种植、收获、作物生长等功能。

• 提供的接口：

  • plantCrop(Seed seed, Vector2 location)：在指定位置种植作物。
    参数：Seed seed，Vector2 location
  • harvestCrop(Vector2 location)：收获指定位置的作物。
    返回值：FarmProduct（返回收获的作物）

• 使用其他模块的接口：
  Player.holdItem()：玩家手持种子，进行播种操作。

2.3.2.2商店模块：

• 接口功能：
  商店模块用于处理玩家在商店的购物、卖出农产品以及与 NPC 的交易。

• 提供的接口：

  • addItem(Item item, int quantity)：添加指定数量的物品。
    参数：Item item，int quantity。
    返回值：bool（成功/失败）。
  • getReward()：获取当天商店的总收入
    返回值：int (当天的营业额)

• 使用其他模块的接口：
  Inventory.addItem(Item item,int quantity): 将物品放置到背包中

2.3.2.3背包模块：

• 接口功能：
  背包模块管理玩家持有的物品，可以添加、移除物品，并与手持物品进行互动。

• 提供的接口：

  • addItem(Item item)：向背包中添加物品。
    参数：Item item。
    返回值：bool（成功/失败）。
  • removeItem(Item item)：从背包中移除物品。
    参数：Item item。
  • getSelectedItem()：获取当前玩家选中的物品。
    返回值：Item（返回当前选中物品）

• 使用的接口：
  Player.holdItem()：玩家使用背包中的物品

2.3.2.4送货模块：

• 接口功能：
  送货模块管理玩家将物品送至指定地点的任务流程。

• 提供的接口：

  • addProduct(FarmProduct product, int quantity)：添加需要运送的货物
    参数：FarmProduct product, int quantity
  • getReward()：获取任务的报酬
    返回值：int money (玩家本次任务获得的报酬)

• 使用的接口：
  Inventory.selectedItem()：玩家选中的背包物品

2.3.2.5存档模块：

• 接口功能：
  存档模块负责管理游戏的保存与读取，包括玩家状态、世界状态等数据的保存与加载。

• 提供的接口：

  • saveGame()：保存当前游戏进度。
    返回值：bool（成功/失败）。
  • loadGame(int id)：加载游戏进度。
    返回值：GameData 对象。

• 使用的接口：
  Player.getPlayerStatus()：获取玩家状态并保存。
  Farming.getFieldStatus()：获取耕地状态并保存。
  Inventory.getItemList()：获取玩家的背包信息并保存。

3 类图、系统安全

3.1类图

3.1.1图

总体设计

3.1.2 设计思路

3.1.2.1存档系统

• 设计图
  

  

• 类设计

  • SaveManager类：用来管理所有的存档，提供新建、删除和加载存档的操作，记录当前的存档。

  • Save类：在Save类中，记录描述存档的数据，包括存档名、存档位置、存档是否收藏（已收藏的存档无法删除）以及存档的创建时间。
    Save类还需要记录游戏内的数据，使用一个GameSaveData类对象来存储。存档保存到文件或数据库中。

  • GameSaveData类：在GameSaveData中，存储包括玩家、地图以及游戏设置等数据。

• 类的关系
  Save类和SaveManager类使用组合关系，Save类和GameSaveData使用组合关系。

• 设计模式
  存档系统实现采用备忘录模式，为游戏存档系统提供了一种有效的方法来保存和恢复游戏状态，增强了游戏的可玩性和用户体验。

3.1.2.2背包系统

• 设计图
  

  

• 类设计

  • Inventory类：存放背包中的各种信息，包括背包容量、背包状态（打开或关闭）、选择的物品以及背包物品的数组。提供给玩家添加、丢弃、查看、查找以及整理背包的功能。
  • Slot类：表示背包的一个槽位，存储一个Item，记录堆叠数量。可以设置或移除当前槽位的物品。

• 类的关系
  由于Slot对象由Inventory创建时创建，并且具有强关联关系，因此采用组合关系。

• 设计模式
  使用到单例模式，每个玩家只能拥有一个背包。

  3.1.2.3商店系统

• 设计图
  

  

• 类设计

  • StoreBox类：记录上架的产品，可以使用玩家提供的算法工具对产品进行排序、查找等操作。
  • StoreManager：记录商店的销售额以及销售的数量，用于一段周期的结算，设计采用单例模式。
  • Customer类：来到商店内的顾客，记录顾客的请求。顾客有等待时间属性，提供商品超出该时间会导致顾客评价降低，更长的超时会使顾客离开。顾客的评价会影响流量和报酬。
  • CustomerManager：用于管理到店顾客的产生和离开，采用单例模式。
  • SortTool和SearchTool：提供给玩家的算法工具，采用策略模式，提供不同的算法供玩家使用。
  • Strategy：包括SortStrategy和SearchStrategy，使用不同算法实现接口，如快速排序、选择排序等排序策略，以及线性查找、二分查找等查找策略。

• 类的关系
  Save类和SaveManager类使用组合关系，Save类和GameSaveData使用组合关系。

3.1.2.4 送货系统

• 设计图
  

  

• 类设计

  • DeliverySystem类：用来管理送货系统，存储玩家送货操作的记录日志。计算玩家获得的所有收益总和等信息。
  • DeliveryManager类：用来管理每一次送货的地图，送货路径，送货时间，送货目标。以及玩家当次送货的路径信息，路途信息。以及送货结果，计算收益等。
  • Graph类：每一次送货时的地图信息。
  • Edge类：地图中结点信息
  • Vertex类：地图中边信息。包括距离，颜色（状态）等。

• 类的关系

  • Graph类和Edge类、Vertex类有强关联关系，因此设置成组合关系。
  • Edge类依赖于Vertex类
  • Graph类和DeliveryManager关联性较弱，设为聚合关系。

3.1.3 数据流图

3.1.3.1 耕种

3.1.3.2 背包

3.2 系统安全

由于我们的游戏为单机游戏，不像联网游戏那样面临大量的外部攻击，但依然有一些安全设计不可忽视，用来保护玩家数据、避免作弊、以及保证游戏的整体体验。
（1）数据加密
使用第三方插件Secure PlayerPrefs对存档进行加密处理，防止用户恶意篡改。
（2）存档系统健壮性
在游戏重要结点备份存档，或游戏内每日开始时，备份存档。同时允许用户保存多个存档，避免单一存档损坏无法恢复。
（3）防止本地作弊
在游戏发布时，采用 IL2CPP编译模式。由于IL2CPP模式将工程中的文件先编译为IL，再使用IL2CPP将这些IL变回CPP，并编译成能执行的汇编代码，最后利用VM运行。相比于unity默认的Mono模式编译，安全性得到很大提高。

4 改进分析

4.1 改进1：不滥用泛化，组合这些强关系

在上一次需求分析中，我们设计的类图多处关系设定不合理。
在本次设计中我们慎重考虑类之间的关系。如图类（Graph）和顶点类（Vertex）、边类（Edge）为组合关系，DeliveryManager和Graph为聚合关系。
更加合理地使用继承关系，如多种排序策略继承排序类，多种搜索策略类继承搜索类。

4.2 改进2：使用更加合理的设计模式

在上一次的类图设计后，我们了解了更多的设计模式，并运用到改进的类图设计中。在存档系统设计中，采用了备忘录模式；在商店系统设计中，对于算法工具，采用了策略模式实现不同的算法。除此之外，我们对单例模式、原型模式等设计模式的理解也更进一步，有利于我们完成接下来的项目工作。

4.3 改进3：类不该使用其他对其他类属性的操作

上次设计Player类中，使用其他类的操作，如plant()应该是Crop类的操作,以及其他函数useTool()等。现在删除这些操作，在具体其他类中进行调用。

5 团队绩效

6 开发计划安排

6.1计划表

6.2 分工表