Assumptions:
The main assumptions made during software design revolve around the capabilities of the Proteus system supplied by the FEH laboratory team. We worked off the assumption that the system had a sufficient frame refresh rate to sustain a paced reaction based game. We also assumed that the touch screen was accurate and precise enough to tell the difference between inputs located within 20 pixels of each other. The final major assumption we made was that our application would be easy to code. It was not easy to code. We encountered many unexpected errors, and we were behind schedule by an entire 1.5 days.
Important variables:
The xValue, yValue, xSize, and ySize variables were all essential when creating the sprite and the falling objects, and they were used to specify the dimensions of each object. In addition, the xValue and yValue variables were used to determine the present location of an object, and was used to detect collision between objects. Furthermore, we have a counter variable named aa that records how many pixels the falling objects have travelled, and this was used to reset object to the top of the screen after they have reached the bottom. Additionally, each time the objects reach the bottom of the screen, another counter variable was incremented, and this was used to determine the score that each player has reached. Finally, various temporary dummy variables were used when creating instances of classes and calling functions.
Description of functions:
⁃ The homeScreen function was used to reset whatever the current screen was to black, and then rewrite each of the labels that belonged to the home screen to the screen.
⁃ The changeObjectValues function was used to change the location and size of objects for when we desired their value to be different than what was initially initialized.
⁃ The changexValues function was used to alter the xValues variable upon touch, to facilitate the side to side movement of the sprite
⁃ The changeyValues function was used to alter the yValues variable at a constant rate for both of the falling objects, to facilitate vertical falling movement of the objects
⁃ The sprite constructor function was used to create and initialize the sprite object
⁃ The objects constructor function was used to create and initialize each of the falling squares
Program performance and limitations:
⁃ Each falling object successfully moves at the same speed as the others. However, the more objects, the slower they all move together as a whole. This is limited by the refresh frame rate of the low processing power proteus.
⁃ The above phenomenon also applies to the movement speed of the sprite, which has its movement speed limited by the creation of more falling objects on the screen. Darn that proteus and its lack of multithreaded rendering.
These problems could be solved by increasing the number of pixels that each objects moves at a time, to revert the entire game to a more proper playing speed. We gave this a try, but unfortunately the fact that the objects jump more than one pixel at a time poses problems and inconsistencies to the collision detection between the sprite and objects. Nonetheless, we implemented this fix and the gameplay now runs smoother.
Additional comments:
⁃ We probably have the most complicated IF statement known to computer-scientist kind, with more than 4 degrees of contrivance and multiple nested logic operators.
⁃ We wish to be able to change the difficulty of the game, but alas we do not have enough time
⁃ Additional features are viable, but due to time constrain will not be included in the final product