琼港计划团队 ——项目系统设计与数据库设计

[琼港计划团队账号]

这个作业属于哪个课程	2501_CS_SE_FZU
这个作业要求在哪里	团队作业——概要设计和数据库设计
这个作业的目标	完成项目系统设计和数据库设计
其他参考文献	《构建之法（第三版)》 《系统设计说明书》《数据库设计说明书》国标规范文本

@

目录

• GitCode仓库链接
• 琼港计划_系统设计说明书
• 琼港计划_数据库设计说明书
• 琼港计划_系统和数据库设计答辩ppt
• 1.系统设计
• 1.1体系结构设计
• 1.2功能模块层次图
• 2.数据库设计
• 2.1ER分析
• 2.2表结构设计
• 3.类图
• 4.系统安全和权限设计
• 5.改进分析
• 一、 系统设计方面的改进​​
• V1.0版本的缺点：刚性架构，难以扩展​​
• ​​V2.0文档的改进​​：
• V1.0版本的缺点：模块界限模糊，高耦合​​
• ​​V2.0文档的改进​​：
• ​​二、 数据库设计方面的改进​​
• V1.0版本的缺点：僵化的表结构​​
• V2.0文档的改进​​：
• V1.0版本的缺点：缺乏游戏数据记录与分析能力​​
• V2.0文档的改进​​：
• 6.团队绩效

GitCode仓库链接

GitCode仓库链接

琼港计划_系统设计说明书

GitCode仓库链接

琼港计划_数据库设计说明书

GitCode仓库链接

琼港计划_系统和数据库设计答辩ppt

GitCode仓库链接

1.系统设计

1.1体系结构设计

用户输入：通过Input System处理用户输入信号。
图形界面：GUI System负责用户界面渲染。
错误处理：Error Manager管理系统错误和异常。
事件管理：Event Manager负责事件分发和处理。
场景管理：Scene Manager管理游戏场景和对象。
图形渲染：Graphical Rendering负责视觉渲染。
音频渲染：Audio Rendering处理游戏音效。
游戏循环：Game Loop驱动游戏主循环。
资源管理：Resource Manager管理游戏资源。
实体管理：Entity Manager管理游戏实体。

1.2功能模块层次图

2.数据库设计

2.1ER分析

效果模块中，所有卡牌实体（包括食谱卡、员工卡、资源卡、营销卡以及boss）均通过效果ID（effectid）这一相同方式与核心的效果表（tbeffect）建立外键关联。这种统一的关联机制意味着，游戏中的每一种卡牌其具体能力、升级行为或特殊作用，都并非硬编码在卡牌自身，而是通过effectid动态引用并执行效果表中预先定义好的逻辑（由classpath和method_name指定）。该设计将效果的具体实现与卡牌实体进行了解耦，通过效果表这一中心化配置点，实现了对所有卡牌效果的统一管理与灵活调配，从而支撑游戏内各类卡牌功能的动态调用与扩展。

游戏分数模块包含游戏成果统计表和游戏日志表。游戏成果统计表记录每局游戏的最终得分和金币数据。游戏日志表记录构成最终得分的各个分数组成部分。两个表通过游戏ID关联，共同完成游戏分数的统计功能。

2.2表结构设计

食材卡实体

食谱实体

员工卡实体

供货卡实体

营销卡实体

效果实体

Boss实体

游戏统计实体

玩家操作日志实体

3.类图

4.系统安全和权限设计

4.1 安全性设计

4.1.1 反盗版与许可证验证
建立基于本地硬件指纹与离线验证相结合的许可证核查机制。对游戏核心执行文件进行加密和代码混淆，防止静态分析与非法分发。游戏启动时和运行关键节点对许可证状态进行静默校验，验证失败则可能触发游戏逻辑异常或内容缺失。采用随机且多层次的校验点设计，增加逆向工程与自动化破解的难度。

4.1.2 游戏逻辑与内存完整性保护
实施针对游戏客户端运行时的全面保护措施。对关键游戏逻辑函数进行循环完整性校验，防止内存补丁。对玩家核心属性、物品数据、系统数值等在内存中的存储进行实时加密或校验，防止通过通用内存修改工具进行实时篡改。确保游戏核心运行逻辑不被外力干扰。

4.1.3 输入验证与逻辑漏洞防护
对所有本地配置文件、存档文件及游戏模组的数据读取进行严格的有效性验证和逻辑边界检查。防止因文件被恶意或异常篡改而导致的游戏崩溃、逻辑错误或利用漏洞获取不正当优势。对游戏内脚本系统的输入进行沙箱化处理，限制其可能执行的危险操作。

4.1.4 本地数据加密与防篡改存储
对游戏存档、配置文件等本地存储的敏感数据进行强加密和完整性保护。存档文件使用自定义二进制格式并结合加密算法进行存储，防止玩家通过文本编辑器或通用工具直接修改。加密密钥通过程序逻辑与静态常量混合动态生成，提高分析难度。同时对存档数据附加校验和，用于检测非法修改。

5.改进分析

一、 系统设计方面的改进​​

V1.0版本的缺点：刚性架构，难以扩展​​

​​缺点描述​​：早期版本可能采用了一种“硬编码”式的架构。例如，每个员工（小丑）的效果被直接编写在Employee类的庞大switch-case或if-else语句中。添加一个新员工，就需要程序员修改核心代码，重新编译整个游戏。
​​带来的问题​​：
​​策划与开发强耦合​​：策划人员无法独立配置新卡牌，必须依赖开发人员，极大拖慢了内容更新速度。
​​代码臃肿且脆弱​​：Employee类会变得极其庞大，修改一个员工的效果可能会意外影响其他效果，测试和调试困难。
​​无法支持数据驱动​​：游戏内容更新几乎等同于版本更新，不灵活。

​​V2.0文档的改进​​：

​​引入了“效果（Effect）”抽象层​​：从类图中可以看到，RecipeCard（食谱卡）、EmployeeCard（员工卡）等都与Effect（效果）关联。这标志着系统从“面向具体卡牌”转变为“面向抽象效果”。
​​实现了数据驱动设计​​：卡牌的能力不再硬编码，而是通过关联的Effect来定义。这使得策划可以通过配置数据（如数据库中的tbeffect表）来调整或创建新卡牌，而无需修改程序代码。这是本次迭代最核心的进步。

V1.0版本的缺点：模块界限模糊，高耦合​​

​​缺点描述​​：游戏逻辑、UI渲染、数据存取等代码可能混杂在一起，没有清晰的界限。例如，一个处理点击卡牌的方法，可能同时包含了判断逻辑、分数计算、播放动画和更新数据库。
​​带来的问题​​：代码可读性差，难以维护和单元测试。修改UI可能影响游戏逻辑，反之亦然。

​​V2.0文档的改进​​：

​​清晰的模块层次图​​：文档中展示了如Input Manager、GUI System、Game Loop、Resource Manager等模块，体现了​​关注点分离​​的原则。
​​初步的分层架构​​：虽然体系结构图较为概念化，但已能看出将用户输入、界面渲染与核心游戏逻辑分离的意图，为低耦合、高内聚的代码结构奠定了基础。

​​二、 数据库设计方面的改进​​

V1.0版本的缺点：僵化的表结构​​

​​缺点描述​​：早期数据库设计可能为每种卡牌类型（员工、食谱）创建了完全独立的表，每个表都包含该卡牌独有的字段（如员工的retire_risk，食谱的ingredient_requirement）。如果要实现一个具有复杂新效果的卡牌，就需要频繁地修改表结构。
​​带来的问题​​：数据库 schema 不稳定，每次添加新卡牌类型都可能需要ALTER TABLE操作，这在产品上线后是高风险行为。

V2.0文档的改进​​：

​​引入核心的tbeffect表​​：这是​​数据库设计上革命性的改进​​。它通过一种“元数据”的方式，将卡牌的​​行为​​与卡牌的​​实体​​解耦。
​​极高的灵活性和可扩展性​​：现在，要添加一个具有全新效果的卡牌，只需在tbeffect表中插入一条新记录，并在相应的卡牌表中设置对应的effectid即可。​​无需修改任何表结构​​。这完美支持了游戏后期大量新增卡牌的需求。

V1.0版本的缺点：缺乏游戏数据记录与分析能力​​

​​缺点描述​​：早期版本可能只保存了最简单的玩家进度（如解锁的卡牌、最高分），而没有记录每局游戏的详细数据。
​​带来的问题​​：当出现Combo强度失衡（太强或太弱）时，策划人员无法追溯对局历史来分析问题根源，只能凭感觉或大量手动测试来调整，效率低下。

V2.0文档的改进​​：

​​设计了详细的tbgame_log表​​：该表记录了每局游戏的详细操作日志。这不仅用于存档/读档，更重要的是为​​游戏平衡性分析​​提供了数据支撑。
​​支持数据驱动的平衡调整​​：通过分析日志，可以统计出哪些员工卡、食谱卡的使用率和胜率最高，哪些Combo被频繁触发。这使得数值调整从“凭经验”变为“看数据”，更加科学和高效。

6.团队绩效

学号	姓名	工作内容	贡献度
102300314	黄逸涵	《系统设计说明书》和 博客编写	10%
102300124	林哲纶	《系统设计说明书》 和 绘图（ER图，类图等）	10%
103200323	施涵	《系统设计说明书》和《数据库设计说明书》	20%
062300243	滕柏宇	《系统设计和数据库设计答辩PPT》	10%
172209065	林伟豪	《系统设计和数据库设计答辩PPT》	10%
102300228	杨欣潼	答辩汇报，博客编写	10%
102300319	陈启航	《系统设计和数据库设计评审表》	10%
102300311	方林升	《数据库设计说明书》和 博客编写	10%
102300201	陈吕萌	《数据库设计说明书》和 绘图（ER图，类图等）	10%