Mutimedia Final Report.docx

ESCAPE Software Requirements Specification

1

ESCAPE Project title:

“ESCAPE”

Done By: 15MIS1004 K.SAIPOOJA Introduction: 2

ESCAPE This software requirements specification document is intended to give a complete overview of a game project Escape (working title), including the game mechanism and user interface. The SRS document details all features upon which Escape have currently decide with reference to the manner and importance of their implementation. 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 uses of the words “player”. 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. Project Goals: Escape is a simple Android Phone game that calls upon you to bounce a ball up through a maze of portals while avoiding obstacles that are placed along the way. Escape also requires a little patience and timing; otherwise the game could drive you crazy. Available for low-memory devices, Escape is a fun game to have in your library for those occasions you need a little help passing the time. The maze you navigate through will have open portals in the solid lines/walls that you must pass your character 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. Overall Description: Product Perspective: While the game itself is not a continuation of any predecessor, its implementation is made possible through HTML, JAVA Scripting and CSS and its ability to compile and build projects for use on website. As part of its inclusion in the website framework it is guaranteed security against access from other applications. one of our goal while designing the game is to be able to let the user understand the game play 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 3

ESCAPE with the game. We have tried to avoid creating the story primarily because the users find it really annoying instead our game model focuses on gaining the score by achieving the difficulty level. Product Features: The following is a summary of the major features implemented in the game. Functional Features: Gravity Rotation: It is the central mechanic of our game, allowing the player to change their perspective and orientation through the use of a touch scroll bar. ACCERLATOR: It is also a necessary movement mechanic, allowing sudden movements upward from solid ground. Death Zones: Areas that trigger the restart of the levels be they encompassing stage boundaries or spike-like traps. Title Screen: It is the first viewable screen upon starting up the application, containing buttons for play game, options. Project Context: This includes Development Strategy, Risk Analysis and Tools, etc 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. DESIGN:

4

ESCAPE This phase consists of gathering requirements and creating software architecture for the game. The phase will be revisited several times during the implementation phase.

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. 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. FINALIZATION: This phase consists of finalizing the document. Development Strategy: 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 Risk Analysis: BAD PROTOTYPE DESIGN: 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 5

ESCAPE 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. 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. Tools: Programming Language: HTML, CSS and Java script Report writing: word System features: Gravity Rotation: 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. Jumping: Being the secondary method of player input, jumping maintains the secondhighest game-play priority. This mechanic allows the player to navigate gaps without having to be adroit at gravity rotation. Death Zones: 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 6

ESCAPE reinforcement. They should be prioritized in level design, as they bring the game-play from “playable” to “enjoyable.” Title Screen: The title screen is the screen the player will see every time upon playing the game. Through this interface, the player can choose to start a new game, play from saved data, or adjust the options. Since the title screen is the “hub” for all activities in the project, it must be included.

Non Functional Requirements: Performance Requirements: 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. Safety Requirements: Escape 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. Escape should not be played when the player’s attention is divided among multiple tasks to prevent potential harm to the player. Functional Requirements: 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. 7

ESCAPE 2)

Upon pressing the button the application should take the

user to the game play 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.

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 game play 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. Code (Implementation): GAME.HTML 8

ESCAPE <style> body{ backgroung-repeat: no-repeat; } input[type=submit]{ background-color: #ff1a75; border-radius: 15px 50px; color: #ffffb3; padding: 16px 32px; text-decoration: none; margin: 4px 2px; cursor: pointer; }

GAME2.HTML 9

ESCAPE <meta name="viewport" content="width=device-width, initial-scale=1.0"/> <style> input[type=submit]{ background-color: #ff1a75; border-radius: 15px 50px; color: #ffffb3; padding: 16px 32px; text-decoration: none; margin: 4px 2px; cursor: pointer; } .button { background-color: #ff1a75; border-radius: 15px 50px; color: #ffffb3; padding: 16px 32px; text-decoration: none; margin: 4px 2px; cursor: pointer; } canvas {

10

ESCAPE border:1px solid #d3d3d3; background-image: url("a.jpg"); } <script>

var myGamePiece; var myObstacles = []; var myScore; var mySound; function startGame() { myGamePiece = new component(50, 50, "star.gif", 50, 50, "image"); myGamePiece.gravity = 0.9; myScore = new component("30px", "Consolas","white", 230, 40, "text"); mySound = new sound("l.mp3") myGameArea.start(); }

var myGameArea = { canvas : document.createElement("canvas"), start : function() { 11

ESCAPE this.canvas.width = 1250; this.canvas.height = 400; this.context = this.canvas.getContext("2d"); document.body.insertBefore(this.canvas, document.body.childNodes[0]); this.frameNo = 0; this.interval = setInterval(updateGameArea, 8); }, clear : function() { this.context.clearRect(0, 0, this.canvas.width, this.canvas.height); }, stop : function() { clearInterval(this.interval); } }

function component(width, height, color, x, y, type) { this.type = type; if (type == "image") { this.image = new Image(); this.image.src = color; } this.score = 0; this.width = width; this.height = height; 12

ESCAPE this.speedX = 0; this.speedY = 0; this.bounce = 0.6; this.x = x; this.y = y; this.gravity = 0; this.gravitySpeed = 0; this.update = function() { ctx = myGameArea.context; if (type == "image") { ctx.drawImage(this.image, this.x, this.y, this.width, this.height); } else if (this.type == "text") { ctx.font = this.width + " " + this.height; ctx.fillStyle = color; ctx.fillText(this.text, this.x, this.y); } else { ctx.fillStyle = color; ctx.fillRect(this.x, this.y, this.width, this.height); } } 13

ESCAPE this.newPos = function() { this.gravitySpeed += this.gravity; this.x += this.speedX; this.y += this.speedY + this.gravitySpeed; this.hitBottom(); } this.hitBottom = function() { var rockbottom = myGameArea.canvas.height - this.height; if (this.y > rockbottom) { this.y = rockbottom; this.gravitySpeed = -(this.gravitySpeed * this.bounce); } } this.crashWith = function(otherobj) { var myleft = this.x; var myright = this.x + (this.width); var mytop = this.y; var mybottom = this.y + (this.height); var otherleft = otherobj.x; var otherright = otherobj.x + (otherobj.width); var othertop = otherobj.y; var otherbottom = otherobj.y + (otherobj.height); var crash = true;

14

ESCAPE if ((mybottom < othertop) || (mytop > otherbottom) || (myright < otherleft) || (myleft > otherright)) { crash = false; } return crash; } }

function updateGameArea() { var x, height, gap, minHeight, maxHeight, minGap, maxGap; for (i = 0; i < myObstacles.length; i += 1) { if (myGamePiece.crashWith(myObstacles[i])) { mySound.play(); myGameArea.stop(); return; } } myGameArea.clear(); myGameArea.frameNo += 1; if (myGameArea.frameNo == 1 || everyinterval(150)) { x = myGameArea.canvas.width; minHeight = 70; maxHeight = 200; height = Math.floor(Math.random()*(maxHeight-minHeight+1)+minHeight); 15

ESCAPE minGap = 80; maxGap = 200; gap = Math.floor(Math.random()*(maxGap-minGap+1)+minGap); myObstacles.push(new component(10, height, "LIGHTSALMON", x, 0)); myObstacles.push(new component(10, x - height - gap, "LIGHTSALMON", x, height + gap)); } for (i = 0; i < myObstacles.length; i += 1) { myObstacles[i].x += -1; myObstacles[i].update(); } myScore.text="SCORE: " + myGameArea.frameNo; myScore.update(); myGamePiece.newPos(); myGamePiece.update(); } function sound(src) { this.sound = document.createElement("audio"); this.sound.src = src; this.sound.setAttribute("preload", "auto"); this.sound.setAttribute("controls", "none"); this.sound.style.display = "none"; document.body.appendChild(this.sound); this.play = function(){ 16

ESCAPE this.sound.play(); } this.stop = function(){ this.sound.pause(); } } function everyinterval(n) { if ((myGameArea.frameNo / n) % 1 == 0) {return true;} return false; }

function accelerate(n) { myGamePiece.gravity = n; }

onmousedown="accelerate(-0.1)"

onmouseup="accelerate(0.05)"

class="button">ACCELERATE

17

ESCAPE

Screen Shots (Output):

18

ESCAPE Conclusion: The result of our project is our video game working perfectly fine. It has the speed that we targeted for that is screen does not flicker, stick moves correctly and movements of images are pretty smooth. The game theory is also accurate. Our game is quite safe as it does not include any RF signals and noise in it. The best part of our game is that it’s very user friendly. Anyone can play it and gets addicted. We have documented the design of our game in such a way that anybody can alter it by reading our documentation.

19