# Software Requirements Specification
## For The G-ScalE Mini-Game Battery Project

Version 0.1
Prepared by Team Ludus
[Alice Ip](@ipa1) - 400078727
[Jack Buckley](@bucklj4) - 400144747
[Meijing Li](@lim147) - 400110713
[Shuo He](@hes11) - 400023520
[Yunfei Yang](@yangy113) - 400049426
Instructor: [Dr. Jacques Carette](@carette)
Course: [COMPSCI 4ZP6: Capstone Project](https://www.cas.mcmaster.ca/~carette/CS4ZP6/2020_21/index.html)
Date: 2020-10-16

Table of Contents
=================
[[_TOC_]]

## Revision History
| Name | Date | Reason For Changes | Version |
| ---- | ------- | ------------------- | --------- |
| ALL | 2020-10-16 | First Release | Version 1.0 |
| ALL | 2020-10-18 | <ol><li>Modify the doc to be more ability driven</li> <li>Change some Fit Criterion to be more specific/testable</li> <li>Add Measurement to abilities</li> | Version 1.1 |
| | | | |

## 1. Introduction

### 1.1 Document Purpose
##### 1.1.a Background
The G-ScalE Mini-Game Battery Project is a capstone project for COMPSCI 4ZP6 at McMaster University. This project is developed by Team Ludus, a team that consists of five fourth-year Computer Science students from McMaster University under the supervision of [Sasha Soraine](@sorainsm). Completion of this capstone project is a mandatory requirement for graduation and also a process for students to apply their knowledge in a year long project.

Our capstone group is developing the G-ScalE Mini-Game Battery Project, a project composed of five to ten single-player mini games designed in Unity, to measure approximately five out of 46 identified human cognitive and psychomotor skills. Each game will take players no more than a minute to play, and will be used to establish player competencies in a specific cognitive or psychomotor group. The structure of the games will be similar to minigame compilations like Mario Party.

##### 1.1.b Goals
The purpose of the capstone project is to give students an opportunity to apply and practice their knowledge learned through their university study experience to create a set of mini-games that could practice their creativity, teamwork, and technical skills. This will also let students participate in a full life-cycle of software development, which enhances the understanding of the software design process.

The goal of the G-ScalE Mini-Game Battery Project is to measure a subset of cognitive and motor abilities through the process of playing and enjoying the games. The subset size is approximately five as required and which abilities being tested will be decided by our group with the agreement of [Sasha Soraine](@sorainsm). Games then will be driven from selected abilities where each individual game is aimed to focus on one identified cognitive ability. Through the mini games, we expect to collect representative data from adequately sized sample groups varying in cognitive aptitude. This data will then contribute to the research that Sasha is currently doing on the mechanical experience of video games. As a result, the major component of our project is the backend measurement system for this subset of cognitive abilities with the games based around them taking on a less prominent role.

##### 1.1.c Purpose
The purpose of this requirements document is to lay out who the stakeholders of this project are, the constraints and scope of the project, as well as state the functional and non-functional requirements that need to be met to ensure the success of the ability measurement. In this way, this document serves as a contract between us, Team Ludus, and our stakeholders on what we will deliver to ensure our solution fully addresses the problem our stakeholders face, as laid out in our previous project summary document, all while ensuring we meet the many individual requirements that compose this problem.

### 1.2 Stakeholders
#### The Client
* [Dr. Jacques Carette](@carette): The professor for the Computer Science Capstone Project: COMPSCI 4ZP6. He establishes the requirements, milestones, deadlines, and other course-related objectives. He is also responsible for evaluating and grading the final project.

* [Sasha Soraine](@sorainsm): A PhD. Candidate in the Department of Computing and Software at McMaster University. She is our supervisor for the G-ScalE Mini-Game Battery Project. She will provide us with detailed information and requirements about the project and assist us in finishing the challenges during the development process.

* [Ethan Chan](@chaneh) and [Brendan Fallon](@fallonbr): These are the TAs for COMPSCI 4ZP6. They will be responsible for grading and providing feedback on project deliverables.

#### The User Group
* Players: The people who will be playing the mini-games, consisting of people of different ages. They will participate in gameplay designed to provide data that we will measure to extract cognitive and motor ability aptitudes.

* Other students taking COMPSCI 4ZP6: The other students taking the capstone course will submit feedback and bug reports during the testing phase of the project.

#### Others
* Team Ludus: The developers of the G-ScalE Mini-Game Battery Project. This team consists of five students enrolled in the Computer Science Capstone Project: COMPSCI 4ZP6. The final deliverable and the documents will be made by these team members who will also give a demo presentation of the project at the end of the semester to a panel of judges at the Faculty of Engineering Capstone Day.

* Team Mactivision: The other team working under our supervisor to develop a different set of mini-games for the G-ScalE Mini-Game Battery Project. The members of this group include: [Bryan Chiu](@chiub1), [Sijie Zhou](@zhous16), [Kunyuan Cao](@caok10), [David Hospital](@hospitad), and [Mike Tee](@teemh). We will be collaborating with this group at a further stage of development in the project.

* Panel of judges: The judges will critique the final product during showcase at the Faculty of Engineering Capstone Day in early April. The panel consists of people with different backgrounds in computer science and game design.

### 1.3 Mandated Constraints

##### Solution Constraints
* Each game must measure and focus on exactly one ability.
* The game must be developed using the Unity game development software.
* The game must be modular: a change of controller must not change the underlying test.
* Each mini-game should take players no more than one minute to finish.
* The measurement methods used in the game must accurately record the player's competency in the focused cognitive or motor ability.

##### Implementation Environment
* Computer System: The mini-games must be designed to be operating system independent.

* Input devices: The primary mode of input is the keyboard, and games must first be designed with this in mind.

* Output devices: The output device will be the computer monitor and speakers.

##### Partner or Collaborative Applications
* GitLab: Our ability to track issues and manage project progress will be limited to what is supported by GitLab.

* Microsoft Teams: Due to COVID-19, our team members are unable to meet in person, so our meeting collaboration has been limited to what is supported by Microsoft Teams.

##### Off-the-Shelf Software
* Unity: Game functionality will be limited to what is supported by the Unity platform.

##### Schedule Constraints
* All course deliverables must be completed on time according to the schedule provided by [Dr. Carette](@carette). The final project must be fully finished by April 5th.

##### Budget Constraints
* There are no budget constraints for this project. For the purposes of our project, we will not be paid nor will we need to pay for any software.

##### Final Product Constraints
* The final product must consist of several one-minute mini-games that will measure at least five cognitive and motor abilities from the set of identified cognitive and motor abilities.

### 1.4 Work Scope
##### Existing Inspirations For Game Design
* [Super Mario Party](https://www.nintendo.com/games/detail/super-mario-party-switch/) (Nintendo, 2018): A party video game where players compete with each other while having fun by playing several small games to earn points. Unique challenges are designed in those small games that require different abilities to be successful. Games in the G-ScalE Mini-Game Battery Project will be designed similarly to the mini-games found in Super Mario Party.

##### Context of the Work
* The completion of this project is the focus of the course COMPSCI 4ZP6 and is a key requirement needed to graduate from the undergraduate computer science program at McMaster.
* A good understanding on motor and cognitive abilities is required to establish accurate measurement methods, which needs learning and reach on cognitive psychology.
* A good understanding of video game interface and design is required to ensure that the target data is collected in the most accurate and efficient methods allowed by the software.
* Design and implement a backend framework that automatically receives and stores data collected from the game interface.
* Beyond the end of the course, future work on the project could entail the development of further mini-games testing other abilities as well as the use of other input controllers apart from the keyboard.

### 1.5 Product Scope
##### Product Boundary
* The final product will be a series of mini-games consisting of at least five selected cognitive and motor abilities to be measured.
* Mini games should be designed as single-player games.
* The product will not be commercially sold and the platform will solely be laptop and desktop computers.
* In order for the mini-games to be played by more players and to collect rich data, we choose the web server as a platform for distribution and make our games playable in the browser using WebGL.
* Each mini-game is independent and has no continuity; players can choose which mini-game to start from freely.
* Due to the physical distance constraints caused by COVID-19 and the imposed limitations on interfaces, the testings on most of motor abilities will become less applicable. The main testing must then focus on cognitive abilities.
* The cognitive abilities that our group has decided to focus on are:
1. Object Recognition
2. Heading
3. Time To Contact
4. Audial Perception
5. Selective/Focused Visual

*Note*: the selected abilities will be confirmed with [Sasha Soraine](@sorainsm) in the biweekly meeting on Wednesday, Oct. 21st. They may be modified if necessary.

##### Measuring and Gamifying Our Chosen Cognitive Abilities
##### 1. Object Recognition: Flip-Flop-Clear
###### What is object recognition?
Object Recognition is the cognitive ability for an individual to identify the objects in their view based on visual input. It requires a person to perceive an object's physical properties, such as shape, colour and texture, and apply semantic attributes to the object, which include the understanding of its use, previous experience with the object, and how it relates to others.

###### Which theories underlie object recognition?
**Viewpoint-invariant Theory** - Led from the research done by Biederman showing that an object can be recognised equally easily from nearly all viewing angles (Eysenck, 97).

**Recognition by Components Theory** - There is generally much redundant information available for recognising complex objects, and so they can still be recognised when some geons or components are missing.

**Within-category Discriminations Theory** - A part of object recognition which deals with how a person is able to distinguish between categorisation and identification.

###### How can one measure object recognition?
The measuring of object recognition should be conducted through seeing how the individual would perform in recognizing images that comply with the above three theories. To quantify the measurement, timer and counter tools will be used to record the time and success rate of a person in recognizing objects underlying these three types respectively. The results together reveal the person's object recognition ability.

###### How will we gamify our measurement of object recognition?
The game driven from the object recognition ability is a card-flipping game called **Flip-Flop Clear**. It is 2-D card game where 9 cards are placed face down on the screen in a 3 x 3 array. Each card has a different image, and three of the images on the cards are related to each other. When the player presses the key matched to a card, the card flips over and the player can see its image. When the second card is turned over, if its image correlates to the first card, both cards remain face up, otherwise both cards go face down. The third card is flipped over in the same way. When a player has three cards with related images all face up, this type of cards is cleared. To win the game, the player must clear all three types of cards.

To correctly and fully measure the object recognition ability through the game, the images chosen will follow the above three theories such that the related images in the game will be defined as:
1. Three images of one object from a different point of view (corresponding to the Viewpoint-invariant Theory)
2. Three images of one object where each contains a part of the object (corresponding to the Recognition by Components Theory)
3. Three images of objects that belong to the same category. For example, images of a taxi, truck and SUV all belong to the vehicle category. (corresponding to the Within-category Discriminations Theory)

In the backend framework, the following data will be recorded through the timer and counter measurement tools:

The timer tool is used to measure:
* The time spent playing each round.
* The time between when a card is flipped over and the next time the same card is flipped over.
* The time between when the user clears one of the three types of cards and clears another type of cards.

The counter tool is used to measure:
* The number of times a card is flipped over.
* The number of valid flips and invalid flips: a valid flip is the flip that contributes to clearing the card. E.g. When one card *c1* is face up, flipping the card *c2* with the image related to card *c1* is a valid flip; otherwise, it’s an invalid flip.

*Note*:

The method to integrate the collected data and standardize the results will be implemented at a later after discussion with the supervisor, Sasha. We expect it will become more clear when we start implementing and getting the actual data in hand. The same is true for the other four abilities we'll next discuss.

###### Which cognitive abilities are related to object recognition?
To win the game, object recognition will be the core ability that player needs to have. Besides that, some other motor and cognitive abilities will also be involved in the gameplay. Such abilities include:
* Short term memory: remembering the images on a card as well as the position of a card; remembering which key on the keyboard is matched to which card on the screen.
* Pressing: the player's object recognition ability score is affected by how quickly they are able to press the key indicating their choice.

##### 2. Heading: Holy Sinkholes!
###### What is heading?
Heading is the cognitive ability to use visual information to move directly towards a goal or target (Eysenck, 124).

###### Which theories underlie heading?
Research has shown that an individual need not be moving to understand heading. Hahn et al showed in a 2003 study that the distance between nearby objects and an individual is what is important in rapidly determining heading. Additionally, Snyder and Bischof argued in a 2010 study that objects which are closer to the direction that an individual is heading result in less retinal displacement to the individual as the objects become closer (Eysenck, 125). Their study showed that objects which were nearer to an individual were more useful in determining heading than those further away.

However, Snyder and Bischof showed that using this displacement information to determine heading does *not* apply when an individual is following a complex path, such as one that is curved.

In fact, Hahn et al (2003) found that asking the user to perform additional tasks while determining heading would impair heading judgements when only displacement information is available (Eyesenck, 125).

###### How can one measure heading?
One method for measuring an individual's heading aptitude is to have an environment where there is a target point for the individual to reach and the goal is for the individual to reach said target in the most direct way possible. In this environment, obstacles can be placed such that an individual cannot simply travel in a straight line. Thus, in order for the individual to reach the target in the most direct fashion while avoiding the obstacles, they will need to determine a non-trivial path to the goal. The recorded measurement is then: *d_act - d_min* where *d_min* is the shortest distance of an obstacle-avoiding path from the individual's initial starting point and the target, and *d_act* is the actual distance the user traversed from the starting point to the target should they reach the target in the time provided.

###### How will we gamify our measurement of heading?
We will gamify the measurement of heading by developing a 2-D game called **Holy Sinkholes!**. In this game, the player must control a character on a gameboard. Also on the gameboard is a gold coin, which will be placed in a random location, as well as numerous sinkholes. The goal of the game is for the user to reach the gold coin by travelling the shortest distance possible all while avoiding any sinkholes within 60 seconds. If the user falls into a sinkhole, or runs out of time, they lose the game. The user is able to move in the left, right, up, and down directions and their movement is limited in this regard. The gameboard is a 2-D grid such that the user can only move atomically to another cell of the grid.

The location of the gold coin in this game allows for the player to establish heading information. Placing the gold coin in random locations at random distances from the player's character allows for us to test how the closeness of the gold coin to the player's character affects the player's heading performance using the work by Snyder and Bischof. Additionally, the sinkholes placed in the game will allow us to test how the user's heading performance is impaired by the additional task of avoiding the sinkholes. We can also collect data from these tests on how complex paths affect an individual's heading aptitude by having the shortest path generated contain a certain number of direction changes. We can then observe how the user's performance is affected as the number of direction changes in the shortest path increase. We anticipate that the surplus distance the user will traverse compared to the shortest distance will increase as the number of direction changes in the path increase, and our game will allow us to quantify this.

###### Which cognitive abilities are related to heading?
In addition to heading, our game **Holy Sinkholes!** might measure other cognitive abilities due to their relation to heading. The most similar motor ability in this respect is steering. With steering, an individual, or their game character, is already in movement meaning only direction need be considered when determining a path. In this respect, steering is a simplified version of heading as it takes the movement aspect out of the question. Since the player is in control of how the character moves in Holy Sinkholes!, and the character only moves atomically from one cell to another on a grid, the player must commit to the direction choice they make, and as a result, our measurements will accurately measure the player's heading aptitude with less chance of interference from steering.

##### 3. Time to Contact: Ball!
###### What is Time to contact?
Time to contact means predicting the moment there is going to be contact between a person and some object, including ones in which the individual is moving towards some object (e.g., a wall) and those in which an object (e.g., a ball) is approaching the individual (Eysenck, 1257).

###### Which theories underlie time to contact?
Theories about this concept are connected with the use of Tau. Lee argued in 1976 and 2009 that it is unnecessary to work out the distance or speed of an approaching object to work out the time to contact (Eysenck, 125). Since people are approaching objects (or objects are approaching people) at constant velocity, Lee suggested the use of Tau. Tau is defined as the size of an object’s retinal image divided by its rate of expansion. Tau specifies the time to contact with an approaching object – the faster the rate of expansion, the less time there is to contact. Under Lee's research about Tau, Tresilian analyzed Tau's limited applicability in several ways in the real world in 1999 (Eysenck, 125). Tresilian concluded that Tau is accurate only when applied to spherically symmetrical objects.

###### How can one measure time to contact?
To measure the time to contact, one can use an experiment where there is an object moving towards an individual and the individual needs to make contact with this object at an appropriate time using an apparatus such as a bat. The person's reaction to an object coming from different distances and at different speeds can be used to identify the person's time to contact ability. Such a measurement could include calculating the distance between the object and the individual at the point in time when the player attempts to hit the object. This measurement can reveal if the individual attempted to hit too early or too late. As a result, an individual is deemed to have a higher time to contact aptitude if the absolute value of the distance between the object and the individual is reduced.

###### How will we gamify our measurement of time to contact?
We will gamify our measurement of time to contact by developing a 3-D first-view game called **Ball!**. In this game, there will be a shooter at the front of the field of view. The shooter will shoot baseballs towards the player. The player is required to catch the ball by pressing a key when the baseball enters the outline of a target circle. The baseball will approach the player by moving in only one dimension. That is, the ball will have fixed *x* and *z* dimensions and only change in the *y* dimension(distance) as the ball comes closer to the player. A certain amount of balls will be shot in one round. Each time, the shooter shoots baseball towards the player at different speeds. That is, the difficulty of this game will increase as the speed of the ball and the distance between the shooter and the player increase. The time to contact measurement hidden in this game uses the absolute value of the distance between the ball and the player at the time the player attempts to catch the ball as described in the previous section.

The measurement tools we will need to measure this ability in the **Ball!** game include:
* A counter to measure the number of times that player misses the ball and the number of times that player manages to catch the ball.

* A distance calculator to calculate the absolute value of the distance between the player and the ball at the time that the player presses the button to try to catch.

###### Which abilities are related to time to contact?
Pressing is a motor ability which the players must engage in to play the game **Ball!**. Catching the ball in the game is triggered by pressing a key on the keyboard. As different players have different pressing abilities, their results in this game may vary to some extent. As a result, data gathered in this game can also be helpful to measure the ability of pressing.

##### 4. Audial Perception: Musician
###### What is audial perception?
Auditory perception is defined as the ability to receive and interpret information that has reached the ears through audible frequency waves transmitted through the air or by other means.

###### Which theories underlie audial perception?
According to an [article published at CogniFit.com](https://www.cognifit.com/science/cognitive-skills/auditory-perception#:~:text=Auditory%20perception%20could%20be%20defined,the%20air%20or%20other%20means), there are four properties and characteristics of sounds that the brain has to analyze in auditory perception:

* Intensity: Refers to if the volume is high or low.
* Tone: Refers to if the sound pitch is high or low.
* Timbre: Allows us to distinguish and recognize voices, instruments, or sounds. These are usually identified as the "color" of sound.
* Duration: The time the vibration of the sound lasts.

###### How can one measure audial perception?
Audial perception can be measured according to the four properties and characteristics presented in the previous section. By manipulating these four properties of sound, one can be asked to distinguish the difference within the characteristics of the sounds. For example, one can be asked to tell the difference between two musical sections that are played by different instruments to measure the ability of analysing the timbre of the sound. As well, a person may be presented with a tune with notes of varying intensity, tone and duration, and be asked to mimic the tune that they heard. Through the analysis of the result, one's ability of audial perception can be measured. Also, in such tests, the changes in these characteristics can initially be more pronounced and gradually become more subtle such that a more specific audial perception aptitude can be classified.

###### How will we gamify our measurement of audial perception?
To gamify our measurement, we decided on a music game, where specified keys represents musical notes, and the player is asked to listen to a musical note and repeat that note by pressing the corresponding key on the keyboard. The game will progress by alternating between the computer playing a note and the player playing it back. The notes played by the computer will each contain different timbres, tones, intensities, and durations. The player will be expected to distinguish the note and these four characteristics associated with it in order to play it back. The final score will depend on the number of times that the player accurately repeats the note in correct tone, intensity, timbre and duration.

To measure audial perception, the tools that will be used to record data in gameplay include:
* Timer tool: Used to record how long the player takes to duplicate the note. This is also used to measure the duration that the user plays a note by keeping a key pressed.
* Counter tool: Used to record the number of times that the correct and wrong key is pressed respectively.
* Distance tool: Used to measure the physical distance on the keyboard between the correct key and the wrong key when wrong key is pressed.

###### Which cognitive abilities are related to audial perception?
In the gameplay, besides correctly identifying the musical note, the player also needs to use the procedural memory ability to remember which keys on the keyboard are associated to which musical notes.

##### 5. Selective Visual: Cup Swap
###### What is selective visual?
The selective visual ability is the cognitive ability that has to do with the focus of vision on an area or object in the field of vision.

###### Which theories underlie selective visual?
Prior research on the selective visual topic has shown that some researchers believe that the selective visual ability is similar to a spotlight, where a small area of the vision is focused, or in the paracentral vision, and outside of the focused area, little can be seen (Eysenck, 151). This spotlight can be then be redirected at any time to focus on another area in the area of a person's peripheral vision. Later, researchers have modified this comparison to be that of zoom lens. The area of focal attention can be increased or decreased, similar to how a camera's zoom lens can be adjusted to zoom in, zoom out, sharpen objects or background, or blur objects or background (Eysenck, 151). These two theories are referred to as space-based attention since they refer to attending to a region of space, as opposed to object-based visual attention, the other aspect of selective visual attention that is often studied. Object-based visual attention is concerned with visual perception in terms of objects of interest. Research studies have shown that eye movements of a person when viewing natural scenes were directed almost exclusively to objects. However, both object-based visual attention and space-based visual attention are ideas that are consistent with the theories of visual perception resembling a spotlight or zoom lens. (Eysenck, 155).

###### How can one measure selective visual?

Since we do not have access to, or be able to provide eye tracking tools, our testing methods are limited to that of testing a person on whether they were able to track a moving object over a period of time. However, software tools such as a timer could be used to keep a record of the length of time that a person takes to indicate their guess about the location of the moved object. The person's correct or incorrect answer can also be used as a factor for their selective visual ability.

###### How will we gamify our measurement of selective visual?

We will gamify the measurement of selective visual perception by developing a 2-D game called **Cup Swap**. In this game, the player is shown an object that will be placed under a cup on a table. Several other cups identical to the first cup will also be on the table, but will not contain any objects. The cups on the table will switch positions for a small duration of time, and then the player will be asked to select the cup that they think contains the object.

When the cup that initially contains the object moves positions, the object inside the cup moves with it, and the movement of the cups on the table are shown visually to the player through game graphics. As a result, it is possible for the player to track the movement of the cup containing the object, therefore exercising the selective visual perception ability. The player must focus their visual attention on the cup with the object, and keep track of its position as the cups are shuffled. The player may also, as a result unfocus their attention on the similar looking cups, as well as any other details and distractions on the screen for the most optimal approach to ensure that they get the correct answer at the end.

If the player is confident in their answer, they may immediately submit their answer after the cup position shuffling is complete. If for some reason, the player has difficulty tracking the cup with the object, they may take a longer time to submit their answer. Such an aspect will be taken into account in the selective visual ability measurement.

###### Which cognitive abilities are related to selective visual?

Other related cognitive abilities associated to selective visual perception include the visualspatial sketchpad, the episodic buffer, inhibition, iconic sensory memory and the updating working memory ability. The visuospatial sketchpad in combination with updates to the working memory, as well as the iconic sensory memory will be used to visualize and keep track of the position of the cup as it changes. The iconic sensory memory would be the first ability used, to provide a representation of the current visual perception to the brain before the visuospatial sketchpad and working memory is updated to represent the information. The Episodic Buffer would process the information related to the positions of the target cup over a period of time, and the inhibition ability would constantly be used to unfocus attention on the other cups. All such abilities are necessary for the storage of related visual information, and for the function of selective visual perception.

The pressing motor ability will also be required, since the timer that keeps track of the length of time that the player took to give their answer is stopped when they press the appropriate key. As a result, the player's ability to press the key may affect the elapsed time.

##### Product Use Case (PUC) Table
| PUC | PUC Name | Actor(s) | Input/Output |
| ---- | ------- | ----------| --------- |
| <a name="puc-1"></a>1 | Choose Game | Player | Key Input(In), Initial Game Data (Out) |
| <a name="puc-2"></a>2 | Exit Game | Player | Key Input(In), VOID |
| <a name="puc-3"></a>3 | Pause Game | Player | Key Input(In), Game Status(Out) |
| <a name="puc-4"></a>4 | Resume Game | Player | Key Input(In), Game Status(Out) |
| <a name="puc-5"></a>5 | End Game | Player | Key Input(In), Game Status(Out) |
| <a name="puc-6"></a>6 | Check Final Score | Player | Key Input(In), Score Data(Out) |
| <a name="puc-7"></a>7 | Check Ability Report | Player |Key Input(In), Player Game Data (Out) |
| <a name="puc-8"></a>8 | Move Character | Player | Key Input(In), Character Position(Out) |
| <a name="puc-9"></a>9 | Fall in Sinkhole | Player | Key Input(In), Player Game Data(Out) |
| <a name="puc-10"></a>10 | Change Instrument Options | Player | Key Input(In), Player Game Data(Out), Auditory Data(Out) |
| <a name="puc-11"></a>11 | Select the Cup | Player | Key Input(In), Player Game Data(Out) |
| <a name="puc-12"></a>12 | Catch the ball | Player | Key Input(In), Player Game Data(Out) |
| <a name="puc-13"></a>13 | Show Game Instructions | Player | Key Input(In), Game Status(Out) |
| <a name="puc-14"></a>14 | Dismiss Game Instructions | Player | Key Input(In), Game Status(Out) |
| <a name="puc-15"></a>15 | Flip First Card | Player | Key Input(In), Game Status(Out) |
| <a name="puc-16"></a>16 | Flip Second Card | Player | Key Input(In), Game Status(Out) |
| <a name="puc-17"></a>17 | Flip Third Card | Player | Key Input(In), Game Status(Out) |
| <a name="puc-18"></a>18 | Flip-Flop Clear | Player | Key Input(In), Game Status(Out) |
| <a name="puc-19"></a>19 | Check Auto End | Player | Key Input(In), Game Status(Out) |
| <a name="puc-20"></a>20 | Change Settings | Player | Key Input(In), Game Status(Out) |
| <a name="puc-21"></a>21 | Change Volume | Player | Key Input(In), Game Status(Out) |
| <a name="puc-22"></a>22 | Close Settings | Player | Key Input(In), Game Status(Out) |
| <a name="puc-23"></a>23 | Exit End Screen | Player | Key Input(In), Game Status(Out) |
| <a name="puc-24"></a>24 | Start Timer | Computer | VOID, Game Status(Out) |
| <a name="puc-25"></a>25 | End Timer | Computer | VOID, Game Status(Out) |
| <a name="puc-26"></a>26 | Get Key Input | Computer | Key Input(In), Specific Key Entered(Out) |
| <a name="puc-27"></a>27 | Reset Counter | Computer | Key Input(In), VOID |
| <a name="puc-28"></a>28 | Increment Counter | Computer | Key Input(In), Specific Key Entered(Out) |
| <a name="puc-29"></a>29 | Calculate Distance | Computer | (Start Coordinates, End)(In), Floating-Point Number(Out) |
| <a name="puc-30"></a>30 | Generate Note | Computer | (Tone, Intensity, Timbre, Duration)(In), Sound(Out) |
| <a name="puc-31"></a>31 | Calculate Shortest Distance | Computer | (Graph, Start Vertex, End Vertex)(In), Floating-Point Number(Out) |
| <a name="puc-32"></a>32 | Random Number Generator | Computer | (LowerBound, UpperBound)(In), Integer Number(Out) |
| <a name="puc-33"></a>33 | Indicate Note Length | Player | Key Input(In), Duration(Out) |
| <a name="puc-34"></a>34 | Play the music | Player | Key Input(In), Player Game Data(Out), Auditory Data(Out) |

##### States Table
The following lists the possible states in the game, and a brief description of the purpose of the state.

| State Name | Description of State |
| ----------------- | ---------------------------------- |
| IN_MAIN_MENU | Main menu is shown |
| PAUSE(*g*) | Game *g* is the previously active game, and is now in the pause menu. |
| SETTINGS(*g*) | Game *g* is the previously active game, and is now in the settings menu. |
| ACTIVE(*g*) | Game *g* is the current game being played. |
| FINISHED(*g*) | Game *g* has ended. |
| INSTRUCTIONS(*g*) | Game *g* was chosen from the main menu, and now shows the instructions for game *g* |

The following lists the possible values of *g*. More detail about each game can be seen in their corresponding cognitive ability sections.

| Values for *g* | Brief Description for the Value |
|-----------------|----------------------------------------------------------------|
| SINKHOLE | Game corresponding to the heading cognitive ability |
| MUSICIAN | Game corresponding to the audial perception cognitive ability |
| CUP_SWAP | Game corresponding to the selective visual cognitive ability |
| BALL | Game corresponding to the time to contact cognitive ability |
| FLIP_FLOP_CLEAR | Game corresponding to the object recognition cognitive ability |

##### Individual Product Use Cases
| [PUC No.1](#puc-1) | Event: Choose Game |
| ---- | ------- |
| Trigger | Player selects a mini-game from the game menu. |
| Preconditions | Game state is IN_MAIN_MENU. |
| Procedure | <ol><li>Initialize new game data.</li> <li>Load new game data.</li> <li>Game state is switched to INSTRUCTIONS(*g*) where *g* is the game name.</li></ol> |
| Outcome | Player is in a mini-game instance of game *g*. |

| [PUC No.2](#puc-2) | Event: Exit Game |
| ---- | ------- |
| Trigger | Player selects "Exit" option. |
| Preconditions | Game state is IN_MAIN_MENU, FINISHED(*g*), or PAUSE(*g*) for some game name *g*. |
| Procedure | <ol><li>Display message "Do you really want to exit?".</li> <li>Get input from (1).</li> <li>Close the tab of the web application depending on the input.</li></ol>|
| Outcome | Player exits the web application. |

| [PUC No.3](#puc-3) | Event: Pause Game |
| ---- | ------- |
| Trigger | Player selects "Pause" option. |
| Preconditions | Player is in a mini-game *g*, and the game state is ACTIVE(*g*). |
| Procedure | <ol><li>Game is switched into PAUSE(*g*) state.</li> <li>A pause menu is displayed.</li></ol> |
| Outcome | Game is paused and a pause menu is on the screen. |

| [PUC No.4](#puc-4) | Event: Resume Game |
| ---- | ------- |
| Trigger | Player selects "Resume" option from pause menu. |
| Preconditions | Player is in mini-game *g*, and the game state is PAUSE(*g*). |
| Procedure | <ol><li>Game is switched into ACTIVE(*g*) state.</li> <li>Pause menu is not displayed.</li></ol> |
| Outcome | Game is resumed and players can play the game. |

| [PUC No.5](#puc-5) | Event: End Game |
| ---- | ------- |
| Trigger | Player selects "End" option from pause menu. |
| Preconditions | Player is in mini-game *g*, and the game state is PAUSE(*g*). |
| Procedure | <ol><li>Game is switched into FINISHED(*g*) state.</li> <li>End screen is displayed.</li></ol> |
| Outcome | Game is terminated and the end screen is on the screen. |

| [PUC No.6](#puc-6) | Event: Check Final Score |
| ---- | ------- |
| Trigger | The end screen is displayed. |
| Preconditions | Game state is in FINISHED(*g*) for some game *g*, and the end menu is displayed.|
| Procedure | <ol><li>The final score will be displayed.</li></ol> |
| Outcome | The final score of the player is displayed.|

| [PUC No.7](#puc-7) | Event: Check Ability Report |
| ---- | ------- |
| Trigger | The end menu is displayed. |
| Preconditions | Game state is FINISHED(*g*) or IN_MAIN_MENU. |
| Procedure | <ol><li>The level of competency will be generated for each ability. </li></ol> |
| Outcome | The ability report of the player is displayed. |

| [PUC No.8](#puc-8) | Event: Move Character |
| ---- | ------- |
| Trigger | Player presses a key *k* to move the character. |
| Preconditions |The game state is ACTIVE(SINKHOLE).|
| Procedure | <ol><li>Character moves according to the pressed key.</li></ol> |
| Outcome | Character's direction in 2-dimensional space is changed depending on the key *k* until the key is released. The specific key *k* determines whether the character moves in the up, down, left, or right direction. |

| [PUC No.9](#puc-9) | Event: Fall in Sinkhole |
| ---- | ------- |
| Trigger | Character falls into a sinkhole. |
| Preconditions | The game state is ACTIVE(SINKHOLE). |
| Procedure | <ol><li>Game is switched into the FINISHED(SINKHOLE) state.</li> <li>End screen is displayed.</li></ol> |
| Outcome | Game is terminated and the end screen is on the screen. |

| [PUC No.10](#puc-10) | Event: Change Instrument Options |
| ---- | ------- |
| Trigger | Player cycles between changing the instrument (timbre) and the volume (intensity) using the up and down arrow keys. Player increases or decreases volume level (when volume is being selected) by using the left or right arrow keys. |
| Preconditions | Current game is ACTIVE(MUSICIAN). |
| Procedure | <ol><li>The player cycles between changing the instrument and volume using the up and down arrow keys.</li> <li>If volume is selected, the volume level is decreased using the left arrow key and increased using the right arrow keys.</li></ol> |
| Outcome | The user is able to change their instrument and its volume level. |

| [PUC No.11](#puc-11) | Event: Select the Cup |
| ---- | ------- |
| Trigger | Player clicks on the cup that they think has the object underneath it |
| Preconditions | The player has been shown the object, the object was placed underneath one of the three cups, and the cup positions on the screen are done shuffling, and current state is ACTIVE(CUP_SWAP). |
| Procedure | <ol><li>Game is switched into FINISHED(CUP_SWAP).</li></ol> |
| Outcome | <ol><li>Player gets scored depending on if they chose correctly</li><li>Are there more rounds to be played?<ul><li>YES: Go to the next round</li><li>NO: End game, change state to FINISHED(CUP_SWAP), show the end screen.</ul></li></ol> |

| [PUC No.12](#puc-12) | Event: Catch the Ball |
| ---- | ------- |
| Trigger | Player presses a key *k* on the keyboard that is associated to catching the ball object.|
| Preconditions | Current game is ACTIVE(BALL). |
| Procedure | <ol><li>Save the position of the ball when the key is pressed. </li><li>Calculate the distance between the ball and the target area when the key is pressed. </li></ol> |
| Outcome | <ol><li>Player gets scored depending on the distance between the target area and the location where the ball was when the key was pressed.</li><li>Are there more rounds to be played?<ul><li>YES: Go to the next round.</li><li>NO: End game, change state to FINISHED(BALL),and show the end screen.</ul></li></ol> |

| [PUC No.13](#puc-13) | Event: Show Game Instructions |
| ---- | ------- |
| Trigger | Player has selected game *g* |
| Preconditions | Game state is IN_MAIN_MENU. |
| Procedure | <ol><li>Game state is switched to INSTRUCTIONS(*g*).</li></ol> |
| Outcome | Instructions are shown for the game *g*. |

| [PUC No.14](#puc-14) | Event: Dismiss Game Instructions |
| ---- | ------- |
| Trigger | Player presses the "OK" button on the instruction panel. |
| Preconditions | Game state is INSTRUCTIONS(*g*) for some game *g*. |
| Procedure | <ol><li>Game state is switched to ACITVE(*g*).</li></ol> |
| Outcome | Player can start playing the game *g*. |

| [PUC No. 15](#puc-15) | Event: Flip First Card |
| ---- | ------- |
| Trigger | Players select a card *c1* on the screen. |
| Preconditions | Current game state is ACTIVE(FLIP_FLOP_CLEAR), and there is no card flipped. |
| Procedure | <ol><li>Display the face of card *c1*.</li></ol>|
| Outcome |The card *c1* remains face up.|

| [PUC No.16](#puc-16) | Event: Flip Second Card |
| ---- | ------- |
| Trigger | Players select a card *c2* on the screen. |
| Preconditions |Current game state is ACTIVE(FLIP_FLOP_CLEAR), and the first card *c1* is flipped. |
| Procedure | <ol><li>Flip and display the face of card *c2*.</li> <li>Check the type of the first card *c1*.</li></ol> |
| Outcome | The cards *c1* and *c2* remain face up if the face of *c1* is the same type as that of *c2*; otherwise the card *c1* and *c2* go face down.|

| [PUC No.17](#puc-17) | Event: Flip Third Card |
| ---- | ------- |
| Trigger | Players select a card *c3* on the screen. |
| Preconditions | Current game is ACTIVE(FLIP_FLOP_CLEAR), and the second card *c2* is flipped |
| Procedure | <ol><li>Display the face of flipped card *c3*.</li> <li> Check the type of the second card *c2*.</li></ol> |
| Outcome |The card *c3* remains face up if its face is of the same type of the second one *c2*; otherwise the card *c3* together with the first card *c1* and the second card *c2* go face down. |

| [PUC No.18](#puc-18) | Event: A Type Is Cleared |
| ---- | ------- |
| Trigger | Flip Third Card event is occurring. |
| Preconditions | Current game is ACTIVE(FLIP_FLOP_CLEAR), and the third card *c3* is face up. |
| Procedure | <ol><li>The card type that corresponds to the type of card *c3* is cleared.</li><li>The cards *c1*, *c2*, and *c3* disappear from the game board. |
| Outcome | The player's score is increased. The cleared cards disappear.|

| [PUC No.19](#puc-19) | Event: Check Auto End |
| ---- | ------- |
| Trigger | A Type Is Cleared event is occurring. |
| Preconditions | Current game is ACTIVE(FLIP_FLOP_CLEAR), and there does not exist any card *c* on the game board. |
| Procedure | <ol><li> Game state changes to END(*g*).|
| Outcome | End of the Flip-Flop Clear Game. |

| [PUC No.20](#puc-20) | Event: Open Change Settings |
| ---- | ------- |
| Trigger | Player clicks on the settings icon.|
| Preconditions | Game state *s* is PAUSE(*g*) for some game *g* or IN_MAIN_MENU. |
| Procedure | <ol><li>Game state is changed to SETTINGS(*s*).</li><li>The settings menu appears.</li></ol> |
| Outcome | Player can alter game settings, such as volume and brightness. |

| [PUC No.21](#puc-21) | Event: Alter Settings |
| ---- | ------- |
| Trigger | The user changes the value of a setting *t* such as volume or brightness. |
| Preconditions | Game state is SETTINGS(*s*) for some state *s*. |
| Procedure | <ol><li>Game setting *t* is changed.</li></ol> |
| Outcome | Game settings are changed. |

| [PUC No.22](#puc-22) | Event: Close Settings |
| ---- | ------- |
| Trigger | Player presses the key to close the settings menu. |
| Preconditions | Game state is SETTINGS(*s*) for some state *s*. |
| Procedure | <ol><li>Game state is changed to state *s*.</li></ol> |
| Outcome | Player returns to screen that they were on before they entered the settings menu. |

| [PUC No.23](#puc-23) | Event: Exit End Screen |
| ---- | ------- |
| Trigger | Player presses exit button on the end screen. |
| Preconditions | Game state is END(*g*). |
| Procedure | <ol><li>Game state is changed to IN_MAIN_MENU.</li><li>The screen changes to the main menu.</li></ol> |
| Outcome | The player is returned to the main menu. |

| [PUC No.24](#puc-24) | Event: Start Timer |
| ---- | ------- |
| Trigger | Player presses a key associated with a timer. |
| Preconditions | Game state is ACTIVE(*g*), for some game *g*. |
| Procedure | <ol><li>Create a variable to store the current time.</li></ol> |
| Outcome |Timer has started. |

| [PUC No.25](#puc-25) | Event: End Timer |
| ---- | ------- |
| Trigger | Player presses a key associated with the timer end condition |
| Preconditions | Game state is ACTIVE(*g*), for some game *g*. |
| Procedure | <ol><li>Save the value in the timer.</li>Calculate the different between start timer variable and end timer variable to find the time elapsed.</ol> |
| Outcome | The timer has ended, and time elapsed is recorded. |

| [PUC No.26](#puc-26) | Event: Get Key Input |
| ---- | ------- |
| Trigger | Player presses a key on the keyboard. |
| Preconditions | The web application is open. |
| Procedure | <ol><li>Key input is saved</li><li>The function corresponding to key input is called.</li></ol> |
| Outcome | The player interacts with the software. |

| [PUC No.27](#puc-27) | Event: Reset Counter |
| ---- | ------- |
| Trigger | Player presses a key associated with a new counter object or specific game counter requirements are met. |
| Preconditions | Game state is ACTIVE(*g*). |
| Procedure | <ol><li>A new counter object is initialized, where the value is set to 0.</li></ol> |
| Outcome | A new counter is created. |

| [PUC No.28](#puc-28) | Event: Increment Counter |
| ---- | ------- |
| Trigger | The event associated with the counter has occurred. |
| Preconditions | Game state is ACTIVE(*g*). |
| Procedure | <ol><li>The value existing in the counter is incremented by 1.</li></ol> |
| Outcome | The counter has been incremented. |

| [PUC No.29](#puc-29) | Event: Calculate Distance |
| ---- | ------- |
| Trigger | The distance between two coordinates in a game needs to be calculated. |
| Preconditions | Game state is ACTIVE(*g*), and the game *g* requires a distance calculation. |
| Procedure | <ol><li>The Euclidean distance is calculated between the two coordinates.</li></ol> |
| Outcome | The distance between the two coordinates is established and returned. |

| [PUC No.30](#puc-30) | Event: Generate Note |
| ---- | ------- |
| Trigger | The computer plays a note to the player or the player presses a key to play a note back. |
| Preconditions | Game state is ACTIVE(MUSICIAN). |
| Procedure | <ol><li>Generate the note with the specified tone, timbre and intensity for the specified duration.</li></ol> |
| Outcome | The sound for the specified note is played. |

| [PUC No.31](#puc-31) | Event: Calculate Shortest Distance |
| ---- | ------- |
| Trigger | A new round of Sinkhole game begins. |
| Preconditions | Game state is ACTIVE(SINKHOLES). |
| Procedure | <ol><li>Calculate the shortest distance of a path between the starting point of the player and the gold coin target such that the path avoids any sinkholes.</li></ol> |
| Outcome | The shortest distance from the player's initial coordinate to the coin is returned. |

| [PUC No.32](#puc-32) | Event: Random Number Generator |
| ---- | ------- |
| Trigger | The computer needs an element of randomness in the game being played. |
| Preconditions | Game state is ACTIVE(*g*), for some game *g*. |
| Procedure | <ol><li>Choose an integer between the lower and upper bound inclusive.</li></ol> |
| Outcome | A random number in the range is generated for use in adding an element of randomness to the game *g*. |

| [PUC No.33](#puc-33) | Event: Indicate Note Length |
| ---- | ------- |
| Trigger | The player presses or holds down a key *k* corresponding to a specific note. |
| Preconditions | Game state is ACTIVE(MUSICIAN). |
| Procedure | <ol><li>Call the function to generate the sound with the timbre and intensity saved in the instrument settings with the tone corresponding to key *k* for the duration that key *k* is pressed down.</li></ol> |
| Outcome | The sound of the note indicated is played starting when the key *k* is pressed and lasting until the key *k* is released. |

| [PUC No.34](#puc-34) | Event: Play the music |
| ---- | ------- |
| Trigger | Player press the key *k* that represented different music notes. |
| Preconditions | Current game is ACTIVE(MUSICIAN). |
| Procedure | <ol><li>The music notes are recorded according to the pressed key</li></ol> |
| Outcome | The sound of the music note are played, and players are able to press the next key if it is not the las key, or the game is terminated and the end screen is on the screen. |

### 1.6 Definitions, Acronyms and Abbreviations
#### Domain-specific terminology
* Cognitive abilities: Brain-based skills which are needed in acquisition of knowledge, manipulation of information, and reasoning.
* Competency profile: The set of cognitive and motor abilities that characterize a task.
* Episodic Buffer - Components of the working memory model, a temporary store that integrates information from the other components and maintains a sense of time, so that events occur in a continuing sequence
* Gameplay challenges: Any in-game activity with a success condition which engages the player in a way that requires some level of proficiency in at least one dimension (physical or cognitive).
* Gameplay mechanics: The game's rules, objectives, challenges and methods that the player is meant to use or follow to interact with the game.
* Geon: Basic shapes or components of an object. Examples of geons are blocks, cylinders, spheres, arcs and wedges.
* Iconic Sensory Memory - A brief (<1 second) high capacity memory story, providing a coherent representation of our entire visual perception for a very brief period of time
* Inhibition - Ability to tune out stimuli that are irrelevant to the task
* Mechanical achievability: A notion whether a player can complete a game's challenges given their cognitive and motor abilities.
* Mechanical difficulty: A notion how the design of the game itself affects this mechanical achievability.
* Mechanical experience: The underlying interaction between the user and game.
* Motor abilities: Learned abilities to cause a predetermined movement outcome with maximum certainty.
* OS: Operating System. The system software that manages computer hardware, software resources, and provides common services for computer programs.
* Paracentral Vision: A form of vision that utilizes the retinal area immediately surrounding, but not including, the fovea centralis.
* Parameters: A numerical value or property of the software that helps determine the environment or state of the software.
* PC: Personal Computer. A multi-purpose machine whose size, capabilities, and price make it feasible for individual use.
* Time to contact: Time to contact means predicting the moment there is going to be contact between a person and some object, including ones in which the individual is moving towards some object (e.g., a wall) and those in which an object (e.g., a ball) is approaching the individual.
* Unity: A cross-platform game engine developed by Unity Technologies.
* UI: User Interface. The method through which users interact with the hardware and software of computers and other electronic devices.
* Updating Working Memory - Updating the limited capacity that holds information temporarily, what is used for reasoning and guidance of decision-making and behavior, manipulation of stored information
* Visuospatial Sketchpad is a component of working memory model which stores and processes information in a visual or spatial form

#### Document-specific terminology
* Mid-range modern computer: We consider a mid-range modern computer to be a laptop or desktop from 2015 or newer with a 2.9 GHz Intel Core i5 or better processor, 8GB or more of 1867 MHz DDR3 memory, and a integrated GPU that performs at the level of or better than an Intel Iris Pro 5200.
* N/A: Indicates that a section is not applicable.
* SRS: Software Requirements Specification. This requirements document.

### 1.7 References
“Unity (Game Engine).” Wikipedia. Wikimedia Foundation, October 2, 2020. https://en.wikipedia.org/wiki/Unity_(game_engine).

"Visual object recognition (animal test)." Wikipedia. Wikimedia Foundation, October 18, 2020,
https://en.wikipedia.org/wiki/Visual_object_recognition_(animal_test)

“User Interface.” Dictionary.com. Accessed October 12, 2020, https://www.dictionary.com/browse/user-interface.

“Operating System.” Wikipedia. Wikimedia Foundation, October 7, 2020.
https://en.wikipedia.org/wiki/Operating_system.

“Personal Computer.” Wikipedia. Wikimedia Foundation, October 7, 2020. https://en.wikipedia.org/wiki/Personal_computer.

“Cognitive Skill.” Wikipedia. Wikimedia Foundation, September 13, 2020. https://en.wikipedia.org/wiki/Cognitive_skill.

“Motor Skill.” Wikipedia. Wikimedia Foundation, September 22, 2020. https://en.wikipedia.org/wiki/Motor_skill.

"Auditory Perception." Cognifit.com. Accessed October 18, 2020,
https://www.cognifit.com/science/cognitive-skills/auditory-perception#:~:text=Auditory%20perception%20could%20be%20defined,the%20air%20or%20other%20means.

Soraine, Sasha. “CS 4ZP6: Mini-Game Battery Project.” 2020. PDF file.
Robertson, James P. and S. Robertson. “Volere: Requirements specification template.” 2000. PDF file.

Eysenck, M. W., & Keane, M. T. (2020). Cognitive psychology a student's handbook. London: Psychology Press, Taylor & Francis Group.

### 1.8 Document Overview
The rest of this document will be divided into 4 parts. The first part is the product overview which consists of topics such as the product perspective, functions, and constraints. This part describes information about the general factors of the product and requirements. The second part describes the requirements related to the external interface, functional requirements, and quality of service. This part illustrates the detailed and specific requirements of the product. The third part relates to verification which provides the verification approaches and methods that are going to determine whether the software is successful at solving the problems posed by the stakeholders. The last part describes the appendix.

## 2. Product Overview
Our product is composed of a series of small video games that focuses on five select cognitive abilities out of [46 identified human cognitive and psychomotor requirements](#121-identified-cognitive-and-motor-abilities) associated with video game challenges: object recognition, token change direction, time to contact, audial perception, and selective visual. Each individual game will be designed as single-player game and will focus primarily on one of the five selected abilities. The games will be accessible by the players through a web application that runs on a web server, and collects input through the keyboard and mouse. The input collected by the web application will be used to establish an ability baseline for the player, and to determine how parameter changes in the atomic challenges affect mechanical achievability and mechanical difficulty. The research results from the product will be used to contribute to the creation of innovative approaches in future game development and will bring about a greater understanding of the underlying science behind video games.

### 2.1 Product Perspective
The G-ScalE project has existing research by [Sasha Soraine](@sorainsm), who has created a framework for identifying atomic challenges in video games and hypotheses about the mechanical experiences of video games. Our capstone group is one of two groups that will be working on products to test and further the hypotheses and research already done. The two groups will be sharing the backend framework and will design and implement it such that the video game designs from both groups adhere to it. The video game designs will reference existing test methods and research of the selected cognitive abilities to design video games that can be used to test and capture data related to the cognitive abilities.

### 2.2 Product Functions
* User must understand how to navigate through the application using the user interface
* User must understand how to play the game
* The user should be able to complete each mini game without major software errors that prevent the user from completing the game
* The mini game must be completed in under a minute
* Sufficient data should be able to be collected from each mini game

### 2.3 Product Constraints

The only external devices that can be used to collect user data at this point in time is the computer keyboard and computer mouse, due to the ongoing coronavirus pandemic. As such, our product's software must be accessed as a web application that can be reached using a standard internet browser on a laptop or desktop.

### 2.4 User Characteristics
* Proficient with use of a computer mouse and computer keyboard
* Able to read and understand the instructions of the game
* Has access to the internet and has a browser that can run the web application
* Has a computer mouse and computer keyboard
* Player is a generic able-bodied neurotypical person, a player with
normative motor and cognitive abilities

### 2.5 Assumptions and Dependencies

* Free-to-use assets from the Unity asset store will remain free to use during project implementation and after project completion
* The license requirements for the software being developed and Unity do not change
* The expectations required by the project lead do not change
* The product will not be commercially released
* Game assets may come from third party resources
* There exist effective methods to measure a subset of the cognitive and motor abilities using the keyboard only as the main input device

## 3. Requirements

### 3.1 External Interfaces

#### 3.1.1 User interfaces

##### Ease of Use Requirements
| **ID**: EU-1 | **Type**: Non-Functional (Ease of Use) |
| -------------------- | --------------------------------------- |
| **Related PUC**: N/A | **Originator**: [Yunfei](@yangy113) |
| **Description** | The player should know how to control all the mini games after a relatively short game time. |
| **Rationale** | The control of mini games should not make players confused or frustrated. |
| **Fit Criterion** | More than 85% of players can master these games after reading the provided game instructions as measured by a user survey. |
| **Priority** | Medium |

| **ID**: EU-2 | **Type**: Non-Functional (Ease of Use) |
| -------------------- | --------------------------------------- |
| **Related PUC**: N/A | **Originator**: [Yunfei](@yangy113) |
| **Description** | Players from all ages can enjoy playing these games. |
| **Rationale** | Collecting game data from different age groups is very important for measuring motor and cognitive abilities of different individuals. |
| **Fit Criterion** | General population of players aged about 10 to 70 can all play these games because game difficulty is designed to match this demographic. |
| **Priority** | High |

##### Personalization Requirements
| **ID**: PR-1 | **Type**: Non-Functional (Personalization) |
| -------------------- | ------------------------------------------- |
| **Related PUC**: N/A | **Originator**: [Yunfei](@yangy113) |
| **Description** | In each mini game, players can modify the game settings to adapt to their needs for volume and window size. |
| **Rationale** | Each player has their preference on setting options. |
| **Fit Criterion** | Setting options can be adjusted. |
| **Priority** | Low |

##### Learning Requirements
| **ID**: LR-1 | **Type**: Non-Functional (Learning) |
| -------------------- | ---------------------------------------- |
| **Related PUC**: N/A | **Originator**: [Yunfei](@yangy113) |
| **Description** | Players can learn these games quickly, making the motor and cognitive ability aptitudes reflected by the data obtained accurate. |
| **Rationale** | The motor and cognitive abilities reflected by the data should not be made inaccurate because the player does not understand the game. |
| **Fit Criterion** | More than 85% of players can master these games after reading the provided game instructions as measured by a user survey. |
| **Priority** | Medium |

| **ID**: LR-2 | **Type**: Non-Functional (Learning) |
| -------------------- | ---------------------------------------- |
| **Related PUC**: N/A | **Originator**: [Alice](@ipa1) |
| **Description** | Players can quickly understand how to navigate through the menus of our web application. |
| **Rationale** | We need to consider the web application as a whole, rather than just the mini-games, when it comes to learnability or otherwise the player will not play our games if they get lost in menus. |
| **Fit Criterion** | Design an menu that 85% of players find easy to learn how to navigate through the web application as indicated in a post-game user survey. |
| **Priority** | Medium |

##### Understandability and Politeness Requirements
| **ID**: UP-1 | **Type**: Non-Functional (Understandability and Politeness) |
| -------------------- | ---------------------------------------- |
| **Related PUC**: N/A | **Originator**: [Yunfei](@yangy113) |
| **Description** | All text related to settings and rules that appear in mini games must be in English. |
| **Rationale** | The target players of these mini games are in English-speaking countries, so the language of the games should be in English. |
| **Fit Criterion** | All text related to settings and rules that appear in mini games are written in English. |
| **Priority** | High |

| **ID**: UP-2 | **Type**: Non-Functional (Understandability and Politeness) |
| -------------------- | ---------------------------------------- |
| **Related PUC**: N/A | **Originator**: [Yunfei](@yangy113) |
| **Description** | Symbols and icons that appear in mini games should be easy to understand. |
| **Rationale** | The gameplay should not be influenced by complicated and obscure symbols. |
| **Fit Criterion** | More than 85% symbols and icons that appear in the mini games convey intuitive information, as indicated in a post-game user survey. |
| **Priority** | Medium |

##### Accessibility Requirements
| **ID**: AR-1 | **Type**: Non-Functional (Accessibility) |
| -------------------- | ---------------------------------------- |
| **Related PUC**: N/A | **Originator**: [Yunfei](@yangy113) |
| **Description** | Notify the player with the ability required to play a game before the game starts. |
| **Rationale** | People with disabilities may not be able to complete certain games, but there are still some games that they can play. |
| **Fit Criterion** | Some games that have special requirements for players need to be noted. For example, games about audial perception need to explain that hearing impaired players cannot participate, and certain games about motor abilities need to explain that different kinds of disabled people cannot participate. In other words, except for those marked contents, disabled people can play other games. |
| **Priority** | High |

#### 3.1.2 Hardware interfaces

| **ID**: HI-1 | **Type**: Non-Functional |
| -------------------- | ---------------------------------------- |
| **Related PUC**: N/A | **Originator**: [Yunfei](@yangy113) |
| **Description** | All games should be played on mid-range modern computers. |
| **Rationale** | In order to make the games run better, the computer must not be too old. |
| **Fit Criterion** | The games run on mid-range modern computers. On computers with lower specifications than that of a mid-range modern computer, we make no guarantee that the games will run. |
| **Priority** | High |

| **ID**: HI-2 | **Type**: Non-Functional |
| -------------------- | ---------------------------------------- |
| **Related PUC**: N/A | **Originator**: [Yunfei](@yangy113) |
| **Description** | The Internet speed of the player's computer must be at least 10 Mbps. |
| **Rationale** | In order to ensure the player receives optimal and smooth gameplay performance, they need to maintain a good Internet connection. Low gameplay performance caused by unstable internet should not reflect the player's abilities properly. |
| **Fit Criterion** | Test the Internet speed of our players and give them a warning about potential gameplay issues if their Internet speed is lower than 10 Mbps. |
| **Priority** | High |

| **ID**: HI-3 | **Type**: Non-Functional |
| -------------------- | ---------------------------------------- |
| **Related PUC**: N/A | **Originator**: [Yunfei](@yangy113) |
| **Description** | The resolution of computers should be not be too low. |
| **Rationale** | Low resolution games can affect the player's visual experience and result in bad gameplay performance, which can cause inaccuracies in the testing results. |
| **Fit Criterion** | In order for the graphic objects to show clearly on player's computer, the resolution of the computer should be greater than 1024×768p. |

| **Priority** | High |

| **ID**: HI-4 | **Type**: Non-Functional |
| -------------------- | ---------------------------------------- |
| **Related PUC**: N/A | **Originator**: [Yunfei](@yangy113) |
| **Description** | The keyboard of computers running these games should be in good condition. |
| **Rationale** | The problem of the keyboard itself can interfere with the results of measuring motor and cognitive abilities. |
| **Fit Criterion** | The keyboards of computers running these games should have no missing keys and no sticky keys. |
| **Priority** | High |

| **ID**: HI-5 | **Type**: Non-Functional |
| -------------------- | ---------------------------------------- |
| **Related PUC**: N/A | **Originator**: [Yunfei](@yangy113) |
| **Description** | The mouse of computers running these games should be in good condition. |
| **Rationale** | The mouse, although not the primary input source for the mini-games, is used to navigate the menus of our web application. |
| **Fit Criterion** | The mouse of computers running these games should be responsive and its latency should be at most 4 milliseconds. |
| **Priority** | Medium |

| **ID**: HI-6 | **Type**: Non-Functional |
| -------------------- | ---------------------------------------- |
| **Related PUC**: N/A | **Originator**: [Yunfei](@yangy113) |
| **Description** | The RAM of computers should be proper to run these games. |
| **Rationale** | In order to make the games run better, the RAM of computers should not be too bad. |
| **Fit Criterion** | The RAM of computers running these games should be at least 8GB. |
| **Priority** | High |

| **ID**: HI-7 | **Type**: Non-Functional |
| -------------------- | ---------------------------------------- |
| **Related PUC**: N/A | **Originator**: [Yunfei](@yangy113) |
| **Description** | Computers running these games should have enough storage. |
| **Rationale** | In order to make the games run better, the storage of computers should not be too bad. |
| **Fit Criterion** | The storage of computers running these games should have at least 50 GB of free disk space. |
| **Priority** | High |

| **ID**: HI-8 | **Type**: Non-Functional |
| -------------------- | ---------------------------------------- |
| **Related PUC**: N/A | **Originator**: [Meijing](@lim147) |
| **Description** | Computer running these games should have a speaker which is in good condition. |
| **Rationale** | The mini game **Musician* requires a player to listen to a note and duplicate it. A speaker in good condition will be used to play the sound of the node.|
| **Fit Criterion** | Computer running these games should have a speaker that plays clear and fluent audio. |
| **Priority** | High |

#### 3.1.3 Software interfaces

| **ID**: SI-1 | **Type**: Non-Functional |
| -------------------- | ---------------------------------------- |
| **Related PUC**: N/A | **Originator**: [Yunfei](@yangy113) |
| **Description** | Game functionality will be limited to what is supported by the Unity platform. |
| **Rationale** | According to the needs of this project, all games should be run on the Unity platform. |
| **Fit Criterion** | Unity must be used to create mini games. No other game engine or library will be used. |
| **Priority** | Very High |

### 3.2 Functional
#### General functional requirements

| **ID**: FG-1 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [1](#puc-1) | **Originator**: [Alice](@ipa1) |
| **Description** | The player must have the ability to choose the game they play.|
| **Rationale** | The player may have some preference on which game they want to play . |
| **Fit Criterion** | The player can scroll through the games in the collection, and can press a button when the game they want to play is selected. |
| **Priority** | High |

| **ID**: FG-2 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [3](#puc-3) | **Originator**: [Alice](@ipa1) |
| **Description** | The player must be able to pause the game.|
| **Rationale** | The player may want to take a break, or change game settings, or exit the current mini game. |
| **Fit Criterion** | The player can press the pause button to pause the game. |
| **Priority** | High |

| **ID**: FG-3 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [5](#puc-5) | **Originator**: [Alice](@ipa1) |
| **Description** | The player must have the ability to exit the current mini game.|
| **Rationale** | The player may wish to stop playing the mini game.|
| **Fit Criterion** | The player can choose to exit the mini game from the pause menu. |
| **Priority** | High |

| **ID**: FG-4 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [14](#puc-14) | **Originator**: [Alice](@ipa1) |
| **Description** | After the instructions for the game are given, the game must start when the player is ready to play the game.|
| **Rationale** | The player may need some time to read and understand the instructions |
| **Fit Criterion** | There is a button on the instructions screen that the player can press when they are ready to play the game |
| **Priority** | High |

| **ID:** FG-5 | Type: Functional |
|-----------------------|--------------------|
| **PUC**: [7](#puc-7) | Originator: [Meijing](@lim147) |
| **Description** | At the end of games, the player is able to get a testing report of all abilities.|
| **Rationale** | The player may be curious about the testing result of testing results of motor and cognitive abilities. |
| **Fit Criterion** | A participant ability profile will be generated to show the level of competency the player has in the tested abilities. |
| **Priority** | High |

| **ID**: FG-6 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [6](#puc-6) | **Originator**: [Alice](@ipa1) |
| **Description** | The player must be able to see their score for the current game|
| **Rationale** | The player may wish to see how well they are doing in the games |
| **Fit Criterion** | The score of the player is stored after each round of a game instance, and is displayed at the end of the round. |
| **Priority** | High |

| **ID**: FG-7 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [13](#puc-13) | **Originator**: [Alice](@ipa1) |
| **Description** | The player must know how to play the game.|
| **Rationale** | The player needs to know how to play the game so that data can be collected. |
| **Fit Criterion** | The instructions for the game will appear after selecting the game from the game selection menu. |
| **Priority** | High |

| **ID**: FG-8 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [32](#puc-32) | **Originator**: [Alice](@ipa1) |
| **Description** | There must be a function to allow for randomness in the mini-games. |
| **Rationale** | Many mini-games have game aspects that should be randomized. The player should not be able to memorize the answer for each cognitive ability test, and should be utilizing the target and related cognitive abilities to complete the task. |
| **Fit Criterion** | A random number function is created, that sufficiently outputs numbers that are distributed, when run 1000 times.|
| **Priority** | High |

| **ID**: FG-9 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [24](#puc-24), [25](#puc-25) | **Originator**: [Alice](@ipa1) |
| **Description** | Have a functional timer that can keep track of the start and end time in relation to some task in a cognitive ability test. |
| **Rationale** | Many mini-games have time sensitive aspects, or requires measurement of the time that was taken to complete a task, in order to provide data related to a particular cognitive ability |
| **Fit Criterion** | A timer function exists that can accurately save the start and end times of a task, and calculate the time elapsed, to a margin of error of 100 milliseconds. |
| **Priority** | High |

| **ID**: FG-10 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [27](#puc-27), [28](#puc-28) | **Originator**: [Alice](@ipa1) |
| **Description** | Have a functional counter that can keep track of the number of some occurrence in a mini-game. |
| **Rationale** | Some mini-games are associated with cognitive abilities where the number of times an event occurs in the mini-game is indicative of a player's cognitive ability level. |
| **Fit Criterion** | A counter function exists that can be initialized to 0 and increment by 1 when necessary. |
| **Priority** | High |

| **ID**: FG-11 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [29](#puc-29) | **Originator**: [Jack](@bucklj4) |
| **Description** | There must be a tool to calculate the distance between two 3-D coordinates. |
| **Rationale** | In some games, distance value is used to identify the player's level of abilities.|
| **Fit Criterion** | Calculate the Euclidean distance from a point $`p = (p1, p2, p3)`$ to a point $`q = (q1, q2, q3)`$ using the formula $`\sqrt{(q1 - p1)^2 + (q2 - p2)^2 + (q3 - p3)^2}`$ |
| **Priority** | High |

| **ID**: FG-11 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [26](#puc-26) | **Originator**: [Alice](@ipa1) |
| **Description** | Have a function to get key input from the user. |
| **Rationale** | All our mini-games and require input from the user to get measurements for the cognitive abilities, and to interact and navigate through the web application. |
| **Fit Criterion** | All explicitly stated key inputs that the game introduces to the player must provide the functions that are stated, within 1 second. |
| **Priority** | High |

#### Functional requirements for specific games driven from selected abilities

##### Game: Cup Swap (Measuring Selective Visual Perception)

| **ID**: FCS-1 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: N/A | **Originator**: [Alice](@ipa1) |
| **Description** | The Cup Swap game must show the object, the cups, and the swapping of positions in a graphical quality such that the cup with the object can be tracked.|
| **Rationale** | The player needs to see the objects and cups to decide which cup has the object. It must be feasible to track the object to test the selective visual ability. |
| **Fit Criterion** | The object and cups will be displayed and animated on the screen using graphical assets, with graphical animations at a minimum of 30 frames per second. |
| **Priority** | High |

| **ID**: FCS-2 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: 32 | **Originator**: [Alice](@ipa1) |
| **Description** | The Cup Swap game must randomize the swapping of the cups.|
| **Rationale** | The cognitive ability being tested requires keeping track of the object, and the correct answer should not be memorizable. |
| **Fit Criterion** | The random number generator used follows a standardized random number algorithm to randomize the swapping. |
| **Priority** | High |

| **ID**: FCS-3 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [11](#puc-11) | **Originator**: [Alice](@ipa1) |
| **Description** | The Player should be able to choose the cup that has the object.|
| **Rationale** | The player must provide input for the game to progress and for to get a player score, as well as get data on the player's incorrect or correct answer on which cup has the target object. This in turn can be used in the measurement of the selective visual ability.|
| **Fit Criterion** | The player has the option to press a button to indicate their guess |
| **Priority** | High |

| **ID**: FCS-4 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [24](#puc-25)[25](#puc-25) | **Originator**: [Alice](@ipa1) |
| **Description** | The amount of time it takes for the player to guess the position of the cup is recorded.|
| **Rationale** | The player's confidence in their guess will be reflected in the amount of time it takes for them to give their answer. |
| **Fit Criterion** | The start and end time of the phase in the game when the player is allowed to give an answer is recorded using a timer. |
| **Priority** | High |

##### Game: Musician (Measuring Audial Perception)

| **ID**: FM-1 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [30](#puc-30) | **Originator**: [Shuo](@hes11) |
| **Description** | The **Musician** game must play a note clearly, and let the player know when to respond. |
| **Rationale** | The player needs to listen to a musical note first before duplicating it. |
| **Fit Criterion** | The sound of the musical note will be played from a speaker using auditory assets. |
| **Priority** | High |

| **ID**: FM-2 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [34](#puc-34) | **Originator**: [Shuo](@hes11) |
| **Description** | The player must be able to enter different musical notes from the keyboard using different keys. |
| **Rationale** | Player needs to recognize different keys corresponding to different musical notes to play back the the music notes. |
| **Fit Criterion** | Each musical note is linked to a certain key on the keyboard. |
| **Priority** | High |

| **ID**: FM-3 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [10](#puc-10) | **Originator**: [Shuo](@hes11) |
| **Description** | There must be different volume options that players are able to choose. |
| **Rationale** | To measure the ability to analyze the intensity, players should be able to change the volume for the note that they play back. |
| **Fit Criterion** | The option of different volume values is available for the player to change the volume. |
| **Priority** | High |

| **ID**: FM-4 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [30](#puc-30) | **Originator**: [Shuo](@hes11) |
| **Description** | Each round of the game must consist of different musical notes that differ in pitch. |
| **Rationale** | To measure the ability to analyze the tone, players should be able to play the game with different notes that differ in pitch. |
| **Fit Criterion** | A random musical note generator will be used to randomize the musical notes. |
| **Priority** | High |

| **ID**: FM-5 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [33](#puc-33), [24](#puc-24), [25](#puc-25) | **Originator**: [Shuo](@hes11) |
| **Description** | The amount of time that the player holds a key must be recorded.|
| **Rationale** | To measure the ability to analyze the duration, the time that the player holds a key should be recorded. |
| **Fit Criterion** | A timer will be used to record the time of the pressed key. |
| **Priority** | High |

| **ID**: FM-6 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [29](#puc-29) | **Originator**: [Shuo](@hes11) |
| **Description** | The distance between the correct key and wrong key must be calculated. |
| **Rationale** | To measure the ability to distinguish the tone, the distance between the player's input key for a certain musical note and the key of the correct musical note should be calculated. |
| **Fit Criterion** | A distance calculator will be used to calculate how much the difference is. |
| **Priority** | High |

| **ID**: FM-7 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [10](#puc-10) | **Originator**: [Shuo](@hes11) |
| **Description** | The musical notes must be played in different timbre. |
| **Rationale** | To measure the ability to analyze the timbre, the musical notes that played should be used in different instruments. |
| **Fit Criterion** | Two different audio generators, piano and violin, will be used to generate the musical notes with different timbre. |
| **Priority** | High |

| **ID**: FM-8 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [10](#puc-10) | **Originator**: [Shuo](@hes11) |
| **Description** | The game must allow the players to play back a note in different instruments. |
| **Rationale** | To measure the ability to analyze the timbre, the players should be able to select the instruments that the musical notes comes from and play it back. |
| **Fit Criterion** | There will be an option that players can chose the instruments to play. |
| **Priority** | High |

| **ID**: FM-9 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [27](#puc-27), [28](#puc-28) | **Originator**: [Shuo](@hes11) |
| **Description** | The number of players played a correct key and a wrong key must be recorded |
| **Rationale** | To measure the ability of audial perception, the final score of the player will calculated by the correct rate . |
| **Fit Criterion** | There will be a counter to counter the number of correct keys and wrong keys |
| **Priority** | High |

##### Game: Ball! (Measuring Time to Contact)

| **ID**: FB-1 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [12](#puc-12) | **Originator**: [Yunfei](@yangy113) |
| **Description** | The ball should only travel in the *y* dimension. |
| **Rationale** | We want to leverage the research that says time to contact can be determined for spherically symmetric objects by size and speed change alone. To only consider these properties, the ball should change in only the *y* dimension, so the ball's size only changes in one dimension also, meaning the player can use the notion of Tau. |
| **Fit Criterion** | The baseball only moves in the *y* dimension when it is shot at the player in the game. |
| **Priority** | High |

| **ID**: FB-2 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: N/A | **Originator**: [Yunfei](@yangy113) |
| **Description** | The speed and initial distance between the ball and player should vary between rounds. |
| **Rationale** | We want to test how the player performs at different speeds and distances to see how these affect the player's performance. |
| **Fit Criterion** | In a test of 50 iterations of the game, the shooter should appear at a different distance from the player and shoot the ball at a different speed. |
| **Priority** | High |

| **ID**: FB-3 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: N/A | **Originator**: [Yunfei](@yangy113) |
| **Description** | The size of the ball should change to mimic how an approaching ball increases in size in the real world. |
| **Rationale** | In order to test Tau, we need to test how the increase of size in the object affect's the player's aptitude. Additionally, this is needed to make this game appear 3-D on a 2-D screen. |
| **Fit Criterion** | Use Unity's 3-D engine to make the size change in the baseball appear realistic by moving the ball towards the player at a constant speed. |
| **Priority** | High |

##### Game: Holy Sinkholes! (Measuring Heading)

| **ID**: FHS-1 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [8](#puc-8) | **Originator**: [Jack](@bucklj4) |
| **Description** | Players must be able to move in the left, right, up, and down directions using four distinct keys on the keyboard for the game **Holy Sinkholes!**. In this game, the gameboard must be a grid of cells where the player can only move atomically from one cell to another using these four movements. |
| **Rationale** | We want to test heading, so we need the player to travel from one point to another. To make things non-trivial, they cannot simply travel in a straight line, meaning we need to model the game in at least two dimensions. We chose to use a Cartesian plane for this reason. The player can only move between atomic cells on this plane because we want to limit continuous movement such that we focus on the heading ability over steering in this game.
| **Fit Criterion** | The gameboard is a Cartesian plane where the user's character can only move atomically between cells on this plane by moving left, right, up, and down. When the player is located in *d*-most cell, they will no longer be allowed to move in the *d* direction where *d* is up, down, left, or right. |
| **Priority** | High |

| **ID**: FHS-2 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [32](#puc-32) | **Originator**: [Jack](@bucklj4) |
| **Description** | The sinkholes must appear in random locations of the screen at the beginning of a round in the game **Holy Sinkholes!**.
| **Rationale** | The location of all these elements affects the path and heading that the player must traverse to reach the gold coin in the shortest distance. If we do not randomize these locations, then the player can simply memorize which direction (heading) they should move towards during gameplay, defeating altogether the purpose of our measurements. |
| **Fit Criterion** | The player's character must appear in a random location of the screen at the beginning of a round. The gold coin must appear in a random location of the screen at the beginning of this round. The initial random location of the player's character cannot be the same as the random location of any sinkhole. The initial random location of the player's character cannot be the same as the random location of the gold coin. |
| **Priority** | High |

| **ID**: FHS-3 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [8](#puc-8) | **Originator**: [Jack](@bucklj4) |
| **Description** | There must always exist a path for the player to traverse such that they will avoid the sinkholes and make it from their initial position to the gold coin. |
| **Rationale** | We want to determine how well the user can determine heading when faced with obstacles. If there comes a point where there is no such possible way for the user to avoid the obstacles, then we cannot objectively determine how well the user performed since any move they would have made would have resulted in the game ending. |
| **Fit Criterion** | There must always be a path for the user to move from their initial position to the gold coin while avoiding sinkholes in the game **Holy Sinkholes!**. |
| **Priority** | High |

| **ID**: FHS-4 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [27](#puc-27), [28](#puc-28) | **Originator**: [Jack](@bucklj4) |
| **Description** | The number of movements the player makes must be recorded in **Holy Sinkholes!**. |
| **Rationale** | To determine the player's heading aptitude, we need to compare the distance they traversed compared to the shortest path. Since the player can only move atomically in a Cartesian plane, the distance traversed is the number of movements the player made. |
| **Fit Criterion** | In **Holy Sinkholes!**, using the atomic counter measurement tool, record how many movements the player made from their initial position until they reach the gold coin target or the round ends. |
| **Priority** | High |

| **ID**: FHS-5 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [31](#puc-31) | **Originator**: [Jack](@bucklj4) |
| **Description** | The distance of a shortest path between the player's initial position and the gold coin such that this path does go through any sinkholes must be calculable. |
| **Rationale** | To determine the player's heading aptitude, we need to compare the distance they traversed compared to the shortest path. |
| **Fit Criterion** | In **Holy Sinkholes!**, using a shortest path algorithm, calculate the length of the shortest path between the player's initial position and the gold coin such that the path only moves atomically on the Cartesian plane and does not go through any sinkholes. The returned length is thus a measure of atomic movements in the Cartesian plane. |
| **Priority** | High |

| **ID**: FHS-6 | **Type**: Functional |
|-----------------------|--------------------|
| **Related PUC**: [31](#puc-31) | **Originator**: [Jack](@bucklj4) |
| **Description** | The number of direction changes in a shortest path from the player's initial position to the gold coin without going through any sinkholes must be calculable. |
| **Rationale** | One of the things we are interested in is how the complexity of the path impairs the user's heading judgement.|
|**Fit Criterion** | In **Holy Sinkholes!**, using a shortest path algorithm, find all shortest paths between the player's initial position and the gold coin such that each path only moves atomically on the Cartesian plane and does not go through any sinkholes. For each path, calculate the number of direction changes *n* in this path. Return the smallest such *n*. |
| **Priority** | High |

##### Game: Flip-Flop Clear (Measuring Object Recognition)

| ID: FFC-1 | Type: Functional |
|-----------|--------------------|
| PUC: N/A | Originator: [Meijing](@lim147) |
| Description | When choosing images of an object from different viewpoints, the viewpoint should be in a angle that makes the object identifiable by the player. |
| Rationale | An object may appear distorted if it is in a uncommon angle. For example, If you are looking at a pen lib, where the pen is perpendicular from the person, you may only see a dot (pen lib) in the middle of a circle (the body of the pen). Such an angle would make it difficult for a player to recognize the object. |
| Fit Criterion | The object in the image is from an angle such that more than 85% of neurotypical able-bodied persons can recognize the object as indicated by a survey. |
| Priority | High |

| ID: FFC-2 | Type: Functional |
|-----------|--------------------|
| PUC: N/A | Originator: [Meijing](@lim147) |
| Description | When choosing images showing only components of an object, the image should display enough of the object's surface area. |
| Rationale | If the images lack critical object information, it may be too difficult for the players to recognize the object. |
| Fit Criterion | The images should display no less than 30% of the surface area of the object. |
| Priority | High |

| ID: FFC-3 | Type: Functional |
|-----------|---------