DefendAR Software Design Description

Software Design Description for DefendAR Page 1
COMSATS University Islamabad,

Park Road, Chak Shahzad, Islamabad Pakistan
SOFTWARE DESIGN
DESCRIPTION
(SDD DOCUMENT)
for
DefendAR
(An Augmented Reality based strategy game)
Version 1.0
By
Muhammad Waleed Yousaf CUI/FA15-BSE-058/ISB
Nermeen Haider CUI/ FA15-BSE -081/ISB
Supervisor
Mr Qasim Malik


Bachelor of Science in Software Engineering (2015-2019)



Table of Contents
Table of Contents
1. Introduction 1
2. Design methodology and software process model 1
3. System overview 1
3.1 Architectural design 2
3.2 Process flow/Representation 3
3.2.1 Activity Diagram 1 3
4. Design models [along with descriptions] 6
4.1 Class Diagrams: 6
4.1.1 Overall Class Diagram: 6
4.1.2 Class Diagrams 1: 7
4.2 Sequence Diagrams: 10
4.2.1 Sequence Diagram 1: 10
4.3 State Transition Diagrams: 12
4.3.1 State Transition Diagram 1: 12
5. Data design 16
5.1 Data dictionary 16
6. Algorithm & Implementation 18
6.1 Artificial Intelligence: 18
6.1.1 Path Finding: 18
6.1.2 Ray Casting: 18
6.1.3 Enemy Combat: 18
6.2 Augmented Reality: 18
6.2.1 Marker Based AR: 18
6.2.2 Marker Less AR: 18
6.3 Physics: 18
6.4 Weapons: 19
6.5 Game Progress: 19
6.6 Audio: 19
7. Software requirements traceability matrix 19
8. Human interface design 21
9. Appendix I 23



Revision History
Name Date Reason for changes Version


Application Evaluation History
Comments (by committee) Action Taken

*include the ones given at scope time both in doc and
presentation
Supervised by
Mr Qasim Malik
Signature______________


1. Introduction
The following content is written to provide you an insight about our proposed project. Detailed
descriptions of “Defend AR”, an android game based on augmented reality, have been included
in the document. At present, augmented reality technology is in its initial evolution phase when it
comes to android applications, yet it has a vast, eager audience awaiting its progress. The game
under discussion is being developed to target this specific audience in the gaming world. All the
necessary specifications required to design the game have been provided here; design
methodology, process models, system overview, design models, data design, algorithms,
requirement traceability matrix and interface design. Defend AR is a one of a kind, innovative
application which gives the user a wonderful experience of playing an augmented reality game
without the dependency of any additional hardware.
2. Design methodology and software process model

We have chosen Object-Oriented design methodology for this software product. Our proposed
system is a game and thus, coding will follow the Object-Oriented techniques. By using the
Object Oriented approach our code will not only be more maintainable but it will also be easier
to identify the source of errors because objects are self-contained (encapsulated). Another reason
for us to follow Object Oriented Approach is that modules that we will develop don’t fall under
the Procedural paradigm.
The software process model that we will be following is incremental. There are several reasons
due to which we have chosen it. Firstly, because it is flexible; we can keep on changing
requirements and features without worrying about the cost. Following this model, we will get a
working software fast. We will keep on getting a good idea of what the end product will and thus
will be able to test the application while we are developing it. At each increment, we will get an
iteration. We need our project to be in different iterations due to the different evaluation
milestones during the project 30%, 60%, and 100% implementation. Thus, it will be easily
managed.
3. System overview
This project is an augmented reality game, Defend AR. It is based on the popular tower defense
game but it includes the augmented reality aspect. In the proposed game, the user’s primary goal
will be to defend the hideout of the main character. The system will target the cards and augment
objects accordingly, to be seen through the mobile screen. The enemies will be spawning from a
single instantiation marker towards the hideout using intelligent path finding and collision
avoidance. The system will allow user to defend the hideout using weapons. The range of each
weapon, the trajectory of attacks, and the impact will be different for every weapon. User will
also be able to upgrade and get better weapons as the levels progress. Because the game is
physics based, the impact of attacks on both sides will be shown. The enemies will progressively
get better as levels progress. Whatever is happening in the game, the system will allow the user


to view it in 3D as the user tilts and rotates phone to enhance AR experience. The game will not
be multiplayer; only one person can play it on their phone. The game is not a one vs. one game,
as it’s primarily defense vs. attack, contrary to attack vs. Attack.


3.1 Architectural design
This is the architecture diagram of the intended system. In this, we have divided the system
architecture in three levels: game framework, game engine, and game itself. At the framework
level, we have Android OS of the target devices at the bottom. Then, Graphics, sound, and input
are above that OS, which means that they are dependent on the android OS. Graphics define the
resolution, aspect ratio, and level of rasterization the game will run at. The sound will depend on
the inherent sound setting of the android phone. The input will also be mapped onto the graphics
provided by the android OS. In the game Engine level, we will include the algorithms: like
pathfinding, player preferences, occlusion culling etc. User Interface, and the world model the
system will represent. In the top level, we will have the .apk files of the game as well as the
supporting items, and other exported packages of that format.

3.2 Process flow/Representation
3.2.1 Activity Diagram 1
The activity diagram shows the overall flow of the system, from the point where the user clicks
on the game icon till he exits the game.


This activity diagram shows the flow of the system when the user enters the settings menu till, he
clicks back.


The activity diagram shows the flow of the system from when the user enters/visits the store till
he exits. The activity diagram shows the flow of the system from when the user enters/visits the
store till he exits.


4. Design models
4.1 Class Diagrams
4.1.1 Overall Class Diagram


4.1.2 Class Diagrams 1
The class diagram revolves around the “Player’s Data” class. In this first class diagram,
MainMenu and LevelNavigation are GUI related classes. Level Data stores all the information
about a level may have. Music class deals with the overall sound effects and background effects.


The diagram has Environment class which is responsible for the look and feel of the main game
scene. The diagrams main classes are shop and weapon.


This class diagram focuses on classes related to Artificial Intelligence i.e. Pathfinding,
Raycasting and Attacking. The other class in the diagram is Augmented Reality which deals
with the algorithms of AR like image detection and ground plane detection.
4.2 Sequence Diagrams
4.2.1 Sequence Diagram 1


This sequence diagram deals with the interaction among various objects that are related to store
and inventory.
This diagram deals with the main user interface and its components like navigating through the
menu, changing music preferences till selecting the level to play.
In this diagram, the sequence of the main game scene is show. The level data is loaded to
augment environment for that particular level. Enemies are spawned on the game scene and
starts attacking.


4.3 State Transition Diagrams
4.3.1 State Transition Diagram 1
This State Transition Diagram describes all the states that the object will have during the game
play, as well as the events under which the said states will change
This State Transition Diagram describes all the states the object will have during the
pause/resume scenario


This State Transition Diagram describes the states the game will go into as it loads Ads on the
user’s screen.


Diagrams Details
Architectural Diagram This is the architecture diagram of the
intended system. In this, we have divided the
system architecture in three levels: game
framework, game engine, and game itself.
At the framework level, we have Android OS
of the target devices at the bottom. Then,
Graphics, sound, and input are above that OS,
which means that they are dependent on the
android OS. Graphics define the resolution,
aspect ratio, and level of rasterization the
game will run at. The sound will depend on
the inherent sound setting of the android
phone. The input will also be mapped onto the
graphics provided by the android OS.
In the game Engine level, we will include the
algorithms: like pathfinding, player
preferences, occlusion culling etc. User
Interface, and the world model the system will
represent.
In the top level, we will have the .apk files of
the game as well as the supporting items, and
other exported packages of that format.
Activity Diagram 1 The activity diagram shows the overall flow
of the system, from the point where the user
clicks on the game icon till he exits the game.
Activity Diagram 2 This activity diagram shows the flow of the
system when the user enters the settings menu
till, he clicks back.
Activity Diagram 3 The activity diagram shows the flow of the
system from when the user enters/visits the
store till he exits.
Class Diagram 1 The class diagram revolves around the
“Player’s Data” class. In this first class
diagram, MainMenu and LevelNavigation are
GUI related classes. Level Data stores all the
information about a level may have. Music
class deals with the overall sound effects and
background effects.
Class Diagram 2 The diagram has Environment class which is
responsible for the look and feel of the main
game scene. The diagrams main classes are
shop and weapon.


Class Diagram 3 This class diagram focuses on classes related

to Artificial Intelligence i.e. Pathfinding,
Raycasting and Attacking. The other class in
the diagram is Augmented Reality which
deals with the algorithms of AR like image
detection and ground plane detection.
Sequence Diagram 1 This sequence diagram deals with the
interaction among various objects that are
related to store and inventory.
Sequence Diagram 2 This diagram deals with the main user
interface and its components like navigating
through the menu, changing music
preferences till selecting the level to play.
Sequence Diagram 3 In this diagram, the sequence of the main
game scene is show. The level data is loaded
to augment environment for that particular
level. Enemies are spawned on the game
scene and starts attacking.
State Transition Diagram 1 This State Transition Diagram describes all
the states that the object will have during the
game play, as well as the events under which
the said states will change.
State Transition Diagram 2 This State Transition Diagram describes all
the states the object will have during the
pause/resume scenario.
State Transition Diagram 3 This State Transition Diagram describes the
states the game will go into as it loads Ads on
the user’s screen.
5. Data design
“Player’s Data Management” module deals with the data design of the system, where creation,
updating, and deletion of data is being done.
As the system under consideration is a single player game and the it doesn’t needs to store a huge
number of entities. So, we wont use any databases and instead, we’ll use Player Preferences
which is a built in class of Unity Engine which is used to store data in user’s device.
Since the data is stored in user’s device via Shared Preferences so it can be easily manipulated by
using programing languages such as C# and JavaScript. The physical storage of this data is in
/data/data/pkg-name/shared-prefs/pkg-name.xml, where pkg-name is the name of the apk file
that is being run on the device.


The variables to be stored in our system will be the ones storing player’s identity, his game
progress, the weapons in his inventory, player’s XP’s, and other user’s preferences like music
sounds and player customization.
5.1 Data dictionary
Entity Attribute Data Description Parameters

Type
Audio Music Int Checks if the music is on and stores 0: Off
user preference 1: On
Sound Int Checks if the sound is on and stores 0: Off
user preference 1: On
Levels LevelsUnlocked Int Stores how many levels are 0-10: Levels
unlocked in total Unlocked
DifficultyLevel int Checks and stores difficulty Level 0: Easy
1: Medium
2: Hard
Level01Lock Int Checks if Level 01 is locked or 0: Locked
Unlocked 1: Unlocked
LevelsUnlocked Int Stores how many levels are 0-15: Levels
unlocked in total Unlocked
Player PlayerID String Stores the ID of the user in the Combination
system for future reference of
Alphanumeric
PlayerStatus Int Checks if the player is a new player 0: New Player
or a returning player


1: Returning
player
PlayerXPs Int Checks the amount of player 0: 10000
experience points.
PlayerHPs Int Checks the players/hideouts health 0: 10000
points.
Tutorials TutorialCleared Int Stores if the user has cleared tutorial 0: Not
Cleared
1: Cleared
Weapons WeaponEquipped Int Stored the ID of the current weapon 0-5: Weapon
the player has equipped Choice
Weapon1Lock Int Checks if Weapon 01 is locked or 0: Locked
unlocked 1: Unlocked
6. Algorithm & Implementation

6.1 Artificial Intelligence:
As the game is a single player strategy game, so the enemy’s behavior must be dynamic each
time a level is played. Similarly, the enemy’s bots must be intelligent and should have a decent
sense of attack and defense. So for that reason, we’ll use various Artificial Intelligence
algorithms.
6.1.1 Path Finding
This algorithm will determine the path between current location and destination. The enemies
will follow checkpoints in order to navigate through the game scene.
6.1.2 Ray Casting
A ray casting algorithm will make the enemies aware of their surrounding, player’s weapons,
traps, obstacles and other enemy’s bots by casting ray on from them towards multiple directions.


6.1.3 Enemy Combat
Once the enemy knows its destination and reaches the hideout by using path finding and ray
casting algorithms, they’ll start attacking the hideout or the weapons or the traps placed by the
player on the game scene.
6.2 Augmented Reality
6.2.1 Marker Based AR
This generally involves tracking a camera against a planar texture pattern, but sometimes also a
3D object. Key algorithms include interest point(image target) detection and matching, as well as
tools and techniques to filter out erroneous matches, plus a basic geometric model of the scene.
6.2.2 Marker Less AR
Here you don’t have to put pre-specified markers in the scene, so the system can run in many
environments right out of the box. Algorithms include recreating dense 3d environment and
multi view of 3d augmented objects.
6.3 Physics
The game heavily depends upon physics and the system will have different algorithms for
dealing with that. Like for example algorithms for gravitational effects for all the enemies and
bullets etc. Projectile motion of catapult’s fireballs will also be dealt with algorithms based of
physics.
The speed and velocity of the bots will also be defined in these algorithms. Similarly, the rigid
body and collision detection will be taken care off by the algorithms defined.
6.4 Weapons
The game will have a wide range of weapons broadly classified into two main categories i.e.
Offensive and Defensive. All the weapons will have different behavior which will be determined
in this algorithm. Like how the short range long range weapons will be used to effect enemy’s
and player’s HP.
6.5 Game Progress
This algorithm deals with the player’s current level and will determine the intractability options
the player has, the items that are locked and when to unlock them. Like some weapons wouldn’t
be available till the player finishes a certain level. Similarly, the level difficulties will also be
determined by comparing it to the current progress of the player.


6.6 Audio
The game will have background music and sound effects for different weapons and enemy’s
types. So an algorithm will be implemented for controlling these music and sound effects
throughout the game. User’s preferences will be taken into consideration for our previous
choices and current results.
7. Software requirements traceability matrix

Table 1 Requirements Traceability Matrix
Req. Number Ref. Item Design Component Items
Component
FR01 Class Diagram Level Data SpawnEnemies()
FR02 Class Diagram Enemy ChangeDifficulty()
FR03 Class Diagram Weapon Fire()
FR04 Class Diagram Ray Casting AvoidCollision()
FR05 Class Diagram Attack OnTriggerAttack()
FR06 Class Diagram Level Data EndLevel()
FR07 Class Diagram Level Data EndLevel()
FR08 Class Diagram Level Navigation UpdateLevelXP()
FR09 Sequence Diagram Enemy EnemyKilled()
FR10 Class Diagram Environment HideoutDestroyed ()
FR11 State Transition Diagram Enemy Movement EnemyMovement()
FR12 State Transition Diagram Enemy Movement EnemyMovement()
FR13 Class Diagram Environment DecreaseHP()
FR14 Class Diagram Weapon Fire()
FR15 Class Diagram Player Data UpdateXPs()
FR16 Class Diagram Weapon RangeWeapon()
FR17 Architecture Diagram Game Engine Vuforia
FR18 Architecture Diagram Game ImportImage()
FR19 State Transition Diagram Game Play LoadScene()
FR20 Class Diagram Game State PlayState()
FR21 Activity Diagram Press Buy DeductXP()
FR22 Class Diagram Player Data UpdateXP()
FR23 Class Diagram Player Data UpdateXP()
FR24 Activity Diagram Weapon Status UnlockWeapon()
FR25 Sequence Diagram Store Store
FR26 Class Diagram Weapon WeaponDetails()
FR28 Activity Diagram Main Menu MainMenu()
FR29 Activity Diagram Level Selection ChooseLevel()



FR31 Class Diagram Game State Play State
FR32 Class Diagram Enemy EnemySpawn()
FR33 Architecture Diagram User Interface WinningPanel()
FR34 Architecture Diagram User Interface LosingPanel()
FR35 Architecuture Diagram Game Framework Graphics()
FR36 Class Diagram Weapons WeaponsModeling()
FR37 Class Diagram Level Data CharacterImport ()
FR38 Architecture Diagram Game Framework Graphics()
FR41 Class Diagram PlayerData Controller()
FR42 Sequence Diagram Music ToggleOn()
FR44 Activity Diagram TurnSoundOn soundBtnClick()
FR46 Sequence Diagram Music WinningLevelMusic()
FR47 Sequence Diagram Music LosingLevelMusic()
FR48 Sequence Diagram Player Data gameProgress()
FR49 Sequence Diagram Player Data gameProgress()
FR50 Class Diagram Inventory InventoryDisplay()
FR51 Sequence Diagram Player Data gameProgress ()
FR52 Class Diagram Player UpdateLevelXP()
FR53 Class Diagram Player viewLevelList()
FR54 State Transition Diagram Pause Game PauseGame()
FR55 State Transition Diagram Resume Game ResumeGame()
FR56 Sequence Diagram Music ToggleOnOff()
FR57 Activity Diagram Tutorial tutorialOneBtnClick()
FR58 Activity Diagram Settings Press Help
FR59 State Transition Diagram Show Ad DisplayAd()
FR60 State Transition Diagram Show Ad DisplayAd()


8. Human interface design


n Objects ns
gs Clicking this button, the user will be directed to
the settings menu from where he can adjust
the volume of sound, music as well as adjust
controls according to his needs.
ctions will be provided through help to the user.
hop button will lead the user to the game’s shop
from where he can buy items as well as equip
with the items already bought.
clicking this button, the user will enter the
game.
clicking this button, the user will be directed
back to the screen before the one he is already
on right now.
k level clicking this button, if the required constraints
have been met, the selected level will be
unlocked.
em clicking this button, if the required constraints
have been met, the selected item will be
bought.
clicking the button, the selected item, if
unlocked, will be equipped.


9. Appendix I
● How to design using UML (OOP): For guidance please follow the instructions mentioned
in the link: http://agilemodeling.com/artifacts/
● How and when to design ER diagrams: For guidance please follow the instructions
mentioned in the link:
http://people.inf.elte.hu/nikovits/DB2/Ullman_The_Complete_Book.pdf
● Data flow diagrams: For guidance please follow the instructions mentioned in the link
and book:
o http://www.agilemodeling.com/artifacts/dataFlowDiagram.htm
o Software Engineering –A Practitioner’s approach by Roger Pressman
● Architecture diagram: For guidance please follow the instructions mentioned in the link
and book:
o Ian Sommerville – Software Engineering 9th Edition– Chapter 6

DefendAR Software Design Description

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DefendAR Software Design Description

Uploaded by

Copyright:

Available Formats

Software Design Description for DefendAR Page 1

COMSATS University Islamabad,

Bachelor of Science in Software Engineering (2015-2019)

Application Evaluation History

Comments (by committee) Action Taken

2. Design methodology and software process model

3.1 Architectural design

3.2 Process flow/Representation

3.2.1 Activity Diagram 1

3.2.2 Activity Diagram 2

3.2.3 Activity Diagram 3

4.1.1 Overall Class Diagram

4.1.2 Class Diagrams 1

4.1.3 Class Diagrams 2

4.1.4 Class Diagrams 3

4.2 Sequence Diagrams

4.2.1 Sequence Diagram 1

4.2.2 Sequence Diagram 2

4.2.3 Sequence Diagram 3

4.3 State Transition Diagrams

4.3.1 State Transition Diagram 1

4.3.2 State Transition Diagram 2

4.3.3 State Transition Diagram 3

Class Diagram 3 This class diagram focuses on classes related

Entity Attribute Data Description Parameters

6. Algorithm & Implementation

6.1.1 Path Finding

6.1.2 Ray Casting

6.1.3 Enemy Combat

6.2 Augmented Reality

6.2.1 Marker Based AR

6.2.2 Marker Less AR

6.5 Game Progress

7. Software requirements traceability matrix

FR30 State Transition Diagram Game Play LoadScene()

You might also like