• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Arcanoid 3D
 

Arcanoid 3D

on

  • 572 views

The report discusses my version of the arcade game Arcanoid. My version of...

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

Statistics

Views

Total Views
572
Views on SlideShare
572
Embed Views
0

Actions

Likes
0
Downloads
7
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Arcanoid 3D Arcanoid 3D Document Transcript

    • Arcanoid 3D Computer Graphics Project Raffaele De Amicis, Giuseppe Conti Sukesh Jain (128691) February 10, 2008
    • Abstract The report discusses my version of the arcade game Arcanoid. My version of Arcanoid is developed as the project for the Computer Graphics course. The report presents the logic and concepts for building the geometries, navigation, collision detection and reflection techniques used to build my version of the game. 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 whose able help and guidance this project could never have been seen to fruition. I would, first and foremost, like to thank Prof. Dr. Raffaele De Amicis for teaching and making clear the concepts of computer graphics and OpenGL during the course lecture and for his motivation and guidance throughout the course. The acknowledgements section would be hopelessly incomplete if I failed to thank Dr. Giuseppe Conti, who has helped to understand JOGL through the course lectures and also for his timely guidance during the lab meetings. I would also like thank for his suggestions of including some features in the Game and also for his feedback. Additionally, I would like to thank Olga Symonova for her theory lecture classes of the course. I would also like to express gratitude to all the colleagues of the course for their help during entire course period to understand the course better. 1
    • Contents 1 Introduction 4 1.1 Structure of the Report . . . . . . . . . . . . . . . . . . . . . . . 4 2 Requirements 5 3 Components of the Game 6 3.1 Playing Field / Arena . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1 Construction . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2 Transformations . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Paddle / Pad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1 Construction . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.2 Transformation . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.3 Restriction of Pad’s movement beyond Arena . . . . . . . 9 3.3 Brick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.1 Construction . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4 Special Bonus Brick . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4.1 Construction . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4.2 Transformations . . . . . . . . . . . . . . . . . . . . . . . 10 3.4.3 Collision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4.3.1 Collision with Arena’s Bottom Face . . . . . . . 11 3.4.3.2 Collision with Pad’s Top Face . . . . . . . . . . 11 3.5 Tracker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.5.1 Construction . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.6 Ball . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.6.1 Construction . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.6.2 Transformation . . . . . . . . . . . . . . . . . . . . . . . . 13 3.6.3 Collision & Reflection . . . . . . . . . . . . . . . . . . . . 13 3.6.3.1 Collision & Reflection of Ball with Bricks . . . . 13 3.6.3.2 Collision & Reflection of Ball with Arena’s Faces 15 3.6.3.3 Collision & Reflection of Ball with Pad’s Top Face 15 4 Controls, Bonus & Level Strategy 16 4.1 Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2 Bonus Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2
    • CONTENTS 3 4.3 Level Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5 Implementation 18 5.1 Data Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2 Geometry Package . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.3 Math Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.4 Event Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6 Evaluation & Features 24 6.1 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1.1 Visual Aids . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1.2 Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1.3 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.2 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7 Conclusion 27 7.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 against a 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 another pattern of bricks appear[1]. There are number of variations of this game exists and I am presenting my variation of it. 1.1 Structure of the Report Chapter 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 discusses the different components that make up the game and also the various logic and concepts involved in the construction and movement of each component. Chap- ter 4 discusses the controls, options, bonus and level strategies of the game. In Chapter 5 the implementation of the game is presented. Chapter 6 discusses the evaluation techniques used and the changes incorporated in the game. Finally it lists some of the important features of the game. The report then concludes with 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-in geometries. • The project musnt’t use glTranslate, glRotate and glScale methods for the movement of the geometries and navigation around the geometries with the exception of using to place the geometries to initial position at the start of the game using glTranslate(0.0,0.0,-7.0). Instead use transformation matrix to achieve the movement of the geometries and navigation around the geometries. • The playing field or arena can be a 2D based on the plane or 3D using a cube. 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 field or 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 listed in the chapter 6. 5
    • Chapter 3 Components of the Game The Chapter lists the different components that make up the game and it also discusses the logic and concepts that goes behind the construction, movement and 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 Taito in 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 and not on the textual components like Game’s History, Controls etc as they are static except the Level, Lifes and Score which is based on the state of the game. 3.1 Playing Field / Arena From here onwards the playing field would be called as arena because it is the place where all the action is taking place. 3.1.1 Construction The Arena is made up of six planes and each plane consist of the four points representing four corners of the plane. 3.1.2 Transformations The Arena has its own transformation matrix stack which helps to roam around the arena and this is achieved using the mouse drag event based on the direction of the drag. The angle of rotation is determined by the amount of drag. The navigation around arena is achieved by first bringing the arena to the origin using the translate transformation matrix along the Z axis and then applying the rotation transfromation matrix along Y axis to arena and finally pushing the arena back to its position by using the translate transformation matrix in the opposite direction of the first translate transformation matrix along Z axis. This gives the effect of roaming around the arena. Similarly zoom-in and zoom-out is achieved using the translate transformation matrix along Z axis depending upon 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)
    • CHAPTER 3. COMPONENTS OF THE GAME 8 3.2 Paddle / Pad The paddle or pad in short is the space vessel which is used to prevent the ball from falling or hitting the bottom of the arena by making the ball to bounce back. 3.2.1 Construction As in the case of arena, the pad is also made up of six planes and each plane consist of the four points representing four corners of the plane. 3.2.2 Transformation Like 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 of the pad is based on the current state of its transformation matrix stack applied to the arena’s current state. The pad can be moved up, down along Z axis, left and right along X axis using the arrow keys of the keyboard. The speed of the pad movement can also be increased by holding the SHIFT key. The movement of pad is based on the user’s view point i.e. based on the arena position. This is achieved by calculating the amount of movement in both X and Z direction in 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 Z the translation matrix is pushed into its transformation stack.
    • CHAPTER 3. COMPONENTS OF THE GAME 9 3.2.3 Restriction of Pad’s movement beyond Arena The pad’s movement is restricted to inside arena by the concept of distance between parallel lines. A line equation is constructed for each face of the pad from the bottom two points of each face using the point formula. Similarly the line equation is constructed for each face of arena and then finally distance is calculated between them. If the distance is large enough to accomodate the movement based on the x and z values calculated as shown above then corresponding translation matrix is pushed into its transformation matrix stack else the translation matrix corresponding to the actual distance is pushed. Equation of line using two points (x1 ,y 1 ) and (x2 ,y 2 ) (x − x1 )/(x2 − x1 ) = (y − y1 )/(y2 − y1 ) using this equation co-efficient of x, y and constants are calculated. Then distance 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-efficient of x and y. Since the lines are parallel their co-efficients are proportional that means one can use co-efficients of any line but one also has to normalize one of the constants before applying to the above distance formula. 3.3 Brick Brick is the target of the ball and the user. Each brick has the score and the number 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 level and is discussed in chapter 4. 3.3.1 Construction Similar to Pad, Brick is made up of six planes and each plane consist of the four points representing four corners of the plane. But unlike Pad, Brick doesn’t have transformation matrix stack as it is stationary and not moving. Hence the current state of the Brick is solely depends upon the current state of the Arena. 3.4 Special Bonus Brick These are the bonus bricks which drops out as soon as the ball hits the special brick. There are variety of special bonus bricks which are discussed in chapter 4. But they are not distinguished to add the adventure, excitement and thrill to the game and make the user to get all of them.
    • CHAPTER 3. COMPONENTS OF THE GAME 10 Algorithm 1 Collision Algorithm for Special Bonus Brick Check collision with Arena’s Bottom Face if collided with Arena then Remove special bonus brick. else { Calculate special bonus brick’s next movement and Check collision with Pad’s Top Face if collided with Pad { then Perform corresponding special operation and Remove special bonus brick. } else { Check if special bonus brick’s next movement calculated during Arena collision can be performed if not then calculate its updated next’s movement. } } 3.4.1 Construction Special Bonus Bricks are cube where as the pad and bricks are not cube as they had different values for length, width and height. But in case of Special Bonus Bricks they are same. 3.4.2 Transformations Unlike 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 of these 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 means it just requires the translation matrix along the Y axis that is pushed in its transformation stack. 3.4.3 Collision Special Bonus Bricks can collide with either the bottom face of the Arena or the top face of the Pad. Different techniques of collision detection is used in each case. But the overall collision detection technique for the special bonus brick is shown in algorithm 1.
    • CHAPTER 3. COMPONENTS OF THE GAME 11 Algorithm 2 Collision with Arena’s Bottom Face ∆y = bonus brick s center.y − Arena s Bottom F ace s P1 .y if (∆y ≤ bonus brick s size/2) Collision so remove bonus brick else { 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 component i.e y component of the center of the special bonus brick with y component of any of the point of the bottom face of the Arena as y component for the bottom face is same. If the difference between two of them is less than half the size of the special bonus brick then collision has taken place else we calculate its next movement. The next movement is obtained by checking if the difference between distance (difference between two y components) and half the size of the special bonus brick is greater or equal to the movement we want else this difference is the next amount of movement. The collision detection with Arena’s Bottom 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 to checking y as mentioned in algorithm 2 we also need to check if x and z of the center of the special bonus brick is also inside the area of Pad’s top face. The collision detection with Pad’s Top Face is shown in algorithm 3 on the next page 3.5 Tracker During testing the application it was found that users were finding it difficult to locate the ball and special bonus brick. Hence the idea of providing the tracker for them.
    • CHAPTER 3. COMPONENTS OF THE GAME 12 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 and remove 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 Construction Tracker in both the cases are circle representing their movements. The center of the tracker is either center of the ball or the center of the special bonus brick whose 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 special bonus brick and its position in the arena. Hence the radius of the tracker varies depending upon the position of the ball or special bonus brick. The tracker is bigger when the ball is going to hit the bottom face of the arena and smaller when it is near to the top face of arena thereby, providing an excellent visual aid to the user about the position of the ball. The tracker doesn’t have its own transformation matrix stack but it has current state which depends upon the arena’s current state. 3.6 Ball It is one of the main component of the game. The whole of the game is around the ball’s movement which involves collision and reflection with brick, pad and arena.
    • CHAPTER 3. COMPONENTS OF THE GAME 13 3.6.1 Construction It is sphere whose points are obtained using the following equations shown below[2][3] x = x0 + r cos θ sin φ y = y0 + r sin θ sin φ z = z0 + r cos φ 0 ≤ θ ≤ 2π and 0 < φ ≤ π where (x0 ,y 0 ,z 0 ) is the center of the sphere and r is the radius of the sphere. 3.6.2 Transformation Ball has its own transformation matrix stack. The current state of the ball depends upon the current state of the arena and the current state of its trans- formation matrix stack. 3.6.3 Collision & Reflection Ball collides with the bricks, arena and with the pad. The overall collision technique used is shown in the algorithm 4 on the following page. The ball has direction indication for each of the axis indicating if the ball is moving in the positive or negative direction of the corresponding axis. For example when ball collides with right face of the arena then direction of x axis is changed to negative 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 with all the faces of each brick in each display method call. Instead we check if the ball is near the base of the Brick grid if so then only we check for all the faces of 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 as the ball’s collision with top face of the arena and hence it is not discussed over here. The collision detection of the ball with any face of the brick is same as the collision of special bonus brick with the top face of Pad. The only difference being here we need to consider the center of the ball instead of the center of the special bonus brick and once the collision is detected we need to create the special bonus brick if the brick was special one, update the score and also bounce the ball back for example if the ball collides with right face of the brick then we change the x direction to the positive x axis.
    • CHAPTER 3. COMPONENTS OF THE GAME 14 Algorithm 4 Collision of Ball Check collision with Brick’s Base Plane if ball is near the Brick’s Base Plane then check all the face of each brick for collision if collision with any face of brick then create special bonus brick if brick was special else skip update score, remove brick and change direction of ball. else skip brick check Check collision with each face of Arena if collision with any face of Arena except bottom face then change the direction of the ball depending upon the face if collision with bottom face then check if ball doesn’t die power is acquired by Pad if yes then bounce the ball back else ball dies if ball is not dead then check collision with Pad’s top face if collision then change the direction of ball i.e bounce ball back. else do nothing.
    • CHAPTER 3. COMPONENTS OF THE GAME 15 Algorithm 5 Collision of Ball with Arena’s Face Form the Plane Equation of the face with the three non co-linear corner points of the plane using the equation[4] x − x1 y − y1 z − z1 x2 − x1 y 2 − y1 z2 − z1 =0 x3 − x1 y 3 − y1 z3 − z1 We have the plane equation ax + by + cz + d = 0 Now we calculate the distance between the center (x0 ,y 0 ,z 0 ) of the 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 ball collision with left face of arena the distance would be positive if ball is inside the arena and would be negative if ball goes outside arena and hence sign of the distance changes ) then collision has taken place and we need to bounce the ball back. else check if next movement of ball doesn’t causes the sign change as it would mean some portion of the ball going out of arena which is not desired and hence if it result in sign change then calculate appropriate amount of next 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 the ball with either pad or brick. Here in the algorithm 5 we show the collision detection 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 the ball hits and also in case of the bottom face we perform additional check for the pad’s special power of ball doesn’t die and decide whether to bounce the ball back 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 collision detection of special bonus brick with Pad’s top face. The difference being here we need to use the center of ball instead of center of the special bonus brick and once the collision is detected we need to bounce the ball back i.e change the direction of Y axis to positive.
    • Chapter 4 Controls, Bonus & Level Strategy The chapter discusses various controls of the game. It also presents the strategy used to give bonus and to build different levels of difficulty for the game. 4.1 Controls The controls of the game are shown in the table 4.1. 4.2 Bonus Strategy If the ball hits a brick whose special value is greater than zero then a special bonus brick drops out. When the paddle catches these special brick then cor- responding bonus activity is performed but if the special bonus brick hits the bottom face of arena then no bonus is provided to the user of the game. All Key Use Arrow Paddle movement Shift Increase Speed of Paddle movement p/P Pause/Resume the game r/R Reset the Arena to original Position g/G Show/Hide the floor grid n/N Start a new game Left Mouse button drag Rotate the Arena Mouse 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 Value INCREASE_PAD_LENGTH 1 INCREASE_PAD_WIDTH 2 ADD_100_POINTS 3 REDUCE_PAD_LENGTH 4 REDUCE_PAD_WIDTH 5 EXTRA_LIFE 6 DOUBLE_BALL_SPEED 7 REDUCE_BALL_SPEED 8 BALL_DOESNT_DIE 9 DOUBLE_POINTS 10 ADD_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 zero cannot be used as it indicates the normal brick. Hence to add new bonus type one 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 new value to the constant MAX_BONUS_TYPES in the GeometryConstant.java. Then automatically system will create special bonus brick corresponding to this new bonus type but to handle this bonus type when the speical bonus brick corresponding to this type one has to add the case corresponding to this bonus type in the switch case of the method specialOperation in GLRenderer.java file. In this method, the special brick corresponding to this bonus type which hit the pad is also available as the parameters of this method and also all the data of 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 Strategy The 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 of the bricks are special also depends upon the constants INITIAL_MAX_PER_OF_BRICKS_2B_DISPLAYED and INITIAL_MAX_PER_OF_SPECIAL_BRICKS respectively but it is only for the first level and subsequent level will derive the value based on its previous value. Also the score associated to each bricks depends upon the level. Similarly the Paddle length, width, size of the bricks, number of hits required by brick to be shot down etc also depends upon the level. There is no limit to levels because of the number of hits required to shoot a brick down changes for each level.
    • 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 the following page. All the geometries are inside the package geometry which is inside gt. The main game starter class is inside the package arcanoid3D. All the data that is shared over the application is in the data package. The class diagram of the whole game application is shown in the figure 5.2 on page 20 5.1 Data Sharing Simultaneously multiple instances of the game can be running without any in- terdependence between one another. The reasons behind this is there is no sharing of variables with multiple instances i.e no static variables in the class GeometryData. At the beginning of the game, an instance of the GeometryData class is created and the reference of this variable is set in all places where ever data access is required. This makes the multiple instances of the game to be run simultaneously without any interference between them. To get the clear understanding of the organisation of data the class diagram is shown in the figure 5.3 on page 21. 5.2 Geometry Package All the Geometries extends an abstract class BaseGeometry which provides the basic variables and methods need by all geometries. The variables are the color variables and methods are getter-setter methods for color and dispaly method 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 geometries are shown in the figure 5.4 on page 22. Other geometries whose constructions logic 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 3 is shown in figure 5.5 on page 23. 5.3 Math Package The math package contains the classes which provides the basic mathematical operations. The math package contains classes namely GLMath, MatrixStack and 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 double matrix and vice versa. MatrixStack provides methods corresponding to the stack of transformation matrices which is used by geometries. It provides methods like • 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 and deletes 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.
    • CHAPTER 5. IMPLEMENTATION 20 Figure 5.2: Arcanoid3D class diagram
    • CHAPTER 5. IMPLEMENTATION 21 Figure 5.3: Class Diagram showing data sharing 5.4 Event Handling Keyboard 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 extends MouseAdapter and implements MouseMotionListener and MouseWheelListener interfaces for mouse motion and wheel events respectively. These classes pro- vides methods corresponding to event handling like keyPressed, keyReleased, keyTyped, mousePressed, mouseReleased, mouseDragged etc.
    • CHAPTER 5. IMPLEMENTATION 22 Figure 5.4: Class Diagram of all the Geometries
    • CHAPTER 5. IMPLEMENTATION 23 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 the changes or enhancements incorporated based on these evaluations. Finally the chapter lists some of the important features of the game application. 6.1 Evaluation After the game application was evaluated with users using two techniques namely Silent Observation and Think-Aloud testing methodology the following features were enhanced or included: 6.1.1 Visual Aids A 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 users throughout the game. • Tracker: Users found it difficult to track the ball in 3D space and hence later tracker of the ball was added to the game to provide the visual aid to the user. The tracker is a circle representing the current location of the ball in the 3D Arena and the size of the circle indicates whether the ball is 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 was based on the initial position of arena i.e Arena’s position at the start of the game and wouldn’t take into account that user can rotate the arena. Hence this resulted inconsistence between the user key presses and the pad movement in the visual. Therefore the pad movement was changed to take into account the user’s point of view and made its movement relative to this point of view. 24
    • CHAPTER 6. EVALUATION & FEATURES 25 • Some users find it difficult to visualize the rotation of the arena and hence a floor Grid was incorporated to make the visualization easier. But some users also found this floor Grid as a sought of distraction to their play and hence later an option was included to show/hide this floor Grid. 6.1.2 Feedback The feature of more than one hits required to shoot a brick down was found to be interesting among many users. But it was also found that some users found strange when the ball hits to brick and brick doesn’t disappear. Hence as a feedback to the user that application has recognised that ball has hit the brick a random color change of the brick was done and also a red color was applied to the brick if it required only one hit to shoot it down as an informational feedback to the user. 6.1.3 General Some 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 the arena to initial position after some random rotation, zoom and up/down movements. Hence a feature of resetting the arena’s position to initial start position with the press of a key ’r/R’ was included without affecting the game. • Bugs/Improvements/Enhancements/Suggestions reporting feature was in- cluded later in the game. 6.2 Features Some of the important features of the game in addition to the ones discussed in all 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 because there is no end in the level of difficulty. As each level is based on the previous level, the number of hits required to shoot down a brick increases with the level and thereby the level of difficulty of the game is endless. • The performance of the game application is increased by checking the collision of the ball with brick only when the ball comes closer to the brickgrid instead of checking the collision of the ball for each face of the brick 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 Graphics course. The goal of this course is to learn the basic principles of the computer graphics. 7.1 Future Works & Improvements There 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 work on the game application. Some of these include: • The most important would be the improvement of the collision-detection techniques which would even further improve the performance of the sys- tem. • The level of difficulty of the game can be further increased by adding the number of hits required to shoot the brick to be associated to each face of the brick instead of the brick in general and hence two different levels can be generated out of this. One way to increase the difficulty level can be when 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 the brick gets shot down irrespective of the other faces count. • Save and Load functionality of the game can be easily provided as all the data 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, August 1996, http://local.wasp.uwa.edu.au/~pbourke/texture_colour/spheremap/ [4] Plane - Wikipedia, http://en.wikipedia.org/wiki/Plane_%28mathematics%29 28