Gaming SRS

3/25/24, 2:28 PM The complete srs documentation of our developed game.
| PDF
Search
Upload Login Signup
The complete srs documentation of our developed game.

Aug 25, 2016 • 12 likes • 27,778 views
Isfand yar Khan Follow
This documentation is an SRS of your SE project where we have developed the game.
The pptx also uploaded as well.
Software
Recommended
Final year project
presentation
SulemanAliMalik
1.7K views • 25 slides
Android Application And

Unity3D Game
Documentation
Sneh Raval
Software Engineer- A
unity 3d Game
Isfand yar Khan
Final project report of a

game
Nadia Nahar
Android Project
Presentation
Laxmi Kant Yadav
Car Game - Final Year

Project
Vivek Naskar
29K views • 64 slides
Software Requirements
Specification on Pubg
Gaming App (SRS on …
KAUSHAL KUMAR JHA
Learn More
Software engineering
project(srs)!!
sourav verma
Skip Ad
https://www.slideshare.net/Axphey/the-complete-srs-documentation-of-our-developed-game 1/28
3/25/24, 2:28 PM The complete srs documentation of our developed game. | PDF
Save slide
5 of 27 Download Now
Download to read offline
More Related Content

What's hot (20)
SRS REPORT ON A SRS For Online Store Hostel management Report on car racing
ANDROID GAME system srs game for android
milan tripathi • 4.5K views Ahsan Rizwan • 57.1K views hira akram • 24K views ravijot singh • 19.1K views
Similar to The complete srs documentation of our developed game. (20)

Black book Kingston University AR Mini Project- Game Project Report Tron
Drone game-final … Hardware Development Legacy
PawanYadav348 • 1.1K views Anne David • 1.1K views University of H… • 1.4K views Manpreet Singh • 483 views
Slideshows for you (20)
Cloud Computing ppt WIPRO PRESENTATION college website project Final Report for Summer
report internship at Software …
OECLIB Odish… • 51.1K views Sunil G R • 55.5K views Mahendra Cho… • 59.2K views Saad Shahzad • 20.1K views
Recently uploaded (20)
Telebu Social -Whatsapp Cybersecurity Challenges Rebuilding Your Cloud Deep Learning for Images
Business API : Mastering… with Generative AI - for … Native Community … with PyTorch - Datacamp
telebusocialm… • 10 views Ivo Andreev • 9 views Imma Valls Ber… • 15 views VICTOR MAEST… • 6 views
Related Books
Free with a 30 day trial from Everand View All
Ebook Ebook Ebook Ebook Ebook Ebook

Unity from Zero Godot from Godot from Learning C# by Godot from Unity f
to Proficiency… Zero to… Zero to… Developing… Zero to… to Prof
Patrick Felicia Patrick Felicia Patrick Felicia Lukosek Greg Patrick Felicia Patrick F
5/5 4.5 / 5 5/5 5/5 5/5
Related Audiobooks
Free with a 30 day trial from Everand View All
Audiobook Audiobook Audiobook Audiobook Audiobook Audioboo

Blood, Sweat, Python for Software Clean Python Python
and Pixels: Th… Beginners: A… Engineering… Architecture: … Programming… Progra
Jason Schreier Timothy C. Needh… Introbooks Team Robert C. Martin Anthony Adams Anthony
4.5 / 5 4.5 / 5 4/5 5/5 5/5
The complete srs documentation of our developed game.

1. 1| P a g e 1. INTRODUCTION: 1.1 PURPOSE: This Software Requirements Specification (SRS) document is intended to give a complete overview of Android game project Amazing
Boxy (working title), including the game mechanics, user interface and story therein. The SRS document details all features upon which Amazing boxy have currently decided with
reference to the manner and importance of their implementation. 1.2 DOCUMENT CONVENTIONS: 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” 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. This document is too printed on A4 paper in Times New Roman font. Normal text is size 12 black,
while section headings are size 24 bolded white against green backgrounds. Subheadings are bolded size 14 black upon green backgrounds, and third subheadings are bolded size
13 black indented with green hooks. 1.3 INTENDED AUDIENCE AND READING SUGGESTIONS: The SRS document also gives testers and project managers a way to ensure the game’s
adherence to 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 (Section 2). For a detailed description of the game play elements and their interaction with the
character, see System Features (Section 3). Readers interested in the game-play interface and navigation between different front-end menus should see External Interface
Requirements (Section 4). Technical standards to which the team will hold the project are laid out in Other Nonfunctional Requirements (Section 5). The development schedule,
meanwhile, will be maintained in the Key Milestones (Section 6).
2. 2| P a g e 1.4 PROJECTGOAL: Amazing Boxy is a simple Android Phone game that calls upon you to bounce a brick up through a maze of portals while avoiding obstacles that are
placed along the way. Amazing Boxy also requires a little patience and timing; otherwise the game could drive you crazy. Available for low-memory devices, Amazing Boxy is a fun
game to have in your library for those occasions you need a little help passing the time. Amazing Boxy's main menu is minimal by design with two gaming modes available and an
option to rate the game in the Google Play Store. The two gaming modes are Easy and hard. The key difference in these two modes is the size of the portal you have to bounce your
brick through. Controlling your brick (which looks more like a black diamond) is done by tapping the left or right side of the screen. Tapping the left side bounces the brick upwards
to the left and tapping the right will send the brick upwards to the right. Taping these taps just right and your brick will move upwards in a somewhat straight direction. The maze
you navigate through will have open portals in the solid lines/walls that you must pass your brick through. You will also have blocks placed in between the walls that you must
avoid. Contact with any of the obstacles of walls will end the game. 2. OVERALL DESCRIPTION: 2.1 PRODUCT PERSPECTIVE: While the game itself is not a continuation of any
predecessor, its implementation is made possible through the game development tool Box2d and its ability to compile and build projects for use on the Android mobile device. As
part of its inclusion in the Android framework it is guaranteed security against access from other applications. Since smartphones these days are full of tons of games therefore, one
of our goal while designing the game is to be able to let the user understand the gameplay at the first look no matter how often and how least he opens the game, we are achieving
this by showing the control guide screen every time at the beginning of the game, hence engaging the user every time with the game. We have tried to avoid creating the story
primarily because the users (especially when it comes to small smartphone games) find it really annoying instead our game model focuses on gaining the score by achieving the
difficulty level. The game would allow the users to pause the game by stopping the frames being executed, so it wouldn’t create aggressive feedback like recently hyped game
flappy bird did.
3. 3| P a g e 2.2 PRODUCT FEATURES: The following is a summary of the major features implemented in the game. They are separated into categories based on those that are
necessary for the game to function. 2.2.1 FUNCTIONALFEATURES:  GRAVITY ROTATION: The central mechanic of our game, allowing the player to change their perspective and
orientation through the use of a touch scroll bar.  JUMPING: Also a necessary movement mechanic, allowing sudden movements upward from solid ground.  DEATH ZONES:
Areas that trigger the restart of the level, be they encompassing stage boundaries or spike-like traps.  TITLE SCREEN: The first viewable screen upon starting up the application,
containing buttons for play game, options.  PAUSE MENU: In game option to halt game-play. This also allows access to the fields displayed on the title screen. 2.3 USER CLASSES
AND CHARACTERISTICS: Our control scheme is designed to be intuitive and our game-play innovative and unfamiliar. Therefore, experience with games will not be a major factor in
determining who is able to play: players of any age or skill level should be able to pick it up. However, as with any game with a large enough fan base, there will be a natural divide
between casual and hardcore players. These two classes will naturally differentiate themselves through the use of the gameplay mechanics and the structure of the levels. The
abilities and characteristics distinguishing hardcore players will include: ● Drifting: The ability to spin the rapidly accelerating gravity vector with proper timing in order to reach
certain points without landing on intermediary walls.
4. 4| P a g e ● Foresight: The ability to plan out the paths of multiple falling objects to get each of them to their optimal positions. ● Speed: The ability to complete levels quickly. ●
Intuition: The ability to make successful guesses about the existence of off-screen objects. 3. PROJECT CONTEXT: This includes Mile-stones, Development Strategy, Risk Analysis and
Tools, and Version Control Procedures. 3.1 MILESTONES: MILESTONE START FINISH Pre study 10 0ct, 2014 15 Oct, 2014 Design 17 Oct, 2014 27 Oct, 2014 Implementation 28 Oct, 2014
3 Nov, 2014 Content and demonstration preparation 5 Nov, 2014 7 Nov, 2014 Demonstration 8 Nov, 2014 10 Nov, 2014 Evaluation 11 Nov, 2014 17 Nov, 2014 Platform design 18 Nov,
2014 21 Nov, 2014 Finalization 23 Nov, 2014 10 Dec, 2014 3.1.1 PRESTUDY: This phase consists of gaining an insight into the different subjects that concern this project. This
preliminary study will also include creating the research part of the written report. 3.1.2 DESIGN: This phase consists of gathering requirements and creating a software architecture
for the game. The phase will be revisited several times during the implementation phase. 3.1.3 IMPLEMENTATION: This phase consists of the iterative process of creating the game.
The overall architecture should be implemented, and then the actual code should be written, along with tests and a thorough documentation. The implementation phase is divided
into three sprints.
5. 5| P a g e MILESTONE START FINISH Sprint 1 10 Oct, 2014 20 Oct, 2014 Sprint 2 22 Oct, 2014 5 Nov, 2014 Sprint 3 7 Nov, 2014 10 Dec, 2014 3.1.4 CONTENTAND
DEMONSTRATIONPREPARATION: This phase consists of preparing for the demonstration on 6th of December. The content of the game must also be prepared. This includes the
creation and finalizing of tasks. 3.1.5 DEMONSTRATION: This is a one day test consisting of letting several groups compete against each other. The experiences and results from this
demonstration will form the basis for the evaluation. 3.1.6 EVALUATION: This phase consists of evaluating the experiences and results from the demonstration, and will form part of
the basis for the platform design. 3.1.7 PLATFORM DESIGN: This phase consists of designing the platform, based on the evaluation of the results and experiences from our game, as
well as any conclusions made on the background of our research questions. 3.1.8 FINALIZATION: This phase consists of finalizing the thesis document. 3.2 DEVELOPMENTSTRATEGY:
In order to implement the prototype, we are going to use a combination of the waterfall and the iterative software development strategy. We will make an overall design of the
application using a waterfall approach, which means we will have a good idea about what the system should look like; and what we are going to implement. The implementation
will be based on an iterative software development strategy. This means that the implementation process will be divided into smaller segments of design, implementation, and
testing; thus allowing for a better planning of the time used on implementation.
6. 6| P a g e 3.3 RISK ANALYSIS: This section is about the risks in this project. They are separated into two parts, general risks and demonstration specific risks. 3.3.1 GENERALRISKS:
 INTERNALCONFLICTS: Conflicts between team members can occur, and is even more likely since we will be working closely together over a long period of time. It is therefore
important to communicate openly, and handle issues internally before they become too much to handle. Should this be insufficient one could always seek help from the
supervisors, or in the worst case scenario - dissolve the group.  ANDROID DIFFICULTY: Development with Android is something none of us are familiar with. If we spend too much
time getting an understanding of the framework, development will take more time than expected and other parts of the project will suffer. We can avoid this by planning accordingly
and allocate sufficient time to understand Android, as well as start development early.  BAD PROTOTYPEDESIGN: The survey and evaluation tells us that the concept for the
prototype is bad. This is a risk that can make us unable to design a satisfactory platform, which would have a huge impact on the project. One way to reduce the probability of this
occurring is to interview teachers to verify the learning aspect of the concept. The impact can be reduced by making a survey that will give us useful information even if the design of
the prototype is bad. 3.3.2 DEMONSTRATIONSPECIFIC RISKS:  BATTERY: The low battery time for smartphones is a well-known issue, especially when GPS is enabled or the touch
screen is used extensively. This can disrupt the demonstration of our prototype, should any of the phones run out of battery. We need to program with battery usage in mind, i.e. use
GPS as little as possible.
7. 7| P a g e  UNCLEAR TASKS: When creating task descriptions, one runs the risk of making tasks that are unclear. This can lead to frustration from participant and they may get
stuck. This can be avoided by scrutinizing tasks and making sure that they are clear and have no ambiguity. Should that not work, the participants could always contact a
demonstration supervisor and receive clarification.  PARTICIPANTS UNFAMILIAR WITH ANDROID: Demonstration participants may be unfamiliar with using an Android device. This
can lead to frustration and problems during the demonstration. The problem can be avoided by giving them a brief introduction before the demonstration starts, and prepare the
phones ahead of time for ease of use. 3.4 TOOLS:  Programming language: processing  Programming IDE: processing development environment (PDE)  Diagram editor:
Microsoft Visio 2010  Report writing: open office 3.5 VERSION CONTROLPROCEDURES: The following guidelines should be followed when using Git: 1. Perform updates before
committing any changes. 2. Only commit working code. 3. Several people should not work in the same file at once. 4. SYSTEM FEATURES: 4.1 GRAVITY ROTATION: 4.1.1 DESCRIPTION
AND PRIORITY: This mechanic gives the player full control over the orientation of the level in relationship to the character. Gravity rotation replaces primary movement controls (left
and right) by allowing the player to incline surfaces for sliding and “falling” at different speeds and directions.
8. 8| P a g e 4.1.2 STIMULUS/ RESPONSESEQUENCES: Step 1: The player slides their finger up/down the scroll bar on the right or left side of the screen. Step 2: The level rotates
counter clock wise/clockwise around the character in real time at a speed proportional to the physical distance scrolled by the player. 4.1.3 FUNCTIONALREQUIREMENTS: REQ-1:
The scroll bar must constantly update the current position of the player’s finger to allow for real-time gravity repositioning. REQ-2: The scroll bar’s effect on rotation must be scaled
so that the player will be able to manipulate the level with precision. REQ-3: Different surface inclinations must affect the player’s velocity vector. REQ-4: Levels should be designed
to take advantage of the implications of this game mechanic. 4.2 JUMPING: 4.2.1:DESCRIPTION AND PRIORITY: Being the secondary method of player input, jumping maintains the
second- highest game-play priority. This mechanic allows the player to navigate gaps without having to be adroit at gravity rotation. 4.2.2:STIMULUS/ RESPONSESEQUENCES: Step
1: The player presses the jump button located on the side of the screen opposite the gravity scroll bar. Step 2: The character jumps with a constant force.
4.2.3:FUNCTIONALREQUIREMENTS: REQ-1: Because the touch-screen is not pressure-sensitive, the jump force must be standardized. REQ-2: Levels should be adapted to this
standard jump. REQ-3: Jumping should take into account the current vertical and horizontal velocities as well as the surface inclination. REQ-4: Jump force should be large enough
that the mechanic is not made useless but not so large that gravity rotation can easily replace the effect.
9. 9| P a g e 4.3 DEATH ZONES: 4.3.1 DESCRIPTIONSAND PRIORITY: Death zones are the opposite of level completion zones in that when touched, they send the character back to the
starting point of the level. Some death zones take on the form of environmental obstacles; others are black shapes which represents holes in the protagonist’s memory. Death zones
are a necessary replacement for bottomless pits, which prove impossible to implement given the changeling nature of gravity. These zones increase the game’s difficulty and
incentivize good performance via negative reinforcement. They should be prioritized in level design, as they bring the game-play from “playable” to “enjoyable.” 4.3.2 STIMULUS/
RESPONSESEQUENCES: Step 1: The character comes into contact with a death zone. Step 2: The character is immediately returned to the beginning of the level. 4.3.3
FUNCTIONALREQUIREMENTS: REQ-1: No death zone should be placed so as to make its respective level impossible to complete. 4.4 TITLE SCREEN: 4.4.1 DESCRIPTIONSAND
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. 4.4.2 STIMULUS/ RESPONSESEQUENCES: 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.
10. 10| P a g e 4.4.3 FUNCTIONALREQUIREMENTS: 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. 4.5 PAUSE MENU: 4.5.1 DESCRIPTIONSAND 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. 4.5.2 STIMULUS/ RESPONSESEQUENCES: 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” and “Exit
Game.” Step 3: The player presses one of the buttons, triggering its respective function. 4.5.3 FUNCTIONALREQUIREMENTS: REQ-1: The “Exit Game” option must return the player to
the main screen of the game or phone. 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. 5. EXTERNAL INTERFACE REQUIREMENTS: 5.1 HARWARE INTERFACES: Amazing Boxy 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 Android device using a SQLite relational database.
11. 11| P a g e Amazing Boxy has been developed for Android Version 2.2 and all subsequent releases. 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. 5.2
SOFTWARE INTERFACES: Amazing Boxy is to be developed under the Android operating system using a series of game development tools.  Android Software Development Kit
(Android SDK): Software development kit for applications on the Android platform.  Box2D: Primary game development library using Java  Used in conjunction with the Android
SDK and Processing  Box2D Processing: A helper class that communicates with jBox2D and Processing.  PDE: Processing Development Environment 6. OTHER NON-FUNCTIONAL
REQUIREMENTS: 6.1 PERFORMANCEREQUIREMENTS: Based on the capabilities of current phones and the Android system, performance should not be an issue. However, phones
with weaker hardware may incur some difficulties and potentially run slower. The game design will be tailored in order to give an enjoyable experience on all Android phones,
regardless of hardware. The functionality of the game will be simplistic enough, but not trivial, and the graphics will not be overly detailed so the system does not become slowed
down. 6.2 SAFETYREQUIREMENTS: Amazing Boxy will not affect or damage any of the other applications installed on the player’s phone. The game will also not cause any
overheating of the player’s phone; therefore, the phone's internal components will not be damaged. Amazing Boxy should not be played when the player’s attention is divided
among multiple tasks to prevent potential harm to the player. 6.3 SECURITYREQUIREMENTS: Amazing Boxy will not ask for any personal information from the player and will thus be
unable to compromise such information. There is no player authentication required to play Amazing Boxy. The player simply has to download the application in order to start
playing Amazing Boxy. That being said, anyone who has access to the player’s phone will have the ability to play Amazing Boxy. If any unauthorized player acquires the original
player’s phone, that unauthorized player will be able to play Amazing Boxy. It is the responsibility of the Player to
12. 12| P a g e make sure that no unauthorized player/ person will have access to his or her phone. 6.4 SOFTWARE QUALITY ATTRIBUTES: To ensure reliability and correctness,
Amazing Boxy will respond to the player’s commands in a timely manner. When the player makes the box jump the gravity and velocity components would response immediately,
the player should see the effects of this command within milliseconds not 10 seconds after the effect. For adaptability and flexibility, Amazing Boxy will automatically save the
player’s progress after every level completion. That way, in the event that the player’s phone runs out of battery during game-play, the player can resume game-play at a reasonable
starting point. In terms of usability, the graphical user interface will be very intuitive for the player to use. The beginning levels of Amazing Boxy will also slowly introduce each of the
unique commands available to the player as well as any other game mechanics the player may need to know to complete the level. In more complicated and elaborate levels, these
introductions and hints will not be available because the player will have already been introduced to all the tools needed to complete the level. This method will ensure that the
player gradually learns all the game mechanics and also enjoys a challenging game-play experience. Our game focuses on both ease of use and ease of learning while not leaning
towards one or the other. Amazing Boxy should be a game that any player can pick up and play instantly without much down time in figuring out the controls. The controls will be
easy and intuitive to use and the player will not be bombarded by having to use all the controls at once in the beginning levels. The game play will ease the player into learning and
using each of the commands by gradually introducing each command as the player progresses through the game and completes each level. By the end of any given level, the player
should be familiar with and fully able to use the command introduced in that level and all the commands introduced in previous levels. 7. SOFTWARE ARCHITECTURE: 7.1
ARCHITECTURE CHOICES: 7.1.1 SERVER SOLUTION: Initially we considered client-server architecture for the prototype where content was located at the server and sent to clients on
request. This idea was ultimately scrapped in favor of an architecture that does not include any server, meaning the whole system is on the user’s device. There are several reasons
for this. Most important of these, the purpose of the prototype is to test the game concept. This needs to be done relatively fast so that we have the necessary time to evaluate the
prototype and create a platform design based on the results. Implementing a server would unnecessarily complicate the design process and require more time spent
13. 13| P a g e in implementation on an architecture that does not really yield any substantial benefits at this stage in the project. 7.1.2 STORAGE SOLUTION: We evaluated two
possible solutions for storage of game data. The alternatives were using a file or using an integrated database. We decided on using a database, because the support for databases
in Android is very good, with simple interfaces for retrieving and storing data. Android offers an easy way to create, edit and manage a SQLiteDatabase with the class
SQLiteDatabase. Also, each database created and its content is visible only to its parent application. A database combined with frequent saving of game data will ensure that data
will not be lost even if the application were to terminate unexpectedly. 8. IMPLEMENTATION PHASE: 8.1 REQUIREMENTS: The requirements for this sprint are: ID DESCRIPTION
PRIORITY AB – 01 The current route shall be retrieved from the database upon game start. High AB – 02 The current task shall be retrieved from the database upon game start. High
AB – 03 The game state shall be updated in the database during game play. High AB – 04 The application shall display a welcome screen on startup. Low AB - 05 The welcome screen
shall contain a button for starting the next task. Low 8.2 DESIGN: 8.2.1 GAME START: When the game is installed, the database is created and the game content is filled in. Upon game
start the game retrieves the current game state, which is the current task as well as the route. If there is no current game state, a new route is retrieved from the database, and the
current task is set to the first task in the route.
14. 14| P a g e 8.2.2 TASK FLOW: The first user interface screen the user encounter a welcome screen containing a welcome text and a button for getting to the next task. When the
user pushes the next task button, the next task in the route is retrieved from the database. Upon completing the task, the application automatically retrieves the next task. If the
user exits the game, the user will again encounter the welcome screen, and the route and task is retrieved from the database. If the user pushes the next task button, the application
will load the task that the user was on when he or she killed the application. 8.2.3 COHESIVENESS: High cohesion leads to the reliability, robustness and reusability. Since it is a
game project therefore each module, each class and each file in the entire project is somehow dependent upon one another and can’t be completed independently. In order to
detect the collision of the main character with the boundaries or walls and any other obstacles we would have to access the location of both the actual character and any of the
colliding objects. Similarly if we have to take any food or coins we have to detect the collision and trigger the respective behavior in the game. In almost every game the code is most
of the time cohesive because each object in the game has to obtain the information or fields of the other objects in order to make the game physics work therefore the cohesion of
this project is high in comparison to the usual software projects. Reducing the cohesiveness might lead the game to look like a fake physics and not a clean work, hence high
cohesiveness in this project can be said as mandatory. 8.3 IMPLEMENTATION: 8.3.1 GAME START: The game starts in the class Main. First off the database creation is forced by
creating a new DbAdapter then using its methods open() and close(). The database is created only at first installation of the game. When the user starts the game, the game state is
loaded by calling the the loadGameState() method. This method uses the DbAdapter methods getGameStateRoute() and getGameStateTaskId() to retrieve the current game state. If
there is no current game state, which means that routeId and currentTaskId are 0, then a new game state is created. The new game state contains a new route and first task id of the
route. If a new game state is created, the game state is stored in the database using DbAdapter.updateGameState(). Finally the welcome screen is created. The
15. 15| P a g e welcome screen is very simple and contains a LinearLayout, TextView and a Button. 8.3.2 TASK FLOW: When the user pushes the button on the welcome screen, the
next task is loaded through the Main.loadTask() method. The loadTask() method creates a new Intent with the class TaskActivity and currentTaskId parameters. It then starts the
activity. When TaskActivity is loaded, TaskActivity first calls the the method fetchTask(). The fetchTask() method retrieves the currentTaskId from the Intent and then calls the
method DbAdapter.getTask() to retrieve the task from the database. TaskActivity then uses fetchView() to retrieve the UI according to the task type of the current task. It then creates
the view by calling TaskUI.createView(). 8.4 TESTING: 8.4.1 TASK FLOW: Testing of the task flow was done incrementally. The overall task flow was created and tested first. This
includes Main.loadTask(), TaskActivity.fetchTask(), and TaskActivity.fetchView().In order to test these methods we added a dummy task and a view. Main.loadTask() called
startActivityForResult() with TaskActivity as a parameter to start the activity. TaskActivity then used fetchTask() to create the dummy task. The method fetchView() was then called to
load the view. When the user completed the dummy Task, finish() was called on TaskActivity to finish the activity. The application then returned to Main, and Main called loadTask()
and the cycle was complete. We had no issues with testing the overall task flow. 8.5 EVALUATION: We encountered a few problems during the implementation of this sprint, due to
our inexperience with and our limited understanding of the Android framework. For instance, we struggled a while with passing objects between Activities, and in the end decided
to implement a database to bypass the problem. Most of the other problems originated in the usage of a database, like correctly loading game state variables, objects, etc.
16. 16| P a g e APPENDIX A: USE CASE MODELLING
17. 17| P a g e WHITE SELECT MODE EXIT GAME SAVE GAME DIFFICULT EASY SQUARE CIRCLE DIAMOND CHANGE CHARA- CTER SHAPE BLACK CHANGE BACK GROUND COLOR CHECK
SCORE PLAY GAME PAUSE GAME RESUME GAME
18. 18| P a g e APPENDIX B: FUNCTIONAL REQUIREMENTS
19. 19| P a g e USE CASE: Play Game ID: UC 1 ACTOR: Gamer/Player Pre-condition: The application should have launched correctly Flow Of Events: 1) On the title screen the play
game button populates on the screen. 2) Upon pressing the button the application should take the user to the gameplay screen. 3) The tutorial screen populates, which should
disappear on a single tap. Secondary Scenario:  User exits the application by pressing the back or home button of the Android device. Post-condition:  The game starts. USE CASE:
Pause Game ID: UC 2 ACTOR: Gamer/Player Pre-condition: The game should have started Flow Of Events: 1) When the game starts the pause button populates on the screen. 2) Upon
pressing the button the application should take pause the drawing of the graphics. 3) The screen fades and populates the exit game and resume game buttons Secondary Scenario:
 User exits the application by pressing the back or home button of the Android device. Post-condition:  The gameplay and drawing should be paused, FPS should be decreased to
1 or 0.
20. 20| P a g e USE CASE: Resume Game ID: UC 3 ACTOR: Gamer/Player Pre-condition: The game should have been paused Flow Of Events: 1) When the paused button is pressed the
resume button should populate on the screen. 2) Upon pressing the resume button the application should resume and start drawing the graphics again. 3) The screen fades into the
normal gameplay. Secondary Scenario:  User exits the application by pressing the back or home button of the Android device. Post-condition:  The gameplay and drawing should
be resumed, FPS should be set back to the 60fps. USE CASE: Save Game ID: UC 4 ACTOR: Gamer/Player Pre-condition: The game should have be played. Flow Of Events: 1) When the
paused button is pressed the save button should populate on the screen. 2) Upon pressing the save button the application should save the progress in the database. 3) The
application takes the user back to the main/title screen. Secondary Scenario:  User exits the application by pressing the back or home button of the Android device. Post-
condition:  The information at that particular frame should be saved in the database.
21. 21| P a g e USE CASE: Exit Game ID: UC 5 ACTOR: Gamer/Player Pre-condition: The application should be at the title screen or the game should have been paused. Flow Of Events:
1) When the pause button is pressed the exit button appears, or when user launches the application. 2) Upon pressing the exit button the application should kill all the objects and
the bodies and it should end the gameplay 3) The application closes. Secondary Scenario:  User exits the application by pressing the back or home button of the Android device.
Post-condition:  The game process is killed. USE CASE: Select Mode ID: UC 6 ACTOR: Gamer/Player Pre-condition: The application should have launched Flow Of Events: 1) The
button is populated on the main screen of the application. 2) Upon pressing the select mode button the application should take the user to the mode selection area 3) The different
modes should be populated. Secondary Scenario:  User exits the application by pressing the back or home button of the Android device. Post-condition:  The user gets into the
mode selection area
22. 22| P a g e USE CASE: Easy ID: UC 7 ACTOR: Gamer/Player Pre-condition: The mode selection event should have triggered Flow Of Events: 1) The game mechanics and physics
becomes easy 2) The user is brought back to the main screen Secondary Scenario:  User exits the application by pressing the back or home button of the Android device. Post-
condition:  The gameplay becomes easy USE CASE: Difficult ID: UC 8 ACTOR: Gamer/Player Pre-condition: The mode selection event should have triggered Flow Of Events: 1) The
game mechanics and physics becomes difficult 2) The user is brought back to the main screen Secondary Scenario:  User exits the application by pressing the back or home button
of the Android device. Post-condition:  The gameplay becomes difficult.
23. 23| P a g e USE CASE: Change Background Color ID: UC 9 ACTOR: Gamer/Player Pre-condition: The application should have launched Flow Of Events: 1) The button is populated
on the main screen of the application. 2) Upon pressing the change background color mode button the background color of the gameplay would change. Secondary Scenario: 
User exits the application by pressing the back or home button of the Android device. Post-condition:  The background color has been changed during the gameplay USE CASE:
Black ID: UC 10 ACTOR: Gamer/Player Pre-condition: The application should be in the change background color mode Flow Of Events: 1) The button should be populated on the
screen brought by change background color use case. 2) Upon pressing the black color mode button the background color of the gameplay would change to the black. Secondary
Scenario:  User exits the application by pressing the back or home button of the Android device. Post-condition:  The background color has been changed to the black during the
gameplay
24. 24| P a g e USE CASE: White ID: UC 11 ACTOR: Gamer/Player Pre-condition: The application should be in the change background color mode Flow Of Events: 1) The button should
be populated on the screen brought by change background color use case. 2) Upon pressing the black color mode button the background color of the gameplay would change to
the white. Secondary Scenario:  User exits the application by pressing the back or home button of the Android device. Post-condition:  The background color has been changed
to the white during the gameplay USE CASE: Change Character Shape ID: UC 12 ACTOR: Gamer/Player Pre-condition: The application should be in the main screen. Flow Of Events:
1) The button should be populated on the start of the application. 2) Upon pressing the change character shape button, the user is brought to the screen where he can choose
different shapes of the game character. Secondary Scenario:  User exits the application by pressing the back or home button of the Android device. Post-condition:  The user ends
up in the shape selection menu
25. 25| P a g e USE CASE: Circle ID: UC 13 ACTOR: Gamer/Player Pre-condition: The application should be in the Change Character Shape mode. Flow Of Events: 1) The button
representing the circle shape is populated in the change background shape color menu. 2) Upon pressing the circle shape button, the game character’s shape is changed to the
circle in the gameplay. Secondary Scenario:  User exits the application by pressing the back or home button of the Android device. Post-condition:  The shape of the character is
now a circle. USE CASE: Square ID: UC 14 ACTOR: Gamer/Player Pre-condition: The application should be in the Change Character Shape mode. Flow Of Events: 1) The button
representing the square shape is populated in the change background shape color menu. 2) Upon pressing the square shape button, the game character’s shape is changed to the
square in the gameplay. Secondary Scenario:  User exits the application by pressing the back or home button of the Android device. Post-condition:  The shape of the character is
now a square.
26. 26| P a g e USE CASE: Diamond ID: UC 15 ACTOR: Gamer/Player Pre-condition: The application should be in the Change Character Shape mode. Flow Of Events: 1) The button
representing the diamond shape is populated in the change background shape color menu. 2) Upon pressing the diamond shape button, the game character’s shape is changed to
the diamond shaped in the gameplay. Secondary Scenario:  User exits the application by pressing the back or home button of the Android device. Post-condition:  The shape of
the character is now a diamond shaped. USE CASE: Check Score ID: UC 16 ACTOR: Gamer/Player Pre-condition: The application should be in the main screen. Flow Of Events: 1)
Upon pressing, the check score buttons leads to the list of the highest scores or hall of fame. 2) Upon pressing back or swiping, the user is brought back to the main screen
Secondary Scenario:  User exits the application by pressing the back or home button of the Android device. Post-condition:  The user saw the score list
27. 27| P a g e APPENDIX C: DATA FLOW MODEL DIAGRAMS
About Support Terms Privacy Copyright Cookie Preferences Do not sell or share my personal information
English 
Everand
© 2024 SlideShare from Scribd  

Gaming SRS

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Gaming SRS

Uploaded by

Copyright:

Available Formats

3/25/24, 2:28 PM The complete srs documentation of our developed game.

Upload Login Signup

The complete srs documentation of our developed game.

Android Application And

Final project report of a

Car Game - Final Year

More Related Content

Similar to The complete srs documentation of our developed game. (20)

Slideshows for you (20)

Recently uploaded (20)

Ebook Ebook Ebook Ebook Ebook Ebook

Audiobook Audiobook Audiobook Audiobook Audiobook Audioboo

The complete srs documentation of our developed game.

© 2024 SlideShare from Scribd  

You might also like