SRS of software project lab 1

1 | P a g e
Table of Contents
Abstract................................................................................................................................................................3
Acknowledgement...............................................................................................................................................4
Chapter – 1: The Project Plan.............................................................................................................................5
Gaming in the Field of Software Engineering................................................................................................6
Background......................................................................................................................................................7
1.1 The Project.................................................................................................................................................7
1.2 The Project Scope......................................................................................................................................7
1.3 Project Scheduling.....................................................................................................................................8
Chapter – 2: Software Requirement Specification............................................................................................9
Section – 2.1: Introduction.............................................................................................................................9
2.1.1 Purpose.............................................................................................................................................10
2.1.2 Document Conventions...................................................................................................................10
2.1.3 Intended Audience and Reading Suggestions ...............................................................................10
2.1.4 Document Scope..............................................................................................................................11
Section – 2.2: General Description...............................................................................................................12
2.2.1 Product and Business Perspective..................................................................................................13
2.2.2 System Environment .......................................................................................................................13
2.2.3 Quality Function Deployment.........................................................................................................14
2.2.4 Usage Scenarios...............................................................................................................................16
Section – 2.3: Specific Requirements...........................................................................................................17
2.3.1 External Interface Requirements....................................................................................................18
2.3.2 User Characteristics.........................................................................................................................19
Section – 2.4: Analysis Models.....................................................................................................................20
2.4.1 Scenario Based Model.....................................................................................................................21
2.4.2 Data Model.......................................................................................................................................48
2.4.3 Behavioral Model.............................................................................................................................51
Section – 2.5: Requirement Change Management.....................................................................................58
2.5.1 Bugs and Glitches.............................................................................................................................59
2.5.2 Patches .............................................................................................................................................59

2 | P a g e
Chapter – 3: Design and Implementation........................................................................................................60
3.1 Product Design Terms.............................................................................................................................61
3.1.2 User Experience (UX).......................................................................................................................61
3.1.2 Backend Programming ....................................................................................................................62
3.2 System Features......................................................................................................................................62
3.2.1 CCTV Camera....................................................................................................................................63
3.2.2 Automatic Doors..............................................................................................................................63
3.2.3 Title Screen.......................................................................................................................................64
3.2.4 Level Selection .................................................................................................................................65
3.2.5 Pause Menu......................................................................................................................................66
3.2.6 Option Menu....................................................................................................................................67
3.2.7 Suspicious Meter .............................................................................................................................68
3.2.8 Flying.................................................................................................................................................68
3.2.9 Disguise.............................................................................................................................................69
3.2.10 Dialogue or Tips.............................................................................................................................70
3.3 Assumptions and Dependencies............................................................................................................71
3.3.1 Construction of the Game...............................................................................................................71
3.3.2 Integration with Android.................................................................................................................72
3.4 Key Resource Requirements ..................................................................................................................72
3.5 Implementation Tools.............................................................................................................................74
Chapter – 4: Testing ..........................................................................................................................................75
Chapter – 5: User Manual.................................................................................................................................79
5.1 Playing Procedure...................................................................................................................................80
5.2 Some Snapshots......................................................................................................................................81
Future Plan.........................................................................................................................................................83
Conclusion..........................................................................................................................................................87
6.1 The Obstacles ..........................................................................................................................................87
6.2 The Achievements...................................................................................................................................88
6.3 Last Few Words.......................................................................................................................................88
Appendix A: References....................................................................................................................................89
Appendix B: Abbreviation and Acronyms........................................................................................................90

3 | P a g e
Abstract
The software industry continues to evolve rapidly, expanding due to innovative new product
and service applications (apps), hardware platforms, delivery mechanisms and growing global
markets. Software Industry consists software development, game development, designing,
testing, quality assurance this sort of things .Games developers are involved in the creation and
production of games that range from computer, handheld, console and arcade games to games
on the internet, mobile phones and other wireless game applications. Their work involves
either design (including art and animation) or programming.
Games development is a fast-moving, multi-billion pound industry. The making of a game from
concept to finished product can take up to three years and involve teams of up to 200
professionals. There are many stages, including creating and designing a game’s look and how it
plays, animating characters and objects, creating audio, programming, localization, testing and
producing.
This Report is intended to give a complete overview of our Project the game “Ghost in the
Town” including the software requirement specification, working tools, features, playing
procedure , analysis model and overall description therein. This Report details all features upon
which we have currently decided with reference to the manner and importance of their
implementation. It’s important to illustrate that, this project shown as software project lab- II.

4 | P a g e
Acknowledgement
By the Grace of ALMIGHTY ALLAH we are completed some phases of our project to
demonstrate.
We are grateful to the project supervisor Md.Nurul Ahad Tawhid Sir for his supervision
throughout the project time. He helped us a lot by sharing his valuable knowledge with us.

5 | P a g e
Chapter – 1: The Project Plan

6 | P a g e
This chapter covers the project proposal and feasibility of the proposal along with background
study, product and business perspective, the scopes and some preliminary idea of our game.
Gaming in the Field of Software Engineering
In the fast growing field of software engineering and development and even more rapidly
growing sector of game development the future is hard to predict. We are working with this
game as our software project lab-II.SPL-II is a 3 credit course and as part of our degree we
choose this type of work for doing better with development cycle, development period,
graphics, scripting, adopting new technology, animation.
In general software project is a project focusing on the creation of software. Consequently,
Success can be measured by taking a look at the resulting software.
In a game project, the product is a game. But and here comes the point: A game is much more
than just its software. It has to provide content to become enjoyable. Just like a web server:
without content the server is useless, and the quality cannot be measured. This has an
important effect on the game project as a whole. The software part of the project is not the
only one, and it must be considered in connection to all other parts: The environment of the
game, the story, characters, game plays, the artwork, and so on.

7 | P a g e
Background
Background is a set of events invented for a plot, presented as preceding and leading up to that
plot. It is a literary device of a narrative history all chronologically earlier than the narrative of
primary interest. In our project it’s a single player strategy game emphasizing logical thinking
and planning. They often stress resource and time management, which usually takes
precedence over fast action and character involvement. Tactical organization and execution are
necessary, and the game creators usually place the decision-making skills and delivery of
commands in the player’s hands.
1.1 The Project
It’s a complete strategy game with different levels. The main character of ‘Ghost in the Town’ is
a little ghost who loses its parents in a human neighborhood. The baby is afraid of people and
hasn’t adopted many ghost tricks yet. So it’s difficult for it to return to its parents. Now it must
find food and keep itself hidden in a crowded town. The main mission of the gamer is to use his
logic and save the ghost. There are several levels and in each level the gamer must hide the
ghost from people and feed it.
1.2 The Project Scope
This Report describes all the requirements for the project. The purpose of this research is to
provide a virtual image for the combination of both structured and unstructured information of
our project “Ghost in the Town”. “Ghost of the Town” is a single-player strategy game on the
Android platform. The player will progress through levels which require precise manipulation of
the environment, though the game Encourages creativity and daring via branching pathways.

8 | P a g e
The episodic structure of the game facilitates the pace of the story. We demonstrate the action
flow between input, script, display (output).We working mainly with story, levels, object,
animation, graphics, scripts, game engine facilities. We aren’t working with web launching, free
hand programming, carton making.
1.3 Project Scheduling
Start Date End Date Project states and Objective
January 15 January 25 Project Proposal, meeting with supervisor about
our idea
January 26 February 15 Planning , thinking about game story , levels and
Learning Technology
February 16 March 07 Construct SRS document, choose tools, and
environment
March 08 March 20 Start designing and implementation
March 21 April 08 Developing, Testing and enhancement running with
writing the report
April 09 May 28 Final revision of the report and testing on the
constructing level/levels.
June 06
Project submission

9 | P a g e
Chapter – 2: Software Requirement Specification
Section – 2.1: Introduction

10 | P a g e
2.1.1 Purpose
This Software Requirements Specification (SRS) part is intended to give a complete overview of
our Project the game “Ghost in the Town” including the action flow, initial user interface and
story therein. The SRS document details all features upon which we have currently decided with
reference to the manner and importance of their implementation.
2.1.2 Document Conventions
This document will freely interchange the pronoun “we” with the team’s acronym. As the
development team is responsible for the SRS document, no ambiguity arises from its usage.
There is a clear distinction, however, between the use of the words “player/gamer” and
“character.” The “player” is the human being interacting with the game in the real world, while
the “character” is the in-game player avatar being manipulated.
2.1.3 Intended Audience and Reading Suggestions
The SRS document also gives project managers a way to ensure the game’s adherence to our
original vision. Although the document may be read from front to back for a complete
understanding of the project, it was written in sections and hence can be read as such. For an
overview of the document and the project itself, see Overall Description. For a detailed
description of the game-play elements and their interaction with the character, read System
Features. Readers interested in the game-play interface and navigation between different
front-end menus should go through External Interface Requirements. Technical standards to
which the team will hold the project are laid out in Other Nonfunctional Requirements. The
development schedule, meanwhile, will be maintained in the Key Milestones.

11 | P a g e
2.1.4 Document Scope
This Software Requirements Specification (SRS) describes the functional and nonfunctional
requirements for the project. As we said before the purpose of this research is to provide a
virtual image for the combination of both structured and unstructured information of our
project “Ghost in the Town”.
Project “Ghost in the Town” was conceived by the 3 of our team members as having an
anticipated development cycle greater than the length of the semester. The team wishes to
carry on the project until its completion. The game will continue to grow until we feel it
satisfactory for open-source distribution.

12 | P a g e
Chapter – 2: Software Requirement
Specification
Section – 2.2: General Description

13 | P a g e
2.2.1 Product and Business Perspective
Software product development is a paradigm shift from routine application maintenance and
support in the software industry. Development a game/software product from scratch is a
significant challenge for any organization. It requires considerable investments in terms of
effort and cost and also confirms client involvement, knowledge about client market (example:
Google play).
We have compiled some interesting articles from the web for you which should form the basis
for a concluding public discussion about the future of the game industry. Please feel free to
interrupt us any time and contribute your ideas. This will make our game much more lively and
interesting. Here this report product perspective describes the overall description.
2.2.2 System Environment
Gamer
Input Manager
(Key pad/game pad)
Script
(Compile)
Renders
(Display)

14 | P a g e
Gamer can interact with system by giving input (press key to start game) to the system. System
give those inputs to script, if any change occur (if the value is changed) this object send to
renders to display the things (a character can change its place).
2.2.3 Quality Function Deployment
Quality Function Deployment is a technique that translates the needs of the
customer into technical requirements for software/game. It concentrates on
maximizing customer satisfaction from the Software engineering process .With
respect to our project the following requirements are identified by a QFD.
o Normal Requirements.
o Expected Requirements.
o Exciting requirements.
Normal Requirements
Normal requirements consist of objectives and goals that are stated during the
meeting with the actor/gamer/relevant people. Normal requirements of our project
are:-
1. User friendly efficient and lucrative system.
2. Minimum maintenance cost (may be graphics definition).
3. Availability of expected requirements within the PC/mobile configuration.
4. Easy to operate.

15 | P a g e
5. They observe our game as this is build with professional manner.
6. The game with measured coding, professional thinking.
Expected Requirements
These requirements are implicit to the system and may be so fundamental that the
actor/gamer/ relevant people does not explicitly state them .Their absence will be a
cause for dissatisfaction.
1. Develop system within limited cost.
2. Maximum high definition.
3. Minimum hardware requirements which is relevant for this game.
4. Design whole system with efficient manner.
Exciting requirements
These requirements are for features that go beyond the customer's expectations and
prove to be very satisfying when present:
1. We may provide some cheat codes.
2. Maximum high regulation with minimum hardware.
3. We may provide an international player rank list.
4. Easy to update.

16 | P a g e
2.2.4 Usage Scenarios
First, gamer needs to download the game from our sponsor. After installation
he/she should read how to play and must see the initial “Story” provided by us. If
anyone takes the honey of our game then he feel the test and hopefully enjoy our
game. We provide also some typical options like “continue”, “score board”, “exit”
etc.
UX (user experience) is very important part of any software project/game. UX is a
broad term used to explain all aspects of a person’s experience with the system,
including the interface, graphics, industrial design, physical interaction, and the
manual. It’s essential that how much gamer can interact with our game.

17 | P a g e
Specification
Section – 2.3: Specific Requirements

18 | P a g e
2.3.1 External Interface Requirements
2.3.1.1 User Interfaces
Every game must has a menu so is can be user friendly enough and gamers can easily fulfill their
need. Menu is also an important thing while creating the SRS document section. In this SRS
document part; we have used the menu snapshots in the user manual part. These snapshots
are based on the menu of the game.
2.3.1.2 Hardware Interfaces
“Ghost in the town” is a mobile gaming application designed specifically for the Android
platform and is functional on both mobile smart phones and tablets. Gaming application data is
stored locally on the game engine elements. “Ghost in the town” has been developed for
Android developed Version and all subsequent releases. In the future we released in the
android platform. Now the Android platform is graphically adaptable with a 2 dimensional
graphics library and a 3 dimensional graphics library based on OpenGL ES 2.0 specifications as
well as hardware orientation, scaling, pixel format conversion and accelerated 3D graphics.

19 | P a g e
2.3.1.3 Software Interface
“Ghost in the town” has been developed using a series of game development tools.
Working tools and platform
 Unity3D
 Autodesk Maya
 Autodesk 3ds Max
 Android Software Development Kit (Android SDK): Software development kit for applications on
the Android platform. We want to release this game in the Android platform.
2.3.2 User Characteristics
There is one user all the time and the user always interact with the game (system) in different
manner.
So, Gamer is the only who communicate with the system through playing the game. The
Primary requirement is that Gamer must read the playing procedure provide by us
(developers).

20 | P a g e
Specification
Section – 2.4: Analysis Models

21 | P a g e
2.4.1 Scenario Based Model
2.4.1.1 Use Case Scenario
The following table summarizes the use cases of the system. We have created the use cases
based on the UX view of the game. The swimlane diagram connects UX with background
programming which are the two important views of a game SRS.
Level – 0 Level – 1 Level – 2
Game ( Ghost in the
Town )
Play
New Game
Resume Game
Select Level
Exit Game
Options
Show Control
Change Configuration (Graphics)
Change Sound/ Music Volume
Score Board
View Scores
Reset Score Board
Story View Story
Quit -

22 | P a g e
2.4.1.2 Use Case Descriptions with Activity and Swimlane Diagram:
01. Play
i.
Use case: New Game
Primary Actors: Any one playing the game
Goal in context: To start a new game
Precondition:
1. System supports the game configuration
2. The file has been triggered to run and the game screen has appeared
Triggers: The player needs to start a new game
Scenario:
1. Go to the main menu of the game
2. Click new game button
3. New game is loaded on system
Exception: Game crushed
Priority: Essential, must be implemented
When Available: First increment

23 | P a g e
Activity Diagram:
Swimlane Diagram:
Go to Main Menu
Click New Game
Level-1 loaded
UX Background Programming
Go to Main Menu
Click New Game
Level-1 Loaded

24 | P a g e
ii.
Use case: Resume Game
Goal in context: To resume game from previous play
Precondition:
1. Game was played before
2. Game supports to have a checkpoint to start from
Triggers: Need to resume game
Scenario:
1. Go to the main menu of the game
2. Click the resume game button
3. Game is loaded from the last checkpoint
Exception:
1. Level cannot be loaded
2. Game crushed

25 | P a g e
Activity Diagram:
Swimlane Diagram:
Go to Main Menu
Click Resume Game
Last Played Level loaded
Background ProgrammingUX
Go to Main Menu
Click Resume Game
Last Played Level loaded

26 | P a g e
iii.
Use case: Select Level
Goal in context: To load the game from a required level
Precondition:
1. Required level has been unlocked
2. Game supports loading levels
Triggers: Need to load a level
Scenario:
1. Go to the main menu
2. Click the select level button
3. Select a level
4. The level is loaded for play
Exception: Level cannot be loaded

27 | P a g e
Activity Diagram:
Swimlane Diagram:
Go to Main Menu
Click Select Level
Select a Level
Go to Main Menu
Click Select Level
Selected Level Loaded
Selected Level Loaded
Select a Level

28 | P a g e
iv.
Use case: Exit Game
Goal in context: To exit from the game level
Precondition: A game level is being played
Triggers: Player needs to exit from the game level
Scenario:
1. Press game pause
2. When Pause Menu appears, click Return to Menu button
3. Game is exited and Title screen appears

29 | P a g e
Activity Diagram:
Swimlane Diagram:
Press Pause Game
Pause Menu Appears
Click Exit Game
Press Pause Game
Pause Menu Appears
Game Exited
Game Exited
Click Exit Game

30 | P a g e
02. Options
i.
Use case: Show Controls
Goal in context: To know the controls of playing the game
Precondition: Game provides control information
Triggers: Player needs to know the controls to play the game
Scenario:
2. Click the Options button
3. When Option menu appears click the show control button
4. Game controls are being showed
Exception: No control information

31 | P a g e
Activity Diagram:
Swimlane Diagram:
Go to Main Menu
Click Options
Option Menu Appears
Go to Main Menu
Options Menu Appears
Controls Showed
Click Show Controls
Click Show Controls
Controls Showed
Click Options

32 | P a g e
ii.
Use case: Change Graphics Configuration
Goal in context: To change the graphics configuration of the game
Precondition:
1. Player is allowed to change configuration
Triggers: Player has a need to configure graphics
Scenario:
2. Click on Options button
3. Click on Graphics slider and set the required value
4. Game is updated
Exception: System doesn’t support given graphics configuration
Priority: Expected
When Available: Second increment

33 | P a g e
Activity Diagram:
Swimlane Diagram:
Go to Main Menu
Click Options
Option Menu Appears
Go to Main Menu
Updated
Set Value on Graphics Slider
Set Value on Graphics Slider
Updated
Click Options

34 | P a g e
iii.
Use case: Change Sound/ Music Volume
Goal in context: To change the sound or music volume
Precondition: Player is allowed to change volume of game
Triggers: Player has a need to change volume of the game
Scenario:
2. Click on Options button
3. Click on Music/ Sound Slider and change the value
4. Music or Sound Volume is changed
Exception: System is in mute mode, cannot increase volume
Priority: Expected

35 | P a g e
Activity Diagram:
Swimlane Diagram:
Go to Main Menu
Click Options
Option Menu Appears
Go to Main Menu
Volume Changed
Set Value on Volume Slider
Set Value on Volume Slider
Volume Changed
Click Options

36 | P a g e
03. Score Board
i.
Use case: View Scores
Primary Actors: Anyone playing the game
Goal in context: To see the score board
Precondition:
1. Game has been programmed to save scores in database
2. Game has a prepared rank list for the players
Trigger: Player needs to see the game scores
Scenario:
2. Click Score Board
3. Select a level
4. Scores of the level is shown in ranking order
Exception:
1. No Scores (Game is not played once yet)
2. Score Board has been reset
Priority: Expected

37 | P a g e
Activity Diagram:
Swimlane Diagram:
Go to Main Menu
Click Score Board
Select a Level
Go to Main Menu
Click Score Board
Rank Showed
Rank Showed
Select a Level

38 | P a g e
ii.
Use case: Reset Score Board
Goal in context: To reset the score board
Precondition:
1. Game has a score board
2. Players are allowed to reset the score board
Trigger: Player wants to reset the scores of the game
Scenario:
2. Click on Score Board button
3. Click reset Score board
4. Score board is reset
Exception:
1. No Scores in Score board
Priority: Expected

39 | P a g e
Activity Diagram:
Swimlane Diagram:
Go to Main Menu
Click Score Board
Click Reset
Go to Main Menu
Click Score Board
Score Board Reset
Score Board Reset
Click Reset

40 | P a g e
04. Story
i.
Use case: View Story
Goal in context: To watch the game story
Precondition:
1. Game has a back ground story
2. Story is prepared for the gamers
Trigger: Player wants to see the game story
Scenario:
1. Go to the game menu
2. Click Story button
3. Story of the game is played
Priority: Expected

41 | P a g e
Activity Diagram:
Swimlane Diagram:
Go to Main Menu
Click Story
Game Story Played
Go to Main Menu
Click Story
Game Story Played

42 | P a g e
05. Quit
Use case: Quit
Goal in context: To Exit from the Game Process
Precondition: Player has entered in the game process
Triggers: Player needs to exit from the game
Scenario:
2. Click Quit button
3. Game is exited
Exception: Something went wrong. Cannot exit now.

43 | P a g e
Activity Diagram:
Swimlane Diagram:
Go to Main Menu
Click Quit
Game Exited
Go to Main Menu
Click Quit
Game Exited

44 | P a g e
2.4.1.3 Use Case Diagram
Game (Ghost
in the Town)
System
Fig: Level 0 for Game UX
Quit
Story
Action Object
Score Board
Options
Play
Player
Player

45 | P a g e
Fig: Level 1 for Game UX
Exit Game
Action Object
Select Level
Resume Game
New Game
Player
Fig: Level 2.1(Play) for Game UX

46 | P a g e
Action Object
Change Sound
/ Music
Volume
Change
Graphics
Show
Controls
Player
Fig: Level 2.2(Options) for Game UX

47 | P a g e
Action Object
Reset
View
Player
Fig: Level 2.3(Score Board) for Game UX

48 | P a g e
2.4.2 Data Model
If software requirements include the need to create, extend or interface with database or if
complex data structures must be constructed and manipulated, the software team may choose
to create a data model as part of overall requirements modeling. As our game has many data
objects, we have chosen to create a data model which includes a E-R diagram and a data
schema.
Before going to the data model of “Ghost in the Town”, here is a generic data model for games
–
Fig: Generic Data Model for Games

49 | P a g e
2.4.2.1 Data Schema
1.
Ref_Special_Ability_Type
abilityTypeCode: int
abilityTypeName: string
abilityTypeDescrip: string
eg. Fly, Disappear
Ref_Participant _Type
participantTypeCode: int
participantTypeName: string
participantTypeDescri: string
eg. House Resident, Animal
Genres
genreCode: int
genreDesciption: string
eg. Strategy, Puzzle
Environments
environmentID: int
enviName: string
eg. Palace, Party
Special_Ability
abilityID: int
abilityTypeCode: int
abilityName: string
Levels
levelName: string
genreCode: int
environmentID: int
levelDescip: string
Participants
participantID: int
participantTypeCod
e: int
ParticipantName:str
ing
Special_Ability_in_Level
levelName: string
abilityID: int
Participants_in_level
levelName: string
participantID: int
Fly
flyID: int
flyTimer: int
flyDetails: string
Diappear
disappearID: int
disappearNo: int
maxDisappearNo: int
disappearDetails: string
Disguise
disguiseID: int
disguiseType:string
disguiseDetails: string
House_Residents
residentID: int
position: int
genderMF: enum
name: string
otherDetails: string
Animals
animalID: int
position: int
otherDetails: string
Events
eventID: int
eventOutcomeCode: int
eventTypeCode: int
levelName: string
eventDetails: string
Ref_Event_Type
eventTypeCode: int
eventTypeName: string
eventTypeDes: string
eg. Move, Grab
Resources
resourceID: int
resourceTypeCode: int
resourceName: string
Event_Type_Resourse_Usage
eventTypeCode: int
resourceID: int
quantityUsed: int
Ref_Event_Outcome
eventOutcomeCode: int
eventOutcomeName:
string
eventOutcomeDes: string
eg. Had food, escape from
Locations
locationID: int
eventID: int
locationName: string
locationDescrip: string
eg. Castle, Maze

50 | P a g e
2.4.2.2 E-R Diagram
Genres
ID
Description
Environment
ID
Name
Levels
ID
Name
importSpecial Ability
ID
Type
Name
Special Ability
in Level
Participants ID
Type
Name
Other Details
Participant
in Level
Disappear
DisguiseFly
Max No
No
Timer
Type
Animal
Resident
Position
Gender
Name
Type
Event Outcome
Event Type
Code
Name
Description
Code
Name
Description
Events
Resources
Location
ID
Name
ID
Details
ID Name
Event Type
Resource Usage
Quantity Used
Description

51 | P a g e
2.4.3 Behavioral Model
The Behavioral indicates how software will respond to external events or stimuli. There are two
ways to show these responses. One is state diagram and the other is sequence. Usually state
diagram came be made in two ways, one is creating a state diagram for each class and the
other is to create a state diagram of the whole system. As we don’t have any class, for this is
not an object oriented game, we have followed the later one. And to lessen complexity we have
divided the state diagram into two diagrams. On the other hand, for the sequence diagram, we
have created separate a sequence diagram for all the use cases if necessary.

52 | P a g e
2.4.3.1 State Diagram
Idle Open
Game
Splash
Screen
Main
Menu
from Level Select, Level Complete, and In Game Menus in Play Level
Checking
Do: isclicked
“Play” “Quit” “Options”
Close
Game
Options
Menu
Play
Menu
“Select Level”
To level select menu
To idle
“Return”“Controls”“Sound/Music”“Graphics”
Adjust Check
Fig: top level state diagram

53 | P a g e
“Next Level”
Checking
Do: isclicked
Level Select
Menu
To main menu
“Return”
Play Level
“Level X”
Checking
Do: isclicked
“In Game Menu”“Level Complete”
Level Complete Menu In Game Menu
Checking
Do: isclicked
“Main Menu”
Next Level Menu To main menu
Checking
Do: isclicked
“Resume”
Fig: play level state diagram

54 | P a g e
2.4.3.2 Sequence Diagram
Click resume
game
Open game
Click new game
Open game
BackendUX
Fig: Sequence diagram (New Game)
Level 1
Loaded
Fig: Sequence diagram (Resume Game)
Level
Loaded
Last played level
returned
Database
lookup
DatabaseBackendUX
Checking

55 | P a g e
Press Game Pause
Playing game
select level X
Click select level
Open game
Taking input
Fig: Sequence diagram (Select Level)
Click back to main menu
Fig: Sequence diagram (Exit Game)
Main Menu
Appears
Pause Menu
Appears
BackendUX
Level X
Loaded
Level Select
Menu
BackendUX

56 | P a g e
Click Options
Click options
Open game
Open game
Change graphics/
sound/ music
Fig: Sequence diagram (Show Control)
Controls
Showed
Click back to show controls
Option Menu
Appears
BackendUX
Fig: Sequence diagram (Change Graphics/Sound/Music)
Option Menu
Appears
DatabaseBackendUX
Updated

57 | P a g e
Lookup information
Click Score Board
Open game
Fig: Sequence diagram (View and Reset Score Board)
Click Reset
Score Board
Appears
DatabaseBackendUX
Change graphics/
sound/ music
Updated

58 | P a g e
Specification
Section – 2.5: Requirement Change Management

59 | P a g e
The developers intend to release a complete and fully functional game that follows the
guidelines mentioned in the SRS document. However, since the product will be released for
multiple Android platforms (i.e. the different phones running the Android system), updates will
likely be required. These updates would consist of any bug fixes that are necessary,
compatibility patches for all of the current phones that support the Android System, and
expansions of the content. If the players find any issues or has any comments they would be
able to contact the developers through the official support email address which is
ghostInTheTown_support@gmail.com.
2.5.1 Bugs and Glitches
The players would be able to contact the developers through the support email system. This is
where they would present any bugs or glitches they have detected and if they have any beliefs
that the game is not functioning properly. General concerns or comments would also need to
be submitted here.
CAE will check this email regularly in order to respond to any time sensitive information.
2.5.2 Patches
As the Android system is updated and new phones come out, the game would also need to be
updated. Developers would constantly be making changes in order to keep up with any
compatibility issues that may arise. These changes and any others that may be fixing bugs or
glitches would be released through these patches.

60 | P a g e
Chapter – 3: Design and Implementation

61 | P a g e
3.1 Product Design Terms
For every enterprise product two key terms of design is very important. They are:
 UX (User Experience)
 Backend Programming
3.1.2 User Experience (UX)
To avoid unnecessary product features, simplifying design documentation and customer-facing
technical public at, Incorporating business and marketing goals UX design is must.
User experience design (UXD or UED) is any aspects of a user's experience with a given system,
including the interface, graphics, industrial design, physical interaction, and the manual in most
cases,
User Experience Design fully encompasses traditional Human-Computer Interaction (HCI)
design, and extends it by addressing all aspects of a product or service as perceived by users.
UX stands for mainly relevant access of usability, accessibility and HCI.
UX defines user experience as “a person’s perceptions and responses that result from the use
or anticipated use of a product, system or service”.

62 | P a g e
3.1.2 Backend Programming
The "back end" is the code supporting that front end (responsible for database access, business
logic etc).
In simple term, application front end is what you see (i.e the user interface) and application
back end is the application engine that you do not see. The "back end" is the code supporting
that front end (responsible for database access, business logic etc).
Foe efficient implementation, to increase user acceptance both two are very important in
software industry.
3.2 System Features
I. CCTV Camera
II. Automatic Door
III. Title Screen
IV. Level Selection Menu
V. Pause Menu
VI. Option Menu
VII. Suspicion Meter
VIII. Flying
IX. Disguise
X. Dialogue on Tips

63 | P a g e
3.2.1 CCTV Camera
3.2.1.1 Description and Priority
CCTV Cameras are added in game Streets and other places in the game scene. The player needs
to be very careful so that the ghost child doesn’t get caught into the camera. If it is, the player
will lose the game.
3.2.1.2 Stimulus/Response Sequences
Step 1: The player notices the camera and checks the target area of camera.
Step 2: If player can survive from being camera target he can successfully leave the section.
Step 3: Otherwise, camera caught the ghost and game is finished.
3.2.1.3 Functional Requirements
REQ 1: Camera must change target area in a loop to catch ghost.
REQ 2: Camera must consistently update its current position.
REQ 3: If it catches the ghost in its area, it forces to abort the scene.
3.2.2 Automatic Doors
There are a few automatic doors in the scene .These doors open whenever the ghost comes
near to it.
Step 1: The ghost comes near to the door.
Step 2: Door opens automatically.

64 | P a g e
REQ 1: It must be continuously updated about the objects near it.
REQ 2: It must differentiate the ghost with other game object.
REQ 3: Whenever it feel ghost around it, must be opened.
3.2.3 Title Screen
The title screen is the screen the player will see every time upon playing the game. Through this
interface, the player can choose to start a new game, play from saved data, or adjust the
options. Since the title screen is the “hub” for all activities in the project, it must be included.
Step 1: The player launches the game from their portable device.
Step 2: The start screen loads and appears, prompting the player with three buttons: “Play
Game”, “Options”, and “Exit”.
Step 3: The player presses one of the buttons, triggering its respective function.
REQ-1: The title screen must load and appear every time the game is launched.
REQ-2: If the player quits the game during any stage of a level, they must be returned to the
title screen.
REQ-3: If the player presses the exit button, the game will end and return the player to the
phone’s regular interface.

65 | P a g e
REQ-4: If the player completes the game, the game will end and return the player to the title
screen.
3.2.4 Level Selection
The level selection screen is the primary way for the player to choose between different levels.
The game is separated into narrative chapters, inside of which are multiple levels. The hierarchy
holds true for the level select screen as well. Because this screen constitutes the player’s main
method of accessing the level database, it is essential to the game.
Step 1: Available chapters appear, as well as a “Return to Title Screen Option.”
Step 2: The player selects one of the chapters or returns to the title screen.
Step 3: If the player chooses a chapter, available levels within the chapter appear as well as an
option to return to the chapter view.
Step 4: The player selects one of the available levels or returns to the chapter view (Step 2.)
REQ-1: To unlock a chapter on the map screen, a player must complete the final non-bonus
stage in the previous chapter.
REQ-2: When a chapter is completed, the chapter’s bonus levels which have not been unlocked
become visible on the map screen in sequence with their respective non-bonus levels, but are
still inaccessible to the player.
REQ-3: Only chapters and levels which the player has unlocked are displayed on the level
selection screen, excepting those bonus levels falling under REQ-2.

66 | P a g e
3.2.5 Pause Menu
The player should be able to pause anytime during game-play, and this screen fulfills that
requirement. The pause menu also allows the player to navigate between game-play and the
level selection and title screens. The portable nature of the console renders player convenience
paramount, so this feature must be included.
Step 1: The player presses the pause button on the game-play interface.
Step 2: The level pauses, drawing up the pause menu which prompts the player with three
options: “Resume Game,” “Return to Map” and “Exit Game.”
Step 3: The player presses one of the buttons, triggering its respective function.
REQ-1: The “Return to Map” option must return the player to the chapter to which the exited
level belongs.
REQ-2: The “Resume Game” option must continue the game without any change to the
character’s vector or the state of the level from the moment of the pause action.

67 | P a g e
3.2.6 Option Menu
The options menu is accessible from the title screen and allows the player to configure controls
and graphical settings to suit his/her convenience. This screen is not essential to accessing
game-play and is hence of lower priority than the Title Screen or Pause Menu, but constitutes a
standard feature in commercial titles and is thus a desirable inclusion.
Step 1: The player accesses the options menu from the title screen. From here, the player
chooses to:
A) Select “On” or “Off” for “Sound”
B) Select “Left” or “Right” for “Controls”
C) Select “Return to Title Screen”
Step 2: The chosen options are written to the game and take effect immediately.
REQ1: Sound will be enabled when “On” is selected and disabled when “Off” is selected.
REQ2: The Sound will be set to “On” by default.
REQ3: Movement Scroll Bar will be set to the left side of the screen if “Left” is selected and set
to the right side of the screen if “Right” is selected.
REQ4: The Movement Scroll Bar is set to “Right” by default.
REQ5: Player will be directed back to the Title Screen when “Return to Title Screen” is selected.

68 | P a g e
3.2.7 Suspicious Meter
3.2.7.1 Descriptions and Priority
Suspicious will not be visible in the play screen. But it is a measurement of game score. The
more the player makes people suspicious the less is the score and so to get maximum stars in a
game scene the gamer must not raise suspicious among the civilians
Step 1: Ghost makes sound
Step 2: People suspicious
Step 3: Game score lessons
REQ 1: Store ghost actions during the game
REQ 2: Calculate stars depending on people suspicious
3.2.8 Flying
Introduced in higher level. As our ghost doesn’t have feet, user can say that he is actually flying
always. But this is not the thing we are intended to say by this flying feature. We will give the
play on a option to fly higher and hide from people in multistoried building.
Step 1: The player process the fly button.
Step 2: The ghost flies with a constant force.
Step 3: Player releases the button.

69 | P a g e
Step 4: Ghost falls.
REQ 1: Fly force should be standardized.
REQ 2: Levels should be adapted to this standard fly.
REQ 3: Flying should take into account the current vertical and horizontal velocities.
3.2.9 Disguise
Introduced in higher level (party scene). Ghost can disguise itself here by putting on a mask.
Step 1: Players comes to an interaction with a mask.
Step 2: Player selects the mask and put it on.
REQ 1: Mask must be ready and available to wear.
REQ 2: Levels should be adopted with disguise.
REQ 3: People must not recognize ghost with a mask.

70 | P a g e
3.2.10 Dialogue or Tips
Dialogue is the primary method by which the player will experience the game’s story. The
character’s guide carries on dialogue with the silent protagonist, providing context and
narrative. While this feature is secondary in importance to the primary game mechanics, it is an
important aspect of the game’s atmosphere and informs the level design and music to heighten
the player’s connection to the experience.
Step 1: The player passes a certain waypoint in a stage or completes a certain action.
Step 2: Dialogue is triggered and a text box or floating text pops up.
Step 3: To dismiss text boxes or continue reading multiple-page text boxes, the player clicks on
the text box or floating text area.
REQ-1: Dialogue should not pause the game to prevent player disorientation.
REQ-2: Text boxes and floating text should be brief and placed away from UI components so as
not to interfere with game-play.
REQ-3: The text must be readable from any device.

71 | P a g e
3.3 Assumptions and Dependencies
The final destination of our game's operation will be the Android mobile device. However, Unity
will be responsible for both the construction of the game and its integration within the Android
framework.
3.3.1 Construction of the Game
Unity includes many built-in components which will expedite the process of game development
immensely. These include:
o Physics Engine
o Collision Detection and Handling
o Input Recognition
o Object Creation and Transform Manipulation (position and rotation of game objects)
o Scene Integration (transition of one level to the next)
o Model Attachment (representing game objects with 3D models from external programs)

72 | P a g e
3.3.2 Integration with Android
Unity3D's build settings simplify the process of transferring our game to the Android mobile
device. After completing the project, or during any intermediary step for testing, we can select
Android from the list of options, build the project, and upload it to one of our own devices. A
separate license is required for this functionality, which has already been obtained by one of
the members of our group.
3.4 Key Resource Requirements
Major Project
activities
Skill/Expertise
Required
Internal
Resources
External
Resources
Issues/Constraints
Level Design
Ability to
translate aspects
of the story into
playable levels
All three
members made
the decision
about game
levels together
Ideas from
existing games
(Ex. Stealth)
Conflicting ideas per
level
Physics Engine
Knowledge of
functions
available in Unity
and the ability to
change them as
needed
Nadia and
Tahmid worked
on Unity game
engine
Unity game
engine
Ability to angle
interactive portions
of levels

73 | P a g e
Graphics Design
Knowledge of
graphical
modeling and
implementation
Arif and Nadia
worked for
creating 3d
models
3d model
design using
Maya and
3dsMax
Visibility of the
details on the 3d
models
Music
Development/
Implementation
Ability to
incorporate
sound clips
smoothly into
the game
-
Sound clips
from the
Internet
Ability to play sound
clips at precious
times during
gameplay
Level
Implementation
Familiarity with
scripting
language of
game engine
All members
have some
knowledge
about scripting
language
Background
images from
the internet
Level size dependent
on hardware
configuration
Documentation
Knowledge about
SRS and Formal
Report Writing
Arif and Nadia
worked more
on Reporting
Idea from
Existing Reports
(Ex. IITDU
Online Judge
System)
Game Reports are
Different from
Conventional ones

74 | P a g e
3.5 Implementation Tools
Product of Tool Usage Work exp.
Unity
Technologies
Unity3d Game Engine Backend activity
Autodesk
3ds Max
Graphics
Design and
Animation
Create 3d Model
and Animate
Maya
Graphics
Design and
Animation
Create 3d Model
Adobe Photoshop Picture Edit 3d Model textures
Microsoft
Windows
Movie Maker Create Videos
Game story
creation

75 | P a g e
Chapter – 4: Testing

76 | P a g e
Test Case-1 : This test will check if the animation is working
correctly.
Test Procedure : Import a character model with animation in unity. Place
character on the scene. Run the game.
Expected Result : Animation works perfectly in the environment.
Actual Result : Animation is not working.
Comment : Need to check character configuration on inspector
window. The appropriate animation was not selected.
Select it.
Conditional Test : Again run scene.
Expected Result : Animation is working now.
Actual Result : Yes, it is working.
Accuracy : Accuracy depends on hardware configuration.

77 | P a g e
Test Case-2 : This test will check if the interaction between objects are
working correctly.
Test Procedure : Add scripts of interaction in the objects that we want to
interact with each other. Run scene.
Expected Result : Objects are interacting.
Actual Result : Run time exception
Comment : Need to add checking in the scripts for the objects that
have a particular script.
Conditional Test : Run scene.
Expected Result : Interaction is ok now.
Actual Result : Interaction is ok now.
Accuracy : Perfectly accurate.

78 | P a g e
Test Case-3 : This test will check if the dialogue box are working.
Test Procedure : Add dialogue box in the scene. Run scene.
Expected Result : Dialogue box appears in the correct dimension.
Actual Result : Working perfectly
Comment : Tips and dialogues are working as expected.
Test Case-4 : This test will check if the automatic door opens when
ghost is around
Test Procedure : Configure door. Run scene.
Expected Result : Door opens and closes depending on ghost position.
Actual Result : Working perfectly
Comment : Automatic door can recognize ghosts presence and
opens.

79 | P a g e
Chapter – 5: User Manual

80 | P a g e
5.1 Playing Procedure
Gamer first interact system UI to start playing. We provide playing tips to all users so that
he/she can easily understand about the playing procedure.
There are different levels in our game. Gamer can play each level by finishing the previous one.
Player uses his/her logic and maintains time to accomplish the game. He needs to feed the little
ghost to survive and take him out from the civilization. If gamer caught with baby ghost by
CCTV camera or any civilian, he loses the game. Here at the first level, gamers aim to be
communicating with the parents of the baby ghost. It can be through telephone or mobile
phone inside those civilians’ houses. Like that different level has different complexity and
different logic to finish. But the main thing is that gamer should survive with the child ghost
which is separated from its family.

81 | P a g e
5.2 Some Snapshots
Fig: Unity view of main menu (curser is on start button)
Fig: Play menu with its options

82 | P a g e
Fig: Pause menu while playing the game
Fig: Ghost Character Model created by 3ds Max

83 | P a g e
Fig: Bed Room with Character Sleeping
Fig: Drawing room

84 | P a g e
Fig: Study room
Fig: House yard

85 | P a g e
Fig: CCTV Camera
Fig: Street

86 | P a g e
Fig: Overall Construction view of level 1

87 | P a g e
Future Plan
 Level Extension
 Improve Graphical Representation
 Introduce new game features
 Introduce new environment and scenes
 Take user response through website and produce web rank list
Conclusion
A software project means a lot of experience. In this section we summarize the experience
gained by project team during development of “Ghost in the Town”.
6.1 The Obstacles
1. Working with game engine completely a new experience for us. Normally we are working
with different OO languages, DBMS, mark up languages etc.
2. We adopt these things by video tutorials, text tutorials, internet and learning materials given
by the tools themselves. It's a matter of time, patience and hard work.
3. It is very sensible work and it demands much time because the game engines try to connect
game environment with the real world.
4. Creating a 3d model is very difficult because you need to work with each and every point of
the model.
5. The Exists game engines demands vast knowledge about its properties, sections and sub-
sections.
After all the thing is that a game project is not a project of 6 or 8 months for three people !

88 | P a g e
6.2 The Achievements
1. Now we know much more about game engines. How it works? The properties, objects and
others.
2. We know how a model is constructed and how it is animated.
3. The main thing is that as a software engineer, skill and expertise to create a SRS document
and a overall software product report is now better than before.
4. Co-Operation between group members.
5. Develop communication skills
6. Growing creative thinking and imagination capability .
6.3 Last Few Words
We learned a lot through this project. This project has sharpened our concept of Game engine,
animation and the software-hardware interface.
We learned a lot about different documentation. The piece of software we developed is
intended to serve the gamers of the world. The success of this project may give pleasure to
billions of game lovers among the universe. This project not only tested our technical skills but
also our temperament.
There were times that we almost lost hope but we recovered through constant concentration
and hard work.
If any kind of suggestion, improvements, more efficient development idea please feel free to
communicate with us.

89 | P a g e
Appendix A: References
General References
1. http://www.mixamo.com/, accessed on 1st
March, 2013
2. http://thefree3dmodels.com/stuff, accessed on 6th
March, 2013
3. http://www.unity3dstudent.com/, accessed on 23rd
January, 2013
4. http://students.autodesk.com/, accessed on 23rd
January, 2013
5. http://www.digitaltutors.com/11/index.php, accessed on 5th
March, 2013
6. http://library.creativecow.net/articles/3dsmax.html, accessed on 25th
March, 2013
7. http://www.good-tutorials.com/tutorials/3ds-max/animation, accessed on 27th
May, 2013
8. Project “Perihelion” Document by Crtl Alt Elite, accessed throughout Documentation
Period
9. Software Evaluation – A Product Perspective by Infosys, accessed on 28th
May, 2013
10. Software Engineering in Games by Balazs Lichtl and Gabriel Wurzer from Institute of
Computer Graphics, Technical University of Vienna, accessed on 26th
May, 2013
Special Thanks To
1. YouTube - http://www.youtube.com/
2. Archive3d - http://archive3d.net/
3. http://unity3d.com/
4. Unity Cookie - http://cgcookie.com/unity/
5. Unity Asset Store
6. Software Engineering, A practitioner’s approach -6th
edition, Roger S.Pressman

90 | P a g e
Appendix B: Abbreviation and Acronyms
Term Definition
Game engine
A game engine is a system designed for the creation and development of video
games.
UX
User experience (UX or UE) involves a person's emotions about using a particular
product, system or service.
Animation
Animation is the rapid display of a sequence of images to create an illusion of
movement.
Android Android (Google product) is a Linux-based operating system.
Scripting
A scripting language or script language is a programming language that supports the
writing of scripts, programs written for a special runtime environment that can
interpret and automate the execution of tasks which could alternatively be
executed one-by-one by a human operator.
Graphics
Graphics are visual presentations on some surface, such as a wall, canvas, screen,
paper, or stone to brand, inform, illustrate, or entertain
3d Model
In 3D computer graphics, 3D modeling is the process of developing a mathematical
representation of any three-dimensional surface of object (either inanimate or
living) via specialized software.
SRS Software Requirements Specification
UI User Interface
Gamer
A person who plays a game or games, typically a participant in a computer or role-
playing game.
System
A system is a set of interacting or interdependent components forming an
integrated whole or a set of elements (often called 'components' ) and relationships
which are different from relationships of the set or its elements to other elements
or sets.

SRS of software project lab 1

More Related Content

What's hot (20)

Similar to SRS of software project lab 1 (20)

Recently uploaded (20)

SRS of software project lab 1