Arcanoid 3D

Arcanoid 3DComputer Graphics Project

Sukesh Jain (128691)

February 10, 2008

Abstract

The report discusses my version of the arcade game Arcanoid. My version ofArcanoid is developed as the project for the Computer Graphics course. Thereport presents the logic and concepts for building the geometries, navigation,collision detection and reflection techniques used to build my version of thegame. It also lists the features available in my version of the game.

Acknowledgements

I would like to take the opportunity to thank the following people, without whoseable help and guidance this project could never have been seen to fruition. Iwould, first and foremost, like to thank Prof. Dr. Raffaele De Amicis forteaching and making clear the concepts of computer graphics and OpenGLduring the course lecture and for his motivation and guidance throughout thecourse.

The acknowledgements section would be hopelessly incomplete if I failed tothank Dr. Giuseppe Conti, who has helped to understand JOGL through thecourse lectures and also for his timely guidance during the lab meetings. I wouldalso like thank for his suggestions of including some features in the Game andalso for his feedback.

Additionally, I would like to thank Olga Symonova for her theory lecture classesof the course. I would also like to express gratitude to all the colleagues ofthe course for their help during entire course period to understand the coursebetter.

1

Contents

1 Introduction 41.1 Structure of the Report . . . . . . . . . . . . . . . . . . . . . . . 4

2 Requirements 5

3 Components of the Game 63.1 Playing Field / Arena . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1.1 Construction . . . . . . . . . . . . . . . . . . . . . . . . . 73.1.2 Transformations . . . . . . . . . . . . . . . . . . . . . . . 7

3.2 Paddle / Pad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2.1 Construction . . . . . . . . . . . . . . . . . . . . . . . . . 83.2.2 Transformation . . . . . . . . . . . . . . . . . . . . . . . . 83.2.3 Restriction of Pad’s movement beyond Arena . . . . . . . 9

3.3 Brick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3.1 Construction . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.4 Special Bonus Brick . . . . . . . . . . . . . . . . . . . . . . . . . 93.4.1 Construction . . . . . . . . . . . . . . . . . . . . . . . . . 103.4.2 Transformations . . . . . . . . . . . . . . . . . . . . . . . 103.4.3 Collision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.4.3.1 Collision with Arena’s Bottom Face . . . . . . . 113.4.3.2 Collision with Pad’s Top Face . . . . . . . . . . 11

3.5 Tracker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.5.1 Construction . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.6 Ball . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.6.1 Construction . . . . . . . . . . . . . . . . . . . . . . . . . 133.6.2 Transformation . . . . . . . . . . . . . . . . . . . . . . . . 133.6.3 Collision & Reflection . . . . . . . . . . . . . . . . . . . . 13

3.6.3.1 Collision & Reflection of Ball with Bricks . . . . 133.6.3.2 Collision & Reflection of Ball with Arena’s Faces 153.6.3.3 Collision & Reflection of Ball with Pad’s Top Face 15

4 Controls, Bonus & Level Strategy 164.1 Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.2 Bonus Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2

CONTENTS 3

4.3 Level Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5 Implementation 185.1 Data Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.2 Geometry Package . . . . . . . . . . . . . . . . . . . . . . . . . . 185.3 Math Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.4 Event Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6 Evaluation & Features 246.1 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6.1.1 Visual Aids . . . . . . . . . . . . . . . . . . . . . . . . . . 246.1.2 Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.1.3 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.2 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

7 Conclusion 277.1 Future Works & Improvements . . . . . . . . . . . . . . . . . . . 27

Chapter 1

Introduction

The Arcanoid 3D game is based on the arcade game developed by Taito in 1986.The player controls a space vessel that acts as the game’s "paddle" which pre-vents a ball from falling from the playing field, attempting to bounce it againsta number of bricks. The ball striking a brick causes the brick to disappear.When all the bricks are gone, the player goes to the next level, where anotherpattern of bricks appear[1]. There are number of variations of this game existsand I am presenting my variation of it.

1.1 Structure of the ReportChapter 2 discusses the requirements of the project. This is followed, in Chap-ter 3 with the overview of my version of the game. The chapter also discussesthe different components that make up the game and also the various logic andconcepts involved in the construction and movement of each component. Chap-ter 4 discusses the controls, options, bonus and level strategies of the game. InChapter 5 the implementation of the game is presented. Chapter 6 discusses theevaluation techniques used and the changes incorporated in the game. Finallyit lists some of the important features of the game. The report then concludeswith a brief discussion on the scope of future enhancements of the game.

4

Chapter 2

Requirements

The chapter lists the requirements of the project. The following are the require-ments of the project:

• The geometries used in the project must be developed by the individ-ual based on the GL primitives and musn’t use the glu or glut built-ingeometries.

• The project musnt’t use glTranslate, glRotate and glScale methods for themovement of the geometries and navigation around the geometries withthe exception of using to place the geometries to initial position at the startof the game using glTranslate(0.0,0.0,-7.0). Instead use transformationmatrix to achieve the movement of the geometries and navigation aroundthe geometries.

• The playing field or arena can be a 2D based on the plane or 3D using acube. But the game should be in the model view i.e game should be 3D.

• As the game is 3D it should be possible to roam around the playing fieldor arena using mouse.

• The paddle movement should be based on the keyboard arrow keys.

• The game should have some form of bonus scheme.

• The game should also have different levels of difficulty.

The above all requirements are satisfied by the game presented in this report.The additional important features provided by the Arcanoid3D game are listedin the chapter 6.

5

Chapter 3

Components of the Game

The Chapter lists the different components that make up the game and it alsodiscusses the logic and concepts that goes behind the construction, movementand navigation around the components.

Figure 3.1: Components of Game “Arcanoid 3D”.

The game is a 3D version of the arcade game Arcanoid developed by Taitoin 1986 with some variations based on the 3D requirements. The additional

6

CHAPTER 3. COMPONENTS OF THE GAME 7

important features of Arcanoid3D game are listed in the chapter 6.

The Game is made up of the different components as shown in the figure 3.1.The discussion is focussed on the graphical components like Ball, Bricks etc andnot on the textual components like Game’s History, Controls etc as they arestatic except the Level, Lifes and Score which is based on the state of the game.

3.1 Playing Field / ArenaFrom here onwards the playing field would be called as arena because it is theplace where all the action is taking place.

3.1.1 ConstructionThe Arena is made up of six planes and each plane consist of the four pointsrepresenting four corners of the plane.

3.1.2 TransformationsThe Arena has its own transformation matrix stack which helps to roam aroundthe arena and this is achieved using the mouse drag event based on the directionof the drag. The angle of rotation is determined by the amount of drag. Thenavigation around arena is achieved by first bringing the arena to the originusing the translate transformation matrix along the Z axis and then applyingthe rotation transfromation matrix along Y axis to arena and finally pushing thearena back to its position by using the translate transformation matrix in theopposite direction of the first translate transformation matrix along Z axis. Thisgives the effect of roaming around the arena. Similarly zoom-in and zoom-outis achieved using the translate transformation matrix along Z axis dependingupon the direction of the mouse wheel scroll direction and the amount of scroll.The current state of the arena affects other components of the game.

• Rotation around Arena along Y axis

– Translate transformation matrix(z)

– Rotation along Y axis(rotationAngle)

– Translate transformation matrix(-z)

• Zoom-In

– Translate transformation matrix(-z)

• Zoom-Out

– Translate transformation matrix(z)


3.2 Paddle / PadThe paddle or pad in short is the space vessel which is used to prevent the ballfrom falling or hitting the bottom of the arena by making the ball to bounceback.

3.2.1 ConstructionAs in the case of arena, the pad is also made up of six planes and each planeconsist of the four points representing four corners of the plane.

3.2.2 TransformationLike arena pad too has its own transformation matrix stack. But this transfor-mation matrix stack is used only for navigation purpose and the current state ofthe pad is based on the current state of its transformation matrix stack appliedto the arena’s current state. The pad can be moved up, down along Z axis, leftand right along X axis using the arrow keys of the keyboard. The speed of thepad movement can also be increased by holding the SHIFT key. The movementof pad is based on the user’s view point i.e. based on the arena position. Thisis achieved by calculating the amount of movement in both X and Z directionin all the key press using the formula shown below:

• On pressing left arrow key

– x = cos(π − θ) ∗ pad′s speed ∗ amount of movement

– z = sin(0− θ) ∗ pad′s speed ∗ amount of movement

• On pressing right arrow key

– x = cos(θ) ∗ pad′s speed ∗ amount of movement

– z = sin(θ) ∗ pad′s speed ∗ amount of movement

• On pressing up arrow key

– z = cos(π − θ) ∗ pad′s speed ∗ amount of movement

– x = sin(θ) ∗ pad′s speed ∗ amount of movement

• On pressing down arrow key

– z = cos(θ) ∗ pad′s speed ∗ amount of movement

– x = sin(0− θ) ∗ pad′s speed ∗ amount of movement

where θ is the angle of rotation of the Arena. Based on these values of X and Zthe translation matrix is pushed into its transformation stack.


3.2.3 Restriction of Pad’s movement beyond ArenaThe pad’s movement is restricted to inside arena by the concept of distancebetween parallel lines. A line equation is constructed for each face of the padfrom the bottom two points of each face using the point formula. Similarlythe line equation is constructed for each face of arena and then finally distanceis calculated between them. If the distance is large enough to accomodatethe movement based on the x and z values calculated as shown above thencorresponding translation matrix is pushed into its transformation matrix stackelse the translation matrix corresponding to the actual distance is pushed.

Equation of line using two points (x1,y1) and (x2,y2)

(x− x1)/(x2 − x1) = (y − y1)/(y2 − y1)

using this equation co-efficient of x, y and constants are calculated. Thendistance between two parallel lines is calculated using the formula given below:

distance = (c1 − c2)/√

(a ∗ a) + (b ∗ b)

where c1 and c2 are constants of two parallel lines, a and b are the co-efficientof x and y. Since the lines are parallel their co-efficients are proportional thatmeans one can use co-efficients of any line but one also has to normalize one ofthe constants before applying to the above distance formula.

3.3 BrickBrick is the target of the ball and the user. Each brick has the score and thenumber of hits required to shoot it down. The number of bricks to be displayed,score and number of hits required to shoot it down all depends upon the leveland is discussed in chapter 4.

3.3.1 ConstructionSimilar to Pad, Brick is made up of six planes and each plane consist of the fourpoints representing four corners of the plane. But unlike Pad, Brick doesn’thave transformation matrix stack as it is stationary and not moving. Hence thecurrent state of the Brick is solely depends upon the current state of the Arena.

3.4 Special Bonus BrickThese are the bonus bricks which drops out as soon as the ball hits the specialbrick. There are variety of special bonus bricks which are discussed in chapter4. But they are not distinguished to add the adventure, excitement and thrillto the game and make the user to get all of them.


Algorithm 1 Collision Algorithm for Special Bonus BrickCheck collision with Arena’s Bottom Faceif collided with Arena

then Remove special bonus brick.else{

Calculate special bonus brick’s next movement andCheck collision with Pad’s Top Faceif collided with Pad{

then Perform corresponding special operation andRemove special bonus brick.

}else{

Check if special bonus brick’s next movement calculatedduring Arena collision can be performed if not thencalculate its updated next’s movement.

}}

3.4.1 ConstructionSpecial Bonus Bricks are cube where as the pad and bricks are not cube as theyhad different values for length, width and height. But in case of Special BonusBricks they are same.

3.4.2 TransformationsUnlike the normal bricks, special bonus bricks drops and hence we have trans-formation stack for each of the special bonus brick. Hence the current state ofthese special bonus bricks depends upon the arena’s current state and the cur-rent state of the transformation stack. Since the bonus brick drops that meansit just requires the translation matrix along the Y axis that is pushed in itstransformation stack.

3.4.3 CollisionSpecial Bonus Bricks can collide with either the bottom face of the Arena or thetop face of the Pad. Different techniques of collision detection is used in eachcase. But the overall collision detection technique for the special bonus brick isshown in algorithm 1.


Algorithm 2 Collision with Arena’s Bottom Face∆y = bonus brick′s center.y −Arena′sBottomFace′sP1.yif (∆y ≤ bonus brick′s size/2)

Collision so remove bonus brickelse{

if ((∆y − bonus brick′s size/2) < desired movement )){

next movement = (∆y − bonus brick′s size/2).}else

next movement = desired movement.}

3.4.3.1 Collision with Arena’s Bottom Face

To check the collision it is sufficient to check their current state y componenti.e y component of the center of the special bonus brick with y component ofany of the point of the bottom face of the Arena as y component for the bottomface is same. If the difference between two of them is less than half the sizeof the special bonus brick then collision has taken place else we calculate itsnext movement. The next movement is obtained by checking if the differencebetween distance (difference between two y components) and half the size ofthe special bonus brick is greater or equal to the movement we want else thisdifference is the next amount of movement. The collision detection with Arena’sBottom Face is shown in algorithm 2

3.4.3.2 Collision with Pad’s Top Face

Here the technique used for collision detection is slightly different as the dimen-sion of Pad is small compared to bottom face of arena. Here in addition tochecking y as mentioned in algorithm 2 we also need to check if x and z of thecenter of the special bonus brick is also inside the area of Pad’s top face. Thecollision detection with Pad’s Top Face is shown in algorithm 3 on the next page

3.5 TrackerDuring testing the application it was found that users were finding it difficult tolocate the ball and special bonus brick. Hence the idea of providing the trackerfor them.


Algorithm 3 Collision with Pad’s Top Face

∆x = |spl bonus brick’s center.x - Pad’s Top Face center.x |∆y = |spl bonus brick’s center.y - Pad’s Top Face center.y |∆z = |spl bonus brick’s center.z - Pad’s Top Face center.z |if ((∆x ≤ Pad’s length / 2 + spl bonus brick’s size / 2 ) &&

(∆y ≤ spl bonus brick’s size / 2 ) &&(∆z ≤ Pad’s width / 2 + spl bonus brick’s size / 2 ))

{Collision and hence perform the special operation andremove the special bonus brick.

}else{

if ((∆x ≤ Pad’s length / 2 + spl bonus brick’s size / 2 ) &&(∆z ≤ Pad’s width / 2 + spl bonus brick’s size / 2 ) &&((∆y - spl bonus brick’s size / 2 ) < next movement ))

{next movement = (∆y - spl bonus brick’s size / 2 )

}}

3.5.1 ConstructionTracker in both the cases are circle representing their movements. The centerof the tracker is either center of the ball or the center of the special bonus brickwhose y component is equal to the y component of the Arena’s Bottom Face.The radius of the tracker depends upon the radius of the ball or size of the specialbonus brick and its position in the arena. Hence the radius of the tracker variesdepending upon the position of the ball or special bonus brick. The tracker isbigger when the ball is going to hit the bottom face of the arena and smallerwhen it is near to the top face of arena thereby, providing an excellent visualaid to the user about the position of the ball. The tracker doesn’t have its owntransformation matrix stack but it has current state which depends upon thearena’s current state.

3.6 BallIt is one of the main component of the game. The whole of the game is aroundthe ball’s movement which involves collision and reflection with brick, pad andarena.


3.6.1 ConstructionIt is sphere whose points are obtained using the following equations shownbelow[2][3]

x = x0 + r cos θ sinφ

y = y0 + r sin θ sinφ

z = z0 + r cos φ

0 ≤ θ ≤ 2π and 0 < φ ≤ π

where (x0,y0,z0) is the center of the sphere and r is the radius of the sphere.

3.6.2 TransformationBall has its own transformation matrix stack. The current state of the balldepends upon the current state of the arena and the current state of its trans-formation matrix stack.

3.6.3 Collision & ReflectionBall collides with the bricks, arena and with the pad. The overall collisiontechnique used is shown in the algorithm 4 on the following page. The ballhas direction indication for each of the axis indicating if the ball is moving inthe positive or negative direction of the corresponding axis. For example whenball collides with right face of the arena then direction of x axis is changed tonegative direction of x axis.

3.6.3.1 Collision & Reflection of Ball with Bricks

To increase the performance of the game we avoid checking collision of ball withall the faces of each brick in each display method call. Instead we check if theball is near the base of the Brick grid if so then only we check for all the facesof each brick for collision else we skip the collision check with all the bricks.The algorithm to check if the ball is near the base of the Brick grid is same asthe ball’s collision with top face of the arena and hence it is not discussed overhere. The collision detection of the ball with any face of the brick is same asthe collision of special bonus brick with the top face of Pad. The only differencebeing here we need to consider the center of the ball instead of the center ofthe special bonus brick and once the collision is detected we need to createthe special bonus brick if the brick was special one, update the score and alsobounce the ball back for example if the ball collides with right face of the brickthen we change the x direction to the positive x axis.


Algorithm 4 Collision of BallCheck collision with Brick’s Base Planeif ball is near the Brick’s Base Planethen

check all the face of each brick for collisionif collision with any face of brickthen

create special bonus brick if brick was special else skipupdate score, remove brick and change direction of ball.

elseskip brick check

Check collision with each face of Arenaif collision with any face of Arena except bottom facethen

change the direction of the ball depending upon the faceif collision with bottom facethen

check if ball doesn’t die power is acquired by Padif yesthen

bounce the ball backelse

ball diesif ball is not deadthen

check collision with Pad’s top faceif collisionthen

change the direction of ball i.e bounce ball back.else

do nothing.


Algorithm 5 Collision of Ball with Arena’s FaceForm the Plane Equation of the face with the three nonco-linear corner points of the plane using the equation[4]∣∣∣∣∣∣

x− x1 y − y1 z − z1

x2 − x1 y2 − y1 z2 − z1

x3 − x1 y3 − y1 z3 − z1

∣∣∣∣∣∣ = 0

We have the plane equation ax + by + cz + d = 0Now we calculate the distance between the center (x0,y0,z0) ofthe ball and plane using the equation[4]

D = (ax0 + by0 + cz0 + d)/√

a2 + b2 + c2

if D is zero or changes sign (for example checking ballcollision with left face of arena the distance would bepositive if ball is inside the arena and would be negativeif ball goes outside arena and hence sign of the distancechanges ) then collision has taken place and we need tobounce the ball back.else

check if next movement of ball doesn’t causes the signchange as it would mean some portion of the ball goingout of arena which is not desired and hence if it resultin sign change then calculate appropriate amount ofnext movement of ball.

3.6.3.2 Collision & Reflection of Ball with Arena’s Faces

The collision of ball with the face of Arena is different from the collision of theball with either pad or brick. Here in the algorithm 5 we show the collisiondetection technique with only one face as it is similar in case of all other faces.The difference being in the direction of bounce depending upon the face theball hits and also in case of the bottom face we perform additional check for thepad’s special power of ball doesn’t die and decide whether to bounce the ballback or make it die.

3.6.3.3 Collision & Reflection of Ball with Pad’s Top Face

The collision detection of ball with Pad’s top face technique is similar to collisiondetection of special bonus brick with Pad’s top face. The difference being herewe need to use the center of ball instead of center of the special bonus brickand once the collision is detected we need to bounce the ball back i.e changethe direction of Y axis to positive.

Chapter 4

Controls, Bonus & LevelStrategy

The chapter discusses various controls of the game. It also presents the strategyused to give bonus and to build different levels of difficulty for the game.

4.1 ControlsThe controls of the game are shown in the table 4.1.

4.2 Bonus StrategyIf the ball hits a brick whose special value is greater than zero then a specialbonus brick drops out. When the paddle catches these special brick then cor-responding bonus activity is performed but if the special bonus brick hits thebottom face of arena then no bonus is provided to the user of the game. All

Key UseArrow Paddle movementShift Increase Speed of Paddle movementp/P Pause/Resume the gamer/R Reset the Arena to original Positiong/G Show/Hide the floor gridn/N Start a new game

Left Mouse button drag Rotate the ArenaMouse wheel scroll Zoom-In/Zoom-Out

q/Q Quit the game.

Table 4.1: Controls of the game

16

CHAPTER 4. CONTROLS, BONUS & LEVEL STRATEGY 17

Constant Name ValueINCREASE_PAD_LENGTH 1INCREASE_PAD_WIDTH 2

ADD_100_POINTS 3REDUCE_PAD_LENGTH 4REDUCE_PAD_WIDTH 5

EXTRA_LIFE 6DOUBLE_BALL_SPEED 7REDUCE_BALL_SPEED 8

BALL_DOESNT_DIE 9DOUBLE_POINTS 10ADD_500_POINTS 11

Table 4.2: Bonus Types

the Bonus are indicated as constant in the GeometryConstant.java file. Cur-rently the values ranging from 1 to 11 are used for the existing bonus and zerocannot be used as it indicates the normal brick. Hence to add new bonus typeone has to create a constant with value incrementing with previous last value(for current it is 11) in the GeometryConstant.java file and also assign this newvalue to the constant MAX_BONUS_TYPES in the GeometryConstant.java.Then automatically system will create special bonus brick corresponding to thisnew bonus type but to handle this bonus type when the speical bonus brickcorresponding to this type one has to add the case corresponding to this bonustype in the switch case of the method specialOperation in GLRenderer.java file.In this method, the special brick corresponding to this bonus type which hitthe pad is also available as the parameters of this method and also all the dataof the game is available through the gData variable of the GLRenderer class.Currently available bonus types in the game are listed in the table 4.2.

4.3 Level StrategyThe first level is based on the constants declared in the file GeometryCon-stant.java. Each subsequent level depends upon the previous level. The maxi-mum number of bricks to be displayed and also what maximum percentage ofthe bricks are special also depends upon the constantsINITIAL_MAX_PER_OF_BRICKS_2B_DISPLAYED andINITIAL_MAX_PER_OF_SPECIAL_BRICKS respectively but it is only forthe first level and subsequent level will derive the value based on its previousvalue. Also the score associated to each bricks depends upon the level. Similarlythe Paddle length, width, size of the bricks, number of hits required by brickto be shot down etc also depends upon the level. There is no limit to levelsbecause of the number of hits required to shoot a brick down changes for eachlevel.

Chapter 5

Implementation

This chapter provides the details regarding the implementation of the game.The package diagram of the implementation is shown in the figure 5.1 on thefollowing page. All the geometries are inside the package geometry which isinside gt. The main game starter class is inside the package arcanoid3D. Allthe data that is shared over the application is in the data package. The classdiagram of the whole game application is shown in the figure 5.2 on page 20

5.1 Data SharingSimultaneously multiple instances of the game can be running without any in-terdependence between one another. The reasons behind this is there is nosharing of variables with multiple instances i.e no static variables in the classGeometryData. At the beginning of the game, an instance of the GeometryDataclass is created and the reference of this variable is set in all places where everdata access is required. This makes the multiple instances of the game to berun simultaneously without any interference between them. To get the clearunderstanding of the organisation of data the class diagram is shown in thefigure 5.3 on page 21.

5.2 Geometry PackageAll the Geometries extends an abstract class BaseGeometry which providesthe basic variables and methods need by all geometries. The variables are thecolor variables and methods are getter-setter methods for color and dispalymethod which is required by all geometries to display the particular geometries.Point2D, Point3D and Plane3D are the classes which represents point in 2D,3D space and a plane in 3D space. The Plane3D class consist of four points rep-resenting the four corners of the plane. The class diagram of all the geometriesare shown in the figure 5.4 on page 22. Other geometries whose constructionslogic discussed in Chapter 3 are just the appropriate use of these simpler classes

18

CHAPTER 5. IMPLEMENTATION 19

Figure 5.1: Package Diagram of the Game Implementation

discussed above. The class diagram of the components discussed in Chapter 3is shown in figure 5.5 on page 23.

5.3 Math PackageThe math package contains the classes which provides the basic mathematicaloperations. The math package contains classes namely GLMath, MatrixStackand PlaneEqn. GLMath class provides the basic mathematical operations corre-sponding to creating the transformation matrices corresponding to translation,rotation, scaling etc. It also provides methods for matrix multiplication, calcu-late plane equation, display a matrix, converting a Point3D object to doublematrix and vice versa. MatrixStack provides methods corresponding to the stackof transformation matrices which is used by geometries. It provides methodslike

• push: Pushes the non-null matrix in top of the stack.

• pop: If stack is not empty then it returns the top element of the stack anddeletes it from the stack else returns null.

• clear : Removes all elements of the Stack.

• current : Returns the current state of the stack i.e. result of matrix mul-tiplication of all the matrices that are in the stack.


Figure 5.2: Arcanoid3D class diagram


Figure 5.3: Class Diagram showing data sharing

5.4 Event HandlingKeyboard and Mouse events are handled by KeyEventListener and MouseEventLis-tener classes respectively which are inside the event package. The KeyEventLis-tener class extends the KeyAdapter class while MouseEventListener extendsMouseAdapter and implements MouseMotionListener and MouseWheelListenerinterfaces for mouse motion and wheel events respectively. These classes pro-vides methods corresponding to event handling like keyPressed, keyReleased,keyTyped, mousePressed, mouseReleased, mouseDragged etc.


Figure 5.4: Class Diagram of all the Geometries


Figure 5.5: Class Diagram of Components of Game

Chapter 6

Evaluation & Features

The chapter discusses the evaluation techniques used to test the game and thechanges or enhancements incorporated based on these evaluations. Finally thechapter lists some of the important features of the game application.

6.1 EvaluationAfter the game application was evaluated with users using two techniques namelySilent Observation and Think-Aloud testing methodology the following featureswere enhanced or included:

6.1.1 Visual AidsA set of visual aids were provided to help the user in playing the game effec-tively in addition to the textual help about the controls available to the usersthroughout the game.

• Tracker: Users found it difficult to track the ball in 3D space and hencelater tracker of the ball was added to the game to provide the visual aidto the user. The tracker is a circle representing the current location of theball in the 3D Arena and the size of the circle indicates whether the ballis approaching down or moving up in the arena.

• Similar tracker was also provided for the special bonus brick.

• During the initial development of the game, the movement of pad wasbased on the initial position of arena i.e Arena’s position at the start ofthe game and wouldn’t take into account that user can rotate the arena.Hence this resulted inconsistence between the user key presses and thepad movement in the visual. Therefore the pad movement was changed totake into account the user’s point of view and made its movement relativeto this point of view.

24

CHAPTER 6. EVALUATION & FEATURES 25

• Some users find it difficult to visualize the rotation of the arena and hencea floor Grid was incorporated to make the visualization easier. But someusers also found this floor Grid as a sought of distraction to their play andhence later an option was included to show/hide this floor Grid.

6.1.2 FeedbackThe feature of more than one hits required to shoot a brick down was found tobe interesting among many users. But it was also found that some users foundstrange when the ball hits to brick and brick doesn’t disappear. Hence as afeedback to the user that application has recognised that ball has hit the bricka random color change of the brick was done and also a red color was appliedto the brick if it required only one hit to shoot it down as an informationalfeedback to the user.

6.1.3 GeneralSome of the general changes or improvement suggested by the users are

• To provide a pause/resume feature which was not there in the initial ver-sion of the game

• For the first time users of the computer, they found it difficult to bring thearena to initial position after some random rotation, zoom and up/downmovements. Hence a feature of resetting the arena’s position to initialstart position with the press of a key ’r/R’ was included without affectingthe game.

• Bugs/Improvements/Enhancements/Suggestions reporting feature was in-cluded later in the game.

6.2 FeaturesSome of the important features of the game in addition to the ones discussed inall the previous chapters are highlighted below:

• Multiple instance of the game can be run simultaneously without interfer-ence between them.

• One can keep on playing the game provided he has lifes and time becausethere is no end in the level of difficulty. As each level is based on theprevious level, the number of hits required to shoot down a brick increaseswith the level and thereby the level of difficulty of the game is endless.

• The performance of the game application is increased by checking thecollision of the ball with brick only when the ball comes closer to thebrickgrid instead of checking the collision of the ball for each face of thebrick in each frame call.

CHAPTER 6. EVALUATION & FEATURES 26

• The game application provides an easier way to change some of the fea-tures of the game by providing a list of constants in the file GeometryCon-stant.java which can be changed to achieve the desired changes.

Chapter 7

Conclusion

The Arcanoid3D game application is a result of Principles of Computer Graphicscourse. The goal of this course is to learn the basic principles of the computergraphics.

7.1 Future Works & ImprovementsThere are several things that can be done to improve the game application.However, it was infeasible to accomplish them during the short time of my workon the game application.

Some of these include:

• The most important would be the improvement of the collision-detectiontechniques which would even further improve the performance of the sys-tem.

• The level of difficulty of the game can be further increased by adding thenumber of hits required to shoot the brick to be associated to each face ofthe brick instead of the brick in general and hence two different levels canbe generated out of this. One way to increase the difficulty level can bewhen all the faces count becomes zero then only the brick gets shot down.Another way is when the ball hits the face whose count becomes zero thebrick gets shot down irrespective of the other faces count.

• Save and Load functionality of the game can be easily provided as all thedata that needs to be saved is there in the class GeometryData

• The aesthetic appeal of the game can also be further beautified.

27

Bibliography

[1] Arcanoid - Wikipedia, http://en.wikipedia.org/wiki/Arcanoid.

[2] Sphere - Wikipedia, http://en.wikipedia.org/wiki/Sphere

[3] Paul Bourke, Parametric Equation of a Sphere and Texture Mapping, August1996, http://local.wasp.uwa.edu.au/~pbourke/texture_colour/spheremap/

[4] Plane - Wikipedia, http://en.wikipedia.org/wiki/Plane_%28mathematics%29

28

Education

Arcanoid 3D