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.
2. 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.
3. 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
6. 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
7. 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
8. 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
9. 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)
10. 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.
11. 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.
12. 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.
13. 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.
14. 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.
15. 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.
16. 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.
17. 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.
18. 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
19. 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.
20. 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
21. 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.
23. 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.
26. 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
27. 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.
28. 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.
29. 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
30. 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
