该文档是关于COMP9201和SOFT2201课程作业2的说明，主要内容包括作业截止日期、占比、重要提示、任务概述、提供的资源、期望的成果、提交细节等。学生需要实现Pac – Man游戏，使用指定的设计模式（观察者模式、工厂方法模式、单例模式、命令模式），确保游戏可通过JSON配置文件进行配置，并根据实现的代码重构UML类图。此外，还需要提交包含UML类图和相关说明的报告，以及代码（包含src文件夹、build.gradle和README）。

SOFT2201/COMP9201作业2

截止日期：澳大利亚东部标准时间2024年9月22日星期日晚上11:59 本作业占期末评估的15%

重要提示：在本作业中，您只允许实现作业2的要求。请勿包含任何其他功能，否则将扣除分数。

重要提示：您必须使用我们提供的模板，并且只能使用JavaFX库进行GUI开发。不得使用任何其他GUI库。

任务概述

在作业2中，您将实现Pac – Man游戏，并根据实现的代码重构UML类图。您可以在作业1的描述中找到Pac – Man游戏的一般描述。您必须确保游戏可以通过JSON配置文件进行配置。在实现过程中，您必须按照以下要求使用以下GoF设计模式： – 观察者模式：用于更新游戏窗口的UI，包括分数、Pac – Man的生命数量以及“GAME OVER”、“YOU WIN”和“READY”屏幕。 – 工厂方法模式：所有游戏实体（包括墙壁、 pellets、Pac – Man和鬼魂）都将使用工厂方法模式构建。 – 单例模式：确定实现中自然为单例且需要全局访问的类。使用单例模式实现这些类，以确保在整个应用程序中每个类只有一个实例。 – 命令模式：用于处理玩家的键盘输入并移动Pac – Man向上、向左、向右和向下。您可以在适当的地方使用其他设计模式。

SOFT2201/COMP9201作业2

我们为您提供的内容

在提供给您的代码框架中，您将能够找到： – JSON文件：一个示例配置文件（config.json） – 地图文件：一个示例地图文本文件（map.txt） – build.gradle文件：一个示例build.gradle文件 – 代码框架：提供了一个代码框架来帮助您开始。您可以根据需要对其进行或多或少的修改。 – 该框架在当前状态下无法运行。您需要进行一些修改才能使其能够运行。 – 注意：框架使用像素碰撞而不是网格碰撞。您可以按照自己的意愿实现碰撞。 – 您必须使用JavaFX进行GUI开发 – 不允许使用其他GUI库。 – 精灵：您将使用这些来渲染游戏实体。它们可以在src/main/resources中找到。 – 字体：用于显示游戏消息和分数的字体。它可以在src/main/resources中找到。注意，要下载框架，请在EdStem代码提交页面上打开文件资源管理器，然后右键单击以下载所有文件。

SOFT2201/COMP9201作业2

我们对您的期望

实现任务（9分）

您将使用Java编程语言实现下面描述的Pac – Man游戏。在实现过程中，您可以考虑作业1中的设计。您的Pac – Man游戏应包括以下功能：

地图

地图指定了Pac – Man和鬼魂可以移动的位置。它以网格形式布局；实体可以在没有墙壁（由蓝色线条表示）的行和列上移动。地图布局存储在文本文件中（例如map.txt），地图文件的名称可以在JSON配置文件的“map”属性下找到。地图文件将地图存储为多维字符数组，其中每个字符代表该单元格中的内容。

字符可渲染精灵 |字符|可渲染精灵| |—|—| |0|空单元格不适用| |1|水平墙壁| |2|垂直墙壁| |3|角落墙壁（上 + 左）| |4|角落墙壁（上 + 右）| |5|角落墙壁（下 + 左）| |6|角落墙壁（下 + 右）| |7|Pellet| |p|Pac – Man| |g|鬼魂|

注意： – 保证地图高36行，宽28列，前3行和后2行为空。每个网格空间为16×16像素。 – 游戏屏幕尺寸为448×576。 – 保证提供的所有地图都是有效的。每个地图都代表一个迷宫，允许Pac – Man和鬼魂在其中移动。 – 地图中包含的所有可渲染对象（Pac – Man、鬼魂、墙壁、Pellet）都必须使用工厂方法模式构建。

Pac – Man

玩家必须能够使用箭头键控制Pac – Man在迷宫中移动（上、下、左、右）。玩家的键盘输入处理和Pac – Man的相应移动应使用命令模式完成。 Pac – Man有五个可以渲染的精灵：一个闭着嘴的精灵和四个分别指向每个基本方向的张嘴精灵。Pac – Man的图像应每八帧在张嘴和闭嘴之间交替，并且张嘴精灵应与他移动的方向相关。例如，如果Pac – Man向上移动，他的嘴应指向上方。游戏开始时，Pac – Man应自动向左移动。除非与墙壁碰撞，否则Pac – Man始终在移动。如果与墙壁碰撞，Pac – Man将停留在同一位置，但会继续在张嘴和闭嘴精灵之间交替。玩家可以排队移动，以便Pac – Man在下次可能时相应地转弯。例如，如果Pac – Man处于以下位置，向左移动，并且玩家按下了以下键： – 向下：Pac – Man将继续向左移动，并在下次可能的十字路口向下转弯。 – 向上：Pac – Man将继续向左移动，并在下次可能的十字路口向上转弯。 – 向右：Pac – Man将立即转身（Pac – Man总是可以转身）。 – 向左：Pac – Man将继续保持不变。请注意，如果玩家在Pac – Man转弯之前按下多个键，则使用最近按下的键。例如，如果玩家先按下向下键，然后按下向右键，在Pac – Man实际向下转弯之前，Pac – Man将仅向右转弯。 Pac – Man以恒定速度移动。他在每个关卡的速度在配置文件的“pacmanSpeed”属性中指定。配置文件中的“numLives”属性指定了Pac – Man的生命数量。剩余的生命在屏幕底部用面向右的Pac – Man图像表示。

注意：您必须使用观察者模式在屏幕上显示Pac – Man剩余的生命数量。当Pac – Man用完生命时，游戏结束。

鬼魂

鬼魂是Pac – Man的敌人。他们的目标是通过追捕并击中Pac – Man来阻止他收集地图上的所有pellet。在作业2中，只有一种类型的鬼魂。游戏中鬼魂的数量在地图上指定，地图将显示所有鬼魂的起始位置。与Pac – Man一样，鬼魂可以在地图上水平和垂直移动。他们不能穿过墙壁；然而，他们可以相互穿过。鬼魂有两种模式：SCATTER和CHASE。这些模式决定了鬼魂在到达十字路口时的行为。您的应用程序将在这两种模式之间交替鬼魂，第一种模式为SCAT – TER。这些模式的持续时间（以秒为单位）在JSON配置文件的“modeLengths”属性中指定。鬼魂以恒定速度移动。他们在每个模式下的速度在配置文件的每个关卡的“ghostSpeed”属性中指定。当鬼魂到达十字路口（可以转弯的点）时，它确定目标位置，然后根据欧几里得距离朝着最接近目标的方向移动。鬼魂的目标位置由其当前模式决定： – 如果鬼魂处于SCATTER模式，目标位置是地图的一个预先分配的角落。在创建时，为每个鬼魂随机分配地图的一个角落。 – 如果鬼魂处于CHASE模式，目标位置是Pac – Man的位置。请注意，除非被困住，否则鬼魂不能转身并朝着它刚刚移动的相反方向移动。例如，如果一个鬼魂向上移动到一个十字路口，它不能向下转弯，而是必须朝着其他三个基本方向中最接近目标位置的方向移动。当鬼魂与Pac – Man碰撞时，Pac – Man失去一条生命，所有鬼魂和Pac – Man返回他们的起始位置。当Pac – Man失去所有生命时，游戏结束。

Pellet

Pac – Man的目标是收集地图上的每个pellet。Pac – Man通过与pellet碰撞来收集它。当发生这种情况时，pellet将从地图上移除。Pellet实体不会移动，鬼魂也不会收集它们。 Pac – Man每收集一个pellet，他将获得100分。他的分数显示在迷宫上方的屏幕顶部。注意，您需要使用观察者模式在屏幕上显示玩家的分数。如果Pac – Man被鬼魂击中，pellet不会重置 – 相反，之前碰撞前收集的所有pellet仍将从地图上清除。一旦Pac – Man收集了地图上的所有pellet，游戏将进入下一关。

其他要求

当游戏实体处于起始位置时，屏幕将显示“READY!”文本，持续100帧，然后继续。这适用于： – 每个关卡开始之前（包括游戏启动） – Pac – Man失去一条生命后（并且仍有生命剩余）如果Pac – Man用完生命，将显示“GAME OVER”屏幕5秒钟，然后应用程序结束。注意，当Pac – Man失去所有生命时，他和所有鬼魂将从屏幕上消失。当玩家完成配置文件中提供的所有关卡时，将显示“YOU WIN!”屏幕5秒钟，然后应用程序结束。注意，当Pac – Man完成所有关卡时，他和所有鬼魂将从屏幕上消失。我们在提供的代码库的资源文件夹中提供了字体文件。您需要使用观察者模式实现这些屏幕。

重要提示：您只能在当前作业中实现上述功能，不应包含任何其他功能。否则将扣除分数。您可能希望参考作业1中的一般问题描述，并考虑您的设计是否可以扩展以允许这些功能，或者是否需要完全重写。

SOFT2201/COMP9201作业2

报告任务（6分）

对于您的报告，最多1000字，包括以下部分： 1. 设计概述。包括整个系统的UML类图，包括设计模式。 – 由于您的UML类图可能很大且复杂，目标是仅显示每个类中的重要属性和方法（即不显示getters/setters）。此外，仅显示模块之间的重要关系。 – 如果您的UML图太大，则需要： – 在本节中包含整个UML图；并且 – 在“设计模式”部分中包含关键组件的放大版本。 – 您必须确保您的图对标记人员可读/可理解（例如，尽可能避免交叉线）。如果您的标记人员无法理解您的图，则该相应部分将得零分。 – 您的标记人员不会在本地下载您的PDF，因此请确保您的图在Canvas中可读。请注意，在Canvas中您最多可以放大200％。如果您的图在放大200％时不清晰可读，请在从您选择的UML工具导出时使用更高的屏幕质量，或将其导出为PDF并与您的报告PDF合并。 2. 设计模式。使用以下详细信息描述您在实现中使用的所有设计模式： – 涉及的类及其角色。您可以在此处包含参与类的放大类图。 – 此模式在SOLID/GRASP原则方面对您的代码所做的事情 – 此模式提供的总体好处（具体针对您的代码，而不是一般模式） – 此模式导致的缺点（具体针对您的代码，而不是一般模式） – 对于单例模式，解释为什么您选择此/这些类为单例。 3. 作业1反思。在本节中，讨论您在作业1中的设计（即类图）如何帮助或阻碍您在本作业中的设计。 4. 变更理由。简要说明您对作业1设计所做的更改的理由。 5. 任何致谢/参考要求。

SOFT2201/COMP9201作业2

提交细节

您需要在截止日期前将所有评估项目提交到其提交门户。这包括： 1. 报告（6分）：在Canvas页面上提交报告作为单个PDF文档。 2. 代码（9分）：您的代码应作为ZIP文件提交，仅包含您的src文件夹、build.gradle和README在EdStem页面上的代码。 – 编译和运行 – 重要提示：示例JSON配置文件和map.txt文件必须包含在您的src/main/resources文件夹中。如果放置不正确，将扣除分数。 – README文件必须涵盖您希望标记人员知道的任何细节。在您的README中，您必须包括以下项目： – 如何运行您的代码（例如，运行您的应用程序的任何特殊要求） – 哪些文件和类参与了实现的每个设计模式 – 您希望标记人员知道的任何其他事情 – 我们将通过在终端中运行gradle clean build run来执行您的代码，环境配置如下： – Gradle 7.4.2 – JDK 17 – Unix基于的系统 – 如果您的代码按照上述提供的说明无法运行，您将在本评估的编码部分获得零分。 – 风格和文档 – 请遵循Google Java风格指南 – 确保使用的名称有意义，结构清晰一致 – Javadoc不是必需的，但请确保在需要时提供注释。 – 将与模式相关的文件放在具有模式相关名称的包中，例如observer、command、factory