Aero Strike

AeroStrike
1
Contents
1. FINAL PROJECT DOCUMENTATION ............................................................................... 4
2. Project Proposal ....................................................................................................................... 5
PROBLEM STATEMENT......................................................................................................... 5
EXECUTIVE SUMMARY ........................................................................................................ 5
INTRODUCTION ...................................................................................................................... 6
COMPETITORS/COMPETITIVE ANALYSIS ........................................................................ 6
OBJECTIVES ............................................................................................................................. 6
MOTIVATION ........................................................................................................................... 6
REQUIREMENTS ..................................................................................................................... 7
FEATURES OF PROJECT ........................................................................................................ 7
ARCHITECTURAL DESIGN ................................................................................................... 8
IMPLEMENTATION TOOLS AND TECHNIQUES ............................................................... 8
PROJECT PLAN ........................................................................................................................ 9
VERSION CONTROL ............................................................................................................... 9
REFERENCES ......................................................................................................................... 10
Final year project Documentation .................................................................................................... 12
3. Chapter1: Introduction to the Problem .................................................................................. 12
Introduction .............................................................................................................................. 12
Purpose ..................................................................................................................................... 12
Objective ................................................................................................................................... 12
Existing Solution ...................................................................................................................... 13
Proposed Solution..................................................................................................................... 13
4. Chapter2: Software Requirement Specification .................................................................... 14
4.1 Introduction .................................................................................................................... 14
4.2 Overall description ......................................................................................................... 16
4.3 Specific requirements ..................................................................................................... 19
5. Chapter3: Use Case Analysis ................................................................................................ 22
Use Case Diagram OF User Flow ............................................................................................ 22
Use Case Scenario’s ................................................................................................................. 23
6. Chapter4: Design ................................................................................................................... 33
Architectural Diagram .............................................................................................................. 33
ERD with data dictionary ......................................................................................................... 34
Data Flow diagram ................................................................................................................... 35
Page 2
Class Diagram........................................................................................................................... 37
Activity Diagram ...................................................................................................................... 38
Sequence Diagram .................................................................................................................... 39
Collaboration Diagram ............................................................................................................. 40
State Transition Diagram .......................................................................................................... 41
Deployment Diagram ............................................................................................................... 42
7. Chapter5: Testing .................................................................................................................. 43
7.1 Test Case Specifications................................................................................................. 43
7.2 Black Box Test Cases..................................................................................................... 70
Use Case Testing ...................................................................................................................... 76
7.3 White Box Test Cases .................................................................................................... 76
7.4 Performance testing ........................................................................................................ 76
7.5 Stress Testing ................................................................................................................. 76
7.6 System Testing ............................................................................................................... 77
7.7 Regression Testing ......................................................................................................... 77
8. Chapter6: Tools and Techniques ........................................................................................... 78
8.1 Tools: .............................................................................................................................. 79
8.2 Techniques ..................................................................................................................... 80
9. Chapter7: Summary and Conclusion ..................................................................................... 81
9.1 Summery ........................................................................................................................ 81
9.2 Conclusion ...................................................................................................................... 82
10. Chapter8: User Manual.......................................................................................................... 83
10.1 How to Change and Save Skin: .................................................................................. 83
10.2 How to Select Stage and Play: .................................................................................... 88
10.3 How to Move the Helicopter: ..................................................................................... 90
10.4 How to Fire: ................................................................................................................ 91
10.5 How to Pick Ammo: ................................................................................................... 92
10.6 How to Pick Health: ................................................................................................... 93
10.7 How to Pause Game: .................................................................................................. 94
10.8 To Resume: ................................................................................................................. 95
10.9 To Go on Main Menu: ................................................................................................ 95
10.10 To Quit Game: ............................................................................................................ 96
Page 3
1. FINAL PROJECT DOCUMENTATION
Final Year Projects (FYP) in Department of Computer Science, the university of Lahore are
considered as group projects mandatory for every student in order to complete their
Bachelor/Masters programs
Here are some important points to be considered
 All students (BSCS, BSSE, MCS/MIT) who enroll in final year project spring 2017 (Phase
1) are required to submit their proposal latest by February 15, 2017
 All students sire required to make group in their respective program only, BSCS students
are not allowed to make group with BSSE students and vice versa
 Students are required to submit their transcript along with their project proposal to Mr.
Soban Mamoon in admin office between 2pm-3pm till February 15, 2017
 No student having less than 97 credit hours is allowed to enroll final year project.
 No student with probation is allowed to enroll final year project
 Checklist for Proposal submission
1) Project Proposal
2) Allocation form
3) Volunteer form
4) Transcripts of each group member
Some of the pre-requisite which all students which are enrolling have studded in earlier semesters
 Introduction to Database
 Core-subjects of programming including Object Oriented Programming
 Web Engineering
 Java Software Development Paradigm
 Mobile application development
Page 4
2. Project Proposal
Write down the brief project topic and should not be confusing.
PROJECT
AeroStrike
TITLE:
PROBLEM STATEMENT
Now-a-days people love to play action games that involve attacking and survival tactics. But most
of the games lack innovation. Therefore we are developing a game that involves attacking, survival
and scenario based tactics by completing the objectives by destroying the enemy radar system that
is guarded by enemy auto cannons. This is an innovative idea and slightly different from rest of the
war games.
EXECUTIVE SUMMARY
Basic action/war game with a slight twist i.e. the player will provide air support via helicopters by
completing the objective that is destroying all the enemy radar system which is guarded by enemy
auto-cannons and the play use tactics to avoid enemy auto-cannons attacks.
Page 5
INTRODUCTION
The basic plot of this game (AeroStrike) involves a helicopter that is airborne above enemy
territory. The area is consists on multiple enemy bases which consists on a radar truck guarded by
enemy auto-cannons. The player is supposed to complete the objective by destroying all radar
trucks that will interrupt with communication system of enemy bases. The player also has to avoid
the enemy attacks that are coming from auto-cannons guarding the radar truck on the ground while
destroying the radar system of every base.
COMPETITORS/COMPETITIVE ANALYSIS
 Gunship Strike 3D
 Navy Gunner Helicopter
 Helicopter War: Enemy Base
 GUNSHIP BATTLE: Helicopter 3D
These are some of the competitors that are related to our project.
OBJECTIVES
Our objective is to create a single player gaming experience for war game lovers that they can
enjoy and play game. The main object of this project is we can make something different and
amazing for Entertaining people.
The key objectives are :

I. To provide easy access to the players.
II. Free on Play Stores.
III. Enhance user skills for playing war games.
MOTIVATION
Our idea is interesting because of its vast modes, high-end attractive graphics and easy game
play.
Page 6
REQUIREMENTS
 Download the game then install it.

 Run the game.
 Start the game.
 Play the game
 Move the helicopter
 Fire on enemies radar
 Destroy the radar
 Go on next base
 Clear the stage
 Move to next stage
 End the game.
FEATURES OF PROJECT
 Enjoy controls optimized for 3D flight.

 Change the colors of you helicopter.
 Complete missions in Episode mode inspired by real-life conflicts.
 Challenge yourself with the next mission.
 Destroy the objective and find the next one.
Page 7
ARCHITECTURAL DESIGN
IMPLEMENTATION TOOLS AND TECHNIQUES
 We are using Unity-2017-1.0f3 for coding and Google Sketchup Pro-v8.0.14346 for
graphics and for physical characters.
 3DS modeling.
 For converting the game on Android we will be using Android SDK.
Page 8
PROJECT PLAN
VERSION CONTROL
A table that will provide information of each time proposal was updated.
None at this stage.
Page 9
REFERENCES
Give references to the resources you have consulted in finalizing your project topic.
https://docs.unity3d.com/410/Documentation/ScriptReference/index.Accessing_Oth
er_Game_Objects.html
https://unity3d.com/learn/tutorials/topics/scripting/getcomponent
https://unity3d.com/learn/tutorials/s/scripting
https://docs.unity3d.com/560/Documentation/Manual/Namespaces.htm
https://www.youtube.com/watch?v=0fGB2H1AGP8&t=61s
https://www.youtube.com/watch?v=vGkdNlpYgzs&t=92s
https://www.youtube.com/watch?v=DyJ8S_859n0
https://www.youtube.com/watch?v=177SBoXb-24
(To be filled by students)

PROJECT
AeroStrike
TITLE:
STUDENT INFORMATION
Write down the detail of all group members in BLOCK LETTERS ONLY.
Sr. Student ID Name Email Mobile
Muhammad Ghalib 0322-4282707
1. BCS-02143047 ghalib.sid@gmail.com
Siddiqui
Muhammad Ammad 0336-4310672
2. BCS-02133259 depp803@gmail.com
Aslam
Page
10
Abstract
Basic action/war game with a slight twist i.e. the player will provide air support via helicopters by
destroying enemy radar system and also use tactics to avoid enemy attacks.
Contributions
Our idea is interesting because of its vast modes, high-end graphics and easy game play.
…………………………..DO NOT WRITE BELOW THIS LINE……………………………

FYP Proposal Evaluation
FOR OFFICE USE ONLY

Remarks: Accepted Accepted with Minor changes Rejected
Suggested Improvements (if any):

____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
Page
11
____________________________________________________________________________
____________________________________________________________________________
Reviewed By:
________________________________________________________
Name:
Final year project Documentation
3. Chapter1: Introduction to the Problem
Introduction
Today one of the biggest markets in mobile app industry is the gaming market. People all over the
world of different ages download or purchase games in their mobiles to pass the time or amuse
themselves. It is ever growing market with new addition to it on daily basis. Developers are trying
to make games specially focus on real life situation because there is great demand of it. People love
to play those games which they can play in short break and then can continue their work.
Our project is to make a real-life situation 3D game. This game will be a new addition to gaming
industry in android market. Our main goal is to make a game which is faster to load and provide
good graphics and great sound effects. And it will do all of that without slowing the mobile down
or taking all of the memory of the mobile.
This game will include different levels, each level having its own difficulty. So, this game will not
only be a same stage every different level, a player can play a stage again and again to improve his
aiming skills.
Purpose
Our main purpose is to eliminate the extra load and space the games takes and make a game which
once downloaded can be played as long as a user wants. It will not have any time limit to play and
does not require user to connect to the internet to earn more time to play.
The purpose is to make a game which takes less time to load, consume little amount of battery and
also provides independency from the need of connection of the internet all the time. Due to
different difficulty level on different stage it will provide the user to play each level better than
before to unlock the new level so it will have an addictive element to it.
Objective
Our objective is to develop and launch our work at international level and help us starting our
career in game development because gaming society is increasing rapidly every person is playing
game to kill their free time or to get entertain. It’s also a best start for our future career.
Our final year project is hoped to develop a game that should be interesting for user.
Page
12
Existing Solution
When we searched the internet, there are lots of games based on the idea of daily life situations but
all of them either don’t have good quality graphics or uses so much RAM that it slows the mobile
down. Also, most of the requires you to connect to the internet to unlock things like extra life to
play the game or a friend help to get extra time which is very frustrating as it bounds the user to
play whenever he wants. So, there are games made on this concept but majority of them have their
flaws. There are many types of survival game are available in the market about every technology
platform and lots of games are played by the people. The well-known games are following;
 Gunship Strike 3D
 Navy Gunner Helicopter
 Helicopter War: Enemy Base
 GUNSHIP BATTLE: Helicopter 3D
Proposed Solution
Our proposed game will have fewer loads on the device while having a modern day standard
graphics. Also, it will not require internet connection all the time or any friends help to play the
game. It will keep the interest of the user and due to different levels the user will play each level
again and again to improve his aiming skills. Each stage will have different difficulty level. It has
good graphics and good sound effects. It does not have extra goals in the game and it is not more
time consuming. It is more entertaining than others it does not cause irritation.
Page
13
4. Chapter2: Software Requirement Specification
4.1 Introduction
“A Software Requirement Specifications is a description of software system to be developed. It
lays out functional and non-functional requirements, and may include a set of use cases that
describes user interactions that the software must provide”.
Purpose
This subsection should
1. Faster loading time.
2. Less battery consumption.
3. Excellent 3d graphics.
4. Independence from the requirement of internet connection all the time.
5. Free of all the spam’s and ads.
Scope
The “AeroStrike” will be the game which has solid graphics with sound effects to
enhance the environment of the game. The user can play the game directly after installing
the game. When user completes a level he can play that level again to improve his aiming
or go to next stage which has more difficulties.
Definitions Acronyms and Abbreviations
Definitions: a statement of the exact meaning of some words which are used in
the document.
Acronyms and Abbreviations:
Acronyms Abbreviations
3D Three Dimensions
PC Personal Computer
SRS Software Requirement

Specifications
Page
14
References
https://docs.unity3d.com/410/Documentation/ScriptReference/index.Accessing_Oth
er_Game_Objects.html
https://unity3d.com/learn/tutorials/topics/scripting/getcomponent
https://unity3d.com/learn/tutorials/s/scripting
https://docs.unity3d.com/560/Documentation/Manual/Namespaces.htm
https://www.youtube.com/watch?v=0fGB2H1AGP8&t=61s
https://www.youtube.com/watch?v=vGkdNlpYgzs&t=92s
https://www.youtube.com/watch?v=DyJ8S_859n0
Overview
This document contains the general information about the whole game project that includes
software and hardware interfaces, functional and non-functional requirements, objectives, working
of the game and data requirements. It also describes us game plan and tool and language that we
are using while developing the game. This SRS also describes the general factor which affects our
project and its requirements.
Page
15
4.2 Overall description
4.2.1 Project perspective

AeroStrike is a 3D war game in which the player provides air support via helicopter by destroying
enemy radar system guarded by auto-cannons and also uses tactics to avoid enemy attacks while
destroying enemy radar system. There are a lot of games like this in the market and a lot of work
done on such kinds of games. But AeroStrike is better than infinite running, collecting Score and
like other un-end able games. It has a specific goal and after accomplishing a goal a player can go
to the next level to continue the mission. The game which we are building involves a helicopter
that is airborne above enemy territory. The area is consists on multiple enemy bases which consists
on a radar truck guarded by enemy auto cannons. The player is supposed to destroy that radar truck
so that enemy can’t communicate with other bases. The helicopter also has to prevent the enemy
attacks that are coming from the auto-cannons guarding the radar truck on the ground while
destroying the radar system of every base. The game is independent from internet it doesn’t require
the user to connect to the internet all the time. User just has to download it first time then he can
play it directly without need of internet.
 System interfaces There are two interfaces used in AeroStrike written below;
 Player Interface for playing game and user inputs while running game like move
left, right, change height, fire etc.
 Game Handler Interface to handle a game logic like AI, to manage resources like
3D Models and Environment and Outputs like sound and graphics.
 User interfaces AeroStrike provides two types of interface for user;
 1st for main menu to perform different operations like play, settings and exit.
 2nd for where player plays game
The user interface is quite simple. We made it simple so person of any age can easily
play it. When you start the game the welcome screen will come up. It will contain the
option Play the game. When user touches on Play Game it will show different stages
and user can select the level user can change color of helicopter.
Page
16
 Hardware interfaces
Hardware wise user must have the following specifications to play the game:
Processor Minimum Octa-Core
Space 70MB
RAM Minimum 2 GB
 Software interfaces
Operating System Android

Programming Language C#
Database Unity’s Player preferences
 Communications interfaces (This should specify the various interfaces to

communications such also call network protocols etc.)
 Memory The memory constraints required to run this game on Android is;
 2 GB RAM
 100 MBR
Page
17
4.2.2 Product functions
Basic functions in the early version of the game;
 3D Character
o Helicopter
o Enemy Auto Cannons
o Enemy Radar Truck
 For now, it has only Five level and may be more
o First stage is training stage. It will help the player to understand the controls and player can
practice his aiming and movement.
o Second stage is where player can test his training by completing the objectives.
o Third stage in which difficulty level will increase with a new entity an Anti-Aircraft which will
also guarding the Radar Truck and take more damage than Auto-Cannon.
o In fourth stage player can change the height of the helicopter to avoid hills and mountains.
o In fifth stage there will be only one objective that is guarded by a lot of Auto-Cannons and
Anti-Aircraft and the Radar Truck will be protected by a force field. So it will be difficult to
destroy the Radar that’s why player has to play with tactics by managing Health and
Ammunition of the helicopter.
o And each level must be completed before the player power level reaches to zero.
 To complete the level
 Player must destroy all the Enemy Radar trucks present in the environment.
 The power level of player and also the number of ammunition of weapon remaining will be
showing on the screen.
 Game will be controlled by touchpad.
 High quality graphics.
 The game will have music and sound effects on different actions destroying an object, firing or
wining or loosing etc.
4.2.3 User characteristics

User has basic knowledge about the game. In this game no experience requires to play the game.
4.2.4 Constraints
Given items and description might alter the designing and implementation of the game;
 Deployment Issues
 Integration Issues
 Hardware Limitations
Page
18
4.3 Specific requirements
This section will describe the functional and non-functional requirements of System at a sufficient
level of detail for the designers to design a system satisfying the User requirements and testes to verify
that the system satisfies the requirements.
4.3.1 Functional Requirement

Functional requirements of this game are below:
 Start Game
Identifier Chart-1
Purpose Starts the game
 Main Menu
Identifier Chart-2
Purpose Contains options of Quit, Play, Settings
 Go to Settings
Identifier Chart-3
Purpose Selects the setting option
 Helicopter Colors
Identifier Chart-4
Purpose Selects the helicopter Skin
 Level Selection
Identifier Chart-5
Purpose Chooses the Level
 Go on Back Page
Identifier Chart-6
Purpose Goes on previous page.
 Helicopter Moves Left
Identifier Chart-7
Purpose Helicopter will move in left direction.
Page
19
 Helicopter fired
Identifier Chart-08
Purpose Weapon shooting the enemy
 Helicopter fires stopped
Identifier Chart-9
Purpose Weapon will stop.
 Auto Cannon fires
Identifier Chart-10
Purpose Auto Cannon will fire if helicopter is in the range
 Auto-Cannon fires stopped
Identifier Chart-11
Purpose Auto Cannon will not fire if helicopter is not in the range
 Pause
Identifier Chart-12
Purpose Opens the pause menu
 Pause Menu (Exit)
Identifier Chart-13
Purpose Exits game to main menu screen
 Resume Game
Identifier Chart-14
Purpose Game resume
 Quit Game
Identifier Chart-15
Purpose Game Quit
Page
20
4.3.2 Non-functional Requirements
Non-functional requirements are given below.
 Usability
The system interface is user friendly and user can easily use it and should facilitate the user using the
system suitability .The interface component should be clear.
 Reliability
 Data not damaged.
 Restore itself after a failure
 Performance
To make the best performance of this game;

 The game will require internet to download it from the store. Or it can be
installed using APK package in around 1 or 2 minutes (depends on the
processors speed).
 After installing it will take few seconds to run the game.
 Single player play the game
 Single player entity is managed
 Design Constraints
Given detail might change while designing and implementing the game.
Deployment Issues:
 Constraint on resource available to host the game (H/W Limitation)
 Minimum memory required : 2 GB
 Space Required 100 MB
 Portability
 80% of code is independent of the software product operating
environment
 Develop in unity with C#
 Maintainability
The game will be designed without any bugs so it will not need any maintainability.
Page
21
5. Chapter3: Use Case Analysis
Use Case Diagram OF User Flow
Page
22
Use Case Scenario’s
Use Case ID: 1
Setting
Actor
Setting
Name Setting
Description Player can customize the helicopter Skin
Primary Actor Player
Pre-Condition Game must be running and the player must be in the
main menu
Post-Condition Color of both rotors and body will be shown on the
screen
Basic Flow As the player touch on the setting option it will move to
the color selection window
Alternative Flow No alternative flow
Use Case ID: 2
Choose
skin
Actor
Choose Skin
Name Chose Skin
Description To choose the skin for helicopter.
Pre-Condition Player must be at Setting Menu.
Post-Condition Player will choose which part needs to change its
color
Basic Flow Player will choose the part which he wants to
change its color.
Page
23
Use Case ID: 3
Upper
Rotor
Actor
Upper Rotor
Name Upper Rotor
Description To change the color of upper rotor
Post-Condition Player choose the color for upper rotor
Basic Flow Player will select the following colors for upper
rotor
Use Case ID: 4
Lower
Rotor
Actor
Lower Rotor
Name Lower Rotor
Description To change the color of lower rotor
Post-Condition Player choose the color for lower rotor
Basic Flow Player will select the following colors for lower
rotor
Page
24
Use Case ID: 5
Body
Actor
Body
Name Body
Description To change the color of body
Post-Condition Player choose the color for body
Basic Flow Player will select the following colors for body
Use Case ID: 6
Start
Actor
Play the Game
Name Start
Description A separate procedure is available for the visitors to
register on the site.
Pre-Condition Game must be running and the player must be in the
main menu
Post-Condition It shows the mode selection window with mode
selection options.
Basic Flow As the player selects the play option it should load the
game and also load the custom (if player changes
helicopter skin) or default settings.
Page
25
Use Case ID: 7
Select
Level
Actor
Select the Level
Name Select Level
Description Player can select stages of the game.
Basic Flow After the selection of level the game scene will be
shown depending upon the selected level.
Pre-Condition User have pressed Play button available at Main
Menu.
Post Condition Game will be started according the level.
Alternative Flow If player is a beginner then default stage (1st stage) will
be run.
Use Case ID: 8
Game
Starts
Actor
Game will load the stage
Name Game Start
Description Game will load
Primary Actor player
Basic Flow Game will load and take a few seconds
Pre-Condition Player should chose start button
Post Condition Game will load and player can play the game
Alternative Flow No alternative flow.
Page
26
Use Case ID: 9
Enemy
Actor
Enemy
Name Enemy
Description Enemy consists on Auto Cannons and Radar truck
located randomly on map
Pre-Condition Player is in range
Post-Condition It will fire the helicopter
Basic Flow If player is in the range it will fire on it
Use Case ID: 10
Radar
Actor
Radar
Name Radar
Description Radar is the main object of this game guarded by auto
cannons
Pre-Condition Player should be in Range
Post-Condition Radar Destroyed
Basic Flow Player have to locate the Radar and destroy it
Page
27
Use Case ID: 11
Auto
Cannon
Actor
Auto Cannon
Name Auto Cannon
Description Auto cannon Fires
Pre-Condition Player should be in range of auto cannons
Post-Condition Players health decrease if got hit
Basic Flow Auto cannon should fire is player is in range
Use Case ID: 12
Helicopter
Actor
Helicopter
Name Helicopter
Description Control by player to complete the objective
Pre-Condition Game should be Start
Post-Condition Should complete the objective
Basic Flow Player have to locate the Radar and destroy it
Page
28
Use Case ID: 13
Movement
Actor
Movement
Name Movement
Description To change the position of helicopter by using joystick
on screen
Pre-Condition Slide the thumb to dodge the missiles or to be
somewhere
Post-Condition The helicopter will move.
Basic Flow Slide the thumb to turn left, right or forward.
Use Case ID: 14
Aim and Fire

Actor
Aim and Fire
Name Aim and Fire
Description Move the helicopter by aiming the enemy and fire.
Pre-Condition Player must move the helicopter (the aiming cursor) on
the enemy and press the fire button.
Post-Condition If the missile hit the target it will blast
Basic Flow Player must move the helicopter (the aiming cursor) on
the enemy and press the fire button so that the missile
can hit it.
Page
29
Use Case ID: 15
Helicopter
got hit
Actor
Damage
Name Helicopter got hit
Description Enemy missiles hit the player (helicopter) and
decreases it health.
Pre-Condition Enemy missiles hit the helicopter
Post-Condition Health decrease
Basic Flow If the enemy missiles hit the helicopter then the damage
increase and when the health is zero then player lose.
Use Case ID: 16
Collect
Actor
Collect
Name Collect
Description If the player is on low health or low ammunition it can
collect health or ammunition placed randomly on the
map.
Pre-Condition Player must Locate the health or ammunition
Post-Condition Player collect the Goods
Basic Flow When the player need ammunition or heath it can search
for it and collect it.
Alternative Flow None
Page
30
Use Case ID: 17
Health
Actor
Health
Name Health
Description If the player collect the health the health will go
maximum
Pre-Condition Player must search for the health
Post-Condition Health will be maximum
Basic Flow When Player collect the health it will be increase to
maximum
Alternative Flow None
Use Case ID: 18
Ammunition
Actor
Ammunition
Name Ammunition
Description If the player collect the ammunition, it will go
maximum
Pre-Condition Player must search for the ammunition
Post-Condition Ammunition will be maximum
Basic Flow When Player collect the ammunition it will be increase
to maximum
Page
31
Use Case ID: 19
Exit
Actor
Exit
Name Exit
Description To leave the game window or to quit the game, player
must touch on the exit icon on main menu.
Pre-Condition Player must be at Main Menu.
Post-Condition Game will be Exited
Basic Flow Player will be out of the game window.
Page
32
6. Chapter4: Design
Architectural Diagram
Page
33
ERD with data dictionary
Entity Relationship Diagram with complete relations with dependencies of the project
Page
34
Data Flow diagram
Data flow diagram includes two levels
 The level 0
The flow of information inside the system is defined in this level
Page
35
 The level 1
The flow of information outside the system is defined in this level
Page
36
Class Diagram
Describe the structure of a project by showing the systems classes, their attributes, operations (or
methods), and the relation.
Page
37
Activity Diagram
This diagram includes all the activity diagrams of the functional requirements of our project
along with the aggregate deactivated diagram
Figure1 Activity Diagram Create Account
Page
38
Sequence Diagram
 Starting of Game
 Objectives
Figure1 Sequence Diagram Create Account
Page
39
Collaboration Diagram
It shows the object organizations shown below. Here in collaboration diagram the method call
sequence is indicated by some numbering technique as shown below. The number indicates how
the methods are called one after another. We have taken the same order management system to
describe the collaboration diagram.
Page
40
State Transition Diagram
State Transition diagram is used to describe the states of different objects in its lifecycle. So the
emphasis is given on the state changes upon some internal or external events. These states of
objects are important to analyze and implement them accurately
Page
41
Deployment Diagram
Page
42
7. Chapter5: Testing
“Software testing is a process of executing a program or application with the intent of finding the
software bugs. It can also be stated as the process of validating and verifying that a software
program or application or product: Meets the business and technical requirements that guided its
design and development.”
7.1 Test Case Specifications

Test case specification of this game is described below;
Start:
Test Case
Test Case ID TC_1
Description Start the game
Purpose To check whether the game start or not
Pre-Condition Player must touch on the game logo
Input Criteria Touch
Expected Game must load and show the main menu
Result
Status Tested, Passed
Remarks Done
Page
43
Setting:
Test Case
Test Case ID TC_02
Description Touch the Setting Button
Purpose To check whether it load the Setting Window
Pre-Condition Game must be at Main Menu
Expected Load the Setting Window
Result
Remarks Done
Page
44
Skin:
Test Case
Test Case ID TC_03
Description Touch the Skin to select
Purpose To check whether it load the Skin in both rotor and body or not
Pre-Condition Game must be at Setting Menu
Expected Load the Skin color
Result
Remarks Done
Page
45
Upper Rotor Skin:
Test Case
Test Case ID TC_04
Purpose To check whether it load the Skin of upper rotor or not
Result
Remarks Done
Page
46
Lower Rotor Skin:
Test Case
Test Case ID TC_05
Purpose To check whether it load the Skin of lower rotor or not
Result
Remarks Done
Page
47
Body Skin:
Test Case
Test Case ID TC_06
Purpose To check whether it load the Skin of body or not
Result
Remarks Done
Page
48
Save the Settings:
Test Case
Test Case ID TC_07
Description Touch the Back Button
Purpose To check whether it saves the skins and go back to the main menu or not
Expected Save skin and go back to main menu
Result
Remarks Done
Page
49
Play:
Test Case
Test Case ID TC_08
Description Touch the Play Button
Purpose To check whether it load the game stage screen or not
Pre-Condition Game must be at Main Menu
Expected Load the Stage Screen
Result
Remarks Done
Page
50
Selection Stage:
Test Case
Test Case ID TC_09
Description Touch the Stage Button
Purpose To check whether it load the game Stage scene or not
Pre-Condition Game must be at Selection Stage Menu
Expected Load the selected game stage
Result
Remarks Done
Page
51
Turn In Left Direction:
Test Case
Test Case ID TC_10
Description Player can turn in left direction of the scene window
Purpose To check whether it is moving correctly or not
Pre-Condition Game must be in play mode
Input Criteria Move the joystick left which is on right bottom on mobile screen
Expected Player will turn left
Result
Remarks Done
Page
52
Turn In Right Direction:
Test Case
Test Case ID TC_11
Description Player can turn in right direction of the scene window
Input Criteria Move the joystick right which is on right bottom on mobile screen
Expected Player will turn right
Result
Remarks Done
Page
53
Move Straight:
Test Case
Test Case ID TC_12
Description Player can move straight on the scene window
Input Criteria Move joystick straight which is on right bottom on mobile screen
Expected Player will move straight
Result
Remarks Done
Page
54
Pause:
Test Case
Test Case ID TC_013
Description Pause the game to take break
Purpose To check whether it stop the game
Input Criteria Touch the Pause Button
Expected Game will Pause
Result
Remarks Done
Page
55
Resume Game:
Test Case
Test Case ID TC_14
Description Un-pause the game and start where you left
Purpose To check whether the game start from you left or not
Pre-Condition Game must be pause
Input Criteria Touch on Resume
Expected Game should start where you left
Result
Remarks Done
Page
56
Go back to Main Menu:
Test Case
Test Case ID TC_15
Description Go back to main menu
Purpose To check whether it goes to the main menu or not
Pre-Condition Player must be on pause screen
Input Criteria Touch on Main Menu
Expected Main Menu should open
Result
Remarks Done
Page
57
Restart Game:
Test Case
Test Case ID TC_16
Description Restart the game
Purpose To check whether game will restart or not
Pre-Condition Player must be on pause screen
Input Criteria Touch on restart
Expected Game will restart
Result
Remarks Done
Page
58
Enemy Fire on Helicopter:
Test Case
Test Case ID TC_17
Description Enemy Fire on helicopter
Purpose To check whether enemy fire or not
Pre-Condition Player must be in the range of the Enemy
Input Criteria -
Expected Helicopter must get damage
Result
Remarks Done
Page
59
Helicopter Damage:
Test Case
Test Case ID TC_18
Description Helicopter gets damage
Purpose To check whether Helicopter health decreases or not
Input Criteria Helicopter gets hit
Expected Helicopter health -1
Result
Remarks Done
Page
60
Pick Health:
Test Case
Test Case ID TC_19
Description Player pick up health if health is less than maximum
Purpose To check whether helicopter pick health or not
Input Criteria Player should pass through read (+) logo to pick health
Expected Health gets maximum
Result
Remarks Done
Page
61
Fire Auto-Cannon:
Test Case
Test Case ID TC_20
Description Player Fire Auto-cannon
Purpose To check whether Fire Auto-cannon properly or not
Input Criteria Touch on the left bottom bullet logo on mobile screen
Expected Fire Auto-cannon
Result
Remarks Done
Page
62
Pick Ammunition:
Test Case
Test Case ID TC_21
Description Player pick up ammunition if ammunition is less than maximum
Purpose To check whether helicopter pick ammunition or not
Input Criteria Player should pass through green logo to pick ammunition
Expected Ammunition gets maximum
Result
Remarks Done
Page
63
Change Helicopter Height:
Test Case
Test Case ID TC_22
Description Change height to avoid enemy attacks or avoiding mountains and to
collect ammunition or health
Purpose To check whether height changes
Input Criteria Player must touch up or down arrow which is on the mid of the mobile
screen
Expected Height changes
Result
Remarks Done
Page
64
Destroy Radar Truck:
Test Case
Test Case ID TC_23
Description Radar truck will Destroy after get hit by the Auto-cannon
Purpose To check whether radar truck destroyed or not
Pre-Condition Radar must be hit by the Auto-cannon
Input Criteria Player must fire on radar truck 5 times
Expected Radar truck destroy
Result
Remarks Done
Page
65
Helicopter Destroyed by Enemy:
Test Case
Test Case ID TC_24
Description Radar truck will Destroy after get hit by the Auto-cannon
Purpose To check whether radar truck destroyed or not
Pre-Condition Radar must be hit by the Auto-cannon
Input Criteria Player must fire on radar truck 5 times
Expected Radar truck destroy
Result
Remarks Done
Page
66
Helicopter collapse with Mountain:
Test Case
Test Case ID TC_25
Description Helicopter will destroy if it crashed with mountain
Purpose To check whether helicopter destroy after it crashed with mountain or
not
Input Criteria -
Expected Helicopter will destroy
Result
Remarks Done
Page
67
Stage clear:
Test Case
Test Case ID TC_26
Description Destroy all the radars to clear the stage
Purpose To check whether if all the radars are destroyed or not
Input Criteria -
Expected Stage clear
Result
Remarks Done
Page
68
Quit Game:
Test Case
Test Case ID TC_27
Description Game will turn off
Purpose To check whether the game turn off or not
Pre-Condition Must be on Main Menu option
Expected Game will turn off
Result
Remarks Done
Page
69
7.2 Black Box Test Cases
Black box testing also known as Behavioral Testing is a software testing method in which the
internal structure/design/implementation of the item being tested is not known to the tester.
These tests can be functional or non-functional, though usually functional.
7.2.1 Equivalence Partitions (EP)

It is to divide the input data of software into partitions of data from which test cases can be derived.
In principle, test cases are designed to cover each partition at least once. This technique tries to
define test cases thereby reducing the total number of test cases that must be developed.
Methodology
1. In this method the input domain data is divided into different equivalence data classes.
2. This method is typically used to reduce the total number of test cases.
3. In short it is the process of taking all possible test cases and placing them into classes.
4. One test value is picked from each class while testing.
Equivalence Partitioning for fields of forms are implemented below:
For Main Menu

Filed Name Action Invalid Partition Valid Partition Invalid Partition
Play Touch Pause Load The Stage Exit

Selection mode
Stage Touch Back to main Menu Load the Game Skin Change
Selection Scene
Setting Touch Play Load The Skin Stage Selection
Selection mode
Skin Touch Play Skin Change Pause

Selection
Exit Touch Skin Selection Quit The Game Setting
Page
70
For Game Play
Filed Name Action Invalid Partition Valid Partition Invalid Partition
Player Shoot Shoot Nothing Happened Radar Health Game End

and its hit the Reduces
Radar
Player Shoot Shoot Radar Health Nothing Level Cleared

and it did not Reduces Happened
hit the Radar
Enemy Attack Radar Destroyed Player Health Game End

Attack on the Reduces
Player
Helicopter Attack Radar also Destroyed Mission Failed Mission Cleared

Destroyed
Player pick Touch Health Decrease Helicopter Helicopter Destroy

the Health Health goes
Maximum
Player Pick Touch Ammunition Helicopter Nothing Happened

Ammunition Decrease Ammunition
goes Maximum
A Radar Shoot Helicopter Destroy Radar Destroyed Nothing Happened

Destroyed
All Radar Fire Game End Mission Cleared Helicopter Destroy

Destroyed
Page
71
7.2.2 Decision Table Testing
The other two specification-based software testing techniques, decision tables and state transition
testing are more focused on business logic or business rules. A decision table is a good way to deal
with combinations of things (e.g. inputs). This technique is sometimes also referred to as a cause-
effect' table.
Scenario
The basic idea of AeroStrike is to destroy the entire enemy base in the different environments and
provide the air support at the same time. The game starts with the scene where a helicopter is
airborne above enemy territory. The helicopter will provide air support by destroying the enemy
Radar trucks. But each enemy Radar Truck is guarded by auto-cannons and they will try to destroy
the helicopter is it goes in their shooting range so the player has to dough there attacks by moving
away from them and at the same time shooting the radar truck. If the player survives the attack and
able to destroy enemy tank one objective will be completed and player can go and look for other
enemy base to complete all the objectives. If player health is less, then he can collect the health
placed randomly on the map and same for the ammunition. If player health is zero it will destroy
and mission will be a failure. Helicopter will destroy if it collapsed with mountain.
Conditions
The conditions of the above scenario are written below;
 Shoot (Did not Hit)
 Shoot (Hit)
 All Objectives are Complete
 Helicopter destroyed
Actions
The actions depending upon the above conditions are written below;
 Nothing Happened
 Radar Truck Destroy
 You Have Win The War
 You Have Failed The Mission
Page
72
Decision Table
Decision Table is a testing method, which aims to ensure that each one of the possible branch
from each decision point is executed at least once and thereby ensuring that all reachable code is
executed.
Actions Helicopter All Shoot and Shoot and Conditions
Destroy Objectives (Hit) (Did not Hit)
are
Complete
X T T T T R1
X F T T T R2
You Have Failed T F T T R3

The Mission
X F F T T R4
X T T F T R5
X F T F T R6
You Have Failed T F F T R7

The Mission
Nothing Happened F F F T R8
X T T T F R9
You Have Win The F T T F R10

War
You Have Failed T F T F R11
The Mission
Enemy Destroy F F T F R12
X T T F F R13
You Have Win The F T F F R14

Mission
You Have Failed T F F F R15
The Mission
X F F F F R16
Page
73
7.2.3 State Transition Testing
“State Transition testing, a black box testing technique, in which outputs are triggered by changes
to the input conditions or changes to 'state' of the system. In other words, tests are designed to
execute valid and invalid state transitions.”
Page
74
States Transitions
AeroStrike Main Menu Play, Settings, Exit
Settings Change Skin
Change Skin Save Skin
Save Skin Main Menu
Play Select Stage
Select Stage Load Stage
Load Stage Failed, Clear Stage, Pause
Mission failed Restart, Main Menu
Restart Load Stage
Clear Stage Restart, Main Menu, New Stage
Restart Load Game
New Stage Select Stage
Pause Restart, Resume, Main
Exit Game Exit
Page
75
7.2.4 Boundary Value Analysis
A boundary values an input or output value on the border of an equivalence partition, includes
minimum and maximum values at inside and outside boundaries. Normally Boundary value
analysis is part of stress andnegativetesting1
Use Case Testing

Use Case Testing is a functional black box testing technique that helps testers to identify test
scenarios that exercise the whole system on each transaction basis from start to finish.
7.3 White Box Test Cases

White box testing is a testing technique that examines the program structure and derives test
data from the program logic/code. The other names of glass box testing are clear box testing,
open box testing, logic driven testing or path driven testing or structural testing.
7.3.1 Cyclometric complexity

Cyclometric complexity is a source code complexity measurement that is being
correlated to a number of coding errors. It is calculated by developing a Control Flow
Graph of the code that measures the number of linearly-independent paths through a
program module.
Lower the Program's cyclometric complexity, lower the risk to modify and easier to
understand.
7.4 Performance testing

Performance testing, anon-functional testing technique performed to determine the system
parameters in terms of responsiveness and stability under various workloads. Performance
testing measures the quality attributes of the system, such as scalability, reliability and resources
age.
7.5 Stress Testing

Stress testing a Non-Functional testing technique that is performed as part of performance
testing. During stress testing, the system is monitored after subjecting the system to overload to
ensure that the system can sustain the stress.
The recovery of the system from such phase (after stress) is very critical as it is highly likely to
happen in production environment.
Page
76
7.6 System Testing
System Testing (ST) is a black box testing technique performed to evaluate the complete system
the system's compliance against specified requirements. In System testing, the functionalities of
the system are tested from an end-to-end perspective.
System Testing is usually carried out by a team that is independent of the development team in
order to measure the quality of the system unbiased. It includes both functional and Non-
Functional testing.
7.7 Regression Testing

Regression testing is a black box testing technique that consists of re-executing those tests that
are impacted by the code changes. These tests should be executed as often as possible throughout
the software development lifecycle.
Types of Regression Tests:
 Final Regression Tests
A "final regression testing" is performed to validate the build that hasn't changed for a
period of time. This build is deployed or shipped to customers.
 Regression Tests
A normal regression testing is performed to verify if the build has NOT broken any other
parts of the application by the recent code changes for defect fixing or for enhancement.
 Selecting Regression Tests

Requires knowledge about the system and how it affects by the existing functionalities.
Tests are selected based on the area of frequent defects.
Tests are selected to include the area, which has undergone code changes many a times.
Tests are selected based on the criticality of the features.
 Regression Testing Steps

Regression tests are the ideal cases of automation which results in better Return on Investment
(ROI).
Select the Tests for Regression.
Choose the apt tool and automate the Regression Tests
Verify applications with Check points
Manage Regression Tests/update when required
Schedule the tests
Integrate with the builds
Analyze the results
Page
77
8. Chapter6: Tools and Techniques
This chapter includes the following
Computer programming (often shortened to programming or coding) is the process of designing,
writing, testing, debugging, and maintaining the source code of computer programs. This source
code is written in only one language. The purpose of programming is to create a set of instructions
that computers use to perform specific operations or to exhibit desired behaviors. The process of
writing source code often requires expertise in many different subjects, including knowledge of the
application domain, specialized algorithms and formal logic. And the language used in this project
is written below
 C Sharp (C#)
C#
C# (pronounced "C-sharp") is an object-oriented programming language from Microsoft that aims
to combine the computing power of C++ with the programming ease of Visual Basic. C# is based
on C++ and contains features similar to those of Java.
 C# is designed to work with Microsoft's .Net platform. Microsoft's aim is to facilitate the
exchange of information and services over the Web, and to enable developers to build highly
portable applications.
 C# simplifies programming through its use of Extensible Markup Language (XML) and Simple
Object Access Protocol (SOAP) which allow access to a programming object or method
without requiring the programmer to write additional code for each step.
 Because programmers can build on existing code, rather than repeatedly duplicating it, C# is
expected to make it faster and less expensive to get new products and services to market. We
also using the java script for scripts
Page
78
8.1 Tools:
 Unity 3D 5.3.4
Unity is a cross-platform game engine developed by Unity Technologies, which is primarily used
to develop video games and simulations for PC, consoles, mobile devices and websites. This is the
main software on which our game is developed.
 Adobe Photoshop
Adobe Photoshop is the software which is used to edit images and make logos and different text
images. This was used for all the menu screens and all the buttons and dialog boxes.
 Google Sketchup Pro
Google Sketchup Pro-v8.0.14346 is used for graphics and for physical characters.
 Android SDK
Android SDK tool is also used for the purpose of conversion of game on to a mobile platform.
Page
79
8.2 Techniques
 Hardware
Buttons are provided on the screen where user can touch and control the game.
 Internal Progress Storage
Internal memory of mobile is used to store the score and the levels and weapons which are
unlocked so the user can resume from where he left last time.
 Unity Built-in Libraries
The built-in libraries of the unity 3D software are used for making effects and all the Sound and
scene transitioning.
 Unity Physics
Unity Physics technology is used for giving the weapons and buildings mass and gravity and all the
physical properties like Rigid Body, Colliders etc.
 Unity ITS
ITS asset is used for controlling the enemies of the game.
Page
80
9. Chapter7: Summary and Conclusion
9.1 Summery
 We are making a unity 3D game (AeroStrike) which involves a helicopter that is airborne
above enemy territory. The area is consists on multiple enemy bases which consists on a radar
truck guarded by enemy auto-cannons. The player is supposed to complete the objective by
destroying all radar trucks that will interrupt with communication system of enemy bases. The
player also has to avoid the enemy attacks that are coming from auto-cannons guarding the
radar truck on the ground while destroying the radar system of every base. Difficulty level is
based on episodes. For now, it has only Five level and may be more
o First stage is training stage. It will help the player to understand the controls and player can
practice his aiming and movement.
o Second stage is where player can test his training by completing the objectives.
o Third stage in which difficulty level will increase with a new entity an Anti-Aircraft which
will also guarding the Radar Truck and take more damage than Auto-Cannon.
o In fourth stage player can change the height of the helicopter to avoid hills and mountains.
o In fifth stage there will be only one objective that is guarded by a lot of Auto-Cannons and
Anti-Aircraft and the Radar Truck will be protected by a force field. So it will be difficult
to destroy the Radar that’s why player has to play with tactics by managing Health and
Ammunition of the helicopter.
Our Final Year Project is now at the last phases and we are quite satisfied with our work and it
is almost ready to be deployed in Google Play Store which will provide the users with good
entertainment and will help them to cheer up.
Throughout this one year of game development we faced a lot of problems and had many
occasions of stress and being stuck on some problem for long amount of times. But we learnt many
things which will help us and others to guide them in the process of game development. The
gaming industry is now one of the most important and highest revenue generating industry and is
being worked on in the present times making tools for the developers to make games. In our year
of developing the game many tools and techniques came which helped us to make the game. But
sometimes it got frustrated because we worked on something and the next update does not support
that thing but we found ways to get around it. The forums on the internet has guided has greatly to
remove the problem. There is very limited information at present about this because it is relatively
new thing so we had to find very hard to come up with some solution also there is a problem of
finding models which are usually very expensive or of not good quality so we have to spend many
hours just for finding the right model. We have watched many video tutorials and online lectures
and has attended workshops of Unity 3D to learn it because it is currently not being taught in our
university. Our project supervisor also guided us in many parts and given us ideas to solve the
problem and given us recommendations about what can be added to our game to improve it. The
models and diagrams we made at the start and the entire schedule we made helped us a lot to keep
track of time and our work.
Page
81
9.2 Conclusion
Apart from all the work stuff what we also learned is the friendship and how to deal with the stress
and manage time and workload between us to complete our project. We learned how to deal with
people and how to ask guidance from seniors. And lastly, we hope our project will give people a
lot of good time and make them feel happy in their down time and we hope we will make
University proud in the future INSHALLAH.
Page
82
10. Chapter8: User Manual
10.1 How to Change and Save Skin:

 Touch on Settings logo From Main Menu
Page
83
 To Change Upper Rotor Skin
Page
84
 To Change Lower Rotor skin
Page
85
 To Change Body Skin
Page
86
 To Save Skin
Page
87
10.2 How to Select Stage and Play:
 Touch on Play Logo From Main Menu
 Select Stage Level
Page
88
 Wait for few seconds for Game to Load
 Stage Scene will Load
Page
89
10.3 How to Move the Helicopter:
 Use the Joystick to move
Page
90
10.4 How to Fire:
 Touch on Bullet Button to Fire

Page
91
10.5 How to Pick Ammo:
 Collect Green Ammo Box
Page
92
10.6 How to Pick Health:
 Collect Red Health Box
Page
93
10.7 How to Pause Game:
 Touch on Pause Button
Page
94
10.8 To Resume:
 Touch on Resume
10.9 To Go on Main Menu:

 Touch on Main Menu
Page
95
10.10 To Quit Game:
 Touch On Quit Button
Page
96

Aero Strike

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Aero Strike

Caricato da

Copyright:

Formati disponibili

AeroStrike

The key objectives are :

 Download the game then install it.

 Enjoy controls optimized for 3D flight.

IMPLEMENTATION TOOLS AND TECHNIQUES

None at this stage.

(To be filled by students)

…………………………..DO NOT WRITE BELOW THIS LINE……………………………

FOR OFFICE USE ONLY

Suggested Improvements (if any):

Definitions Acronyms and Abbreviations

SRS Software Requirement

4.2.1 Project perspective

Operating System Android

 Communications interfaces (This should specify the various interfaces to

4.2.3 User characteristics

4.3.1 Functional Requirement

 Helicopter Moves Left

 Helicopter fires stopped

 Auto Cannon fires

 Auto-Cannon fires stopped

 Pause Menu (Exit)

To make the best performance of this game;

Use Case Diagram OF User Flow

Use Case ID: 1

Use Case ID: 2

Use Case ID: 4

Use Case ID: 6

Use Case ID: 8

Use Case ID: 10

Use Case ID: 12

Use Case ID: 14

Aim and Fire

Use Case ID: 16

Use Case ID: 18

The flow of information inside the system is defined in this level

The flow of information outside the system is defined in this level

Figure1 Activity Diagram Create Account

Figure1 Sequence Diagram Create Account

7.1 Test Case Specifications

7.2.1 Equivalence Partitions (EP)

For Main Menu

Play Touch Pause Load The Stage Exit

Skin Touch Play Skin Change Pause

Player Shoot Shoot Nothing Happened Radar Health Game End

Player Shoot Shoot Radar Health Nothing Level Cleared

Enemy Attack Radar Destroyed Player Health Game End

Helicopter Attack Radar also Destroyed Mission Failed Mission Cleared

Player pick Touch Health Decrease Helicopter Helicopter Destroy

Player Pick Touch Ammunition Helicopter Nothing Happened

A Radar Shoot Helicopter Destroy Radar Destroyed Nothing Happened

All Radar Fire Game End Mission Cleared Helicopter Destroy

You Have Failed T F T T R3

You Have Failed T F F T R7

You Have Win The F T T F R10

You Have Win The F T F F R14

AeroStrike Main Menu Play, Settings, Exit

Settings Change Skin

Change Skin Save Skin

Save Skin Main Menu

Play Select Stage

Select Stage Load Stage

Load Stage Failed, Clear Stage, Pause