Software Requirements

###Software Requirements Specification (SRS)

#####1. Introduction The purpose of our game is to provide light entertainment that will amuse audiences of different ages and experiences. We believe the theme is easily relatable and will garner interest from potential users without much difficulty.

#####1.1 Intended Audience and Purpose
This game is intended for the current developers and anyone who wishes to continue development in the future.
The purpose of the document is to concatenate relevant project information into one main source. Although this document is not large enough to contain all of the details of the project design and specifications, it also serves to indicate where that information can be found.

#####1.2 How to use the document
This document serves as an overview of the technical specifications of the project. Below is an index of the content.

1. Introduction and intention of document
2. Concept of Operations
3. Behavioral Requirement
4. Quality Requirements
5. Fundamental Assumptions
6. Expected Changes
7. References
8. Appendices

#####2. Concept of Operations
This game will provide our users with their daily dose of the absurd. The premise of the game plays off the idea of being trapped in a nightmare in which you’re completely naked.
Game play starts with the user entering their dream world and realizing they are completely without clothing. The goal is to avoid being seen by peers and colleagues while searching for items of your clothing in a multilevel map of a high school. We plan on building three levels of the game, which correspond to the three floors of the school. Your character will follow a fairly linear path and use objects such as desks to hide behind.

To see our extended Concept of Operations document, please visit the wiki page. There you will be provided with a more in-depth background behind the project.

#####2.1 System Context
This system will be created using the SDL2 cross-platform development library. It is used to create games, video players, and emulators and is available under the zlib license. This will be included in the installation for users, so users will not need to have SDL2 independently installed.
The user does not need to create any kind of account to play the game. After first installation there will not be any steps besides running it.
The game will be compatible with both the Windows and Mac OS.

#####2.2 System Capabilities
• A splash screen will act as home screen of the game. It will be intiated upon startup.
• In game experience will include:
o Window displaying level layout
o Written text displaying self-updating game time
o Written text displaying number of times player has been “seen” by NPC’s
o Ability to pause game. This initiate a pause screen that is visible until the game is restarted.
o Winning screen for when player beats level.

#####3. Behavioral Requirements
#####3.1 System Inputs and Outputs

#####3.1.1 Inputs
Space Bar: Allows user to begin game-play
Q: Allows user to quit game and close window
P: Allows user to pause game play
Up: Allows user to move character towards the top of the game screen
Down: Allows user to move character towards the bottom of the game screen
Left: Allows user to move character towards the left of the game screen
Right: Allows user to move character towards the right of the game screen

#####3.1.2 Outputs
Main game screen: Updates each frame with new status of NPC and main player animation, as well as any collison detection with characters, walls, or items.
Character Movement: Updated each frame to reflect the user directional input.
Pause Screen: Appears in place of main game window when game is in a paused state to signify state to user.
Winning Screen: Appears in place of main game window when user has beaten the level to signify the game is over.
Game time: Appears in upper corner of main game window and is refreshed each frame to reflect the total game play time for that level.
Times Seen: Appears in upper corner of main game window and is refreshed each frame to reflect the total number of times the player has been “seen” so far in current game play.

#####3.2 Detailed Output Behavior
######3.2.1 Use Case: Launch Game Executable • Actors: User

• Preconditions: User has downloaded game and has a keyboard available.

• Triggers: User has just opened the game, which then runs.

• Flow of Events:

o Basic Flow:

1. Game opens to first splash screen.
2. User reads text on screen.
3. User presses the ‘Spacebar’ to continue to game.
4. The instructions splash screen is displayed.
5. User reads the instructions.
6. User presses the ‘s’ key to continue.
7. Game play begins.

o Alternative Flows:
(Steps 1 and 2 executed)
3. User presses the ‘esc’ key to quit.
4. Window closes and the game exits.

• Exceptions: User clicks the ‘close’ title bar button and the game exits.

• Post Conditions: Game play has begun, or the window has been closed.

######3.2.2 Use Case: Game Play Begins • Actors: User

• Preconditions: User has run game and has just moved past the opening splash screens into game play.

• Triggers: User has just hit the ‘s’ key to start the game.

• Flow of Events:

o Basic Flow:

1. User observes the layout of the level.
2. User sees the NPC’s moving and observes their paths
3. User presses the up arrow key
4. The character sprite moves up towards the top of the window

o Alternative Flows:
(Steps 1 and 2 executed)
3. User presses the up arrow key
4. The character sprite moves up towards the top of the window

(Steps 1 and 2 executed)
3. User presses the down arrow key
4. The character sprite moves down towards the bottom of the window

(Steps 1 and 2 executed)
3. User presses the right arrow key
4. The character sprite moves towards the right of the window

(Steps 1 and 2 executed)
3. User presses the up arrow key
4. The character sprite moves towards the left of the window

• Exceptions:
o User chooses not to press any arrow keys. Character sprite does not move.
o User presses keys besides the arrow keys. Character sprite does not move.

• Post Conditions: The user has moved the main naked character sprite either up, down, left, or right.

######3.2.3 Use Case: Main Character is Seen
• Actors: User

• Preconditions: User has entered game play successfully and has made at least minimal movement.

• Triggers: Main character sprite is seen from an NPC detecting it via the line of sight algorithm.

• Flow of Events:

o Basic Flow:

1. Character intercepts a NPC’s line of site.
2. Character sprite is moved back to start of level map.

o Alternative Flows:
None.

• Exceptions: If the character is on the other side of a wall from the NPC, the line of sight detection will not detect them.

• Post Conditions: Character is once more at the start of the level map. User is frustrated and challenged to try again.

######3.2.4 Use Case: Item Pickup
• Actors: User

• Preconditions: User has entered game play successfully and has moved to a section of the level that has an item.

• Triggers: Main character moves towards item.

• Flow of Events:

o Basic Flow:

1. User presses the appropriate arrow keys to navigate character towards item.
2. Character collides with item.
3. Collision is detected.
4. Item sprite no longer appears on game screen.

o Alternative Flows:
(Steps 1 through 4 executed)
5. Item was a clothing item.
6. Character sprite is redrawn wearing clothing item.

(Steps 1 through 4 executed)
5. Item was a bonus item.
6. Character gains the given bonus for a limited number of seconds.
7. Gameplay returns to normal.

• Exceptions: Item is final item at end of level. Enter ‘End of Level’ use case.
• Post Conditions: Character sprite has changed, or character is granted temporarily elavated abilities.

######3.2.4 Use Case: End of Level
• Actors: User

• Preconditions: User has entered game play successfully and has moved through the level in its entirety.

• Triggers: Main character collides with final clothing item in fornt of exit door.

• Flow of Events:

o Basic Flow:

1. User presses the appropriate arrow keys to navigate character towards item.
2. Character collides with item.
3. Collision is detected.
4. Splash screen appears.
5. User congratulates themselves.
6. User presses the ‘c’ key to continue to the next level.
7. The next level replaces the splash screen in the window.

o Alternative Flows:
(Steps 1 through 5 executed)
6. User presses the ‘q’ key to quit the game.
7. The game window is closed.

(Steps 1 through 5 executed)
6. The user has beaten all levels.
7. User presses the ‘q’ key to quit the game.
8. The game window is closed.

• Exceptions: User clicks the ‘close’ title bar button and the game exits.
• Post Conditions: The player has either advanced to the next level, or quit the game.

######3.2.5 Use Case: Pause Game • Actors: User

• Preconditions: User has entered game play and wishes to stop the game temporarily.

• Triggers: User presses the ‘p’ key.

• Flow of Events:

o Basic Flow:

1. User presses the ‘p’ key.
2. The level screen is replaced by the pause menu.
3. User read the options available.
4. User presses the ‘r’ key.
5. Game play resumes.

o Alternative Flows:
(Steps 1 through 3 executed)
6. User presses the ‘q’ key to quit the game.
7. The game window is closed.

• Exceptions: User clicks the ‘close’ title bar button and the game exits.
• Post Conditions: The player has either successfully paused and the resumed game play, or has exited the game.

#####3.3 Level Design Draft

#####4. Quality Requirements

Consistent Game Play:
Character must move smoothly and in direct accordance to the user input.
NPCs must move consistently throughout game level without undefined behaviour, such as random stops or walking through walls. Both sight and collision detection must be accurate, and detect the main character sprite when in defined vicinity. Must not detect through walls.

Intuitive Design:
Game is easy to install and run. Movement commands are easy to understand and responsive. Command keys are few enough to remember without difficulty, but self-explanatory as well.

Challenging and Interesting:
Users must try multiple times to beat any given level. The sprites and level design are visually enjoyable. Users find the theme of the game humorous.

#####6. Fundamental Assumptions
We assume that there will be no changes to the SDL2 development library. We also assume the user has basic familiarity with either the Windows or Mac OS.
Other assumptions are that the user has played a video game before and is familiar enough to infer the basic goals in a maze style sneaking game from limited instruction.

#####7. Expected Changes
We expect:
• The list of features to fluctuate throughout development. These will depend on the difficulty of implementation, time taken to create any relevant art, and time remaining before the project deadline.
• Art to change, with new art being developed and old art being revised.
• Level design to change as we create new features and experiment to see what is engaging and what is not.
• There may be addtions of new levels later in the project timeline, or by future developers looking to expand the game.
• Documentation will change as more features are added and redacted, or if future developers continue work after the project deadline.

#####8. Appendices
#####8.1 Definitions and Acronyms
#####8.1.1 Definitions

	Sprite: A two-dimensional independent object that represents things like an item or person  

    Isometric: A method of visually representing three-dimensional objects in two-dimensions.  

	Frame: An image that is temporarily displayed in the game window,  
             and is updated at least 24 times per   
             second, usually more  with current technology.  

	zlib license: Quoted from http://www.gzip.org/zlib/zlib_license.html:  
    	   "This software is provided 'as-is', without any express or implied warranty.  
            Permission is granted to anyone to use this software for any purpose,   
            including commercial applications, and to alter it and redistribute it 
            freely, subject to the following restrictions:"   
            To avoid redundancy, restrictions can be viewed on the linked site.

#####8.1.2 Acronyms

	SDL2: Simple DirectMedia Layer, version 2  
	NPC: Non Player Character