代写EECS 1720、Java编程设计代做

日期：2024-03-21 08:03

LAB 6 :: Exploring and Using MouseEvents, KeyEvents & Simple Threads (Timers)

Prerequisite – labs 1-5

Lab Resources:

Java API: https://docs.oracle.com/javase/8/docs/api/

Java Swing: https://docs.oracle.com/javase/tutorial/uiswing/components/index.html

Lab Files: http://www.eecs.yorku.ca/course_archive/2023-24/W/1720/labs/lab6/lab6.zip

Lab API: http://www.eecs.yorku.ca/course_archive/2023-24/W/1720/labs/lab6/doc/

** A reminder of the Swing hierarchy of Events/Event Handler Interfaces.

STEP 1: Importing an Archived Project

In this step, you will import an archived project into your Eclipse workspace, (the files for

each lab exercise are embedded). Each question refers to a separate java file. The

instructions for what is required for each question is included in the document below (STEP

2 onward). It is a good idea to create a separate workspace (e.g. “EECS1720”) for this

course.

a. You can download the lab project file from the link above (see Resources)

This file is a zip file, also known as an archive file. Click on the link below to open the

URL in your browser. In the dialog that opens, choose Save, not Open. This file is

typically saved into your home or downloads folder.

b. Open Eclipse and import this archive

IMPORTANT: this process is the same as the process you will use in lab tests, so

please make sure you follow it, so that you do not have submission difficulties during

the lab tests.

DO NOT DOUBLE CLICK ON THE FILE TO OPEN. By importing this project,

you will add it into your EECS1720 workspace. Do this by:

i. Open Eclipse (Applications → Programming → Eclipse) & set/choose your

workspace

ii. Close “Welcome” tab, and navigate to File → Import → General → Existing

Projects into Workspace. Hit “next”

iii. Choose the archive file (zip file you downloaded in (a)). After selecting, hit

Finish, and the file will open up as a project in your Project Explorer.

iv. We are now ready to proceed with the Lab Exercises.

STEP 2: Lab Exercises

The game Tetris is a puzzle game where the player can move and spin falling blocks of

various shapes. The goal of the game is to stack the blocks without leaving any gaps

between the blocks. In this lab, you will complete some components of the classes relating

to modeling the “blocks” we see in a typical game of Tetris, and will add some simple

event-based handling (to keys and mouse) to allow these blocks to be “manipulated”

(rotated/moved) on the screen, along with some basic functionality to animate the blocks.

If you have never played Tetris before, there is a wiki with lots of information about the

game. There are 7 standard blocks (called Tetriminoes). The blocks are all defined on a

square grid of size 3-by-3 or 4-by-4.

Figure 1: Tetris game (playing field)

In this lab, you are given a class BlockGrid that helps you describe the shape of a block.

BlockGrid lets you get, set, and clear the individual grid positions. A grid position is

specified using a pair of zero-based integer indices (the row index and the column index).

The figure below shows the indices for each grid location on a 3-by-3 BlockGrid:

The shape of each block can be represented using a BlockGrid object. The figure above

(right) shows the BlockGrid for an S-block; the white grid locations have the value false

and the green grid locations have the value true.

The player is able to spin a block into any of 4 possible orientations. The figures below

show the 4 possible orientations for the I-block, J-block, and S-block. Column A show the

blocks in their starting orientation. Column B shows the blocks after they have been spun

once to the right. Column C shows the blocks after they have been spun again to the right.

Column D shows the blocks after they have been spun again to the right. Spinning the

blocks once more returns the blocks to Column A. If the player spins the blocks to the left

starting from Column A, then the orientations are given by Column D, then Column C,

then Column B, returning to Column A.

The Tetris playing field is typically a grid with 20 rows and 10 columns. The location of a

block on the field is given by the coordinates of the top-left corner of its grid. The image

below shows a J-block with position (6, 14) on the playing field.

For this lab you will first complete the implementation of three types of blocks: IBlock,

JBlock, and SBlock. All Tetris blocks have three essential features: (1) they can be drawn

on the playing field; (2) they can be moved; (3) they can be spun.

The information needed for every type of block such as the location of the block on the

playing field, the color of the block, and the shape of the block; this information can be

managed by an abstract base class Block that all blocks will extend. The relationships

between the classes are shown in the following UML diagram:

Note, in the above definition, the Block class is already completed for you, however you

will need to complete the child classes (IBlock, JBlock and SBlock) – namely their

constructors, and overridden versions of spinLeft() and spinRight() methods. Please refer

to notes on abstract classes (and the video walkthrough for this lab) – recording in lab

session and to be posted on eClass.

Essentially an abstract class is one that is either explicitly declared as “abstract”, and may

have one or more methods that may also be declared as “abstract”. This means that those

abstract methods are only declared (and are not defined). As such, abstract classes function

much like an interface (that also has partial definition).

For any abstract features, these would need to be defined explicitly (made concrete) by a

child class. So if a child class extends an abstract class, for it to be fully concrete, it must

have a full implementation of every abstract feature inherited. Only classes that have a

full implementation can be instantiated as objects. In this lab, we want to instantiate

each of the child classes (as a specific, concrete sub-type of Block).

Exercise 01

In this lab, the first task is to complete the children classes (IBlock, JBlock and SBlock).

To complete the Block subclasses, you first need to complete the constructors for the

IBlock, JBlock and SBlock classes, along with their spinLeft() and spinRight() methods.

You will also need to complete the moveDown method in the abstract Block class (see the

other move methods for reference).

The constructor for IBlock already completed for you as a reference. Note that the figure

showing the rotated versions of the IBlock above (bottom of page 3 in this document),

forms the basis for the constructor, which makes use of the existing BlockGrid class to

instantiate and store 4 separate BlockGrid’s to hold the shapes of the IBlock when rotated.

These are each stored in an ArrayList called “grids”. There is also a colour, position,

blockgrid size, and gridIndex associated with each block (some of these variables are used

to initialize the parent’s class fields). gridIndex is a variable that indicates which version

of the rotated shape is currently representing the IBlock (so a value of 0 represents the first

state (the horizontal or A position of the IBlock in the above figures), while the gridIndex

3 represents the last D position of the IBlock).

The same is true of the SBlock and JBlock classes (though their states refer to 3x3 blocks

illustrated in the same previous diagram – at the bottom of page 3 of this document).

Complete the constructors for the classes IBlock, JBlock and SBlock, first, then run the

TetrisBlockDemo.java file, and if working, a random block should be positioned near the

top of the playing field. Each time you run, a different block should display (run enough

times to confirm all 3 blocks are initialized and begin with their positions according to

position A.

HINT: the constructors for JBlock and SBlock should create 3x3 (not 4x4) GridBlocks, then should use the

mutators (setters) to set the appropriate grid squares for each rotated version of the block. The spinLeft() and

spinRight() methods should be similar for all blocks as they all contain 4 states to switch between. A=>D if

spinning left and D=>A if spinning right (for all blocks). Also, you can test your blocks as soon as you

complete the constructors (as the spin behaviour will be triggered later with event handling)

In the remaining exercises, you will be working with the TetrisBlockDemo.java file, in

order to add functionality to manage user interaction with the keyboard (key events) as

well as mouse, then finally manage the animation of a block falling on the playing field

(before it re-spawns after falling off the app window at the bottom). This is NOT a

complete implementation of Tetris, but just adds some interaction and tests this interaction

for managing the block behaviour while falling in the game of Tetris. No behaviours

dealing with how the blocks aggregate/connect at the bottom to score points is handled in

this lab.

Exercise 02

(Using KeyEvents to manage the spinLeft/spinRight behaviour of a block)

In this exercise, you will complete the implementation of the KeyListener interface for the

TetrisBlockDemo class. Note, this is started for you (a shell of the methods that could be

used is provided).

The behaviour should see the following key presses do the following:

“Z” key => when pressed, should move the block (stored in block class field) left by 1 grid

position (i.e. should invoke the moveLeft() method of the block)

“X” key => when pressed, should move the block right

“,” key (comma key) => should spin the block left

“.” key (period key) => should spin the block right

“SPACE BAR” key => should set toggle the isFalling state from true to false, or false to

true (this field will be used in Exercise04.

** remember the KeyListener should be registered against the JFrame ideally (and this

should be set to have the focus, prior to being used. See lecture notes for more info.

Test your implementation, by running the TetrisBlockDemo.java file, and pressing keys.

The drawn shape can be updated with a call to this.playingField.repaint().

Exercise 03

(Add events for mouse clicks)

In this exercise, you will add additional functionality for the mouse to achieve the spin left

and spin right behaviours.

Essentially, a mouse click that occurs to the left of the blocks current position, should spin

the block left, while a mouse click that occurs to the right of the current block position,

should spin the block right. This behaviour should not interfere with the existing key

events (i.e. both should work to achieve the same spin functionality). Note: you will need

to reset the focus to the JFrame in order to capture key events and redirect them properly

after clicking a mouse button.

Remember to register your mouse listener to the JFrame (or some aspect of it). Also

remember to refocus the keylistener to the JFrame (clicking on other areas with the mouse

may shift the focus).

Exercise 04

(Add animation capability)

In this task, you should now complete the setup of a Timer thread (please review lecture

17 – which will be covered on March 14), and register it to send regular action events for

updating the position of the block and animate it when in the falling state.

The actionPerformed method is started for you, you will need to modify the constructor to

instantiate a Timer, and configure it appropriately. Lecture 20 includes notes on the Timer

object and how to use it. We will cover this in lectures (in the meantime, you can refer to

those lecture notes).

Some hints are given in the comments of the TetrisBlockDemo class.

Essentially, after pressing the “SPACE BAR” key (setup in Exercise02), you should be

able to see the block that was initially set at the top of the playing field, slowly start to fall

on the screen (step in the downward direction). To enact this, you will need to update the

block by invoking one of its mutator methods (already defined).

The paint() method of the TetrisCanvas class (also already completed for you) should take

care of the painting of this object, which can also be invoked with a call to

this.playingField.repaint().

Exercise 05 (OPTIONAL – to think about … )

Not required, but if you finish this lab and want something to work on, you may think about

how to include other subclasses for other tetriminoes – such as the T-block, or the Square

block, etc… and how to prevent them from moving outside of the playingField. I.e. you

might want to change the detection of a block falling off the bottom, to detecting when it

collides with the bottom edge of the playingField – note, this will not be as simple as you

think – and if you want to take care of pieces stacking correctly, you will have to add some

methods to store the stacked pieces (maybe in a second ArrayList), and test them for

collisions – which will require you to think about the current block’s gridState at contact).

STEP 3: Submission (Deadline: Tuesday March 19st

, 2024 - 11:59pm)

You will formally submit the java files associated with all Exercises 01-04. SUBMIT ALL

OF THE *.java FILES (NO ZIP FILES OR CLASS FILES!!).

Please submit your completed *.java files to “lab6” directory via web-submit.

Web-submit can be found at the link: https://webapp.eecs.yorku.ca/submit/