Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Final project report of a game

Final project report of a game named "Ghost in the Town"

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

Final project report of a game

  1. 1. Chapter – 1: The Project Plan of “Ghost in the 1 | P a g e Town”
  2. 2. This chapter covers the project proposal and feasibility of the proposal along with background study, product and business perspective, the scopes and some preliminary idea of our game. 1.1 Gaming in the Field of Software Engineering In the fast growing field of software engineering and development and even more rapidly growing sector of game development the future is hard to predict. We are working with this game as our software project lab-II.SPL-II is a 3 credit course and as part of our degree we choose this type of work for doing better with development cycle, development period, graphics, scripting, adopting new technology, animation. In general software project is a project focusing on the creation of software. Consequently, Success can be measured by taking a look at the resulting software. In a game project, the product is a game. But and here comes the point: A game is much more than just its software. It has to provide content to become enjoyable. Just like a web server: without content the server is useless, and the quality cannot be measured. This has an important effect on the game project as a whole. The software part of the project is not the only one, and it must be considered in connection to all other parts: The environment of the game, the story, characters, game plays, the artwork, and so on. 2 | P a g e
  3. 3. 1.2 Background of this Project Background is a set of events invented for a plot, presented as preceding and leading up to that plot. It is a literary device of a narrative history all chronologically earlier than the narrative of primary interest. In our project it’s a single player strategy game emphasizing logical thinking and planning. They often stress resource and time management, which usually takes precedence over fast action and character involvement. Tactical organization and execution are necessary, and the game creators usually place the decision-making skills and delivery of commands in the player’s hands. 1.3 About the Project It’s a complete strategy game with different levels. The main character of ‘Ghost in the Town’ is a little ghost who loses its parents in a human neighborhood. The baby is afraid of people and hasn’t adopted many ghost tricks yet. So it’s difficult for it to return to its parents. Now it must find food and keep itself hidden in a crowded town. The main mission of the gamer is to use his logic and save the ghost. There are several levels and in each level the gamer must hide the ghost from people and feed it. 1.4 Scope of Our Game This Report describes all the requirements for the project. The purpose of this research is to provide a virtual image for the combination of both structured and unstructured information of our project “Ghost in the Town”. “Ghost of the Town” is a single-player strategy game on the Android platform. The player will progress through levels which require precise manipulation of the environment, though the game Encourages creativity and daring via branching pathways. The episodic structure of the game facilitates the pace of the story. We demonstrate the action 3 | P a g e
  4. 4. flow between inputs, script, display (output). We are working mainly with story, levels, object, animation, graphics, scripts, game engine facilities. We are not working with web launching, free hand programming, carton making. 1.5 Project Scheduling Start Date End Date Project states and Objective January 15 January 25 Project Proposal, meeting with supervisor about 4 | P a g e our idea January 26 February 15 Planning , thinking about game story , levels and Learning Technology February 16 March 07 Construct SRS document, choose tools, and environment March 08 March 20 Start designing and implementation March 21 April 08 Developing, Testing and enhancement running with writing the report April 09 May 28 Final revision of the report and testing on the constructing level/levels. June 06 Project submission We have found the planning of this project here which now leads us to the specification part of the project.
  5. 5. 5 | P a g e Chapter – 2: Software Requirements Specification of “Ghost in the Town”
  6. 6. This chapter covers the requirements specification of our game “Ghost in the Town”. It includes the specification of this documentation with general description, specific requirements, and analysis of models. It also includes changes management of this requirement specification in case of any change. 2.1 Introduction In this section the documentation of this report is specified. It specifies the document convention, document scope and also provides a suggestion for the readers of the document. 2.1.1 Purpose of this Chapter This Software Requirements Specification (SRS) part is intended to give a complete overview of our Project the game “Ghost in the Town” including the action flow, initial user interface and story therein. The SRS document details all features upon which we have currently decided with reference to the manner and importance of their implementation. 2.1.2 Document Conventions This document will freely interchange the pronoun “we” with the team’s acronym. As the development team is responsible for the SRS document, no ambiguity arises from its usage. There is a clear distinction, however, between the use of the words “player/gamer” and “character.” The “player” is the human being interacting with the game in the real world, while the “character” is the in-game player avatar being manipulated. 6 | P a g e
  7. 7. 2.1.3 Intended Audience and Reading Suggestions The SRS document also gives project managers a way to ensure the game’s adherence to our original vision. Although the document may be read from front to back for a complete understanding of the project, it was written in sections and hence can be read as such. For an overview of the document and the project itself, see Overall Description. For a detailed description of the game-play elements and their interaction with the character, read System Features. Readers interested in the game-play interface and navigation between different front-end menus should go through External Interface Requirements. Technical standards to which the team will hold the project are laid out in Other Nonfunctional Requirements. The development schedule, meanwhile, will be maintained in the Key Milestones. 2.1.4 Scope of this Document This Software Requirements Specification (SRS) describes the functional and nonfunctional requirement for the project. As we said before the purpose of this research is to provide a virtual image for the combination of both structured and unstructured information of our project “Ghost in the Town”. Project “Ghost in the Town” was conceived by the 3 of our team members as having an anticipated development cycle greater than the length of the semester. The team wishes to carry on the project until its completion. The game will continue to grow until we feel it satisfactory for open-source distribution. 7 | P a g e
  8. 8. 2.2 General Description This section includes the perspective of our product and the system environment it requires. It specifies the QFD (Quality Function Deployment) of our game and also the User Story of it. 2.2.1 Product and Business Perspective of the Game Software product development is a paradigm shift from routine application maintenance and support in the software industry. Development a game/software product from scratch is a significant challenge for any organization. It requires considerable investments in terms of effort and cost and also confirms client involvement, knowledge about client market (example: Google play). We have compiled some interesting articles from the web for you which should form the basis for a concluding public discussion about the future of the game industry. Please feel free to interrupt us any time and contribute your ideas. This will make our game much more lively and interesting. Here this report product perspective describes the overall description. 8 | P a g e
  9. 9. 2.2.2 System Environment Gamer Gamer can interact with system by giving input (press key to start game) to the system. System give those inputs to script, if any change occur (if the value is changed) this object send to renders to display the things (a character can change its place). 2.2.3 Quality Function Deployment of “Ghost in the Town” Quality Function Deployment is a technique that translates the needs of the customer into technical requirements for software/game. It concentrates on maximizing customer satisfaction from the Software engineering process .With respect to our project the following requirements are identified by a QFD. 9 | P a g e Input Manager (Keypad/game pad) Script (Compile) Renders (Display)
  10. 10. o Normal Requirements. o Expected Requirements. o Exciting requirements. Normal Requirements Normal requirements consist of objectives and goals that are stated during the meeting with the actor/gamer/relevant people. Normal requirements of our project are:- 1. User friendly efficient and lucrative system. 2. Minimum maintenance cost (may be graphics definition). 3. Availability of expected requirements within the PC/mobile configuration. 4. Easy to operate. 5. They observe our game as this is build with professional manner. 6. The game with measured coding, professional thinking. Expected Requirements These requirements are implicit to the system and may be so fundamental that the actor/gamer/ relevant people does not explicitly state them .Their absence will be a cause for dissatisfaction. 1. Develop system within limited cost. 2. Maximum high definition. 3. Minimum hardware requirements which is relevant for this game. 4. Design whole system with efficient manner. 10 | P a g e
  11. 11. Exciting requirements These requirements are for features that go beyond the customer's expectations and prove to be very satisfying when present: 1. We may provide some cheat codes. 2. Maximum high regulation with minimum hardware. 3. We may provide an international player rank list. 4. Easy to update. 2.2.4 User Story of Our Game “Ghost in the Town” is a strategy game. It is a multi-platform game which is supported by PC, web player, android phone, IOS and other platforms also. So the gamer can use any of these platforms to run the game. After running the game, the UX view of the game will appear on the screen. The term UX means User Experience which is used to explain all aspects of a person’s experience with a system. However, then the gamer can directly select “Start” from the “Main Menu” and start playing the game or may go to “Level Selection Menu” and select his/ her desired level. Gamer can also turn sound on/ off or change graphical settings. Gamer can also check controls of the game by going to “Control Menu” and see the “About Menu”. A “Story” is also provided with the game to understand the game objective. However, after starting a level the player will find helpful tips on the side of the screen and he/ she can follow it and enjoy the game. He may also interact with “Pause Menu” by pressing “Escape”. If he loses he can replay the level by pressing “Restart” or exit game by pressing “Quit” in the “Game Over Menu”. After finishing the game also, he will get option to “Play Next Level” or simply “Quit”. 11 | P a g e
  12. 12. 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
  13. 13. 2.3 Specific Requirements This section covers the project external requirements of our game and also indicates the user characteristics for this project. 2.3.1 External Interface Requirements of the Game 2.3.1.1 User Interfaces Every game must has a menu so is can be user friendly enough and gamers can easily fulfill their need. Menu is also an important thing while creating the SRS document section. In this SRS document part; we have used the menu snapshots in the user manual part. These snapshots are based on the menu of the game. 2.3.1.2 Hardware Interfaces “Ghost in the town” is a mobile gaming application designed specifically for the Android platform and is functional on both mobile smart phones and tablets. Gaming application data is stored locally on the game engine elements. “Ghost in the town” has been developed for Android developed Version and all subsequent releases. In the future we released in the android platform. Now the Android platform is graphically adaptable with a 2 dimensional graphics library and a 3 dimensional graphics library based on OpenGL ES 2.0 specifications as well as hardware orientation, scaling, pixel format conversion and accelerated 3D graphics. 13 | P a g e
  14. 14. 2.3.1.3 Software Interface “Ghost in the town” has been developed using a series of game development tools. Working tools and platform  Unity3D  Autodesk Maya  Autodesk 3ds Max  Android Software Development Kit (Android SDK) : Software development kit for applications on the Android platform. We want to release this game in the Android platform. 2.3.2 User Characteristics for the System There is only one user at a time in this software and the user interacts with the game (system) in different manner. So, Gamer is the only one who communicates with the system through playing the game. And this gamer can be any person. The primary requirement is that, the gamer must read the playing procedure provided by us (developers). 14 | P a g e
  15. 15. 2.4 Analysis Model of Our Game Project This section describes the Software Requirements Specification of our project by analyzing the proper models of requirement engineering. 2.4.1 Scenario Based Model This Model depicts how the user interacts with the system and the specific sequence of activities that occur as the software is used. 2.4.1.1 Use Case Scenario The following table summarizes the use cases of the system. We have created the use cases based on the UX view (mentioned in “User Story Part”) of the game. The swimlane diagram connects UX with background programming which are the two important views of a game SRS (Details of these two terms are in section 3.1). 15 | P a g e
  16. 16. Level – 0 Level – 1 Level – 2 Game ( Ghost in the Town ) 16 | P a g e Play New Game Resume Game Select Level Exit Game Options Show Control Change Configuration (Graphics) Change Sound/ Music Volume Score Board View Scores Reset Score Board Story View Story Quit -
  17. 17. 2.4.1.2 Use Case Diagram with Use Case Description 17 | P a g e Game (Ghost in the Town) System Fig 1: Level 0 for Game UX Play Options Score Board Story Quit Action Object Player Player Fig 2: Level 1 for Game UX
  18. 18. 18 | P a g e New Game Resume Game Select Level Exit Game Action Object Player Fig 3: Level 2.1(Play) for Game UX
  19. 19. This Diagram of Level 2.1(Fig 3) leads us to the “Play” module of the use cases. These use case descriptions are given here – Play i. Use case: New Game Primary Actors: Any one playing the game Goal in context: To start a new game Precondition: 1. System supports the game configuration 2. The file has been triggered to run and the game screen has appeared Triggers: The player needs to start a new game Scenario: 1. Go to the main menu of the game 2. Click new game button 3. New game is loaded on system Exception: Game crushed Priority: Essential, must be implemented When Available: First increment 19 | P a g e
  20. 20. ii. Use case: Resume Game Primary Actors: Any one playing the 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 Priority: Essential, must be implemented When Available: First increment 20 | P a g e
  21. 21. iii. Use case: Select Level Primary Actors: Any one playing the game 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 Priority: Essential, must be implemented When Available: First increment 21 | P a g e
  22. 22. iv. Use case: Select Level Primary Actors: Any one playing the game 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: 5. Go to the main menu 6. Click the select level button 7. Select a level 8. The level is loaded for play Exception: Level cannot be loaded Priority: Essential, must be implemented When Available: First increment 22 | P a g e
  23. 23. v. Use case: Exit Game Primary Actors: Any one playing the 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 Priority: Essential, must be implemented When Available: First increment 23 | P a g e
  24. 24. 24 | P a g e Show Controls Change Graphics Change Sound / Music Volume Action Object Player Fig 4: Level 2.2(Options) for Game UX
  25. 25. 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 Primary Actors: Any one playing the game 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: 1. Go to the main menu 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 Priority: Essential, must be implemented When Available: First increment 25 | P a g e
  26. 26. ii. Use case: Change Graphics Configuration Primary Actors: Any one playing the game 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: 1. Go to the main menu 2. Click on Options button 3. Click on Graphics slider and set the required value 4. Game is updated Exception: System doesn’t support given graphics configuration Priority: Expected When Available: Second increment 26 | P a g e
  27. 27. iii. Use case: Change Sound/ Music Volume Primary Actors: Any one playing the game 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: 1. Go to the main menu 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 When Available: Second increment 27 | P a g e
  28. 28. View Reset This Diagram of Level 2.3(Fig 5) connects with the “Score Board” module of the use cases. These use case descriptions are given here – Score Board i. Use case: View Scores Primary Actors: Anyone playing the game Goal in context: To see the score board 28 | P a g e Action Object Player Fig 5: Level 2.3(Score Board) for Game UX
  29. 29. 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: 1. Go to the main menu 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 When Available: Second increment 29 | P a g e
  30. 30. ii. Use case: Reset Score Board Primary Actors: Any one playing the game 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: 1. Go to the main menu 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 When Available: Second increment 30 | P a g e
  31. 31. 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 Primary Actors: Any one playing the game 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 When Available: Second increment 31 | P a g e
  32. 32. 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 Primary Actors: Any one playing the game 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: 1. Go to the main menu 2. Click Quit button 3. Game is exited Exception: Something went wrong. Cannot exit now. Priority: Essential, must be implemented When Available: First increment 32 | P a g e
  33. 33. 2.4.1.3 Activity Diagram 33 | P a g e Go to Main Menu Click New Game Level-1 loaded Fig 6: Activity Diagram for “New Game” module of “Play” (Fig 3) Go to Main Menu Click Resume Game Last Played Level loaded Fig 7: Activity Diagram for “Resume Game” module of “Play” (Fig 3)
  34. 34. 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. 35. 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. 36. 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. 37. 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. 38. 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. 39. 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. 40. 2.4.1.4 Swimlane Diagram 40 | P a g e UX Background Programming Fig 17: Swimlane Diagram for “New Game” module of “Play” (Fig 3) Background UX Programming Go to Main Menu Click Resume Game Last Played Level loaded Go to Main Menu Click New Game Level-1 Loaded Fig 18: Swimlane Diagram for “Resume Game” module of “Play” (Fig 3)
  41. 41. 41 | P a g e UX Background Programming Go to Main Menu Click Select Level Selected Level Loaded Select a Level Fig 19: Swimlane Diagram for “Select Level” module of “Play” (Fig 3) UX Background Programming Press Pause Game Pause Menu Appears Game Exited Click Exit Game Fig 20: Swimlane Diagram for “Exit Game” module of “Play” (Fig 3)
  42. 42. Click Options Fig 21: Swimlane Diagram for “Show Controls” module of “Options” (Fig 4) Click Options Fig 22: Swimlane Diagram for “Change Graphics” module of “Options” (Fig 4) 42 | P a g e UX Background Programming Go to Main Menu Options Menu Appears Controls Showed Click Show Controls UX Background Programming Go to Main Menu Options Menu Appears Updated Set Value on Graphics Slider
  43. 43. Click Options Fig 23: Swimlane Diagram for “Change Sound/ Music Volume” module of “Options” (Fig 4) 43 | P a g e UX Background Programming Go to Main Menu Options Menu Appears Volume Changed Set Value on Volume Slider UX Background Programming 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. 44. 44 | P a g e UX Background Programming Go to Main Menu Click Score Board Score Board Reset Click Reset Fig 25: Swimlane Diagram for “Reset” module of “Score Board” (Fig 5) UX Background Programming Go to Main Menu Click Story Game Story Played Fig 26: Swimlane Diagram for “Story” module (Fig 1)
  45. 45. 45 | P a g e UX Background Programming Go to Main Menu Click Quit Game Exited Fig 27: Swimlane Diagram for “Quit” module (Fig 1)
  46. 46. 2.4.2 Data Model If software requirements include the need to create, extend or interface with database or if complex data structures must be constructed and manipulated, the software team may choose to create a data model as part of overall requirements modeling. Although our game has many data objects, it does not have any data storage. All the objects and their related data are handled by the game engine. So the developers need not think about data storage. For this reason, data model is redundant for this game project. 2.4.3 Behavioral Model The Behavioral indicates how software will respond to external events or stimuli. There are two ways to show these responses. One is state diagram and the other is sequence. Usually state diagram can be made in two ways, one is creating a state diagram for each class and the other is to create a state diagram for the whole system. As we don’t have any class, for this is not an object oriented game, we have followed the later one. We used the modules of the use case scenario to create the state diagram. And to lessen complexity we have divided the state diagram into two diagrams. On the other hand, for the sequence diagram, we have created separate a sequence diagram for all the use cases when necessary. 46 | P a g e
  47. 47. 2.4.3.1 State Diagram from Level Select, Level Complete, and In Game Menus in Play Level Splash Screen Idle Open 47 | P a g e Game Main Menu Checking Do: isclicked “Play” “Quit” “Options” Close Game Options Menu Play Menu “Select Level” To level select menu To idle “Graphics” “Sound/Music” “Controls” “Return” Adjust Check Fig 28: top level state diagram
  48. 48. “Next Level” 48 | P a g e Level Select Menu Checking Do: isclicked “Return” To main menu Play Level “Level X” Checking Do: isclicked “Level Complete” “In Game Menu” Level Complete Menu In Game Menu Checking Do: isclicked “Main Menu” Next Level Menu To main menu Checking Do: isclicked “Resume” Fig 29: play level state diagram
  49. 49. 2.4.3.2 Sequence Diagram 49 | P a g e UX Backend Active Object Click resume game Open game Click new game Open game UX Backend Fig 30: Sequence diagram (New Game) Level 1 Loaded Checking Level Loaded lookup level returned Fig 31: Sequence diagram (Resume Game)
  50. 50. 50 | P a g e UX Backend Click select level Level Select Menu Level X Loaded Fig 32: Sequence diagram (Select Level) UX Backend Press Game Pause Playing game select level X Open game Taking input Click back to main menu Pause Menu Appears Fig 33: Sequence diagram (Exit Game) Main Menu Appears
  51. 51. 51 | P a g e UX Backend Fig 34: Sequence diagram (Show Control) UX Backend Active Object Click Options Click options Open game Open game Change graphics/ sound/ music Controls Showed Click back to show controls Option Menu Appears Option Menu Appears Updated Fig 35: Sequence diagram (Change Graphics/Sound/Music)
  52. 52. 52 | P a g e UX Backend Active Object Lookup information Click Score Board Open game Change graphics/ sound/ music Click Reset Score Board Appears Fig 36: Sequence diagram (View and Reset Score Board) Updated
  53. 53. 2.5 Requirement Change Management of Our System The developers intend to release a complete and fully functional game that follows the guidelines mentioned in the SRS document. However, since the product will be released for multiple Android platforms (i.e. the different phones running the Android system), updates will likely be required. These updates would consist of any bug fixes that are necessary, compatibility patches for all of the current phones that support the Android System, and expansions of the content. If the players find any issues or has any comments they would be able to contact the developers through the official support email address which is ghostInTheTown_support@gmail.com. For managing the changes we are releasing versions of this document. This one is version 2.1. 2.5.1 Bugs and Glitches The players would be able to contact the developers through the support email system. This is where they would present any bugs or glitches they have detected and if they have any beliefs that the game is not functioning properly. General concerns or comments would also need to be submitted here. CAE will check this email regularly in order to respond to any time sensitive information. 2.5.2 Patches As the Android system is updated and new phones come out, the game would also need to be updated. Developers would constantly be making changes in order to keep up with any compatibility issues that may arise. These changes and any others that may be fixing bugs or glitches would be released through these patches. 53 | P a g e
  54. 54. Chapter – 3: Design and Implementation of 54 | P a g e “Ghost in the Town”
  55. 55. This chapter covers the project design phases, the system features and also the implementation of the features. 3.1 Product Design Terms For every enterprise product two key terms of design is very important. They are:  UX (User Experience)  Backend Programming 3.1.2 User Experience (UX) To avoid unnecessary product features, simplifying design documentation and customer-facing technical public at, Incorporating business and marketing goals UX design is must. User experience design (UXD or UED) is any aspects of a user's experience with a given system, including the interface, graphics, industrial design, physical interaction, and the manual in most cases, User Experience Design fully encompasses traditional Human-Computer Interaction (HCI) design, and extends it by addressing all aspects of a product or service as perceived by users. UX stands for mainly relevant access of usability, accessibility and HCI. UX defines user experience as “a person’s perceptions and responses that result from the use or anticipated use of a product, system or service”. 55 | P a g e
  56. 56. 3.1.2 Backend Programming The "back end" is the code supporting that front end (responsible for database access, business logic etc). In simple term, application front end is what you see (i.e. the user interface) and application back end is the application engine that you do not see. The "back end" is the code supporting that front end (responsible for database access, business logic etc). Foe efficient implementation, to increase user acceptance both two are very important in software industry. 3.2 System Features of Our Game I. CCTV Camera II. Automatic Door III. Title Screen IV. Level Selection Menu V. Pause Menu VI. Option Menu VII. Suspicion Meter VIII. Flying IX. Disguise X. Dialogue on Tips XI. Exit Point XII. Hide Ghost XIII. Laser Grid XIV. Food Counter XV. Timer 56 | P a g e
  57. 57. 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 3.2.2.1 Description and Priority There are a few automatic doors in the scene .These doors open whenever the ghost comes near to it. 3.2.2.2 Stimulus/Response Sequences Step 1: The ghost comes near to the door. Step 2: Door opens automatically. 57 | P a g e
  58. 58. 3.2.2.3 Functional Requirements 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 3.2.3.1 Description and Priority 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. 3.2.3.2 Stimulus/Response Sequences 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. 3.2.3.3 Functional Requirements REQ-1: The title screen must load and appear every time the game is launched. REQ-2: If the player quits the game during any stage of a level, they must be returned to the title screen. REQ-3: If the player presses the exit button, the game will end and return the player to the phone’s regular interface. REQ-4: If the player completes the game, the game will end and return the player to the title screen. 58 | P a g e
  59. 59. 3.2.4 Level Selection 3.2.4.1 Description and Priority 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. 3.2.4.2 Stimulus/Response Sequences 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.) 3.2.4.3 Functional Requirements REQ-1: To unlock a chapter on the map screen, a player must complete the final non-bonus stage in the previous chapter. REQ-2: When a chapter is completed, the chapter’s bonus levels which have not been unlocked become visible on the map screen in sequence with their respective non-bonus levels, but are still inaccessible to the player. REQ-3: Only chapters and levels which the player has unlocked are displayed on the level selection screen, excepting those bonus levels falling under REQ-2. 59 | P a g e
  60. 60. 3.2.5 Pause Menu 3.2.5.1 Description and Priority 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. 3.2.5.2 Stimulus/Response Sequences 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. 3.2.5.3 Functional Requirements REQ-1: The “Return to Map” option must return the player to the chapter to which the exited level belongs. REQ-2: The “Resume Game” option must continue the game without any change to the character’s vector or the state of the level from the moment of the pause action. 60 | P a g e
  61. 61. 3.2.6 Option Menu 3.2.5.1 Description and Priority 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. 3.2.5.2 Stimulus/Response Sequences 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. 3.2.5.3 Functional Requirements REQ1: Sound will be enabled when “On” is selected and disabled when “Off” is selected. REQ2: The Sound will be set to “On” by default. REQ3: Movement Scroll Bar will be set to the left side of the screen if “Left” is selected and set to the right side of the screen if “Right” is selected. REQ4: The Movement Scroll Bar is set to “Right” by default. REQ5: Player will be directed back to the Title Screen when “Return to Title Screen” is selected. 61 | P a g e
  62. 62. 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 3.2.7.2 Stimulus/Response Sequences Step 1: Ghost makes sound Step 2: People suspicious Step 3: Game score lessons 3.2.7.3 Functional Requirements REQ 1: Store ghost actions during the game REQ 2: Calculate points depending on people suspicious 3.2.8 Flying 3.2.8.1 Descriptions and Priority 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. 3.2.8.2 Stimulus/Response Sequences Step 1: The player process the fly button. Step 2: The ghost flies with a constant force. Step 3: Player releases the button. 62 | P a g e
  63. 63. Step 4: Ghost falls. 3.2.8.3 Functional Requirements 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 3.2.9.1 Descriptions and Priority Introduced in higher level (party scene). Ghost can disguise itself here by putting on a mask. 3.2.9.2 Stimulus/Response Sequences Step 1: Players comes to an interaction with a mask. Step 2: Player selects the mask and put it on. 3.2.9.3 Functional Requirements REQ 1: Mask must be ready and available to wear. REQ 2: Levels should be adopted with disguise. REQ 3: People must not recognize ghost with a mask. 63 | P a g e
  64. 64. 3.2.10 Dialogue or Tips 3.2.9.1 Descriptions and Priority 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. 3.2.9.2 Stimulus/Response Sequences 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. 3.2.9.3 Functional Requirements REQ-1: Dialogue should not pause the game to prevent player disorientation. REQ-2: Text boxes and floating text should be brief and placed away from UI components so as not to interfere with game-play. REQ-3: The text must be readable from any device. 64 | P a g e
  65. 65. 3.2.11 Exit Point 3.2.9.1 Descriptions and Priority 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. 3.2.9.2 Stimulus/Response Sequences 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. 3.2.9.3 Functional Requirements 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 3.2.9.1 Descriptions and Priority 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. 3.2.9.2 Stimulus/Response Sequences Step 1: The player finds that a civilian is coming close to the ghost. Step 2: He moves the ghost to the hiding furniture fast. 65 | P a g e
  66. 66. Step 3: He hides the ghost in it by pressing interaction key of the game. 3.2.9.3 Functional Requirements 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 3.2.1.1 Description and Priority 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. 3.2.1.2 Stimulus/Response Sequences 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. 3.2.1.3 Functional Requirements REQ 1: Grid must be active and always keep blinking in its particular area. REQ 2: Grid must consistently update its current state. REQ 3: If it catches the ghost in its area, it forces to abort the scene. 66 | P a g e
  67. 67. 3.2.14 Food Counter 3.2.7.1 Descriptions and Priority 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. 3.2.7.2 Stimulus/Response Sequences 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. 3.2.7.3 Functional Requirements REQ 1: Store ghost collections during the game REQ 2: Calculate points depending on total food collected 3.2.15 Timer 3.2.7.1 Descriptions and Priority 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. 3.2.7.2 Stimulus/Response Sequences Step 1: Timer starts automatically at game begin. Step 2: Player finishes the game. Step 3: Timer stops. 67 | P a g e
  68. 68. 3.2.7.3 Functional Requirements REQ 1: Keep track of taken time of the game. REQ 2: Calculate points depending on timer. 3.3 Assumptions and Dependencies The final destination of our game's operation will be the Android mobile device. However, Unity will be responsible for both the construction of the game and its integration within the Android framework. 3.3.1 Construction of the Game Unity includes many built-in components which will expedite the process of game development immensely. These include: o Physics Engine o Collision Detection and Handling o Input Recognition o Object Creation and Transform Manipulation (position and rotation of game objects) o Scene Integration (transition of one level to the next) o Model Attachment (representing game objects with 3D models from external programs) 68 | P a g e
  69. 69. 3.3.2 Integration with Android Unity3D's build settings simplify the process of transferring our game to the Android mobile device. After completing the project, or during any intermediary step for testing, we can select Android from the list of options, build the project, and upload it to one of our own devices. A separate license is required for this functionality, which has already been obtained by one of the members of our group. 3.4 Key Resource Requirements of the Project Major Project activities 69 | P a g e Skill/Expertise Required Internal Resources External Resources Issues/Constraints Level Design Ability to translate aspects of the story into playable levels All three members made the decision about game levels together Ideas from existing games (Ex. Stealth) Conflicting ideas per level Physics Engine Knowledge of functions available in Unity and the ability to change them as needed Nadia and Tahmid worked on Unity game engine Unity game engine Ability to angle interactive portions of levels
  70. 70. Graphics Design 70 | P a g e Knowledge of graphical modeling and implementation Arif and Nadia worked for creating 3d models 3d model design using Maya and 3dsMax Visibility of the details on the 3d models Music Development/ Implementation Ability to incorporate sound clips smoothly into the game - Sound clips from the Internet Ability to play sound clips at precious times during game play Level Implementation Familiarity with scripting language of game engine All members have some knowledge about scripting language Background images from the internet Level size dependent on hardware configuration Documentation Knowledge about SRS and Formal Report Writing Arif and Nadia worked more on Reporting Idea from Existing Reports (Ex. IITDU Online Judge System) Game Reports are Different from Conventional ones
  71. 71. 3.5 Implementation Tools Required 71 | P a g e Product of Tool Usage Work exp. Unity Technologies Unity3d Game Engine Backend activity Autodesk 3ds Max Graphics Design and Animation Create 3d Model and Animate Maya Graphics Design and Animation Create 3d Model Adobe Photoshop Picture Edit 3d Model textures Microsoft Windows Movie Maker Create Videos Game story creation
  72. 72. 3.6 Implementation Code Example Level Complete Score Board Code We have a number of features that affect the score of the game. These features are – o Suspicious Meter o Food Counter o Timer So, while scoring, we took all of them in account. We also created a proper fancy LEVEL COMPLETION MENU for showing the total score in addition with the separate scores in these three fields. So we are presenting the code for it (using language C#) as an example of implementation codes. using UnityEngine; using System.Collections; public class LevelComplete : MonoBehaviour { private GameObject player; private DonePlayerInventory playerInventory; public bool levelComplete = false; private float widthProportion, heightProportion, x, y, width, height, labelWidthProportion, labelHeightProportion, remainingPortion; private float time; private int timeBonus, foodCollected, suspicious , totalScore; private string timeFormatted, suspicionFormatted, totalScoreFormatted; public GUIStyle style; public Texture2D image; public Texture2D line; private progessBar progress; private Tips tips; void Start () { 72 | P a g e progress = GameObject.Find("Camera_main").GetComponent<progessBar>(); player = GameObject.FindGameObjectWithTag(DoneTags.player); playerInventory = player.GetComponent<DonePlayerInventory>(); tips = GameObject.Find("Camera_main").GetComponent<Tips>(); } void OnGUI () { if( levelComplete == true ) { time= 600 - Time.timeSinceLevelLoad; if(time <= 0) timeBonus = 0; else timeBonus = (int)(time) * 1000; suspicious = (int) progress.suspicionNo * 2000; foodCollected = (int) playerInventory.hasFood * 15000; totalScore = timeBonus + foodCollected - suspicious; totalScoreFormatted = string.Format("{0:#,###0}", timeBonus);
  73. 73. 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. 74. 74 | P a g e tips.GUIEnable = true; tips.tipsNo = 4; } } } bool complete() { if(Time.timeScale == 0f) { Time.timeScale = 1f; return(false); } else { Time.timeScale = 0f; return(true); } } } Hiding Inside Code As we mentioned in the system feature part, we also has a hiding feature for the ghost baby. So, the code for the hiding is given below as another code example. using UnityEngine; using System.Collections; public class HideInside : MonoBehaviour { public AudioClip keyGrab; private Vector3 playerposition; private GameObject player; private PlayerVisibility playerVisibility; private bool buttonDown = false; private Tips tips; void Awake () { player = GameObject.FindGameObjectWithTag(DoneTags.player); playerVisibility = player.GetComponent<PlayerVisibility>(); tips = GameObject.Find("Camera_main").GetComponent<Tips>(); } void OnTriggerStay (Collider other) { if(other.gameObject == player) { if(playerVisibility.isVisible == true) { tips.GUIEnable = true; tips.tipsNo = 1; } else tips.GUIEnable = false; if(Input.GetButtonDown("Switch")) { playerposition = player.transform.position; buttonDown = true;
  75. 75. 75 | P a g e } else if(playerposition!= Vector3.zero && !playerVisibility.isVisible) player.transform.position = playerposition; if(Input.GetButtonUp("Switch")) { if(buttonDown) { if(playerVisibility.isVisible == true) HidePlayer(); else UnhidePlayer(); buttonDown =false; } } else if(playerposition!=Vector3.zero && !playerVisibility.isVisible) player.transform.position = playerposition; } } void HidePlayer () { AudioSource.PlayClipAtPoint(keyGrab, transform.position); player.transform.FindChild("char_ethan_body").renderer.enabled = false; playerVisibility.isVisible = false; player.GetComponent<DonePlayerMovement>().enabled = false; } void UnhidePlayer () { AudioSource.PlayClipAtPoint(keyGrab, transform.position) player.transform.FindChild("char_ethan_body").renderer.enabled = true; playerVisibility.isVisible = true; player.GetComponent<DonePlayerMovement>().enabled = true; } }
  76. 76. Chapter – 4: Testing of “Ghost in the Town” 76 | P a g e
  77. 77. This chapter includes some test cases for the game to check if the game works properly in various situations. We are giving four test examples for four different situations here. 4.1 Test Case 1 Test Case : This test will check if the animation is working 77 | P a g e correctly. Test Procedure : Import a character model with animation in unity. Place character on the scene. Run the game. Expected Result : Animation works perfectly in the environment. Actual Result : Animation is not working. Comment : Need to check character configuration on inspector window. The appropriate animation was not selected. Select it. Conditional Test : Again run scene. Expected Result : Animation is working now. Actual Result : Yes, it is working. Accuracy : Accuracy depends on hardware configuration.
  78. 78. 4.2 Test Case 2 Test Case : This test will check if the interaction between objects is 78 | P a g e working correctly. Test Procedure : Add scripts of interaction in the objects that we want to interact with each other. Run scene. Expected Result : Objects are interacting. Actual Result : Run time exception Comment : Need to add checking in the scripts for the objects that have a particular script. Conditional Test : Run scene. Expected Result : Interaction is ok now. Actual Result : Interaction is ok now. Accuracy : Perfectly accurate.
  79. 79. 4.3 Test Case 3 Test Case : This test will check if the dialogue box is working. Test Procedure : Add dialogue box in the scene. Run scene. Expected Result : Dialogue box appears in the correct dimension. Actual Result : Working perfectly Comment : Tips and dialogues are working as expected. 4.4 Test Case 4 Test Case : This test will check if the automatic door opens when 79 | P a g e ghost is around Test Procedure : Configure door. Run scene. Expected Result : Door opens and closes depending on ghost position. Actual Result : Working perfectly Comment : Automatic door can recognize ghost’s presence and opens.
  80. 80. Chapter – 5: User Manual of “Ghost in the Town” 80 | P a g e
  81. 81. This chapter provides a user instruction for the players. It includes the procedure of playing and also contains some snapshots to give some ideas of the game to the player before starting playing it. 5.1 Playing Procedure Gamer first interact system UI to start playing. We provide playing tips to all users so that he/she can easily understand about the playing procedure. There are different levels in our game. Gamer can play each level by finishing the previous one. Player uses his/her logic and maintains time to accomplish the game. He needs to feed the littl e ghost to survive and take him out from the civilization. If gamer caught with baby ghost by CCTV camera or any civilian, he loses the game. Here at the first level, gamers aim to be communicating with the parents of the baby ghost. It can be through telephone or mobile phone inside those civilians’ houses. Like that different level has different complexity and different logic to finish. But the main thing is that gamer should survive with the child ghost which is separated from its family. 81 | P a g e
  82. 82. 5.2 Some Snapshots 82 | P a g e Fig 37: Unity view of main menu (curser is on start button) Fig 38: Play menu with its options
  83. 83. 83 | P a g e Fig 39: Pause menu while playing the game Fig 40: Ghost Character Model created by 3ds Max
  84. 84. 84 | P a g e Fig 41: Bed Room with Character Sleeping Fig 42: Drawing room
  85. 85. 85 | P a g e Fig 43: Study room Fig 44: House yard
  86. 86. 86 | P a g e Fig 45: CCTV Camera Fig 46: Street
  87. 87. 87 | P a g e Fig 47: Overall Construction view of level 1 Fig 48: Game View with suspicious meter, timer, food counter
  88. 88. 88 | P a g e Fig 49: Finishing Cube Fig 50: Collectable Object (Apple)
  89. 89. 89 | P a g e Fig 51: Our main character (Ghost - Ethan) Fig 42: Ethan, ready to hide under table
  90. 90. 90 | P a g e Chapter – 6: Conclusion
  91. 91. A software project means a lot of experience. In this section we summarize the experience gained by project team during development of “Ghost in the Town”. 6.1 The Obstacles 1. Working with game engine completely a new experience for us. Normally we are working with different OO languages, DBMS, mark up languages etc. 2. We adopt these things by video tutorials, text tutorials, internet and learning materials given by the tools themselves. It's a matter of time, patience and hard work. 3. It is very sensible work and it demands much time because the game engines try to connect game environment with the real world. 4. Creating a 3d model is very difficult because you need to work with each and every point of the model. 5. The Exists game engines demands vast knowledge about its properties, sections and sub-sections. After all the thing is that a game project is not a project of 6 or 8 months for three people! 6.2 The Achievements 1. Now we know much more about game engines. How it works? The properties, objects and others. 2. We know how a model is constructed and how it is animated. 3. The main thing is that as a software engineer, skill and expertise to create a SRS document and an overall software product report is now better than before. 4. Co-Operation between group members. 5. Develop communication skills 6. Growing creative thinking and imagination capability. 91 | P a g e
  92. 92. 6.3 Future Plan  Level Extension  Improve Graphical Representation  Introduce new game features  Introduce new environment and scenes  Take user response through website and produce web rank list 6.4 Last Few Words We learned a lot through this project. This project has sharpened our concept of Game engine, animation and the software-hardware interface. We learned a lot about different documentation. The piece of software we developed is intended to serve the gamers of the world. The success of this project may give pleasure to billions of game lovers among the universe. This project not only tested our technical skills but also our temperament. There were times that we almost lost hope but we recovered through constant concentration and hard work. If any kind of suggestion, improvements, more efficient development idea please feel free to communicate with us. 92 | P a g e
  93. 93. 93 | P a g e Appendix
  94. 94. Appendix A: References General References 1. http://www.mixamo.com/, accessed on 1st March, 2013 2. http://thefree3dmodels.com/stuff, accessed on 6th March, 2013 3. http://www.unity3dstudent.com/, accessed on 23rd January, 2013 4. http://students.autodesk.com/, accessed on 23rd January, 2013 5. http://www.digitaltutors.com/11/index.php, accessed on 5th March, 2013 6. http://library.creativecow.net/articles/3dsmax.html, accessed on 25th March, 2013 7. http://www.good-tutorials.com/tutorials/3ds-max/animation, accessed on 27th May, 2013 8. Project “Perihelion” Document by Crtl Alt Elite, accessed throughout Documentation Period 9. Software Evaluation – A Product Perspective by Infosys, accessed on 28th May,2013 10. Software Engineering in Games by BalazsLichtl and Gabriel Wurzer from Institute of Computer Graphics, Technical University of Vienna, accessed on 26th May, 2013 Special Thanks To 1. YouTube - http://www.youtube.com/ 2. Archive3d - http://archive3d.net/ 3. http://unity3d.com/ 4. Unity Cookie - http://cgcookie.com/unity/ 5. Unity Asset Store 6. Software Engineering, A practitioner’s approach -6th edition, Roger S.Pressman 94 | P a g e
  95. 95. Appendix B: Abbreviation and Acronyms Term Definition Game engine A game engine is a system designed for the creation and development of video games. UX 95 | P a g e User experience (UX or UE) involves a person's emotions about using a particular product, system or service. Animation Animation is the rapid display of a sequence of images to create an illusion of movement. Android Android (Google product) is a Linux-based operating system. Scripting A scripting language or script language is a programming language that supports the writing of scripts, programs written for a special runtime environment that can interpret and automate the execution of tasks which could alternatively be executed one-by-one by a human operator. Graphics Graphics are visual presentations on some surface, such as a wall, canvas, screen, paper, or stone to brand, inform, illustrate, or entertain 3d Model In 3D computer graphics, 3D modeling is the process of developing a mathematical representation of any three-dimensional surface of object (either inanimate or living) via specialized software. SRS Software Requirements Specification UI User Interface Gamer A person who plays a game or games, typically a participant in a computer or role-playing game. System A system is a set of interacting or interdependent components forming an integrated whole or a set of elements (often called ‘components’) and relationships which are different from relationships of the set or its elements to other elements or sets.

×