Town”
1|Pag 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.
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|Pag 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.
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.
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|Pag 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.
We have found the planning of this project here which now leads us to the specification part of
the project.
4|Pag e
Chapter – 2: Software Requirements
Specification of “Ghost in the Town”
5|Pag e
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.
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.
This document will freely interchange the pronoun “we” with the team’s acronym. As the
development team is responsible for the SRS doc ument, 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|Pag 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.
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|Pag 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.
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|Pag e
2.2.2 System Environment
Gamer
Input Manager
(Keypad/game pad)
Script
(Compile)
Renders
(Display)
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).
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|Pag e
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:-
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.
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:
“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.
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.
“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.
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.
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.
This Model depicts how the user interacts with the system and the specific sequence of
activities that occur as the software is used.
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
New Game
Resume Game
Play
Select Level
Exit Game
Show Control
View Scores
Score Board
Reset Score Board
Quit -
16 | P a g e
2.4.1.2 Use Case Diagram with Use Case Description
Play
Options
Score Board
Story
Player
Quit
Action Object
Resume Game
Select Level
Exit Game
Player
Action Object
18 | P a g e
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.
Precondition:
2. The file has been triggered to run and the game screen has appeared
Scenario:
19 | P a g e
ii.
Precondition:
Scenario:
Exception:
2. Game crushed
20 | P a g e
iii.
Precondition:
Scenario:
3. Select a level
21 | P a g e
iv.
Precondition:
Scenario:
7. Select a level
22 | P a g e
v.
Scenario:
23 | P a g e
Show
Controls
Change
Graphics
Change Sound
/ Music
Player
Volume
Action Object
24 | P a g e
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.
Scenario:
25 | P a g e
ii.
Precondition:
Scenario:
4. Game is updated
Priority: Expected
26 | P a g e
iii.
Scenario:
Priority: Expected
27 | P a g e
View
Player Reset
Action Object
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.
28 | P a g e
Precondition:
Scenario:
3. Select a level
Exception:
Priority: Expected
29 | P a g e
ii.
Precondition:
Scenario:
Exception:
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.
Precondition:
Scenario:
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
Scenario:
3. Game is exited
32 | P a g e
2.4.1.3 Activity Diagram
Go to Main Menu
Level-1 loaded
Go to Main Menu
33 | P a g e
Go to Main Menu
Select a Level
Game Exited
34 | P a g e
Go to Main Menu
Click Options
Controls Showed
Fig 10: Activity Diagram for “Show Controls” module of “Options” (Fig 4)
35 | P a g e
Go to Main Menu
Click Options
Updated
Fig 11: Activity Diagram for “Change Graphics” module of “Options” (Fig 4)
36 | P a g e
Go to Main Menu
Click Options
Volume Changed
Fig 12: Activity Diagram for “Change Sound/ Music Volume” module of
“Options” (Fig 4)
37 | P a g e
Go to Main Menu
Select a Level
Rank Showed
Fig 13: Activity Diagram for “View” module of “Score Board” (Fig 5)
Go to Main Menu
Click Reset
Fig 14: Activity Diagram for “Reset” module of “Score Board” (Fig 5)
38 | P a g e
Go to Main Menu
Click Story
Go to Main Menu
Click Quit
Game Exited
39 | P a g e
2.4.1.4 Swimlane Diagram
UX Background Programming
Go to Main Menu
Level-1 Loaded
Fig 17: Swimlane Diagram for “New Game” module of “Play” (Fig 3)
UX
UX Background Programming
Background Programming
Go to Main Menu
40 | P a g e Fig 18: Swimlane Diagram for “Resume Game” module of “Play” (Fig 3)
UX Background Programming
Go to Main Menu
Select a Level
Fig 19: Swimlane Diagram for “Select Level” module of “Play” (Fig 3)
UX Background Programming
Game Exited
Fig 20: Swimlane Diagram for “Exit Game” module of “Play” (Fig 3)
41 | P a g e
UX Background Programming
Go to Main Menu
Controls Showed
Fig 21: Swimlane Diagram for “Show Controls” module of “Options” (Fig 4)
UX Background Programming
Go to Main Menu
Updated
Fig 22: Swimlane Diagram for “Change Graphics” module of “Options” (Fig 4)
42 | P a g e
UX Background Programming
Go to Main Menu
Volume Changed
Fig 23: Swimlane Diagram for “Change Sound/ Music Volume” module of “Options” (Fig 4)
UX Background Programming
Go to Main Menu
Select a Level
Rank Showed
Fig 24: Swimlane Diagram for “View” module of “Score Board” (Fig 5)
43 | P a g e
UX Background Programming
Go to Main Menu
Click Reset
Fig 25: Swimlane Diagram for “Reset” module of “Score Board” (Fig 5)
UX Background Programming
Go to Main Menu
Click Story
Go to Main Menu
Click Quit
Game Exited
45 | 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. 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.
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 Main
Screen Menu
Adjust Check
Checking
Do: isclicked
“Level X” “Return”
To main menu
Play Level
Checking
Do: isclicked
“Level Complete” “In Game Menu”
Checking Checking
To main menu
Next Level Menu
Fig 29: play level state diagram
48 | P a g e
2.4.3.2 Sequence Diagram
UX Backend
Open game
Open game
Click resume Checking lookup
game
level returned
Level
Loaded
49 | P a g e
UX Backend
Open game
Level X
Loaded
UX Backend
Playing game
Pause Menu
Click back to main menu Appears
Main Menu
Appears
Open game
Click options
Option Menu
Click back to show Appears
controls
Controls
Showed
Open game
Click Options
Option Menu
Appears
Change graphics/
sound/ music
Updated
51 | P a g e
UX Backend Active Object
Open game
Change graphics/
sound/ music
Score Board
Appears
Click Reset
Updated
52 | P a g e
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.
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
“Ghost in the Town”
54 | P a g e
This chapter covers the project design phases, the system features and also the implementation
of the features.
For every enterprise product two key terms of design is very important. They are:
UX (User Experience)
Backend Programming
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,
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.
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
Step 2: If player can survive from being camera target he can successfully leave the section.
REQ 3: If it catches the ghost in its area, it forces to abort the scene.
57 | P a g e
3.2.2.3 Functional Requirements
REQ 1: It must be continuously updated about the objects near it.
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-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
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-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
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
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.
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.8 Flying
62 | P a g e
Step 4: Ghost falls.
REQ 3: Flying should take into account the current vertical and horizontal velocities.
3.2.9 Disguise
63 | P a g e
3.2.10 Dialogue or Tips
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-2: Text boxes and floating text should be brief and placed away from UI components so as
not to interfere with game-play.
64 | P a g e
3.2.11 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.
65 | P a g e
Step 3: He hides the ghost in it by pressing interaction key of the game.
REQ-2: The hiding place must be ready for hiding the ghost.
Step 3: If player can survive from being caught in grid he can successfully leave the section.
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
3.2.15 Timer
67 | P a g e
3.2.7.3 Functional Requirements
REQ 1: Keep track of taken time of the game.
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.
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.
All three
Ability to translate
members made Ideas from
aspects of the Conflicting ideas per
Level Design the decision existing games
story into playable level
about game (Ex. Stealth)
levels
levels together
Knowledge of
Nadia and
functions available Ability to angle
Tahmid worked Unity game
Physics Engine in Unity and the interactive portions of
on Unity game engine
ability to change levels
engine
them as needed
69 | P a g e
Knowledge of Arif and Nadia
3d model design
graphical modeling worked for Visibility of the details
Graphics Design using Maya and
and creating 3d on the 3d models
3dsMax
implementation models
Ability to
Music Ability to play sound
incorporate sound Sound clips from
Development/ - clips at precious times
clips smoothly into the Internet
Implementation during game play
the game
All members
Familiarity with have some Background Level size dependent
Level
scripting language knowledge about images from the on hardware
Implementation
of game engine scripting internet configuration
language
Idea from
Knowledge about Arif and Nadia Game Reports are
Existing Reports
Documentation SRS and Formal worked more on Different from
(Ex. IITDU Online
Report Writing Reporting Conventional ones
Judge System)
70 | P a g e
3.5 Implementation Tools Required
Unity
Unity3d Game Engine Backend activity
Technologies
Graphics
Create 3d Model
3ds Max Design and
and Animate
Animation
Autodesk
Graphics
Maya Design and Create 3d Model
Animation
71 | P a g e
3.6 Implementation Code Example
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;
void Start () {
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);
72 | 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 ), "" );
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();
}
}
73 | 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);
}
}
}
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;
void Awake () {
player = GameObject.FindGameObjectWithTag(DoneTags.player);
playerVisibility = player.GetComponent<PlayerVisibility>();
tips = GameObject.Find("Camera_main").GetComponent<Tips>();
}
if(Input.GetButtonDown("Switch")) {
playerposition = player.transform.position;
buttonDown = true;
74 | 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;
}
75 | P a g e
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.
77 | P a g e
4.2 Test Case 2
Test Case : This test will check if the interaction between objects is
working correctly.
Comment : Need to add checking in the scripts for the objects that
have a particular script.
78 | P a g e
4.3 Test Case 3
Test Case : This test will check if the dialogue box is working.
Test Case : This test will check if the automatic door opens when
ghost is around
79 | P a g e
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.
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 39: Pause menu while playing the game
83 | P a g e
Fig 41: Bed Room with Character Sleeping
84 | P a g e
Fig 43: Study room
85 | P a g e
Fig 45: CCTV Camera
86 | P a g e
Fig 47: Overall Construction view of level 1
Fig 48: Game View with suspicious meter, timer, food counter
87 | P a g e
Fig 49: Finishing Cube
88 | P a g e
Fig 51: Our main character (Ghost - Ethan)
89 | P a g e
Chapter – 6: Conclusion
90 | P a g e
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”.
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!
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
We learned a lot through this project. This project has sharpened our concept of Game engine,
animation and the software-hardware interface.
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
93 | 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 28 th 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.
User experience (UX or UE) involves a person's emotions about using a particular product,
UX
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.
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
Scripting
automate the execution of tasks which could alternatively be executed one-by-one by a
human operator.
Graphics are visual presentations on some surface, such as a wall, canvas, screen, paper, or
Graphics
stone to brand, inform, illustrate, or entertain
In 3D computer graphics, 3D modeling is the process of developing a mathematical
3d Model representation of any three-dimensional surface of object (either inanimate or living) via
specialized software.
SRS Software Requirements Specification
UI User Interface
A person who plays a game or games, typically a participant in a computer or role-playing
Gamer
game.
A system is a set of interacting or interdependent components forming an integrated whole
System 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.
95 | P a g e