Java代写：SWEN20003GraphicalGameEngine

代写一个小型的RPG游戏引擎，不过不用从底层开始写，基于Slick进行二次开发。

Overview

In this project, you will create a basic graphical game engine, in the Java
programming language. You will implement the graphical user interface with the
Slick library, as introduced in Workshop 4.
This is an individual project. You may discuss it with other students, but all
of the implementation must be your own work. You may use any platform and
tools you wish to develop the game, but we recommend using the Eclipse IDE for
Java development as this is what we will support in class.
You will be required to briefly demonstrate the game engine in a workshop. In
Project 2, you will continue working on the game engine, and build a working
game.
The purpose of this project is to:

• Give you experience working with an object-oriented programming language (Java);
• Introduce simple game programming concepts (2D graphics, input, simple calculations); and
• Give you experience working with a simple game API (Slick).
  Figure 1 shows a screenshot from the game after completing Project 1. The game
  consists of navigating a character through a maze of trees, mountains and
  water. In this image, you can see the player in a small village, with houses.
  Note that this is a “tile-based” game; the map is arranged in a grid of
  squares (note the blocky shapes of the stone and arrangement of the trees).
  This makes the game easier to program, and was a very common technique in
  games of the ‘90s.
  The game has a single character, called the “player”. The user controls the
  game with the arrow keys on the keyboard, moving the player character around
  the map. The player can walk on grass, stone, wood, etc., but cannot walk on
  trees, houses, water, etc.
  There is no “goal” of the game, and no “enemies”, at this stage - merely
  exploration. These will be introduced in Project 2, in which you will be
  required to program the complete game.
  The rest of this section details precisely how the game works. You must
  implement all of the features described here, unless they are marked
  “optional”.

The game map

In this game, the “world” is a two-dimensional grid of tiles. The player is
able to move freely around the world to explore the entire world (but of
course, the player cannot walk on trees, mountains, water, and other types of
terrain).
The game map is a large 2D array (96 × 96) of tiles, representing the world
the player lives in. Each tile has a particular terrain type, such as grass,
stone, mountains, water and fire. Aside from its graphical appearance, there
is only one physical difference between terrain types: some tiles allow
movement (such as grass and wood) while others block movement (such as
mountains, water, fire and trees). Each tile is 72 × 72 pixels in size.
The supplied map file, map.tmx, contains the tile layout information for the
whole game. Slick comes with a handy class called TiledMap which can read .tmx
files (see “implementation tips” for instructions).

The player

The only character in the “game” at this stage is the player. The player
controls a small character with the keyboard, and is able to move him or her
around the map. The player’s position in the world is stored as an (x, y)
coordinate in pixels 3 . This means that the player 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.
The player should start at location (756, 684). This should place him/her in
the middle of the village, as shown in Figure 1.
Internally, the player has no “size”; it is just a single point. When
displaying the player, the image should be centred around the player’s
position.

Gameplay

The game takes place in frames. Much like a movie, many frames occur per
second, so the animation is smooth. Each frame:

1. If certain keyboard keys are being pressed, the player moves by a small amount in that direction and the players position in the world is updated.
2. The “camera” is updated so that it is centred around the player’s position. This is important! The camera should be reliant on knowing the players position, not the other way around.
3. The entire screen is “rendered”, so the display on-screen reflects the new state of the world.

Display

This is a graphical game, so you will use the Slick library to draw the
graphics onto the screen. We have supplied all of the graphics you will need,
as PNG files (see “the supplied package”).
The game’s main window is 800 × 600 pixels. The game map is much bigger (6912
× 6912 pixels), so you can’t see all of it at once. Instead, the game should
only render a portion of the map at a time - such that the “camera” is centred
around the player. This means that as the player walks around the world, the
camera should follow. You will find that you will need to render 13 tiles wide
and 10 tiles high, to fill up the screen.
You should not render the entire map, or the game may run very slowly (and we
will deduct marks).
Instead, you should calculate which 13 × 10 tiles are required to fill up the
screen, and render those.
Optional feature: In the supplied image, player.png, the character is facing
to the right. Make it so if the player moves left, (s)he faces left instead,
and if the player moves right, (s)he faces right again.

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 a quarter of a pixel per millisecond, in each
direction. For example, if the player is moving east, then every millisecond,
(s)he moves 0.25 pixels to the right. If the player is moving north-east, then
every millisecond, (s)he moves 0.25 pixels up and 0.25 pixels right in the
world. (Note that this enables the player to move slightly faster diagonally).
Optional feature: Allow click to move style controls such that the player can
be controlled by clicking on a point in the map with the mouse and the player
will move towards it. This feature will require pathfinding to work, and
should be considered only if you have an abundance of time and want a
challenge.

Terrain blocking

Some types of terrain (such as water) should stop the player from moving,
while other types should allow the player to walk. The map file itself stores
whether or not each tile should block the player’s movement 4 . See
“implementation tips” for details on determining whether a tile should block.
If the player attempts to walk on terrain which “blocks”, the player should
remain in his/her current location (this will make walls feel “sticky”).
Optional feature: Allow the player to “slide” along walls when moving
diagonally. For example, if the player is trying to move south-east, and there
are mountains to the east, move the player south, rather than not moving at
all. (This may feel more natural than the “sticky” walls approach suggested
above.)

Your code

Your code should consist of at least these four classes:

• RPG - The outer layer of the game. Inherits from Slick’s BasicGame class. Starts up the game, handles the update and render methods, and passes them along to World.
• World - Represents the entire game world, including the map.
• Player - Represents the player character.
• Camera - Represents the viewport, should follow the player.
  You will be supplied with complete code for RPG, and partial code for World.
  You may modify this code however you wish; it is provided merely as a guide.
  Your implementation of the World, Player and Camera classes should follow
  proper object-oriented design practices, such as encapsulation.
  You may find that there are better ways to design the classes than just
  restricting yourself to these three classes and we are open to this (and in-
  fact encourage creative design thinking), just make sure you discuss these
  with your tutor before going ahead.

Implementation tips

This section presents some tips on implementing the game engine described
above. You may ignore the advice here, as long as your game exhibits the
required features.

The game map

You should use the TiledMap class to read the supplied map file, map.tmx. The
following constructor of TiledMap is appropriate:
TiledMap(String ref, String tileSetsLocation)
—|—
The first argument is the location of the map.tmx file; the second is the
location of the assets directory in which the tileset information used by the
map.tmx file is held (when Slick opens the map.tmx file, it will look in this
directory to load the accompanying tileset information - tileset.tsx and
tiles.png. These files contain information about the different tiles). There
are more hints about using TiledMap later in this section.

Display

The TiledMap.render method (in Slick) can be used to draw a portion of the map
to the screen. You should use the version with six arguments:
void render(int x, int y, int sx, int sy, int width, int height)
—|—
Hint: You can pass negative numbers for the x and y parameters to
TiledMap.render, so the top-left tile is rendered a little above and to-the-
left-of the top-left corner of the screen.
You will also need to display the player. You can use the Image.draw method
(in Slick) to render an image onto the background at a particular location.
You should use the version with two arguments:
void draw(float x, float y)
—|—
If you choose to implement the optional “facing left” feature, you can use the
Image.getFlippedCopy method to create a version of the player’s image facing
left.

Controls

The delta argument passed to the RPG.update method by Slick indicates the
number of milliseconds passed since the last frame. You should use this to
determine the number of pixels to move the player each frame. The distance
moved should depend on this delta value, so that your game can be independent
of the frame rate. Otherwise your game will move slower on slow computers, but
faster on faster computers (and you will loose marks for this).

Terrain blocking

Finding out whether any given tile should block the player is a two-step
process:

1. First, call the TiledMap.getTileId method. This gives an integer representing the terrain type (eg. grass = 10, tree = 7, house = 12).
2. Then, call the TiledMap.getTileProperty method, looking up the property name “block” for the given tile ID, with the default value of “0”. A result of “1” means block the player; “0” means allow the player to walk freely.
   The above instructions use the following methods of TiledMap:
   int getTileId(int x, int y, int layerIndex)
   String getTileProperty(int tileID, String propertyName, String def)
   —|—
   Detailed documentation for the classes used in this project, such as TiledMap
   and Image can be found at http://slick.ninjacave.com and may be useful when trying to figure out how
   these classes and their methods work.

Implementation checklist

This project may seem daunting. As there are a lot of things you need to
implement, we have provided a checklist, ordered roughly in the order we think
you should implement them in:

1. Loading the map.
2. Defining the Camera class
3. Rendering the map (center the Camera around position (756, 684), for now).
4. Defining the Player class.
5. Loading the player graphics.
6. Rendering the player.
7. Movement of the player.
8. Centering the Camera around the player.
9. Terrain blocking.

Technical requirements

• The program must be written in the Java programming language.
• The program must not depend upon any libraries other than the Java standard library, and the Slick graphics library we have provided.
• The program must compile and run in Eclipse on the Windows machines in the labs. (This is a practical requirement, as you will be giving a demo in this room; you may develop the program with any tools you wish, as long as you make sure it runs in this environment.)

Good Coding Style

Good coding style is often a difficult objective to decide. More often than
not, what is considered good style is dependent on the company you work for,
the aims of the project and the budget involved. For the purposes of this
project we are looking for the following:

• You should not go back and comment your code after the fact. You should be commenting as you go.
• You should be taking care to ensure proper, secure use of visibility modifiers. Unless you have a very good reason for it, all instance variables should be private. You should consider proper information hiding practice at all times.
• Any constant should be defined as a static final variable, you should not leave any constants in the code base, it makes it difficult to change paths when necessary and contributes to hard to manage code.
• Think about the modifiability of your code, remember that the second portion of the project has not been released yet, but it should be clear that there will be other characters and you should consider how you can generalize this functionality to make things easier for yourself in the future.
• Think about code delegation, you should ensure that each class is responsible for its own functionality and that each class encloses its own functionality fully. For example, all player update should be contained in one update() method with the appropriate arguments.