ENTERPRISER
TABLE OF CONTENTS
1. INTRODUCTION .................................................................................................................. 2
2. GAME OVERVIEW .............................................................................................................. 3
3. FUNCTIONAL REQUIREMENTS ...................................................................................... 6
4. SYSTEM MODELS ............................................................................................................... 6
4.1 Use case model ................................................................................................................. 6
4.1.1 Use Case UC1: Define Profile: ................................................................................. 7
4.1.2 Use Case UC2: Change Game Settings: ................................................................... 7
4.1.3 Use Case UC3: Play Game: ...................................................................................... 8
4.2 Dynamic models ............................................................................................................... 9
4.2.1 Define Profile: ........................................................................................................... 9
4.2.2 Change Settings: ...................................................................................................... 11
4.2.4 Attack Enemy: ......................................................................................................... 13
4.2.5 Pick Item: ................................................................................................................ 15
4.2.6 Change Weapon ...................................................................................................... 16
4.3 Activity Diagram ............................................................................................................ 17
4.4 Object and class model ................................................................................................... 18
4.5 User interface - navigational paths and screen mock-ups .............................................. 18
4.5.1 Main Screen ............................................................................................................. 18
4.5.2 Profile Screen .......................................................................................................... 19
4.5.3 Game Screen .......................................................................................................... 19
1. INTRODUCTION
Star-Track is a single player arcade game, where the Enterpriser saves the universe
from the attack of aliens The aim of the players is to fight with the enemies through seven
levels, which take place in space. The player fights with different types of enemies such as
moving enemy, firing enemy or
both. And, users interact with the
game by the help of both mouse
and keyboard.
We have selected this
type of game because the
objective of this project is to
learn and apply principles of
object-oriented approach. In this
game, there will be different
types of enemies and bonuses
according to levels. Additionally,
inheritance
and
association
relations between these objects
become significant. Therefore, it
helps game helps to reach our
Figure 1.1 – Sample Game Screen Shot
aim. Finally, our game is similar
to popular arcade games with small differences and simple cases. For instance our graphical
elements are inspired from famous TV show Star Trek and the main structure is similar to
popular arcade game Crimsonland.
In this report, we’ll briefly explain the requirements, scenarios and other details of the game.
2. GAME OVERVIEW
Star-Track is a space arcade game where the user fights with enemies; collect bonuses
that enemies left when they die. The goal is to save the world in each level by fighting with
enemies and to gain experience by getting items like weapons and bonuses.
At the beginning of the game, users should define a profile for themselves. If they
have created a profile before, they can use their previous nicknames. After logging in the
system, players have the opportunity to change settings of keyboard controls or adjust music
and sound values. To start to play the game, users should select the level among the level list,
which is composed of last played levels. If the player is a new user, then only first level is
available. After all these settings, the game is ready to begin.
The Enterpriser starts the game with full strength and shield amount. Shield is as outer
protection for the character, which prevent any harm to strength of it. During the game, the
Enterpriser fights with enemies and enemies leave random number of bonuses and weapons in
each level. The player flies around by keyboard keys between the enemies to get these
bonuses and weapon. The shield of the Enterpriser changes as the play continues. It decreases
when user fights with enemies. If the effect of the shield finishes, strength starts to get harm.
The hero dies and game restarts if hero doesn’t have any strength left. In contrast to this
situation, if Enterpriser has strength and all aliens are killed, players pass to next level.
Figure 2.1 - Hero - Enterpriser
There are five types of enemy ships; mine type ship, adze ship, battle ship and turret.
(Table 2.1)
Mine Type Ship: This type of non-firing enemy damages the Enterpriser when enemy
hits.
Adze Ship: This type of enemies gives damage by slicing the Enterpriser when it’s
nearby hero.
Battle Ship: This type of enemy moves and fires bullets to damage the Enterpriser.
Turret: Turret type of enemy can perform full revolution during shooting the
Enterpriser. It can’t move around.
Mother Ship: Jed’Hadar is only example of this type. User fights with this enemy at
the end of only the last level.
Name
Speed
Strength
Damage
Vulcan
Kazon
Kremin
Miradorn
Vor’Cha
Negh’Var
Vorth
Jem’Hadar
None
Low
Medium
Low
Medium
Low
None
Low
Medium
Medium
Low
Low
Low
Low
Low
Low
Low
Medium
Medium
Medium
Medium
Medium
Medium
High
High
High
High
Medium
Medium
Very High High
Very High
Table 2.1 Enemy Types Explained
Figure 2.2 – Vulcan
Figure 2.4 – Kremin
Figure 2.6 - Vor’cha
Figure 2.8 - Vorth
Experience Point
Figure
Additional Info
Figure 2.2
Figure 2.3
Figure 2.4
Figure 2.5
Figure 2.6
Figure 2.7
Figure 2.8
Figure 2.9
Mine Type Ship
Mine Type Ship
Adze Ship
Adze Ship
Battle Ship
Battle Ship
Turret
Mother Ship
Figure 2.3 - Kazon
Figure 2.5 – Miradorn
Figure 2.7 - Negh’var
Figure 2.9 - Jem’Hadar
The hero can take 6 different bonuses. These bonuses are called Cloak, Double Bullet, Triple
Bullet, Shield, and Repair and weapon types. The following table gives you the descriptions
of bonuses and their views. (Table 2.2 )
View
Name
Cloak
Description
Cloak bonus hides the hero from enemies and provide
free movement with a time constraint.
Triple Bullet
Triple Bullet bonus allows user to send 3 bullets at a
single fire command.
Double Bullet
Double Bullet bonus allows user to send 2 bullets at a
single fire command.
Repair
Repair bonus increases the strength of the hero.
Shield
Shield bonus is an extra shield that protects hero against
enemy bullets with a time constraint.
Table 2.2 Bonus Types Explained
The hero fires with four types of weapons, which can be stated as phaser, rocket, ion cannon
and photon torpedo. ( Table 2.3 )
View
Name
Phaser
Rocket
Ion Cannon
Photon Torpedo
Description
Phaser is the default gun of the Enterpriser. It fires a
single bullet to attack the enemies.
Rocket type of weapon fires with a delay time.
Has more damage.
Ion Cannon damages and kills enemies by ion shoots.
This ion cannon can damages more than one enemy at the
same time.
It kills the enemies, which are located inside its
explosion region.
Table 2.3 Weapon Types Explained
The player uses both keyboard and mouse to control the enemy because, by mouse, it
determines the direction to fire and by keyboard, it moves and selects the type of guns.
3. FUNCTIONAL REQUIREMENTS







Game maintains a player profile system in order to ensure a resume option for each
player. The player profile system provides one or more profiles for each user. Each
profile is stored by a unique player name in order to store player's game settings,
achieved high scores and successfully completed game levels or chapters. System
offers the list of the existing profiles, creation of a new profile, selection and deletion
of an existing profile.
System provides game settings, which are custom for each player profile. Game
settings determine the in-game experience and options of a player by introducing 3
settings, which are:
-Sound Effects
-Music
-Keyboard/Mouse Controls
Game settings system offers options to enable or disable the sound effects, music, and
an option to customize the direction and fire keys.
The system allows user to have the hero move, aim at the enemies and fire via
keyboard and mouse.
User can choose a number of levels to play presented by the system.
Various weapons and bonuses are dropped by the slaughtered enemies during the
game. User can pick these weapons and bonuses.
User can change his current weapon with one of the weapons she has gathered during
the game.
The system keeps a high score list, where top-scorers of the game are recorded. User
can see this list.
4. SYSTEM MODELS
4.1 Use case model
Figure 4.1.1 Use Case Diagram
The actor of the game is Player. Player can define a player profile, change the game settings,
and play the game. (Figure 4.1.1)
4.1.1 Use Case UC1: Define Profile:
Primary Actor: Player
Success Guarantee: A profile is successfully assigned for Player.
Main Success Scenario:
1. Player starts up the program.
2. A list of existing player profile names is presented to Player.
3. From the list on the screen, Player chooses a player profile name, and submits their
selection to the System.
4. System accepts and processes the player profile in order to play the game.
Extensions:
3a. Player cannot find their player profile name on the list.
1. Player requests a form to create a new player profile.
2. System displays a form, which asks for a unique profile name.
3. Player fills in the form, and submits it to the System.
4. System creates a new player profile.
4.1.2 Use Case UC2: Change Game Settings:
Primary Actor: Player
Success Guarantee: New settings are successfully updated.
Main Success Scenario:
1. Player goes to game settings section.
2. System displays the Player’s settings.
3. Player changes the setting to its new value.
4. System accepts and updates the new settings.
Extensions:
*a. At any time, Player requests cancellation:
1. System restores the previous settings.
3a. The new value for control setting is already assigned to another control:
1. System messages a warning to Player, and asks them to enter an unused value.
2. Player selects an unused control.
4.1.3 Use Case UC3: Play Game:
Level: User Goal
Primary Actor: Player
Preconditions: Player has a player profile
Main success scenario:
1. Player requests to play game.
2. System displays the completed levels and the first uncompleted level
according to their user profile.
3. Player selects a level and submits the level selection.
4. System accepts the selection and starts the game at selected level.
5. Player plays the level.
Player repeats step 5 until no enemy is left.
6. Selected level is completed.
7. System updates Player’s level list.
8. System displays the updated level list.
Player repeats steps 3-8 until they want to quit.
9. System accepts the request, and exits.
Extensions:
*a. At any time, Player requests to quit:
1. System accepts the request and exits.
5a. Player plays level by moving Hero:
1. Player presses one of the direction keys from the keyboard.
2. System handles the key pressed, and moves Hero.
2a. A key other than direction keys is pressed:
1. Hero does not change its position.
2b. The boundaries of the screen is reached:
1. Hero does not change its position.
5b. Player plays level by turning Hero:
1. Player moves the mouse.
2. System receives the mouse movement.
3. System turns Hero according to the direction of the cursor.
5c. Player plays level by attacking to an Enemy:
1. Player presses left button of the mouse.
2. System receives the input that left button of the mouse is pressed.
3. Hero fires its weapon in the direction he is facing.
4. System moves Enemy and the bullets.
5. Bullet hits Enemy.
5a. Enemy escapes from Bullet:
1. Bullet exits the screen.
2. System destroys Bullet.
6. Strength of the Enemy is decreased.
6a. Strength of Enemy is 0 or less:
1. Enemy is killed.
1a. Enemy holds a bonus.
1. Enemy releases its bonus.
2. Hero gains experience depending on the killed enemy type, the
weapon
type, and the bonuses they have.
5d. Player plays level by picking an item:
1. Player presses one of the direction keys from the keyboard.
2. System handles the key pressed.
3. Hero moves towards the item to pick up.
4. Hero gets the item.
4a. Item’s render time expires:
1. System removes the item.
5. Hero gains an extra feature depending on the item type.
5e. Player plays by changing weapon:
1. Player presses a number key from the keyboard.
2. System determines which weapon to give.
3. Hero receives the new weapon.
3a. Player does not have the specified weapon.
1. System displays a warning message.
2. Hero does not receive new weapon.
4.2 Dynamic models
4.2.1 Define Profile:
Scenario 1: The player is Hakan, who does not currently have a profile. He enters the system,
requests user list. The system returns a list that show existing profiles on the system. Hakan’s
name does not appear on the list, hence he requests a new user form to create his own profile.
System presents a user form, which asks a name only for new profile. Hakan fills in a
nickname and submits The system creates a new user profile with the name Hakan provides.
This sequence diagram corresponds to scenario 1.
Figure 4.2.1.1 Define Profile Sequence Diagram
GUI Manager is basically an abstraction for user interface layer of the system. It
receives user requests and relays them to underlying layers of the system that are responsible
for handling requests, and represents the external view of the system to the user. Player’s
interaction with the system is managed by GUI Manager.
GUI Manager itself does not itself know what it is supposed to display. This
information is supplied by the components beneath the UI level, such as by User Manager in
Sequence Diagram . ( Figure 4.2.1.1 )
User Manager is a placeholder for player profiles. A player profile has a name and also
contains information such as how many levels has been completed successfully or how much
point has been gained by the player associated with that particular profile. User Manager, can
update user profiles, can add new user profiles, and can delete an existing user profile.
User Manager gives user list to GUI Manager to display on the screen. User list is
collection of names of all profiles in User Manager.
New User Form is considered as a GUI component, which asks player a name for the
profile that will belong to them.
4.2.2 Change Settings:
Scenario 2: The player is Yasemin, who is not very happy with current game settings.
She asks the system to display current settings. Yasemin assigns fire button to control key on
the settings window. Then, Settings Manager updates key – button association list.
This sequence diagram corresponds to scenario 2.
For explanation of GUI Manager, see Define Profile.
Settings Manager, keeps information on game settings such as volume or control
settings. There is one common setting configuration for all user profiles. ( Figure 4.2.2.1 )
Settings Manager gives current settings to GUI Manager to display. Current settings
involve information on what values volume and control are set to.
4.2.3 Select Level and Begin Game:
Scenario 3:The player is Osman. Osman has played up to fifth level before. After he
has selected his profile, he starts game. System lists him the levels he can play, levels 1
through 5 in this case. Osman selects level 3.
Then game begins at level 3 .
This sequence diagrams corresponds to scenario 3.
Figure 4.2.3.1 Select Level & Begin Game Sequence Diagram
User Manager keeps the last level number played for each user profile. User Manager
gives the list of these levels to GUI Manager, actually itself requesting this list from Level
Manager. GUI Manager does not pass parameter Osman along the message getUsersLevelList
because User Manager knows who the current player is once the player passes define
profile/user profile step. ( Figure 4.2.3.1 )
Level Manager holds all information concerning levels. These include the map where
a particular level takes place, which enemies appear at what time and at which location and
also which enemies should drop bonus when they die.
After Osman selects Level 3, Game Engine is supposed to start the game. It needs to
know which level it should start at and for which profile this game should be associated with.
Game Engine receives this information from Level Manager and User Manager respectively.
4.2.4 Attack Enemy:
Scenario 4:The player is Yasemin. Yasemin left clicks the mouse to fire at an enemy.
A bullet is created on the screen at the tip of the current weapon. Bullet moves until it hits the
enemy. Bullet kills the enemy. Enemy drops a bonus. Hero gains experience accordingly.
This sequence diagram corresponds to scenario 4.
Figure 4.2.4.1 Attack Sequence Diagram
Hero keeps a reference to the weapon it currently uses, which is why it directly
addresses to the weapon to fire rather than through Weapon Manager. Weapon creates a bullet
in the game, which is added to Game Engine. ( Figure 4.2.4.1 )
Weapon generates a particular type of bullet depending on its type. Each weapon
keeps track of the number of bullets it currently has. See Game Description
Enemy is the object that Hero is supposed to kill. Each enemy can have a bonus. Game
Engine assigns bonuses to enemies according to level information provided by Level
Manager. A new bonus in not created because beforehand it is known to Game Engine exactly
which bonuses will appear. Therefore, Game Engine has already created bonuses but lets
them be visible after they are released.
4.2.5 Pick Item:
Scenario 5: The player is Yasemin. In the game, a weapon bonus has been released
just above Hero. Yasemin, presses up key. Hero moves up and obtains the weapon. System
activates the weapon, which allows Yasemin to change Hero’s weapon to this weapon when
Hero is using another weapon currently.
This sequence diagram corresponds to scenario 5.
Figure 4.2.5.1 Pick Item Sequence Diagram
Collision Detection Manager represents the system component that is responsible for
detection of collision of the entities in the game and reports the collisions back to Game
Engine including information on the types of entities that have collided. Game Engine takes
necessary action as a consequence of what Collision Detection Manager’s report states. (
Figure 4.2.5.1 )
See Weapon Manager for Game Engine
See Change Weapon for Weapon Manager.
4.2.6 Change Weapon
Scenario 6: The player is Yasemin. The hero currently has weapon #1. Hero has the
weapon #2 available in weapon inventory. Yasemin presses key 3. System changes the
current weapon (weapon #1) of hero to the weapon #3.
This sequence diagram corresponds to scenario 6.
Figure 4.2.6.1 Change Weapon Sequence Diagram
Game Engine maintains the information necessary to run the game. Game Engine
keeps the entities that have roles in the game such as Hero, Enemies, information about
current level etc and supervises the interaction between these entities in the game. It also
undertakes responsibility of listening to keyboard and mouse events through which player
specifies the action that Hero is supposed to take. ( Figure 4.2.6.1 )
Weapon Manager is where all weapons are kept. Weapon Manager marks the weapons
that are available to Hero (see Game Description to see when weapons become available) .
Hero represents the ship that player controls. Hero has a reference to exactly one of the
weapons in Weapon Manager, which is the weapon that is currently used. When player
changes their weapon, weapon reference within Hero is set to another marked (available)
weapon of Weapon Manager.
4.3 Activity Diagram
Figure 4.2.6.1 Activity Diagram
4.4 Object and class model
Figure 4.4.1 Object Diagram
4.5 User interface - navigational paths and screen mock-ups
4.5.1 Main Screen
The main screen where menu items are displayed :
-Change Profile : Button for the user to change their profiles
-Play Game : Button for the user to start the game
-High Score : Button for the user to display the highest scores.
-Change Settings: Button for the user to display and change the settings.
-Quit Game : Button for the user to exit the game.
4.5.2 Profile Screen
Profile Screen is the screen where user views the currently created
profiles and creates a new one according to their will. On the left of the screen
a list will be displayed containing previously created users. On the right bottom
a "Create New Profile" button will be located, for defining new profile. (Figure
4.5.2.1)
Figure 4.5.2.1 Profile Screen Sample
4.5.3 Game Screen
Game Screen is the screen is which the game is played. On the upper
side game actions by the hero, enemy, bullets will be shown. On the lower side
the hero’s properties - such as strength, shield, etc. - , weapons, experience
points will be displayed in order to inform the user. (Figure 4.5.3.1)
Figure 4.5.3.1 Game Screen Sample