Java代写:SWEN20003 Shadow Quest Part1

接着上次的继续代写,使用游戏引擎框架,完善RPG游戏。

Overview

In this project, you will create a graphical role-playing game, Shadow Quest, in the Java programming language, continuing on from your work on Project 1. You may use any platform and tools you wish to develop the game, but we recommend the Eclipse IDE for Java development. This is an individual project. You may discuss it with other students, but all of the implementation must be your own work and we will be strictly checking this has been adhered to. Like Project 1, you will be required to briefly demonstrate the game in a workshop.

You are not required to design any aspect of the game itself - this specification should provide all information about how the game works. However, you will be required to design the classes before you implement the game.

There are two parts to the project, with different submission dates.

The first task, Project 2a, requires that you produce a class design, using a diagramming tool of your choice, outlining how you plan to implement the game. This should consist of a UML class diagram, showing all of the classes you plan to implement, the relationships (inheritance and association) between them, and their attributes and primary public methods. If you like, you may show the class members in a separate diagram to the hierarchy diagram, but you must use proper UML notation.

The second task, Project 2b, is to complete the implementation of the game, as described in the manual which follows. You do not have to follow your class design - it is merely there to encourage you to think about the object-oriented design before you start implementing, however if you do change it, you will be required to provide a new class diagram that shows the new relations and a short document explaining the rationale behind your changes.

The purpose of this project is to:

  • Give you experience designing object-oriented software with simple class diagrams,
  • Give you experience working with an object-oriented programming language (Java),
  • Introduce simple game programming concepts (user interfaces, collisions, simple AI),

Shadow Quest

Game Manual

It has been seven days since my father, King Lathran, came down with a terrible illness. To date, the best efforts of our court physicians and magi have been in vain. The Elven priestess, Lady Elvira, suspects this is no ordinary sickness, but a magical curse.

If she is correct, then there is only one way to cure the king, and restore order to the land: the Elixir of Life, a potion rumoured to have been created centuries ago, with the power to heal any wound, and undo any curse.

Unfortunately, the potion is found in the Land of Shadows to the east, held by the Necromancer, Draelic, who commands a vile army of the undead. He will not give it up easily. I only hope that someone shall come forth, with the will to retrieve the elixir before all is lost…

Game overview

Shadow Quest is a role-playing game where one player battles against computer-controlled enemies on a quest to retrieve the Elixir of Life. There are two areas in the game:

  • The town, where friendly characters live. The player can walk around and talk to the villagers. Elvira is an Elven priestess, who will heal the player if they are wounded.
  • The wilderness, where evil creatures live. The player can freely explore these areas, fight monsters, and collect useful items.

The goal of the game is to defeat the Necromancer Draelic, retrieve the Elixir of Life, and return it to Prince Aldric in the town.

The game map

In this game, the “world” is a two-dimensional grid of tiles. The player is able to move about freely to explore the entire world (but of course, the player cannot walk on trees, mountains, water, and other types of terrain).

Units and stats

A unit is our term for a game character or person. There are three general unit types in the game:

  • The player. Controlled by you; able to talk to villagers and fight monsters.
  • Villagers. Friendly units; do nothing until the player talks to them.
  • Monsters. Enemy units; either passive or aggressive. Passive monsters wander around the map, and run away when attacked. Aggressive monsters try to kill the player.

Each unit’s position in the world is stored as an (x, y) coordinate in pixels. This means that units can stand at any point on the map, rather than being constrained to the tiles of the map grid. All measurements are given in pixels.

Internally, a unit has no “size”; it is just a single point. When displaying a unit, the image should be centered around the unit’s position.

All units have a “HP” (short for “hit points”) field which is an integer value that determines their current level of health. Units who are wounded in battle lose HP, and units who are “healed” gain HP. Units who lose all of their HP are “dead”. (See “Combat” later).

A stat (or attribute) is an integer value which determines how powerful a unit is in some way. A unit’s “stats” never change (except in the case of the player picking up items; see “Items” later).

  • Max-HP - (Short for “maximum hit points”). This stat determines the maximum amount of HP the unit has when fully healed.
  • Damage - This stat determines the maximum amount of damage the unit can do when attacking (see “Combat”).
  • Cooldown - This stat determines the minimum length of time the character has to wait between attacks, in milliseconds (see “Combat”).

As shown in Figure 1, all units except the player have a health/name bar floating above their heads. This bar shows the unit’s health percentage as a red bar on a black background, overlayed with the unit’s name in white text.

See the data file data/units.txt for details on the stats and locations of the units.

Gameplay

This is a real-time game, meaning that events happen continuously, even if you do not press any keys. For example, monsters may move or attack the player even if the player stands still. The game takes place in frames. Much like a movie, many frames occur per second, so the animation is smooth. On each frame:

  1. All game units have a chance to move. Monsters move automatically towards or away from the player if they are nearby. The player moves if the keyboard is being pressed.
  2. The “camera” is updated so that it is centered around the player’s position.
  3. The entire screen is “rendered”, so the display on-screen reflects the new state of the world.

Controls

The game is controlled entirely using the arrow keys on the keyboard. The left, right, up and down keys move the player. Each frame, the player moves by a tiny amount in the direction of the keys being pressed, if any. It is possible to move diagonally by holding down two keys at a time (for example, move north-east by holding the up and right keys).

The player moves at a rate of one quarter of a pixel per millisecond, in each direction.

You can attack a monster simply by moving close to it (within 50 pixels) and holding A. Similarly, you can talk to a villager by moving close (within 50 pixels) and pressing T.

Villagers and dialogue

In the town you will find a number of friendly villagers who will help you out. When the player moves within 50 pixels of a villager, some action may occur (depending on the villager). There are three villagers:

  • Prince Aldric - When the player interacts with Prince Aldric, nothing happens, unless the player is carrying the Elixir, in which case the Elixir is removed from the player’s inventory.
  • Elvira - When the player interacts with Elvira, they are healed fully (their HP is brought up to their Max-HP).
  • Garth - While he appears to be a simple farmer, Garth knows many things and will help you to find powerful items.

The game employs a simple dialogue system. Units may display a single line of dialogue above their heads (as shown in Figure 2) for 4 seconds. See the data file data/dialogue.txt for the exact dialogue to be displayed.

Monsters

There are a number of species of creatures which roam the wilderness, some are passive and harmless, while others are aggressive and dangerous. If you aren’t careful, you’ll find them ending your quest early.

Monsters have a very simple AI (artificial intelligence), which will differ depending on whether the monster is passive or aggressive.

Passive Monsters

A passive monster will wander around the map randomly by default. Passive monsters are slow moving, and move at one fifth of a pixel per millisecond. This means that players can always move a little bit faster than passive monsters to chase them down.

Every 3 seconds the monster should pick one of 9 directions to move in (Up, Down, Left, Right, Up-Right, Down-Right, Down-Left, Up-Left, or no direction) and move in that direction. Thus a monster will change its direction of movement once every 3 seconds. Monsters proceed to move in this way until a player attacks it. (See “Combat” later).

Passive monsters do not attack players. They simply wander the world. However, if a passive monster is attacked by a player, it will try to run away from the player (at the same speed of one fifth of a pixel per millisecond) as dictated by Algorithm 1. If 5 seconds pass, and the passive monster has not been attacked by the player again, the passive monster will know it’s safe, and will resume wandering the map. Just like the player, monsters can’t move through trees, water, etc.

Aggressive Monsters

An aggressive monster will do nothing by default. If the player is within 150 pixels of the monster, it will move towards the player. If the player is within 50 pixels of the monster, it will not move, and instead attack the player.

Aggressive monsters move at one quarter of a pixel per millisecond. While the player can move faster diagonally, monsters move at the same speed in all directions, as calculated by Algorithm 1.