Final project report of a game

1 | P a g e

Chapter – 1: The Project Plan of “Ghost in the

Town”

2 | P a g e

This chapter covers the project proposal and feasibility of the proposal along with background

study, product and business perspective, the scopes and some preliminary idea of our game.

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.

3 | 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

http://en.wikipedia.org/wiki/Literary_device

4 | 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

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”

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

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 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.

7 | 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.

8 | 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.

9 | 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.

Input Manager

(Keypad/game pad)

Script

(Compile)

Renders

(Display)

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

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.

11 | 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”.

12 | 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.

13 | 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.

14 | 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).

15 | 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).

16 | P a g e

Level – 0 Level – 1 Level – 2

Game ( Ghost in the Town )

Play

New Game

Resume Game

Select Level

Exit Game

Options

Show Control

Change Configuration (Graphics)

Change Sound/ Music Volume

Score Board

View Scores

Reset Score Board

Story View Story

Quit -

17 | P a g e

2.4.1.2 Use Case Diagram with Use Case Description

Game (Ghost

in the Town) System

Fig 1: Level 0 for Game

UX

Quit

Story

Action Object

Score Board

Options

Play

Player

Player

Fig 2: Level 1 for Game UX

18 | P a g e

Exit Game

Action Object

Select Level

Resume Game

New Game

Player

Fig 3: Level 2.1(Play) for Game UX

19 | 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.

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

20 | 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



21 | 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



22 | 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



23 | 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



24 | P a g e

Action Object

Change Sound

/ Music

Volume

Change

Graphics

Show

Controls

Player

Fig 4: Level 2.2(Options) for Game UX

25 | 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.

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



26 | 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

27 | 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


28 | P a g e

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

Action Object

Reset

View

Player

Fig 5: Level 2.3(Score Board) for Game

UX

29 | P a g e

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


30 | 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


31 | 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


32 | 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.



33 | P a g e

2.4.1.3 Activity Diagram

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)

40 | P a g e

2.4.1.4 Swimlane Diagram

Fig 17: Swimlane Diagram for “New Game” module of “Play” (Fig 3)

Background Programming UX

Go to Main Menu

Click Resume Game

Last Played Level loaded

UX Background Programming

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

Fig 20: Swimlane Diagram for “Exit Game” module of “Play” (Fig 3)

Fig 19: Swimlane Diagram for “Select Level” module of “Play” (Fig 3)


Go to Main Menu

Click Select Level

Selected Level Loaded

Select a Level


Press Pause Game

Pause Menu Appears

Game Exited

Click Exit Game

42 | P a g e

Fig 22: Swimlane Diagram for “Change Graphics” module of “Options” (Fig 4)

Fig 21: Swimlane Diagram for “Show Controls” module of “Options” (Fig 4)


Go to Main Menu

Options Menu Appears

Controls Showed

Click Show Controls

Click Options


Go to Main Menu


Updated

Set Value on Graphics Slider

Click Options

43 | P a g e

Fig 23: Swimlane Diagram for “Change Sound/ Music Volume” module of “Options” (Fig 4)


Go to Main Menu


Volume Changed

Set Value on Volume Slider

Click Options


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


Go to Main Menu

Click Story

Game Story Played

Fig 25: Swimlane Diagram for “Reset” module of “Score Board” (Fig 5)

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)

46 | 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.

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.

47 | P a g e

2.4.3.1 State Diagram

Idle Open

Game

Splash

Screen

Main

Menu

from Level Select, Level Complete, and In Game Menus in Play Level

Checking

Do: isclicked

“Play” “Quit” “Options”

Close

Game

Options

Menu

Play

Menu

“Select Level”

To level select menu

To idle

“Return” “Controls” “Sound/Music” “Graphics”

Adjust Check

Fig 28: top level state diagram

48 | P a g e

“Next Level”

Checking

Do: isclicked

Level Select

Menu

To main menu

“Return”

Play Level

“Level X”

Checking

Do: isclicked “In Game Menu” “Level Complete”

Level Complete Menu In Game Menu

Checking

Do: isclicked “Main Menu”

Next Level Menu To main menu

Checking

Do: isclicked “Resume”

Fig 29: play level state diagram

49 | P a g e

2.4.3.2 Sequence Diagram

Click resume

game

Open game

Click new game

Open game

Backend UX

Fig 30: Sequence diagram (New Game)

Level 1

Loaded

Fig 31: Sequence diagram (Resume Game)

Level

Loaded

level returned

lookup

Active Object Backend UX

Checking

50 | P a g e

Press Game Pause

Playing game

select level X

Click select level

Open game

Taking input

Fig 32: Sequence diagram (Select Level)

Click back to main menu

Fig 33: Sequence diagram (Exit Game)

Main Menu

Appears

Pause Menu

Appears

Backend UX

Level X

Loaded

Level Select

Menu

Backend UX

51 | P a g e

Click Options

Click options

Open game

Open game

Change graphics/

sound/ music

Fig 34: Sequence diagram (Show Control)

Controls

Showed

Click back to show

controls

Option Menu

Appears

Backend UX

Fig 35: Sequence diagram (Change Graphics/Sound/Music)

Option Menu

Appears


Updated

52 | P a g e

Lookup information Click Score Board

Open game

Fig 36: Sequence diagram (View and Reset Score Board)

Click Reset

Score Board

Appears


Change graphics/

sound/ music

Updated

53 | 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

[email protected].

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.

54 | P a g e

Chapter – 3: Design and Implementation of

“Ghost in the Town”

55 | P a g e

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”.

56 | 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

57 | 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.

58 | 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.

59 | 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.

60 | 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.

61 | 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.

62 | 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.

63 | 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.

64 | 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.

65 | 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.

66 | 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.

67 | 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.

68 | 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)

69 | 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

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

70 | P a g e

Graphics Design

Knowledge of

graphical modeling

and

implementation

Arif and Nadia

worked for

creating 3d

models

3d model design

using Maya and

3dsMax

Visibility of the details

on the 3d models

Music

Development/

Implementation

Ability to

incorporate sound

clips smoothly into

the game

- Sound clips from

the Internet

Ability to play sound

clips at precious times

during 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

71 | P a g e

3.5 Implementation Tools Required

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

72 | P a g e

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 () { 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); GUI.Label( new Rect( (width*(1-labelWidthProportion))/4, (height*labelHeightProportion) + ((remainingPortion*3/9)*height), width*labelWidthProportion/2, height*labelHeightProportion), "Time Bonus (+)", style); GUI.Label( new Rect( (width*(1-labelWidthProportion))/4, (height*labelHeightProportion) + ((remainingPortion*4/9)*height), width*labelWidthProportion/2, height*labelHeightProportion), "Food Collected (+)", style);

GUI.Label( new Rect( (width*(1-labelWidthProportion))/4, (height*labelHeightProportion) + ((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); GUI.Label( new Rect( (width*(1-labelWidthProportion))/4, (height*labelHeightProportion) + ((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 , (height*labelHeightProportion) + ((remainingPortion*4/9)*height), width*labelWidthProportion/2, height*labelHeightProportion), playerInventory.hasFood + " X 15,000", style); GUI.Label( new Rect( (width*(1-labelWidthProportion))/4 + width*labelWidthProportion/2, (height*labelHeightProportion) + ((remainingPortion*5/9)*height), width*labelWidthProportion/2, height*labelHeightProportion), 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); GUI.Label( new Rect( (width*(1-labelWidthProportion))/4 + width*labelWidthProportion/2, (height*labelHeightProportion) + ((remainingPortion*6/9)*height), width*labelWidthProportion/2, height*labelHeightProportion), 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<PlayerVisibil ity>(); 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 && !playerVisibil ity.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 && !playerVisibil ity.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;

}

}

76 | P a g e

Chapter – 4: Testing of “Ghost in the Town”

77 | 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

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.

78 | P a g e

4.2 Test Case 2

Test Case : This test will check if the interaction between objects is

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.

79 | P a g e

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

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.

80 | P a g e

Chapter – 5: User Manual of “Ghost in the Town”

81 | 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.

82 | P a g e

5.2 Some Snapshots

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

91 | 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”.

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.

92 | 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.

93 | P a g e

Appendix

94 | 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

http://www.mixamo.com/

http://thefree3dmodels.com/stuff

http://www.unity3dstudent.com/

http://students.autodesk.com/

http://www.digitaltutors.com/11/index.php

http://library.creativecow.net/articles/3dsmax.html

http://www.good-tutorials.com/tutorials/3ds-max/animation

http://www.youtube.com/

http://archive3d.net/

http://cgcookie.com/unity/

95 | P a g e

Appendix B: Abbreviation and Acronyms

Term Definition

Game engine A game engine is a system designed for the creation and development of video games.

UX User experience (UX or UE) involves a person's emotions about using a particular product,

system or service.

Animation Animation is the rapid display of a sequence of images to create an illusion of movement.

Android Android (Google product) is a Linux-based operating system.

Scripting

A scripting language or script language is a programming language that supports the writing

of scripts, programs written for a special runtime environment that can interpret and

automate the execution of tasks which could alternatively be executed one-by-one by a

human operator.

Graphics Graphics are visual presentations on some surface, such as a wall, canvas, screen, paper, or

stone to brand, inform, illustrate, or entertain

3d Model

In 3D computer graphics, 3D modeling is the process of developing a mathematical

representation of any three-dimensional surface of object (either inanimate or living) via

specialized software.

SRS Software Requirements Specification

UI User Interface

Gamer A person who plays a game or games, typically a participant in a computer or role-playing

game.

System

A system is a set of interacting or interdependent components forming an integrated whole

or a set of elements (often called ‘components’) and relationships which are different from

relationships of the set or its elements to other elements or sets.