软件工程第二次个人作业
《Cloud Game 项目分析》
一、项目信息
- 课程：软件工程
- 作业要求链接：https://edu.cnblogs.com/campus/fzu/SE2024/homework/13253
- 作业目标：学习借鉴 AIGC 生成羊了个羊类似游戏
- 学号：102202132
二、项目展示
- GitHub 链接：https://github.com/zhengbingzhi/zhengbingzhi/commit/4ea88c2995ec164a2ce73112dda1db10924e0b0e
三、项目介绍
-
我设计的是一款类似于养了个羊的简单消除小游戏，主要通过pygame实现，名为消云大作战。以下是项目的特色功能和前端设计的介绍：
-
游戏开始界面：
-
游戏游玩界面：
- 游戏名称：消云大作战
- 特色功能和前端设计：
- 游戏开始界面：展示游戏的主菜单，包括游戏难易程度的选择以及困难游戏的排行榜（按通关时间排序）。
- 游戏游玩界面：玩家在游戏中进行消除操作，底部有暂存区，游戏设有时间限制和重置道具，成功消除所有图片则胜利，否则失败。
- 游戏特色：
- 加入倒计时元素，规定时间内未消除所有卡牌则游戏失败。
- 提供三次重置机会的道具。
- 游戏结束界面有 restart 按钮可反复闯关。
- 主菜单设置不同难易程度选项。
- 主菜单有排行榜可查看玩家比赛记录。
- 游戏图片：结合自身 logo“cloud”，对不同形状和颜色的 cloud 进行消除。
四、技术与实现思路
（一）使用的技术
pgzrun库：用于游戏的开发和运行。random库：生成随机数，用于打乱卡片等操作。time库：记录游戏时间。pygame.mixer：处理游戏背景音乐。PIL（Python Imaging Library）：调整图像大小。
（二）特殊算法
- 关卡生成算法：
- 随机打乱：对于不同难度模式，通过随机抽取数字并排列卡片，然后根据难度确定卡片的层数和分布。
- 难度区分：硬模式有更多的卡片和层数，而简单模式相对较少。
- 消除算法：
- 卡片匹配：当玩家点击卡片时，检查与卡片堆中卡片的标签是否不同，如果不同数量小于 2 则添加到卡片堆，否则从卡片堆中移除不同的卡片。
- 连锁反应：当某一层的卡片被移除后，检查下一层与该层接触的卡片，若没有上层卡片接触则将其状态设置为可点击。
- 游戏状态管理算法：
- 游戏结束判断：根据卡片堆长度是否超过 7 或者所有卡片是否被移除来判断游戏是否结束。
- 时间管理：记录游戏开始时间，实时计算剩余时间，当时间耗尽时游戏结束。
（三）实现思路
- 初始化：
- 开始游戏时，先进入主菜单界面，玩家可以选择硬模式、简单模式或查看排行榜。
- 根据玩家选择的难度初始化游戏，包括生成卡片、设置背景音乐等。
- 游戏进行：
- 玩家点击卡片时，根据消除算法处理卡片状态和卡片堆。
- 实时绘制游戏界面，包括背景、卡片、工具栏等。
- 不断更新游戏状态，如检查时间是否耗尽、卡片是否全部消除等。
- 游戏结束：
- 当游戏结束时，显示游戏结束画面，并提供重新开始按钮。
- 如果玩家在硬模式下通关，可以记录通关时间并显示在排行榜上。
五、测试视频
六、AIGC 表格
| 序号 | 项目中学到的内容 | 应用场景 | 心得体会 |
|---|---|---|---|
| 1 | 使用pgzrun库进行游戏开发 |
开发小型游戏项目 | pgzrun提供了简洁高效的游戏开发框架，大大降低了开发难度。 |
| 2 | 利用random库打乱元素 |
随机生成游戏关卡、元素分布等场景 | 增加了游戏的随机性和趣味性，让每次游戏体验都有所不同。 |
| 3 | 通过time库管理游戏时间 |
限时游戏、任务计时等场景 | 增强了游戏的紧迫感，促使玩家在规定时间内做出决策。 |
| 4 | pygame.mixer处理背景音乐 |
各类游戏、多媒体应用中添加音乐氛围 | 合适的音乐能极大地提升游戏的沉浸感和趣味性。 |
| 5 | 图像调整函数处理游戏图片 | 游戏中需要适应不同分辨率、尺寸要求的图像场景 | 学会了灵活调整图像大小，以满足游戏的视觉需求。 |
| 6 | 状态变量管理游戏状态 | 游戏状态的切换、判断胜利或失败等场景 | 清晰的状态管理对于复杂游戏逻辑的实现至关重要。 |
| 7 | 菜单设计与交互 | 游戏开始前的模式选择、设置等场景 | 良好的菜单设计提升了用户体验，方便玩家快速进入游戏。 |
| 8 | 关卡生成算法 | 不同难度的游戏关卡设计场景 | 了解了不同难度关卡的生成方式，丰富了游戏内容，满足不同玩家的需求。 |
| 9 | 消除算法 | 消除类游戏的核心玩法场景 | 逻辑判断的实现让游戏玩法更具挑战性，锻炼了编程思维。 |
| 10 | 游戏结束判断和处理 | 各种游戏判断游戏结束的场景 | 明确了游戏结束的条件和相应的显示，使游戏有始有终，增强了游戏的完整性。 |
七、PSP 表格
| 阶段 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|
| 计划 | 10 | 15 |
| 需求分析 | 20 | 25 |
| 设计 | 30 | 40 |
| 编码 | 120 | 150 |
| 测试 | 30 | 40 |
| 报告 | 20 | 30 |
评价：
完成过程：
- 在需求分析阶段，仔细阅读了代码并确定了各个功能模块的作用，花费的时间比预估稍长是因为需要更深入地理解游戏的逻辑和流程。
- 设计阶段，思考了如何更好地呈现任务分解以及对各个部分的理解，由于对一些细节考虑较多，所以超时。
- 编码阶段，遇到了一些小的逻辑问题和语法错误，调试花费了一些额外的时间。
- 测试阶段，进行了多种场景的测试，确保对各个功能的理解准确无误，也发现了一些之前未考虑到的情况。
- 报告阶段，组织语言和整理思路花费了比预期多的时间。
最终效果：
- 较好地完成了对任务的分解，清晰地呈现了各个阶段的工作内容和耗时情况。
- 通过分析代码，对游戏的架构和实现有了更深入的理解。
做得好的地方：
- 认真进行了需求分析，确保对代码的理解准确。
- 在测试阶段比较全面地考虑了各种情况，提高了分析的准确性。
可以改进的地方：
- 在计划阶段可以更加精确地预估各个阶段的耗时，避免整体超时。
- 在编码阶段可以更加熟练地掌握编程语言和工具，减少调试时间。
- 在报告阶段可以提前规划好报告的结构和内容，提高写作效率。
