A mobile memory game created as a final class project with my group partner, Jennifer Newton. This memory game helps players to improve their memory capability, specifically focusing on enhancing their short-term memory. 

Requirements:

The functional requirements of this application are the rules to how the game will be governed. Each player will have his or her player name in the game. In this memory game, there will be multiple levels that vary in difficulty. The score calculation is determined by the difficulty of the level being played. There will be three levels of difficulty: easy, medium, and hard. The difficulty of a level is determined by the speed between consecutive flashes, this allows the game to be versatile and has an infinite level of difficulty. Points are only award at the completion of a level if the flashing sequence has been guessed correctly. The points awarded are determined by how many flashes were in the sequence multiplied by a difficulty ratio. The difficulty ratios are as follows: 100, 200, 300, for easy, medium, and hard levels respectively. The easy levels run at the slowest speed with 1s between flashes. The medium levels run at medium speed with 0.5s between flashes. The hard levels run at the fastest speed with 0.25s between flashes. Three errors are allowed before the game ends, these are deemed mistakes and are displayed to the player in the UI. The application will contain a system to track scores for the duration of the game, the top score will be displayed to all the users playing the game. When the game ends, the player will have the choice to start a new game. The player will be able to switch difficulties during the duration of their game; as they switch difficulties their score will continue to accumulate and will be determined by the sequence played at that particular level. For example, if the player had played four sequence at the hard difficulty, and then switch and play a sequence at the easy difficulty, the points would be calculated by multiplying the easy sequence by the easy coefficient of 100 and adding it to the existing score. The player would not continue to gain hard difficulty points for playing at an easy level. The player will also have the ability to quit the game anytime. 

The quality requirements for this application include having the potential to make changes for future releases. One of the changes that may be implemented is to add more lights and increase the speed. These changes would create more levels and difficulty to the game. The ability to create these changes in future releases allows this application to be reusable. 
 
The platform requirements required for our application include running the Android 2.2 Froyo operating system or a later version, as well as, Java. Our application GUI is designed to run on the android platform; however, due to the nature of the design, the android environment was not able to execute it. This was a change we had to make in our execution of the project. In our game, there are many delays that are necessary to perform functionality and keep the game secure from most forms of cheating; however, when translating this design over to android, we discovered that android needed a continuous pulse for the server client connection but was not receiving one because of our game’s delays. Overall, we were able to construct an Android GUI for the Nexus 7, and were able to establish a server client connection as well as being able to pass information back and forth. 


Architecture:

Client role:

The client renders the user interface for the game. The user inputs their name and the chosen level of difficulty when starting the game. There are coloured buttons, which flash a sequence for the current level (these buttons are pale when inactive and flash brightly to display the sequence). The user must then recreate the sequence by clicking on the buttons in the same order on the client UI. The speed with which they flash is determined by the chosen difficulty, and sent to the client by the server. While playing the game, the client UI also provides top scores, number of current mistakes, and their current score, which are sent from the server. The client side of the application also interrupts the message received from the server. 

Server Role:

The server receives messages from the client to determine the specific constraints for the game, such as the current level, determines the speed. The server determines the sequence for the flashes and sends them to the client one at a time. The sequence is sent in individual characters to prevent cheating that could occur if the client was to receive the sequence in full. As the sequence is played, the next level is the same sequence with an added addition. This allows the user to improve their ability because at first the game adds to the sequence in slow increments and then the increments get longer and longer. The sequence always stays the same for each level and just has an added portion to it for that level; in the next level this sequence remains and another portion is added to it. This functionality is performed recursively in the program. The server also interrupts message received from the client. As levels are completed on the client, the score is calculated and stored on the server; the server keeps an updated player score and knows the top score for the game. Throughout the execution of the game, top scores are saved and can be seen by the client on the screen. When the server starts, it reads the current top scores from a server-side text file. These are updated each time a new top score is recorded, as well as when the server shuts down. The server also handles starting the game, resetting all the values and sequence for a new game play seamlessly. The server also interprets commands from the server console, Valid commands include: #quit, #stop, #close, #setport <port>, #start, #getport.