Bilkent University
Department of Computer Engineering
CS 319 OOP Project
Project short-name: Boat Drift
Analysis Report
Yunus Nedim Mehel, Mustafa İlker Saraç, Raziye Esra Çetin, İpek Aktaş
Supervisor: Uğur Doğrusöz
Analysis Report Part 1
October 26, 2010
This report is submitted to the Department of Computer Engineering of Bilkent
University in partial fulfillment of the requirements of the Senior Design Project
course CS319.
Contents
1.
Introduction ........................................................................................................................ 3
2.
Current System.................................................................................................................... 3
3.
Proposed System................................................................................................................. 3
3.1 Overview ........................................................................................................................... 4
3.2 Functional Requirements: ................................................................................................ 6
3.3
Non-functional requirements: ..................................................................................... 6
3.4 System models .................................................................................................................. 7
3.4.1 Use case model (use case analysis)............................................................................ 7
3.4.2 Object Model ........................................................................................................... 12
3.4.3 Dynamic Models ...................................................................................................... 13
3.4.3.1 Sequence Diagrams............................................................................................... 13
3.4.3.2
State Diagrams ................................................................................................ 20
3.4.3.3
Activity Diagrams ............................................................................................ 22
3.4.4
User Interfaces ................................................................................................... 24
4. Glossary ................................................................................... Error! Bookmark not defined.
5. Conclusion ............................................................................................................................ 31
6. References ............................................................................................................................ 31
2
1. Introduction
The game “Boat Drift” is a project, which belongs to four computer engineering students
from Bilkent University. It is the major assignment of the course CS 319. The project consists
of analysis, design, implementation and testing phases of Boat Drift, which will be created as
a clone of a similar game from internet1. This report will include an overview of the game,
which we are making the clone of, functional and non-functional requirements for the
implementation, system models and a detailed description of the game’s final version,
including screenshots. The design phase of the project is implemented using various UML
diagrams and Java is the programming language, which is used for the implementation of
the game.
2. Current System
River Draft is a kind of arcade game. The game takes place in a piece of sea or lake. The
area includes many small land pieces and rocks. If the boat crashes one of these small land
pieces, it gets damaged and loses one of its lives. The main sustainer of the game is the wind
factor. The ship sails according to the speed and direction of the wind. Since the weather is
always windy our ship never stops; it only slows down and speeds up. You have to control
and direct according to the wind factor. When you collect all the buoys, you pass the level
and pass through the new level with more fancy wind factor and a bigger number of buoys.
There are some obstacles in the map, such as some the land pieces and rocks. If you hit one
of those you will lose one life; if you lose all your existing lives the game will be over and the
player will need to restart the game if he wants to play again. In the end of the game,
according to the time and bonuses the player gains a score, which gives him a chance to get
into the high score table.
3. Proposed System
There are four groups of objects, which the player can interact with:
Wind: The wind is supposed to be the main source of the movement of our boat. Its
direction and strength change periodically.
Buoys: The goal of each map is to collect all of the existing checkpoints. There is no order or
finish line; the map will be over if all the checkpoints are collected.
1
http://www.game37.net/play_games/Rockfort_Buoy_Ahoy
3
Obstacles:
Islands: There will be several islands on the map. They cost one life when hit. The player
should consider the direction and strength of the wind, in order to collect all the buoys
without losing lives. The game will be over if no lives are left.
Rocks: The solid pieces of stone that destroy our boat. Each hit on them costs one life to the
player, just like the islands.
Bonuses: There will be various bonuses in the map, which can be collected to gain some
advantage in the game. All bonuses can be found within the boxes. The boxes can be shot
with the cannon of the boat, and a random bonus appears. There are three kind of bonuses
in the game:
Cannon: The ship is able to throw cannons, which can eradicate the obstacles in the way. It
can be used to shoot the boxes to get some bonuses. The number of the cannons will be
limited but more can be collected by shooting the boxes on the map.
Turbo: They will momentarily boost the speed of the boat.
Extra lives: They can be collected to recover the lost lives. The game will be over if the
number of lives drops to zero.
3.1 Overview
The game consists of a boat, which is controlled by the player, some obstacles and
collectable bonuses, which can give some advantages to the player. If the boat crashes one
of the obstacles in the map it will sink and the player loses one life. The boat will be drafted
by the wind of the map, which changes periodically. The boat is controlled by the two arrow
keys but the speed and actual moving direction of the boat will be varied according to the
speed and strength of the wind. The boat has a limited number of lives; if this number drops
to zero the game will be over but extra lives can be collected from the boxes, in which the
bonuses exist. The box can be shot by using the cannon of the boat but the number of the
cannons will be limited.
The main object is to collect all of the buoys on each map. When user collects all of
them, the level will be completed. While the player proceeds, the levels will get harder and
the weather conditions will get stronger.
The player will gain points for collecting bonuses and buoys; if his points in the end
are high enough he will have chance to write his name into the high score table. This table
will be available to see by clicking the corresponding button in the game menu. The domain
analysis diagram can be seen below:
4
Figure 1: Domain Analysis Diagram
The game basically consists of five components. The game controller controls the
other components of the game. It holds the timer in it, it compares the player’s score with
the ones in the high score table and it changes the map, after each level is completed. The
game map holds the obstacles and collectibles. It has borders and it calculates the wind,
which affects the boat of the player.
Another group of objects in the game are the obstacles, which consist of rocks and
islands. They all have a position on the island and its type determines if it’s a rock or an
island.
The collectibles are the buoys and bonuses on the map. The type of the collectible
determines if it’s function. The bonuses will be found inside boxes throughout the map,
whereas the buoys can be collected directly. The boxes should be shot by cannons before
they are collected. There will be three kinds of bonuses, whose type will be determined by
the type of the collectible. The player cannot pass the next level unless he collects all the
buoys in the map.
5
3.2 Functional Requirements:
New game: This option will start the game. The player will start playing on the first map and
will go on with the others as he proceeds.
Pause Game: This option will pause the game, allowing the user to stop the game and leave
the computer.
Resume Game: This will resume the paused game.
Settings: There will be two options in this menu. The user will be able to select color and
shape of his boat and he will be able to turn on/off the sound of the game.
High Scores: There will be high score table for the game, which will hold the best ten players
with the highest points. Once the user finishes all five levels, his point will be compared to
the ones in the high score table. If he has a higher score then the last one in the table, then
his name will be asked and written into the table. The table will be held in the local machine.
Credits: In this section there will be information about the game, its contents and our group
with the contact information.
3.3 Non-functional requirements:
Sound: The background music will provide an atmosphere of sea and waves to the user.
Easy GUI: The game should be easily understandable and playable for players with young
and grown-up players.
Easy and smooth controls: The movement of the boat should be easy and smooth.
Low system requirements: The game should not cause a huge load on the machine.
Single player game: The game will be a single player game.
6
3.4 System models
3.4.1 Use case model (use case analysis)
Figure 2: Use Case Diagram
Use Case 1:
Use Case Name: New Game
Participating Actor: Player
Entry Condition: Player opens the game “Boat Drift” by double clicking the jar file “Boat
Drift.jar” and selects the “New Game” option from the initial screen.
Flow of Events:
1. Player chooses “New Game” option from the initial screen of the game “Boat Drift”
2. The game “Boat Drift” starts from the very first level.
3. Player completes all levels one by one and finally gets informed about his/her
score.
7
4. According to the score the player gets his/her score will be registered to the high
scores table.
Exit Condition: There are two conditions to exit from the “Play Game” option.
1. Player completes the game successfully and gets his/her total score.
2. Player cannot complete the game because his/her predetermined lives are
exhausted.
3. Player pauses the game and chooses “Exit” option from the pause menu.
Describe Exceptions:
1. If user clicks the “close” button on the very upper left/right corner (depends on
the Operating System that player uses) the game “Boat Drift” immediately
terminates.
Special Requirements: None.
Use Case 2:
Use Case Name: Pause Game
Participating Actor: Player
Entry Condition: Player clicks the “Pause” while playing the game or simply presses the “Esc”
button from his/her keyboard.
Flow of Events:
1. The player clicks the “Pause” button or press “Esc” button from keyboard while game
is running.
2. Game is paused and the position of the boat and the other object are conserved.
3. Pause Game menu will appear.
Exit Condition: Player chooses resume button or presses the “Esc” from the keyboard then
returns to the game.
Describe Exceptions:
1. Player selects “Main Menu” button from the Pause Game menu.
2. Player selects “Exit Game” button from the Pause Game menu.
3. Player selects “Restart Game” button from the Pause Game menu.
Special Requirements: None
8
Use Case 3:
Use Case Name: Resume Game
Participating Actor: Player
Entry Condition: Player clicks the “Resume Game” while game is paused or simply presses
the “Esc” button from his/her keyboard.
Flow of Events:
1. Player selects “Resume Game” button from the Pause Game menu or press “Esc”
button from keyboard while game is paused.
2. Game will continue from where it stayed.
3. Pause Game menu will disappear.
Exit Condition: Player chooses resume button or presses the “Esc” from the keyboard then
returns to the game.
Describe Exceptions:
1. Player selects a different option from the pause menu.
2. If user clicks the “close” button on the very upper left/right corner(depends on the
Operating System that player uses) the game “Boat Drift” immediately
terminates.
Special Requirements: None
Use Case 4:
Use Case Name: Get Help
Participating Actor: Player
Entry Condition: Player opens the game “Boat Drift” by double clicking the jar file “Boat
Drift.jar” and selects the “Get Help” option from the initial screen.
Flow of Events:
1. Player chooses the “Get Help” option from the Main Menu.
2. Player reads the instructions which are clearly defined and visually represented.
3. When player learns how to play the game, he/she will return to main menu or
directly starts playing game by selecting “Let’s Play Game” button.
Exit Condition: Player learns how to play the game.
Describe Exceptions: If user clicks the “close” button on the very upper left/right corner
(depends on the Operating System that player uses) the game “Boat Drift” immediately
terminates.
Special Requirements: None.
9
Use Case 5:
Use Case Name: Change Settings
Participating Actor: Player
Entry Condition: Player opens the game “Boat Drift” by double clicking the jar file “Boat
Drift.jar” and selects the “Change Settings” option from the initial screen.
Flow of Events:
1. Player chooses “Change Settings” option from the main menu.
2. Player can change the selections of the game from the Change Settings screen.
3. When player done with the desired settings he/she will press the “Save Settings”
button.
4. Player will immediately return to the main menu after clicking “Save Settings”
button.
Exit Condition: Player successfully changes the settings of the game and returns to the main
menu.
Describe Exceptions: None.
Special Requirements: None.
Use Case 6:
Use Case Name: See High Scores
Participating Actor: Player
Entry Condition: Player opens the game “Boat Drift” by double clicking the jar file “Boat
Drift.jar” and selects the “See High Scores” option from the initial screen.
Flow of Events:
1. Player chooses the “See High Scores” option from the Main Menu.
2. Player can observe several high scores that different users did.
Exit Condition: Player chooses “Main Menu” option to return to the initial screen.
Describe Exceptions: None.
Special Requirements: None.
10
Use Case 7:
Use Case Name: See Credits
Participating Actor: Player
Entry Condition: Player opens the game “Boat Drift” by double clicking the jar file “Boat
Drift.jar” and selects the “See Credits” option from the initial screen.
Flow of Events:
1. Player chooses “See Credits” option from the menu in order to see the developers of
the game.
2. Credits appear to the player and the required information is get by the player.
Exit Condition: Player chooses “Main Menu” option to return to the initial screen.
Describe Exceptions: None.
Special Requirements: None.
11
3.4.2 Object Model
Figure 3: Object diagram of the Boat Drift Game.
12
3.4.3 Dynamic Models
3.4.3.1 Sequence Diagrams
1) Sequence diagram of collecting Buoy
Figure 4: Collecting a Buoy
13
Ilker clicks the "BoatDrift.jar" from the desktop. Then main window of the game is
opened. Ilker immedately wants to start game. Therefore, he clicks the "New Game" button
from the main window.Then he starts to play the game "BoatDrift". He makes the boat move
and collect the buoys.
In this sequence diagram, player chooses to play "New Game". He sends instruction
to start a new game to the GameManager which controls basic operations in the game. Then
GameManager sends this start game instruction to the GUIManager that controls the
ManageMap and representations of the boat and buoys. GUIManager sends instruction to
the ManageMap to call map with the information about which level it should be.
ManageMap sets up location of boat and buoys by sending instruction to the
BoatRepresentation and BuoyRepresentation. Then, ManageMap responds to the
GUIManager about readiness of the initial map. After that, player begins the control
movement and speed of the boat with keyboard. GameManager sets up the location of the
boat according to directions which player gives. Then, Boat sends control statement about
Turbo to the GameManager. If Turbo exists, then boat will speed up. The next phase is
controlling if buoy is taken or not. Boat controls it with Buoy. If the buoy is not taken Boat
sends instruction to the Buoy to collect Buoy. Then Buoy checks if the collected Buoy is the
last Buoy on the map with the GameManager. If it is not the last Buoy on the map,
GameManager sends instruction to the GUIManager to make Buoy disappear. GUIManager
sends this instruction to the BuoyRepresentation and Buoy is set invisible. Then,
BuoyRepresentation sends updateMap instruction to the ManageMap. Thus, game will be
continued.
14
2) Sequence diagram of collecting first Bonus(extra life).
Figure 5: Collecting an extra Life
In this sequence, when player named “İpek” moves the boat with the direction and
speed, GameManager wants to Boot objects to set the location of boat. Thus, boat object
checks whether a boat has turbo or not by asking GameManager. If turbo does not exist at
all, this time GameManager wants to know that boat has cannons in order to make decision
to hit the bonus boxes on sea. Thus, GameManager asks Boat whether it has cannons or not.
Boat replies GameManager positively, player realizes that she have a right to hit the box in
order to take surprise furthermore she fires the cannon through the box on the island. After
15
the cannon is fired, GameManager checks whether the target is shot successfully or not. If
the targeted box can not be shot fort he first time, shooting maintains until the hit occurs.
Assume that the box contains bonus in it. Then, GameManager asks GuiManager to show
the existence of bonus where the box is hit. After a while, GuiManager directs
BonusRepresentation to demonstrate the gained bonus. Moreover, İpek continues to move
the boat with a specific direction and speed.
At that point, GameManager sets the location of boat as İpek wants the boat to
move. As the boat comes closer to the bonus and finally touches it, Bonus checks whether
bonus is taken or not. If bonus is taken by the boat, GameManager asks GuiManager to set
the bonus invisible in order to disappear the bonus on the screen. Furthermore, GuiManager
wants BonusPresentation to change the bonus settings which is returning the visibility of
bonus false.
Until this step, boat took the bonus, which has been existing in the box before. Now,
it is time to get the point of bonus on the score table by the courtesy of GameManager’s
order to the Boat object.
3) Sequence diagram of wind changes direction, boat hits an island and loses one life.
Figure 6: Wind Changes Direction and boat loses one life
16
In the process of game maintenance, while the player named “Esra” moves the boat
which has specific direction and speed, Boat object sends the boat’s location. However, in
the game, wind begins to blow at random time. By the effect of this wind, boat cannot move
at the previous speed and direction. At this point, GameManager changes the direction of
the boat and computes the speed of wind. According to the speed of wind, it makes a
physical calculations (by using summation of vectors)** to determine the boat’s new
direction and speed, the updates these values to the Boat object. Obviously, these changes
should be determined on the screen, that GameManager mandates the GuiManager to show
the boat with new specifications.
While the boat moves, it may meet an island and crashes if the boat’s direction is not
changed by Esra. In that case, island positions, which are set initially, are sent as a data to
the GameManager. If at any time, boat’s position approaches the island’s position, this
means, collision is detected. When the collision is detected and the boat crashes the island,
Boat object loses one life that is organized by GameManager.
The maintenance of the game depends on remaining lives. Boat objects checks
whether it has lives except for the lost one. If still there are some, one life chance goes away
and the game maintains until the last life is lost. On the other hand, if the life which has lost,
is also the last life chance, boat sinks and GameManager updates Representations, besides
asks the GuiManager to show this event on the screen. After the demonstration, new map is
managed by ManageMap with the offerings of GuiManager and restarts this level of game
with the initial map.
**Assume that boat moves approximately 58.2 knot (~30 m/sec) with the north direction
before the wind blows to the east direction with approximately 77.6 knot (~40 m/sec). With
the effect of wind, boat’s new direction and speed should be considered as;
17
4) Sequence diagram of user seeing credits
Figure 7: User opens the Credits Window
Yunus clicks the "BoatDrift.jar" from the desktop. Then main window of the game is
opened. He wonders about programmers of the game. So, he clicks the credits button and
learns some information about programmers.
In this sequence diagram player opens the "BoatDrift" game. Then he wants to learn
about programmers and he chooses "See Credits" option. Thus, the player sends instruction
to the GUIManager to see the credits. GUIManager is related to the PanelControl. After
player sent instruction to the GUIManager, GUIManager transfers this request to the
PanelControl.
PanelControl provides credit window to be visible. Then, PanelControl sends respond
to the GUIManager about visibility of credit window. Finally, GUIManager responds to the
player by showing credits. Thus, player accesses the option "See Credit".
18
5) Sequence diagram of user change settings.
Figure 8: User Changes Settings
19
3.4.3.2 State Diagrams
Boat State Diagram
Our boat is initially in “Sail” state. “Sail” state is the most common state that we can
say that the main character boat is sailing during the 80% of the game relative time. This
sailing state changes when player and boat in 4 different occasions. While sailing if player
loses control, boat hits to the islands and loses one of its lives. Therefore every collision
requires life check. If boat consumes its last life this time game ends. If boat collides with a
buoy this time buoy disappears and due to buoy collecting the total points increase. During
sailing if the player decides to fire cannons to break the bonus boxes this interrupts boats
idle sailing state. If the cannon hits the bonus box and box is cracked than boat will gain the
right to collect bonuses which are turbo, extra life and cannon.
Figure 9: Boat State Diagram
20
Game Map
When “Boat Drift” game begun the boat is in its idle states. The flow of the game is
supplied when the boat starts to collect objects while avoiding colliding with islands and
rocks. The game proceeds if the player collecting our collectible objects like buoys and
bonuses while getting stand to the wind factor. If player can collect all buoys successfully in
the game than the game passes either next level or if the last level is passed game reaches
an end and high score table operations should be held.
Figure 10: Completing the Game
21
3.4.3.3 Activity Diagrams
Activity Diagram 1: Achieving a High Score
This diagram shows whether a player gets into the high score or not. The initial node
shows play game activity, after which the boat crashes a rock or an island. If such a collision
is detected, the game checks whether the player has lives remaining or not; if he does, the
level will be restarted and he will continue playing. If that was the last one; the game will be
over and his points will be compared to the ones in the high score table. If his points are
enough to get into it (more points than the last player in the table), his name will be asked.
Whether he made it into the table or not, the high score table in the main menu will be
opened after that activity.
Figure 11: Getting Into The High Score Table after Game Is Over
22
Activity Diagram 2: Getting a Bonus
This diagram shows the procedure of getting a bonus. The initial pointer shows play
game activity, which is followed by a shot of cannon. If the cannon does not hit a box, the
user will simply continue playing but if does hit, the box will be opened and a random bonus
will appear. There will be three types of bonuses: Turbo, cannon balls and extra life. They
can be collected by the boat and each is followed by different results, as shown in the
diagram.
Figure 12: Boat Collects Bonuses
23
3.4.4 User Interfaces2
Main Screen:
The title “River Draft” stands on the top of the page. There will be a picture of a boat
on the right side of the screen, where the buttons are on the other side. Using this page, the
user can start the game, change settings, see the credits, high scores and information pages
or quit the game by pressing the corresponding buttons.
Figure 13: Main Screen
2
The boat image is taken from http://www.freeimages.co.uk, see the references for the exact URL.
24
Options:
This is the page, where the user can change settings. There is a combo box on the
upper side of the page, where the player can select the color of the button. After each
selection, the picture on the right of the combo box will be updated. The player can also
change the controls (right/left handed) and the difficulty of the game by using the two radio
button groups. There will be a check box for the sound. The player will need to press the
“apply” button for the changes to take place; if he changes his mind and wants the game to
ignore his changes, he will need to press the “Main Menu” button.
Figure 14: Options Window
25
About:
This is the screen where the player can find information about how the game will be
played. The controls, the objects, wind factor and point system will be explained in a text
box on the left side of the page. The user can continue reading by using the scroll bar on the
right side of the text box.
Figure 15: About Window
26
High Scores:
This is the page where the user will see the high score table. After a game is over, the
game will check whether the player has made it into the table or not. If his score is higher
than the last player in the lis, his name will be asked and will be shown in the high score
table. After finishing reading the table, the user will be able to turn back to the main menu
by pressing the button below the table.
Figure 16: High Scores Window
27
Credits:
The format of this page is very similar to the page “About”. There will be a text box
on the left side with a scroll bar on its right side. In the text box there will be information
about us, the developers and our email addresses.
Figure 17: Credits Window
28
Game Screen:
This is the screen, where the player sees while he is playing the game. There will be a
box on the upper right corner of the screen with an arrow, where the arrow represents the
wind. The length and the direction of the arrow will be varied according to the strength and
direction of the wind. The time will be on the upper right corner of the screen and it will be
used while calculating the users points. The cannons of the boat will be shown on the
bottom right corner and the remaining checkpoints can be seen on the bottom left corner.
The green and grey shapes on the map are the islands and rocks. They are
indestructible and if the boat crashes one of them, the player will lose one life. The brown
boxes are collectibles, after they are shot, one of three bonuses will appear. And finally the
red buoys are the checkpoints, which need to be collected in order to finish each map. The
number of the level can be seen on top of the page.
Figure 18: Game Play
29
Game Screen (Paused)
The player can pause the game by pressing the “esc” key on the keyboard. When he
does that, a pop-up menu will appear with four buttons on it. The player can resume the
game, restart the game, return to the main menu or exit the game by pressing the
corresponding buttons.
Figure 19: Game Screen (Paused)
30
4. Conclusion
In conclusion, the analysis report explains basic layout of the whole project. In this
report, it is explained that what kind of game is our project and what it includes. Game
features, differences with the similar games are determined and explained in the analysis
report. We have dealt with different types of diagrams while we were preparing this report.
First of all, we focused on different scenarios and UML (Unified Modeling Language).
First part of UML is the use case diagrams. After that part is done; use case scenarios were
explained. Use case diagram provides us to see generalization of our project. After use case
diagrams, we have dealt with Object, Sequence, State, Domain Analysis and Activity
diagrams and included various mock-ups of the game. They provide us to shape our project
in our minds. We studied with Visual Paradigm and Balsemiq Tools programs while we are
preparing these diagrams and mock-ups.
Analysis report helps us to understand clearly our game. We decided all of futures
that our game "BoatDrift" will include. We had general information about our classes and
how they will work. Also, because it was a team work, we had opportunity to see how
different ideas can exist while we are trying to decide something about our game. As a
result, as thinking in detail on the analysis report we make the following processes easier.
5. References
1) For sailor image
http://www.freeimages.co.uk/galleries/lifestyle/slides/maxi_yacht_sail_9062932.ht
m
2) The required course text book, Object Oriented Software Engineering, Bernd Bruegge,
Allen H. Dutoit
3) Mock-ups are done with Balsamiq Mockup Tool
4) Diagrams are done with Visual Paradigm Tool with academic license key.
5) For further information and documentation please check out our google-codes project
page: http://code.google.com/p/boatdrift/
31