The design process of Simon went well as both teammates dedicated time and effort to the project during and outside of class. Communication between the partners was effective as well. The guide provided and resources offered also made for a relatively smooth design process. The basic features were coded within the first two days and the visual components of the game were both enjoyable to code and make for a aesthetically appealing experience for the gamer.
The project posed several challenges, but finding their solutions was rewarding. The first obstacle faced was the creation of buttons and identification of the region they corresponded to. Although it took some trial and error, eventually the team was able to line up the buttons with the correct regions. Next, it was difficult to compare the input of the user and the randomly generated output. After consulting an experienced coder, Jennifer Scott, we were able to create variables that represented these inputs and outputs. The sequences of these variables were then entered into an array and compared to determine if the user had passed or failed each round. The last obstacle faced by the amateur coders was time. This was especially prevalent on the day prior to the project deadline as the server unexpectedly shut down. This issue was solved by working outside of the class time given so that during class, only minor alterations were left to be made.
In the future, more functions would be used in order to save time during the coding process. During the time saved, more features could have been added to the code to make for a more enjoyable gaming experience. For instance, more difficulty levels would be added and they would feature more buttons. A noise element would be added to the buttons, so that when a button was generated by the program or touched by the user, the Proteus would output a corresponding sound. Functions would also make the written code more concise. If more time was given, the coders would’ve also spent more time debugging the code as on a rare occasion the game will record a “phantom touch” at the beginning of the user input loop. These are touches that are not from the user and result in the user losing the game as they don’t typically follow the randomly generated sequence of buttons. Phantom touches occur at a speed much faster than the reaction time of the user. To solve this problem, the software designers would create a loop prior to the if statements that record the touches of the user. This loop would detect the phantom touch by only recording input that occurs at an extremely fast speed, say within the first 100 milliseconds of the user input for loop. This touch would be assigned to a dummy variable and not used in the comparison of the first randomly generated sequence and the second input sequence; therefore, the user’s game would not end prematurely.