Final project report of a game

Chapter – 1: The Project Plan of “Ghost in the
1 | P a g e
Town”

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.
1.1 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.
2 | P a g e

1.2 Background of this Project
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.3 About 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.4 Scope of Our Game
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.
The episodic structure of the game facilitates the pace of the story. We demonstrate the action
3 | P a g e

flow between inputs, script, display (output). We are working mainly with story, levels, object,
animation, graphics, scripts, game engine facilities. We are not working with web launching,
free hand programming, carton making.
1.5 Project Scheduling
Start Date End Date Project states and Objective
January 15 January 25 Project Proposal, meeting with supervisor about
4 | P a g e
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
We have found the planning of this project here which now leads us to the specification part of
the project.

5 | P a g e
Chapter – 2: Software Requirements
Specification of “Ghost in the Town”

This chapter covers the requirements specification of our game “Ghost in the Town”. It includes
the specification of this documentation with general description, specific requirements, and
analysis of models. It also includes changes management of this requirement specification in
case of any change.
2.1 Introduction
In this section the documentation of this report is specified. It specifies the document
convention, document scope and also provides a suggestion for the readers of the document.
2.1.1 Purpose of this Chapter
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.
6 | P a g e

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.
2.1.4 Scope of this Document
This Software Requirements Specification (SRS) describes the functional and nonfunctional
requirement 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.
7 | P a g e

2.2 General Description
This section includes the perspective of our product and the system environment it requires. It
specifies the QFD (Quality Function Deployment) of our game and also the User Story of it.
2.2.1 Product and Business Perspective of the Game
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.
8 | P a g e

2.2.2 System Environment
Gamer
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 of “Ghost in the Town”
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.
9 | P a g e
Input Manager
(Keypad/game pad)
Script
(Compile)
Renders
(Display)

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.
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.
10 | P a g e

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.
2.2.4 User Story of Our Game
“Ghost in the Town” is a strategy game. It is a multi-platform game which is supported by PC,
web player, android phone, IOS and other platforms also. So the gamer can use any of these
platforms to run the game.
After running the game, the UX view of the game will appear on the screen. The term UX means
User Experience which is used to explain all aspects of a person’s experience with a system.
However, then the gamer can directly select “Start” from the “Main Menu” and start playing
the game or may go to “Level Selection Menu” and select his/ her desired level. Gamer can also
turn sound on/ off or change graphical settings. Gamer can also check controls of the game by
going to “Control Menu” and see the “About Menu”. A “Story” is also provided with the game
to understand the game objective. However, after starting a level the player will find helpful
tips on the side of the screen and he/ she can follow it and enjoy the game. He may also
interact with “Pause Menu” by pressing “Escape”. If he loses he can replay the level by pressing
“Restart” or exit game by pressing “Quit” in the “Game Over Menu”. After finishing the game
also, he will get option to “Play Next Level” or simply “Quit”.
11 | P a g e

The story behind the game is about a small ghost who is lost from his parents. As he is still a kid,
he cannot remember the ghost tricks of vanishing and others. The objective of the gamer is to
help him to find foods and to make him survive from the human beings. As mentioned earlier
the gamer will find tips in different steps which will help him to go to the finishing stage. There
are CCTV cameras and laser grids in the area which the gamer needs to avoid. The view area of
the CCTV camera is represented by a red circular area and the view area of human beings is
represented by a green area. The player can turn of the laser grids by a switch which is present
there in the scene. The ghost can also hide into cup-board and under table to avoid human
sight. There will be foods here and there which will raise the score point of the gamer if
collected. But to finish the game, gamer must collect one thing, the “Key” and go to the
finishing cube of the scene.
12 | P a g e

2.3 Specific Requirements
This section covers the project external requirements of our game and also indicates the user
characteristics for this project.
2.3.1 External Interface Requirements of the Game
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.
13 | 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 for the System
There is only one user at a time in this software and the user interacts with the game (system)
in different manner.
So, Gamer is the only one who communicates with the system through playing the game. And
this gamer can be any person. The primary requirement is that, the gamer must read the
playing procedure provided by us (developers).
14 | P a g e

2.4 Analysis Model of Our Game Project
This section describes the Software Requirements Specification of our project by analyzing the
proper models of requirement engineering.
2.4.1 Scenario Based Model
This Model depicts how the user interacts with the system and the specific sequence of
activities that occur as the software is used.
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 (mentioned in “User Story Part”) of the game. The swimlane diagram
connects UX with background programming which are the two important views of a game SRS
(Details of these two terms are in section 3.1).
15 | P a g e

Level – 0 Level – 1 Level – 2
Game ( Ghost in the Town )
16 | P a g e
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 -

2.4.1.2 Use Case Diagram with Use Case Description
17 | P a g e
Game (Ghost
in the Town)
System
Fig 1: Level 0 for Game
UX
Play
Options
Score Board
Story
Quit
Action Object
Player
Player
Fig 2: Level 1 for Game UX

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

This Diagram of Level 2.1(Fig 3) leads us to the “Play” module of the use cases. These use case
descriptions are given here –
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
19 | 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
20 | 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
21 | P a g e

iv.
Use case: Select Level
Goal in context: To load the game from a required level
Precondition:
3. Required level has been unlocked
4. Game supports loading levels
Triggers: Need to load a level
Scenario:
6. Click the select level button
7. Select a level
8. The level is loaded for play
Exception: Level cannot be loaded
22 | P a g e

v.
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
23 | P a g e

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

This Diagram of Level 2.2(Fig 4) connects with the “Option” module of the use cases. These use
case descriptions are given here –
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
25 | 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
26 | 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
27 | P a g e

View
Reset
This Diagram of Level 2.3(Fig 5) connects with the “Score Board” module of the use cases.
These use case descriptions are given here –
Score Board
i.
Use case: View Scores
Primary Actors: Anyone playing the game
Goal in context: To see the score board
28 | P a g e
Action Object
Player
Fig 5: Level 2.3(Score Board) for Game
UX

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
29 | 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
30 | P a g e

We can see a module for “Story” in Figure 1 which is the Level 1 of Use Case Diagram. The Use
Case for it is given below –
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
31 | P a g e

There is another module for “Quit” in Figure 1 which is the Level 1 of Use Case Diagram. The
Use Case for it is given here –
01. 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.
32 | P a g e

2.4.1.3 Activity Diagram
33 | P a g e
Go to Main Menu
Click New Game
Level-1 loaded
Fig 6: Activity Diagram for “New Game” module of “Play” (Fig 3)
Go to Main Menu
Click Resume Game
Last Played Level loaded
Fig 7: Activity Diagram for “Resume Game” module of “Play” (Fig 3)

34 | P a g e
Go to Main Menu
Click Select Level
Select a Level
Selected Level Loaded
Fig 8: Activity Diagram for “Select Level” module of “Play” (Fig 3)
Press Pause Game
Pause Menu Appears
Click Exit Game
Game Exited
Fig 9: Activity Diagram for “Exit Game” module of “Play” (Fig 3)

35 | P a g e
Go to Main Menu
Click Options
Option Menu Appears
Click Show Controls
Controls Showed
Fig 10: Activity Diagram for “Show Controls” module of “Options” (Fig 4)

36 | P a g e
Go to Main Menu
Click Options
Option Menu Appears
Set Value on Graphics Slider
Updated
Fig 11: Activity Diagram for “Change Graphics” module of “Options” (Fig 4)

37 | P a g e
Go to Main Menu
Click Options
Option Menu Appears
Set Value on Volume Slider
Volume Changed
Fig 12: Activity Diagram for “Change Sound/ Music Volume” module of
“Options” (Fig 4)

38 | P a g e
Go to Main Menu
Click Score Board
Select a Level
Rank Showed
Fig 13: Activity Diagram for “View” module of “Score Board” (Fig 5)
Go to Main Menu
Click Score Board
Click Reset
Score Board Reset
Fig 14: Activity Diagram for “Reset” module of “Score Board” (Fig 5)

39 | P a g e
Go to Main Menu
Click Story
Game Story Played
Fig 15: Activity Diagram for “Story” module (Fig 1)
Go to Main Menu
Click Quit
Game Exited
Fig 16: Activity Diagram for “Quit” module (Fig 1)

2.4.1.4 Swimlane Diagram
40 | P a g e
UX Background Programming
Fig 17: Swimlane Diagram for “New Game” module of “Play” (Fig 3)
Background UX Programming
Go to Main Menu
Click Resume Game
Last Played Level loaded
Go to Main Menu
Click New Game
Level-1 Loaded
Fig 18: Swimlane Diagram for “Resume Game” module of “Play” (Fig 3)

41 | P a g e
Go to Main Menu
Click Select Level
Selected Level Loaded
Select a Level
Fig 19: Swimlane Diagram for “Select Level” module of “Play” (Fig 3)
Press Pause Game
Pause Menu Appears
Game Exited
Click Exit Game
Fig 20: Swimlane Diagram for “Exit Game” module of “Play” (Fig 3)

Click Options
Fig 21: Swimlane Diagram for “Show Controls” module of “Options” (Fig 4)
Click Options
Fig 22: Swimlane Diagram for “Change Graphics” module of “Options” (Fig 4)
42 | P a g e
Go to Main Menu
Options Menu Appears
Controls Showed
Click Show Controls
Go to Main Menu
Updated
Set Value on Graphics Slider

Click Options
Fig 23: Swimlane Diagram for “Change Sound/ Music Volume” module of “Options” (Fig 4)
43 | P a g e
Go to Main Menu
Volume Changed
Set Value on Volume Slider
Go to Main Menu
Click Score Board
Rank Showed
Select a Level
Fig 24: Swimlane Diagram for “View” module of “Score Board” (Fig 5)

44 | P a g e
Go to Main Menu
Click Score Board
Score Board Reset
Click Reset
Fig 25: Swimlane Diagram for “Reset” module of “Score Board” (Fig 5)
Go to Main Menu
Click Story
Game Story Played
Fig 26: Swimlane Diagram for “Story” module (Fig 1)

45 | P a g e
Go to Main Menu
Click Quit
Game Exited
Fig 27: Swimlane Diagram for “Quit” module (Fig 1)

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. Although our game has many
data objects, it does not have any data storage. All the objects and their related data are
handled by the game engine. So the developers need not think about data storage. For this
reason, data model is redundant for this game project.
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 can be made in two ways, one is creating a state diagram for each class and the other
is to create a state diagram for the whole system. As we don’t have any class, for this is not an
object oriented game, we have followed the later one. We used the modules of the use case
scenario to create the state diagram. 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 when necessary.
46 | P a g e

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

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

2.4.3.2 Sequence Diagram
49 | P a g e
UX Backend Active Object
Click resume
game
Open game
Click new game
Open game
UX Backend
Fig 30: Sequence diagram (New Game)
Level 1
Loaded
Checking
Level
Loaded
lookup
level returned
Fig 31: Sequence diagram (Resume Game)

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

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

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

2.5 Requirement Change Management of Our System
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.
For managing the changes we are releasing versions of this document. This one is version 2.1.
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.
53 | P a g e

Chapter – 3: Design and Implementation of
54 | P a g e
“Ghost in the Town”

This chapter covers the project design phases, the system features and also the implementation
of the features.
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”.
55 | 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 of Our Game
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
XI. Exit Point
XII. Hide Ghost
XIII. Laser Grid
XIV. Food Counter
XV. Timer
56 | 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.
57 | 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.
REQ-4: If the player completes the game, the game will end and return the player to the title
screen.
58 | P a g e

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.
59 | 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.
60 | 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.
61 | P a g e

3.2.7 Suspicious Meter
3.2.7.1 Descriptions and Priority
Suspicious will be visible in the play screen. It is used for the measurement of game score. The
more the player makes people suspicious the less is the score and so to get maximum points 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 points 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 an 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.
62 | 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.
63 | 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.
64 | P a g e

3.2.11 Exit Point
Exit point is the finishing place of the game. The player needs to lead the ghost to this point to
win the game. But of course with a key which is required to move to the next stage.
Step 1: The player collects the key.
Step 2: Moves the Ghost to the exit point.
Step 3: The Level Complete Screen is showed and options comes to player o Play Next Level or
to Exit to Main Menu.
REQ-1: Key must be collected to finish the game.
REQ-2: Exit point must be in reach of the Ghost.
3.2.12 Hide Ghost
This is a special function for the ghost baby. He can hide from human civilians under table and
also inside cup-board. This function is only available for some specific furniture. When the ghost
goes in touch with those furniture, tip box appears which tells the player that he can hide the
ghost under it.
Step 1: The player finds that a civilian is coming close to the ghost.
Step 2: He moves the ghost to the hiding furniture fast.
65 | P a g e

Step 3: He hides the ghost in it by pressing interaction key of the game.
REQ-1: Ghost must come in touch with the hiding place.
REQ-2: The hiding place must be ready for hiding the ghost.
3.2.13 Laser Grid
Laser grids 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 grid by getting it touch of it. If
the ghost gets in touch of it, the player will lose the game. There will be switch for grids to turn
it off. So, the player can turn it off and then go to that particular section.
Step 1: The player notices the grid and moves away from it.
Step 2: Player turns the grid of using the switch of it.
Step 3: If player can survive from being caught in grid he can successfully leave the section.
Step 4: Otherwise, grid catches the ghost and game is finished.
REQ 1: Grid must be active and always keep blinking in its particular area.
REQ 2: Grid must consistently update its current state.
REQ 3: If it catches the ghost in its area, it forces to abort the scene.
66 | P a g e

3.2.14 Food Counter
There will be food here and there in the scene for the ghost which he needs to collect. Food
collection is used for the measurement of game score. The more the player collects food, the
more points he gets.
Step 1: Player notices food in a certain place
Step 2: He moves ghost to the place
Step 3: Ghost automatically collects food when gets in touch of it.
REQ 1: Store ghost collections during the game
REQ 2: Calculate points depending on total food collected
3.2.15 Timer
There will be a timer in the scene for keeping track of the time player takes to finish the level.
This timer is used for the measurement of game score. The less time the player takes, the more
points he gets.
Step 1: Timer starts automatically at game begin.
Step 2: Player finishes the game.
Step 3: Timer stops.
67 | P a g e

REQ 1: Keep track of taken time of the game.
REQ 2: Calculate points depending on timer.
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)
68 | 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 of the Project
Major Project
activities
69 | P a g e
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

Graphics Design
70 | P a g e
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 game play
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

3.5 Implementation Tools Required
71 | P a g e
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

3.6 Implementation Code Example
Level Complete Score Board Code
We have a number of features that affect the score of the game. These features are –
o Suspicious Meter
o Food Counter
o Timer
So, while scoring, we took all of them in account. We also created a proper fancy LEVEL
COMPLETION MENU for showing the total score in addition with the separate scores in these
three fields. So we are presenting the code for it (using language C#) as an example of
implementation codes.
using UnityEngine;
using System.Collections;
public class LevelComplete : MonoBehaviour {
private GameObject player;
private DonePlayerInventory playerInventory;
public bool levelComplete = false;
private float widthProportion, heightProportion, x, y, width, height, labelWidthProportion, labelHeightProportion, remainingPortion;
private float time;
private int timeBonus, foodCollected, suspicious , totalScore;
private string timeFormatted, suspicionFormatted, totalScoreFormatted;
public GUIStyle style;
public Texture2D image;
public Texture2D line;
private progessBar progress;
private Tips tips;
void Start () {
72 | P a g e
progress = GameObject.Find("Camera_main").GetComponent<progessBar>();
player = GameObject.FindGameObjectWithTag(DoneTags.player);
playerInventory = player.GetComponent<DonePlayerInventory>();
tips = GameObject.Find("Camera_main").GetComponent<Tips>();
}
void OnGUI () {
if( levelComplete == true ) {
time= 600 - Time.timeSinceLevelLoad;
if(time <= 0)
timeBonus = 0;
else timeBonus = (int)(time) * 1000;
suspicious = (int) progress.suspicionNo * 2000;
foodCollected = (int) playerInventory.hasFood * 15000;
totalScore = timeBonus + foodCollected - suspicious;
totalScoreFormatted = string.Format("{0:#,###0}", timeBonus);

73 | P a g e
suspicionFormatted = string.Format("{0:#,###0}", suspicious);
totalScoreFormatted = string.Format("{0:#,###0}", totalScore);
widthProportion = 0.7f;
heightProportion = 0.8f;
labelWidthProportion = 0.8f;
labelHeightProportion = 0.01f;
remainingPortion = 1 - (labelHeightProportion * 8);
x = (Screen.width*(1-widthProportion))/2;
y = (Screen.height*(1-heightProportion))/2;
width = Screen.width*widthPortion;
height = Screen.height*heightPortion;
GUI.BeginGroup(new Rect(x, y, width, height));
GUI.Box( new Rect( 0, 0, width, height ), "" );
GUI.Label( new Rect( (width*(1-labelWidthProportion))/2, ((remainingPortion/9)*height),
width*labelWidthProportion, height*labelHeightProportion), "Level Complete!", style);
GUI.DrawTexture(new Rect( width/2 - 25, 0, 50, 40), image);
GUI.Label( new Rect( (width*(1-labelWidthProportion))/2, (height*labelHeightProportion) +
((remainingPortion*2/9)*height), width*labelWidthProportion, height*labelHeightProportion), "Score Board", style);
((remainingPortion*3/9)*height), width*labelWidthProportion/2, height*labelHeightProportion), "Time Bonus (+)", style);
((remainingPortion*4/9)*height), width*labelWidthProportion/2, height*labelHeightProportion), "Food Collected (+)", style);
((remainingPortion*5/9)*height), width*labelWidthProportion/2, height*labelHeightProportion), "Suspicion Arise (-)", style);
GUI.DrawTexture(new Rect( (width*(1-labelWidthProportion))/4, (height*labelHeightProportion) +
((remainingPortion*5.5f/9)*height), width*labelWidthProportion/2, height*labelHeightProportion), line);
((remainingPortion*6/9)*height), width*labelWidthProportion/2, height*labelHeightProportion), "TotalScore", style);
GUI.Label( new Rect( (width*(1-labelWidthProportion))/4 + width*labelWidthProportion/2,
(height*labelHeightProportion) + ((remainingPortion*3/9)*height), width*labelWidthProportion/2, height*labelHeightProportion),
totalScoreFormatted, style);
GUI.Label( new Rect( (width*(1-labelWidthProportion))/4 + width*labelWidthProportion/2 ,
playerInventory.hasFood + " X 15,000", style);
suspicionFormatted, style);
GUI.DrawTexture(new Rect((width*(1-labelWidthProportion))/4 + width*labelWidthProportion/2,
(height*labelHeightProportion) + ((remainingPortion*5.5f/9)*height), width*labelWidthProportion/2, height*labelHeightProportion), line);
totalScoreFormatted, style);
if( GUI.Button ( new Rect( 0 ,height - height * 0.2f, width/4, height * 0.2f), "Play Next Level")) {
Application.LoadLevel("Level2");
}
if( GUI.Button ( new Rect( width - width/4,height - height * 0.2f, width/4, height* 0.2f), "Quit")) {
Application.LoadLevel("menu");
}
GUI.EndGroup();
}
}
void OnTriggerStay (Collider other) {
if(other.gameObject == player) {
if(playerInventory.hasKey) {
levelComplete = complete();
}
else {

74 | P a g e
tips.GUIEnable = true;
tips.tipsNo = 4;
}
}
}
bool complete() {
if(Time.timeScale == 0f) {
Time.timeScale = 1f;
return(false);
}
else {
Time.timeScale = 0f;
return(true);
}
}
}
Hiding Inside Code
As we mentioned in the system feature part, we also has a hiding feature for the ghost baby.
So, the code for the hiding is given below as another code example.
using UnityEngine;
using System.Collections;
public class HideInside : MonoBehaviour {
public AudioClip keyGrab;
private Vector3 playerposition;
private GameObject player;
private PlayerVisibility playerVisibility;
private bool buttonDown = false;
private Tips tips;
void Awake () {
player = GameObject.FindGameObjectWithTag(DoneTags.player);
playerVisibility = player.GetComponent<PlayerVisibility>();
tips = GameObject.Find("Camera_main").GetComponent<Tips>();
}
void OnTriggerStay (Collider other) {
if(other.gameObject == player) {
if(playerVisibility.isVisible == true) {
tips.GUIEnable = true;
tips.tipsNo = 1;
}
else tips.GUIEnable = false;
if(Input.GetButtonDown("Switch")) {
playerposition = player.transform.position;
buttonDown = true;

75 | P a g e
}
else if(playerposition!= Vector3.zero && !playerVisibility.isVisible)
player.transform.position = playerposition;
if(Input.GetButtonUp("Switch")) {
if(buttonDown) {
if(playerVisibility.isVisible == true)
HidePlayer();
else
UnhidePlayer();
buttonDown =false;
}
}
else if(playerposition!=Vector3.zero && !playerVisibility.isVisible)
player.transform.position = playerposition;
}
}
void HidePlayer () {
AudioSource.PlayClipAtPoint(keyGrab, transform.position);
player.transform.FindChild("char_ethan_body").renderer.enabled = false;
playerVisibility.isVisible = false;
player.GetComponent<DonePlayerMovement>().enabled = false;
}
void UnhidePlayer () {
AudioSource.PlayClipAtPoint(keyGrab, transform.position)
player.transform.FindChild("char_ethan_body").renderer.enabled = true;
playerVisibility.isVisible = true;
player.GetComponent<DonePlayerMovement>().enabled = true;
}
}

Chapter – 4: Testing of “Ghost in the Town”
76 | P a g e

This chapter includes some test cases for the game to check if the game works properly in
various situations. We are giving four test examples for four different situations here.
4.1 Test Case 1
Test Case : This test will check if the animation is working
77 | P a g e
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.

4.2 Test Case 2
Test Case : This test will check if the interaction between objects is
78 | P a g e
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.

4.3 Test Case 3
Test Case : This test will check if the dialogue box is 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.
4.4 Test Case 4
Test Case : This test will check if the automatic door opens when
79 | P a g e
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 ghost’s presence and
opens.

Chapter – 5: User Manual of “Ghost in the Town”
80 | P a g e

This chapter provides a user instruction for the players. It includes the procedure of playing and
also contains some snapshots to give some ideas of the game to the player before starting
playing it.
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 littl e
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
82 | P a g e
Fig 37: Unity view of main menu (curser is on start button)
Fig 38: Play menu with its options

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

84 | P a g e
Fig 41: Bed Room with Character Sleeping
Fig 42: Drawing room

85 | P a g e
Fig 43: Study room
Fig 44: House yard

86 | P a g e
Fig 45: CCTV Camera
Fig 46: Street

87 | P a g e
Fig 47: Overall Construction view of level 1
Fig 48: Game View with suspicious meter, timer, food counter

88 | P a g e
Fig 49: Finishing Cube
Fig 50: Collectable Object (Apple)

89 | P a g e
Fig 51: Our main character (Ghost - Ethan)
Fig 42: Ethan, ready to hide under table

90 | P a g e
Chapter – 6: 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!
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 an 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.
91 | P a g e

6.3 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
6.4 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.
92 | 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 BalazsLichtl 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
94 | 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
95 | P a g e
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.

Final project report of a game

More Related Content

What's hot (20)

Similar to Final project report of a game (20)

More from Nadia Nahar (19)

Recently uploaded (20)

Final project report of a game