CS 319 - Object-Oriented Software Engineering

System Design Report

Crazy Ball

Group 2-CCem Oğuz Yücel

Ekin Öcalan

İstemi Rahman Bahçeci

Mustafa Özkıdık

Özge Karaman

Contents1. Introduction........................................................................................................................................4

1.1 Purpose of the system..................................................................................................................4

1.2 Design Goals.................................................................................................................................4

End User Criteria:...........................................................................................................................4

Maintenance Criteria:.....................................................................................................................5

Performance Criteria:.....................................................................................................................5

Trade Offs:......................................................................................................................................5

1.3 Definitions, acronyms, and abbreviations....................................................................................6

Abbreviations:................................................................................................................................6

1.4. References...................................................................................................................................6

1.5. Overview.....................................................................................................................................6

2. Software Architecture........................................................................................................................7

2.1. Overview.....................................................................................................................................7

2.2. Subsystem Decomposition..........................................................................................................7

2.3. Architectural Styles....................................................................................................................11

2.3.1 Layers..................................................................................................................................11

2.3.2 Model View Controller.........................................................................................................11

2.3. Hardware / Software Mapping..................................................................................................12

2.4. Persistent Data Management....................................................................................................12

2.5. Access Control and Security.......................................................................................................13

2.6. Boundary Conditions.................................................................................................................13

3. Subsystem Services..........................................................................................................................14

3.1. Design Patterns..........................................................................................................................14

Façade Design Pattern:.................................................................................................................14

3.2. User Interface Subsystem Interface......................................................................................14

Menu Class...................................................................................................................................16

ScreenManager Class...................................................................................................................17

MainMenu class...........................................................................................................................18

PauseMenu class..........................................................................................................................19

MenuActionListener.....................................................................................................................19

3.3 Game Management Subsystem Interface..................................................................................20

GameManager Class.....................................................................................................................22

InputManager class......................................................................................................................23

SoundManager Class....................................................................................................................24

Setting Class..................................................................................................................................25

GameInformation Class................................................................................................................25

GameMapManager Class..............................................................................................................25

3.4 Game Entities Subsystem Interface............................................................................................28

GameMap Class............................................................................................................................30

PowerUpTable Class.....................................................................................................................32

Sprite Class...................................................................................................................................33

GameObject Class.........................................................................................................................34

Bullet class....................................................................................................................................35

PowerUp Class..............................................................................................................................35

Paddle Class..................................................................................................................................36

Brick Class.....................................................................................................................................37

NormalBrick Class.........................................................................................................................38

ExplovsiveBrick Class....................................................................................................................39

InvisibleBrick Class........................................................................................................................39

HardBrick Class.............................................................................................................................40

Ball Class.......................................................................................................................................40

3.5 Detailed System Design.............................................................................................................42

1. Introduction

1.1 Purpose of the system

Crazy Ball is a 2-D brick destruction game. Comparing to 3-D games including a real

world environment and high quality graphics, Crazy Ball looks very poor. However,

gameplay of Crazy Ball is designed as challenging as possible to maximize the pleasure of

achievement for player. It is also distinguishable among other brick destruction game with its

difficulty level and different power ups which are making gameplay more enjoyable. Crazy

Ball aims to improve rapid decision making ability, hand-eye coordination and reflexes, while

having good time.

1.2 Design Goals

Before the composing the system it is crucial to identify the design goals of the

system in order to clarify the qualities that our system should focus on. In this respect many

of our design goals inherit from non-functional requirements of our system that are

provided in analysis stage. Crucial design goals of our system are described below.

End User Criteria:

Ease of Use: Since our system is a game, it should provide good entertainment for the

player. In order to provide the entertainment player should not have a difficulty in using our

system. In this respect, system will provide player friendly interfaces for menus, by which

player will easily find desired operations, navigate through menus and perform the desired

operations. Also, it is determined that our system will perform actions according to mouse

input from the user, like clicking buttons, moving paddle. This makes it easy to use the

system from the point of the player.

Ease of Learning: Since player is not ought to have knowledge about how the game is

played, loss-win conditions of game, power-up properties. It is vital for the user to obtain

information about the game concepts, for this purpose system will provide an instructive

help document, by which he will be easily get warmed up to the game. The logic of the game

is also very simple that user can easily understand intuitively or by reading the help

document.

Maintenance Criteria:

Extendibility: In general, in the lifetime of game software, it is always important to

add new components, features to the game in order to sustain the excitement and interest

of the player. In this respect our design will be suitable to add new functionalities, entities

(i.e. new brick types, new power-ups) easily to the existing system.

Portability: Portability is an important issue for a software, since it provides that the

software can reach wide range of users. In this respect we are determined that the system

will be implemented in Java, since its JVM provides platform independency, our system will

satisfy the portability.

Modifiability: In our system it would be easy to modify the existing functionalities of

the system. In order to achieve this we will minimize the coupling of the subsystems as much

as possible, to avoid great impacts on system components by a desired change.

Performance Criteria:

Response Time: For the games, it is vital that users’ requests should be responded

immediately in order not to distract the player’s interest and entertainment. Our system will

respond player’s actions almost immediate, while also displaying animations, effects

smoothly for enthusiasm.

Trade Offs:

Ease Of Use and Ease of Learning vs. Functionality:

In our system we determined that player should be able to learn and use the system

very easily. Therefore our design proposes that the priority of the usability is higher than

functionality. In other words our system does not bother the user with complex

functionalities or we do not make the user to be lost in many functionalities, in order to

make our system easy to understand and use.

Performance vs. Memory:

In our system, it is our main purpose to make the animations, effects, transitions very

smooth. Briefly, performance of our system is our primary focus. For this purpose, we

sacrificed the memory in order to gain the performance. For instance: in our game we have a

bonus called explode explosive bricks, within the regard of this bonus we should

immediately explode all explosive bricks on the map. Since the performance of this event is

important in our system, instead of iterating the all map for explosive bricks, we store the

important game objects of the game map in memory to access them fast when needed.

1.3 Definitions, acronyms, and abbreviations

Abbreviations:MVC: [2] Model View Controller

JDK: [1] Java Development Kit

JVM: [1] Java Virtual Machine

1.4. References[1] http://en.wikipedia.org/wiki/Java_(programming_language)

[2] Object-Oriented Software Engineering, Using UML, Patterns, and Java, 3rd Edition, by Bernd Bruegge and Allen H. Dutoit, Prentice-Hall, 2010, ISBN-10: 0136066836.

1.5. Overview

In this section, we represented purpose of the system, which is basically entertaining the

player as much as possible, to achieve this purpose we defined our design goals in this part. Our

design goals are determined according to provide the portability, ease of use, ease of learning, high

performance, high maintainability. In this respect of course we made some trade-offs to realize our

goals. We sacrificed from functionality to make our system simpler and understandable, also we

sacrificed from memory to gain performance on playing smooth animations and effects.

2. Software Architecture

2.1. Overview

In this section, we will decompose our system into maintainable subsystems. In dividing

these subsystems, our main goal is reducing the coupling between the different subsystems of the

system, while on the other hand increasing the cohesion of subsystem components. On the other

hand we tried to decompose our system in order to apply MVC( Model View controller ) architectural

style on our system.

2.2. Subsystem Decomposition

In this section, the system is divided into relatively independent parts to clarify how it

is organized. Since the decisions we made in identifying subsystems will affect significant

features of our software system like performance, modifiability and extendibility;

decomposition of relatively independent part is crucial in terms of meeting non-functional

requirements and creating a high quality software.

In Figure-1 system is separated into three subsystems which are focusing on different

cases of software system. Names of these subsystems are User Interface, Game

Management and Game Entities. They are working on completely different cases and they

are connected each other in a way considering any change in future. As seen in Figure-2

Game Management and Game Entities subsystems are loosely coupled. Besides, only

connection between User Interface subsystem and Game Management subsystem is also

provided over Game Manager class. Therefore any change or error in User Interface

subsystem will only affect Game Manager class which has a role as interface of control unit.

When we have a deeper look inside the subsystems from Figure-2, we realize classes

who are working on a common purpose are gathered and performing similar tasks. For

instance classes named with word “Manager” are strongly associated to perform control

tasks by sending requests and responds to each other.

While identifying subsystems we aimed to meet our system goals. Therefore, tried to

design an efficient software system with high cohesion and loosely coupling. This will provide

flexibility to our software system for any possible change.

Figure – 1 (Basic Subsystem Decomposition)

Figure-2( Detailed Subsytem Decomposition

2.3. Architectural Styles

2.3.1 Layers

In our system decomposition we decomposed the system into three layers, User

Interface,Game Management, Game Entities, these three layers is decomposed as

hierarchical while grouping the subsystems that provides related services. Our top layer

which have highest hierarchcy is User Interface layer since it is not used by any other layer

above and it is responsible for the interaction with the user. Our following layer is Game

Management layer, in this layer the actual game logic is controlled. Our bottom layer is

Game Entities layer, in which all the necessary entity objects are brought together. Our layer

decomposition also proposes the closed architectural style, in which a layer can only access

to the layer below it. Our layer decomposition is depicted in Figure-3

Figure-3(Layers of system)

User Interface

Game Management

Game Entities

2.3.2 Model View Controller

In this architectural style, the main approach is classifying the subsystems into three

parts, called model, view and controller. By dividing the subsytems into three parts, we

isolate the domain knowledge from the user interface by adding a controller part between

them. In our system, we grouped our domain objects into game entities layer which

constitues the model of our system. The domain objects of our system is only accessed and

controlled by manager classes which are grouped under Game Management layer that

constitues the controller part. We grouped the classes which are responsible for providig the

interaction between user and system into User Interface layer, this layer constitues the View

part since it just communicates with the model part via controller part. By this architecture it

is achieved that changes on the interfaces do not change the model of the system, therefore

it is a good choice to use MVC for games.

2.3. Hardware / Software Mapping

Crazy Ball will be implemented in Java programming language, therefore we will use

latest JDK (1.7). As hardware configuration, Crazy Ball needs a basic keyboard ( for typing

names on high score list ) and mouse for users to give input to the system. Since we will

implement the project in Java and system requirements will be minimal , a basic computer

with basic softwares installed such as an operating system and a java compiler to compile

and run the .java file. Also, we will benefit from java’s platform independency

For storage issues, since we will have .txt based structures to form game maps and high

score list, the operating system should support .txt file formats. Moreover, our system will

not require any kind of internet connection to operate.

2.4. Persistent Data Management

Since our game does not need a complex database system. Crazy Ball will store map

structure and high score list as text files in disk. Our game maps as text files will be created

before Crazy Ball is executed, so these data will be persistent. If text file will be corrupted , it

will not effect in-game issues such as game objects, but of course system will not be able to

load this corrpupted map. We also plan to store sound effects and game object images in

hard disk drive with proper and simple sound, image formats such as .gif, .waw.

2.5. Access Control and Security

As indicated earlier (in Hardware / Software Mapping section ), Crazy Ball will not

require any kind of network connection . Anyone who did the initialization of Crazy Ball will

be able to play the game. So there will not be any kind of restrictions or control for access.

Also it will not include any user profile. Therefore , there will be no kind of security issues in

Crazy Ball.

2.6. Boundary Conditions

Initialization

Since Crazy Ball does not have regular .exe or such extension, it does not require an

install. Though the game will come with an executable .jar file.

Termination

Crazy Ball can be terminated / closed by clicking “Quit Game” button in main menu. If

player wants to quit during game play, system provides a pause menu by which player can

return to main menu and perform quit. Since Crazy Ball will work on full screen , there will

not be “x” button at the upper right.

Error

If an error occurs that game resources could not be loaded such as sound and images,

the game will still start without images or sound.

If program did not respond because of a performance issue, even we keep these kind

of problems minimum, Player will lose all of current data.

3. Subsystem Services

In this section we will provide the detailed information about the interfaces of our subsystems.

3.1. Design Patterns

Façade Design Pattern: Façade design pattern is a structural design pattern which proposes that developers can

easily manage a subsystem from a façade class since the communication between outside of this

subsystem is performed only by this class. This pattern, provides maintainability, reusability and

extendibility since any change in the components of this subsystem can be reflected by making

changes in the façade class.

In our design we used façade pattern in two subsystems: Game Management and Game

Entities. In Game Management subsystem our façade class is GameManager which communicates

with the components of the Game Management subsystem according to the requests of User

Interface subsystem. For our Game Entities subsystem our façade class is GameMap class which

handles the operations on entity objects of our system, according to the needs of Game

Management subsystem.

3.2. User Interface Subsystem InterfaceUser Interface subsystem provides our software system with graphical system components. Besides,

it also manages transition between panels which are constructed for different selections in menu

screens. The reference of User Interface Subsystem to other subsystems is provided by menu class

which is considered as an interface.

Figure-1( User Interface Subsystem )

Menu Class

Attributes:private JFrame frame: This is the frame in which we display all visual context.

private MenuActionListener listener: This attribute is to get the user input from the graphical user interface.

private ChangeSettingsPanel changeSettingsPanel: This Jpanel type property of ChangeSettingsPanel used in graphical user interface to show Change Settings Menu on screen.

This property is constructed by ChangeSettingsPanel class with its components like buttons, labels etc…

private HelpPanel helpPanel: This JPanel type property of HelpPanel class is used in graphical user interface to show Help Menu on screen.

This property is constructed by HelpPanel class with its components like buttons, labels etc…

private CreditsPanel creditsPanel: This JPanel type property of CreditsPanel is used in graphical user interface to show Credits on screen.

This property is constructed by CreditsPanel class with its components like buttons, labels etc…

private GameManager gm: This GameManager type property of Menu class provides reference to GameManagement subsystem, when Play Game selection is received from graphical user interface.

private Setting settings: This Setting type property of Menu class keeps the system settings adjusted by user from change settings menu. settings object has instance variables as soundOn_Off, paddleKind, backgroundImage.

Constructors:public Menu: Initializes changeSettingsPanel, creditsPanel, helppanel, gm, settings and listener properties.

Methods:public void switchPanel(newPanel,removedPanel): It changes the panel on frame according to received selection from game menu.

public void displayHelp(): This method includes switchPanel() method and adds helpPanel to frame by replacing the current panel on frame.

public void displayCredits(): This method includes switchPanel() method and adds creditsPanel to frame by replacing the current panel on frame.

public void displaySettings(): This method includes switchPanel() method and adds changeSettingsPanel to frame by replacing the current panel on frame.

public void applySettings(): This method applies the requested settings by setting values of setting object which are soundOn_Off, paddleKind, backgroundImage.

ScreenManager Class

Attributes:private JFrame frame: This attribute is the main frame of program. All visual context is displayed in this frame.

Constructor:public ScreenManager(int screenWidth, int screenHeight): It takes width and height of screen as parameter to construct an object.

Methods:public JFrame getGameWindow(): returns a JFrame object to display game screen.

public Graphics getGraphics(): returns a graphics context for drawing to an off-screen image.

public void refresh(): It repaints the components in game frame.

MainMenu class

Attributes:private MainMenuMainPanel mainPanel: This MainMenuMainPanel type attribute of MainMenu class is used in graphical user interface to show Main Menu on screen.

Constructor:public MainMenu(): It initializes instances of MainMenu object.

Methods:public void displayMainMenu(): This method includes switchPanel() method and adds mainPanel to frame by replacing the current panel on frame.

public void startGame(): By the reference of gm attribute of MainMenu class (gm attribute is inherited from Menu class) this method invokes gameManagement subsystem to control gameplay routine.

public void exitGame(): This method ends the run of application.

The following methods are inherited from parent Menu class. switchPanel(newPanel : JPanel, removedPanel : JPanel), displaySettings() displayCredits() displayHighScore() displayHelp()

PauseMenu class

Attributes:private PauseMenuMainPanel mainPanel: This PauseMenuMainPanel type attribute of PauseMenu class is used in graphical user interface to show Pause Menu on screen.

Constructor:public pauseMenu(): It initializes instances of PauseMenu object.

Methods:public void resumeGame(): This method removes PauseMenu panel and continuous game routine.

public void returnToMainMenu(): This method creates a new mainMenu object and displays it on screen.

The following methods are inherited from parent Menu class. switchPanel(newPanel : JPanel, removedPanel : JPanel), displaySettings() displayCredits() displayHighScore() displayHelp()

MenuActionListener

Methods:public void actionPerformed(ActionEvent e): This method overrides actionPerformed method of ActionListener interface.

HighScorePanel, HelpPanel, CreditsPanel, ChangeSettingsPanel, MainMenuMainPanel, PauseMenuMainPanel classes are not described in detail. These classes instantiates requested panels and these panels are placed on frame by MenuActionListener class.

3.3 Game Management Subsystem Interface

In this subsystem our controller objects are grouped together to manage the actual

game dynamics and game logic. We have 6 components in this subsystem. However, we have

4 controller classes and 2 property classes. As illustrated in Figure-1, we have GameManager,

SoundManager, GameMapManager and an InputManager which is a subclass of

GameManager for handling the user input. We have also two property classes

GameInformation and Setting. These classes will be explained in detail, in this section.

Figure-2( GameManagement Subsystem Interface )

GameManager Class

This class is the Façade class of the GameManagement subsytem, it performs the proper operations according to the requests that came from User Interface subsystem, also this class runs the game in a loop. This class also implements runnable interface, since the game loop runs as a thread.

Attributes: private boolean paused: this attribute is used for whether the game is paused or not, in game loop

private Setting settings: this attribute holds the settings of the game , like background type, sound on off, type of paddle.

private GameMapManager mapManager: this attribute is a GameMapManager object, by which GameManager class associates with proper methods of GameMapManager class.

Constructors:public GameManager(): it initializes the attributes of the GameManager for the first run of the system.

Methods: public void gameLoop(): this methods runs a loop in which the system is updated continuously.

public void applyDefaultSettings(): this method changes the setting attribute of the class according to the default settings that are determined by system.

public void applySettings( Setting settings ): applies the given settings to system.

public boolean levelPassed(): communicates with GameMapManager class by mapManager attribute to determine that whether the level is passed or not. In this context, this method checks the conditions if there is any bricks on map and number of lives is bigger than zero,

by calling the hasLive method and referencing to the mapManager attribute to check if there is any bricks left.

public boolean hasLive(): checks whether the number of lives bigger than zero, to check this communicates with GameMapManager class by mapManager attribute.

public void skipNextLevel(): first checks whether the level passed or not, if level is passed increments the level number stored int GameMapManager class by referencing mapManager attribute

public void startGame(): starts a new game, by resetting game information stored on GameMapManager class, obviously it is made by mapManager attribute

public void pauseGame(): when invoked causes to prevent the game loop to iterate by setting paused attribute to false.

public void resumeGame(): when invoked causes the game loop to continue to iterate, by setting the paused attribute to true.

public boolean isHighScore( score: int): returns true if the given score is eligible for the high score list else it returns false.

public void endGame(): if the levelPassed method and the hasLive method returns true, this method invokes the isHighScore method.

InputManager class

This class is designed to detect the user actions performed by mouse( to move paddle on screen etc. ), and also performed by keyboard( to pause the game and invoke a pause menu during game ). In this context, this class implements proper interfaces of Java.

SoundManager Class

This class is referenced by GameMapManager when needed to play sounds. This class also implements the runnable interface since SoundManager runs in a different thread.

Attributes:

private boolean soundOn: this attribute is a flag to determine the whether the sound is enabled or disabled in overall system.

Constant static variables in this class are designed to map the proper sound samples as id’s, this approach is used for readability of the code.

Constructors:

public SoundManager(): initializes the object of this class, soundOn is set false as default.

Methods:

public synchronized void playSound(int soundID) : this method is invoked by GameMapManager class when needed. This method plays a sound sample according to given value.

Setting Class

This class is a simple property class, which holds the settings of the system. It is used by GameManager class.

GameInformation Class

This class is a simple property class, which holds the information about the current state of the game. It is used by GameMapManager class

GameMapManager Class

Attributes:private GameMap currentMap: this class performs the map specific operations by referencing to this object. Like getting the Ball objects on the map etc.

private int paddleKind: this value is for determining the paddle kind, since there can be different kinds of paddles in our system, this value is needed to create various types of paddles like green, blue,gray paddle.

private int commonBallState: this attribute is used to determine the common ball type, since it will be needed to determine the actions performed in collision according to ball type. This value is obtained by currentMap attribute by getting the type of one ball object in ball list. This attribute is hold for fast determinations in collisions.

private GameInformation info: this attribute holds the current game information, like current level , number of lives. This information is updated according to game dynamics which are also handled in this class.

private SoundManager soundManager: reference to SoundManager class to play proper sounds when needed.

CELL_WIDTH and CELL_HEIGHT are static constant variables, they are used to divide the map into equally sized pieces according to brick sizes.

Constructors:public GameMapManager(): initializes a GameMapManager object with default attribute values.

Methods:public GameMap getCurrentMap(): returns the current map which is processing by GameMapManager class.

public drawCurrentMap(Graphics g, int screenWidth,int screenHeigh,GameInformation info): draws the current map according to given attributes.

public void setBackGroundImage(int ImageID ): sets the background image according to given ID, by loading a proper image by this id.

public void setPaddleType(int typeID ): sets the type of the paddle object by referencing the currentMap attribute.

public void applyPowerUp(int powerUpID): applies the powerUp to the game by referencing the currentMap attribute, also it references to PowerUpTable class for interpreting which id refers to which powerUp ( which is a class of Game Entities subsystem ).

public boolean isMagnetPaddle() : returns true if the paddle object of currentMap is in the state of magnet paddle.

public boolean isLaserPaddle() : returns true if the paddle object of currentMap is in the state of laser paddle.

public boolean bricksLeft() : returns true if there is any bricks exists in currentMap.

public void update(long elapsedTime) : updates the game objects of currentMap by given elapsed time.

public boolean powerUpExists() : generates a random integer and checks if this number is in the range of the current powerUp number. If it does so method returns true. This method is invoked in when there is a collision between the ball objects and the brick objects, to determine the power up existence.

public void generatePowerUp() : when invoked, generates a random integer and generates a powerUp object with this integer by associating with the PowerUpTable class of GameEntities subsystem, to figure out which powerUp this integer corresponds. This power up is created and added to map by referencing to currentMap attribute.

public void handleBrickBallCollisions() : by referencing the currentMap object, this method finds and handles the collisions between ball and brick objects of currentMap object.

public void handlePaddleBallCollisions() : by referencing the currentMap object, this method finds and handles the collisions between ball and paddle objects of currentMap object.

public void handlePaddlePowerUpCollisions() : by referencing the currentMap object, this method finds and handles the collisions between paddle and power up objects of currentMap object.

public void handleBrickBulletCollisions() : by referencing the currentMap object, this method finds and handles the collisions between bricks and bullet objects of currentMap object.

public void handleBorderCollisions() : by referencing the currentMap object, this method finds and handles the collisions between borders of the screen and the moving objects of the system, like balls, paddle, powerUps.

public void checkAndHandleCollisions(): this method invokes the methods of this class, which are designed to handle the collision issues, and finds and handles the collisions on the currentMap by one invocation.

public void incrementLevel(): this method increments the current level by 1, it is invoked when the conditions of passing a level is satisfied.

public void updatePaddleLocation(int posX, int posY): updates the location of the paddle on gameMap, since paddle is controlled by mouse actions. Also this method is invoked by GameManager when the mouse moves.

3.4 Game Entities Subsystem Interface

As the name suggest this subsystem is a subsystem which holds the domain specific objects

of our system. In this subsystem, we have 13 classes in total. Our game objects inherits from an

abstract base class called GameObject. In this subsystem, our Façade class is GameMap class which

performs the proper actions on game entities such as creating and modifying them. Since we have

the Façade design pattern it is easy to use this subsystem by any other subsystem since the coupling

between the subsystems are minimized. In Figure-3 Game Entities subsystem is visualized. Each class

of this subsystem will be explained in detail in this section.

Figure-3 ( Game Entities Subsystem )

GameMap Class

This class is the Façade class of the GameEntities subsystem, therefore it includes methods related to creating and modifying game entities. Communication between the other components of the GameEntities subsystem is performed by this class

Attributes:

private cells Brick[ ][ ]: this attribute represents the cells of the game map as two dimensional brick array, for the fast detection of collisions and the fast creation of game map.( since the bricks are static, not moving around the map, putting the bricks on the cells is appropriate)

private ArayList<GameObject>[] gameObjects: this array of game object arraylists, references to the all lists which store the game entities of the system.

private ArayList<PowerUp> powerUps: holds the reference to the all PowerUp objects exists on this map.

private ArayList<Ball> balls: holds the reference to the all Ball objects exists on this map.

private ArayList<Bullet> bullets: holds the reference to the all Bullet objects exists on this map.

private Paddle paddle: since there is one paddle for each map, this attribute represents is paddle of game map.

private int mapWidth: briefly, number of map cell columns.private int mapHeight: briefly, number of map cell rows.

Constructors:public GameMap(): constructs a game map with default attribute values.

public GameMap(int mapWidth, int mapHeight): constructs a game map with given map width and map height. Map width and map height represents the number of columns and rows in the cells attribute.

Methods:

public void loadMap( int mapID ): constructs a GameMap object by reading a map from disk which is represented as given ID. Maps are stored in the disk and can be mapped easily by and ID by this method. This method converts the GameMap object into new loaded map.

public Brick getBrickFromCell(int x, int y) : retrieves a Brick object from the cell which is specfied by the x and y( i.e. cells[x][y] ). Returns null if the specified cell does not include Brick object in it.

public void addBrickToCell(int x, int y) : adds a Brick object to the cell, which is specfied by the x and y.

public void deleteBrickFromCell(x : int, y : int) : frees the map cell specified by x and y, if the cell is already free method returns without making any operation.

public PowerUp createPowerUp( int powerUpID ): creates a PowerUp object with given ID.

public Bullet createBullet(): creates and returns a Bullet object.

public Ball createBall(typeID : int, sizeID : int) : creates and returns a Ball object with the typeID and sizeID. typeID determines the type of the ball i.e. riot ball, piericng ball. sizeID represents the size of the ball object.

public void reflectBall(Ball ballObj, int direction) : reverses the sign of the velocity of the given ball object according to direction parameter. Direction parameter specifies the velocity taht will be reversed.

public void updateBrick(brickObj : Brick): calls the update method of the given brick object.

public void applyPowerUpToBall(Ball ballObj, int powerUpID): applies the power up indicated by powerUpID to the given Ball object.

public void applyPowerUpToPaddle(Paddle paddleObj, int powerUpID): applies the power up indicated by powerUpID to the given Paddle object.

public void updatePaddle(Paddle paddle, int posX, int posY): updates the location of the given paddle object.

PowerUpTable Class

This class is composed of the static constant variables; this is included for the readability, maintainability and the extendibility. i.e. if the developers needed to add new bonuses, they simply changes the attribute called NUM_OF_POWERUPS and adds the proper power up image to the proper folder. GameMapManager uses this attribute to use as the boundary of the random power up generation process.

Sprite Class

This class is just for updating the position of an Image object by providing velocity values for x and y directions, and updating its location by multiplying the velocity values by elapsed time in update method of this class.

Attributes:private Image objectImage: image object whose position will be updated according to other attributes of the class

private float velocityX: X direction velocity value.

private float velocityY: Y direction velocity value.

private float positionX: X position of the image.

private float positionY: Y position of the image.

Constructors:public Sprite( Image img, float velX, float velY, float posX, float posY ): creates a Sprite object with given attributes.

Methods:private void update( long elapsedTime ): updates the posX and posY attributes of the img attribute by multiplying the velX and velY values by elapsed time.

GameObject Class

At this point, our approach to change the states of the objects as follows: with every state change we change the image of the game object therefore we map these states as ids to load the proper image. Of course there can be combination of different states in some game objects i.e. red long laser paddle. You can refer to the Paddle and Ball classes for more information.

Attributesprivate ObjectSprite objectSprite: This attribute of Game Object class is an instance of Sprite class.

private int typeID: TypeID attribute of Game Object class is used by some of child classes of Game Object class to specify the type of other objects of child classes.

Methods:public void draw (Graphics g, int posX , int posY ): This draw methods basically provides each GameObject to draw itself. For instance, a brick draws itself by using an instance of Graphics Class and two integers which indicate coordinates on the screen.

public int getWidth ( ) : This getWidth method returns the width of the image of the game objects, by referencing objectSprite attribute..

public int getHeight (): This getWidth method returns the width of the image of the game objects, by referencing objectSprite attribute.

public float getVx (): This getVx method returns the velocityX attribute by referencing the objectSprite attribute

public float getVy(): This getVx method returns the velocityX attribute by referencing the objectSprite attribute

public void changeSpriteImage ( Image img ): This changeSpriteImage method replaces a new instance of Image, instead of previous instance of Image of game object.

public Rectangle getCollisionRectangle ( ): This getColllisionRectangle method returns the boundaries of Image of objectSprite attribute.

Bullet class

Constructors:public Bullet (float velX, float velY, float posX, float posY): This constructor of Bullet class creates an instance of Bullet object by specified values, since the bullets on the game will start from a point and move with a constant velocity.

PowerUp Class

Attributes:Private static int[ ] Power_up_score_values : This attribute is a set of integer elements which hold the score that a specific power up gives.

Constructors:public powerUp ( int ID ): This constructor of PowerUp class uses an integer to define the type of the powerUp objects. By using this ID, it loads the proper image from disk for a specific powerUp.

Paddle Class

Attributes:private int RED_PADDLE_KIND

private int BLUE_PADDLE_KIND

private int GRAY_PADDLE_KIND

These attributes- defines kinds ofs Paddle object.

private int LONG_PADDLE_SIZE

private int SMALL_PADDLE_SIZE

private int NORMAL_PADDLE_SIZE

These attributes define sizes of paddleLength.

private int NORMAL_PADDLE_TYPE

private int LASER_PADDLE _TYPE

private int MAGNET_PADDLE_TYPE

These attributes defines the type of the paddle.

private int paddleKind: this attribute stores the kind of paddle. i.e. red paddle, gre paddle etc.

private int paddleLength: this attribute stores the length of the paddle i.e. long paddle, normal paddle.

Constructor

public Paddle ( int paddleKind ): Initializes a Paddle object with given parameter: paddleKind. Constructor loads proper image from disk according to paddleKind value.

Methods

public void shrinkPaddle(): This shrinkPaddle method shrinks the paddle by name indicates as loading another image from disk, in this case a shorter one.

public void enlargePaddle(): This enlargePaddle method simply enlarges the paddle by loading another image from disk, in this case a bigger one.

public void laserPaddle(): This laserPaddle method modifies the paddle by loading another image from disk.

public void magnetPaddle(): This magnerPaddle method modifies the paddle by loading another image from disk.

public void setDefaultPaddle (): This setDefaultPaddle method of Paddle class ,simply, sets the paddle as default, i.e. system assigns NORMAL_PADDLE_TYPE and NORMAL_PADDLE_SIZE to the paddle also loading proper images respectively, at the beginning of each level or after loosing one live.

Brick Class

Attributes:private int BRICK_COLLISON_SCORE_VALUE: score value for eaach collision with brick.This attribute of Brick class is a static score value for all types of brick.

private boolean canDissappear: This boolean attribute checks if brick can disappear or not.

Methods:public void updateBrick (): This abstract method will be implemented for each child classes of Brick class. It performs operations according to its implementation in child classes. It basically updates new and proper images for specific bricks from disk. i.e. normal brick just deletes its image when this method invoked but in HardBrick class, for every hit count which is smaller than three, just changes the image of the HardBrick object, and when the hit count is three, method deletes the image of the HardBrick object.

NormalBrick Class

Attributes:private int RED_BRICK

private int BLUE_BRICK

private int GREEN_BRICK

These are static attributes of NormalBrick class, which indicate the color of the normal bricks.

Constructors:public NormalBrick (int colorID):This constructor of NormalBrick class creates a NormalBrick object by loading proper image from disk. In addition it takes an integer parameter which indicates the color of the brick, such as red, blue or green. This colorID refers the original TypeID attribute in Game Object class.

Methods:public void updateBrick(): This updateBrick method of NormalBrick class overrides the method of parent class. It removes the image of the NormalBrick object from screen if it is hit.

ExplovsiveBrick Class

Constructors:

public ExplosiveBrick (): This constructor of ExplosiveBrick class creates an instance of Sprite class. It also loads the proper image from disk.

Methods:

public void updateBrick (): This updateBrick method of ExplosiveBrick class overrides the method of parent class. It removes the image of the ExplovsiveBrick from screen.

InvisibleBrick Class

Attributes: private boolean isHit: This boolean isHit attribute is true if the brick is hit.

Constructors:public InvisibleBrick(): This constructor of Invisible Brick class creates an instance of InvisibleBrick object by loading proper image. In this case, since we do not want to show the brick at first place as it should be invinsible, the proper image will be a flue one.

Methods: public void updateBrick(): This method of InvisibleBrick class overrides the parent method. If the isHit attribute is false, this method first changes the image of the object by opaque one. If the isHit attribute is true this method just deletes the image of the object.

HardBrick Class

Attributes:private int hitCount: This attribute of HardBrick class is a counter in order to count how many times the hard brick is hit by a proper object( bullet or ball ). This counter is useful to decide when hard brick will disappear since it is different for hard bricks to explode than normal or explosive bricks.

Constructors:public HardBrick ( ): This constructor creates an instance of HardBrick object by loading proper image.

Methods:public void updateBrick (): This updateBrick method of HardBrick class overrides method of base class. In this method hit count is essential, for hit count is smaller than three, method just changes the image of HardBrick object, when the hit count is three method just deletes the image of the object.

Ball Class

Attributes:int PIERCING_BALL_TYPE

int RIOT_BALL_TYPE

int CRAZY_BALL_TYPE

int NORMAL_BALL_TYPE

These attributes refer indicate the type of the Ball object.

int BIGGER_BALL_SIZE

int NORMAL_BALL_SIZE

int SMALLER_BALL_SIZE

These attributes indicate the size of the Ball object.

private int ballSize: this attribute indicates the size of the ball. i.e. bigger ball, smaller ball etc.

Constructors:public Ball (): This constructor of Ball class creates an instance of Ball object, with default ball type and size.

public Ball ( int typeID, int sizeID ): This constructor of Ball class creates an instance of Ball object, with given size and type. Since, the different typed and sized ball images stored on disk this integer values are used to load these proper images.

Methods:public void accelerateBall (): This method of Ball class accelerates the ball. i.e. increases the amount of speed the ball has.

public void decelerateBall (): This method of Ball class decelerates the ball. i.e. decreases the amount of speed the ball has.

public void increaseBallSize (): This method of Ball class increases the size of the ball, by loading a bigger sized image for ball.

public void decreaseBallSize ():This method of Ball class decreases the size of the ball, by loading a smaller sized image for ball.

public void riotBall (): This method of Ball class turns the ball into a riot ball, by loading riot ball image for ball.

public void piercingBall ():This method of Ball class turns the ball into a piercing ball, by loading piercing ball image for ball.

public void setDefaultBallState(): This setDefaultBallState method of Ball class ,simply, sets the ball type as default, i.e. method assigns NORMAL_BALL_TYPE and NORMAL_BALL_SIZE to the ball and loads images respectively, at the beginning of each level or after loosing one live.

3.5 Detailed System Design

Figure-4(Detailed system Design)