Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


 We wanted to make the game more challenging by having different colored blocks have different strengths, or thresholds. Blue meant it would have to be hit four times to be popped, red meant it would need to be hit three times to be popped, green meant it needed to be hit 2 times, and yellow meant it would have to be hit 1 time. Similarly like with the visible parameter, we had to add a counter parameter for each block. If we wanted the block to have a threshold of 4 (blue) , we set the counter for that specific block to 3. If we wanted it to have a threshold of 3(red), we set the counter for that specific block to 2, etc. We had a conditional statement for each block that would determine its color, or RGB values. In each conditional statement for the drawing of each block we had a statement that said, if the counter for that block is 3, set the color to blue, if the counter for that block is 2, set the color to red, if the counter for that block is 1, set it to green, and otherwise set it to yellow. Every time a collision happened (the shooter block was in the range of any of the other blocks), the counter would be decremented. Then, if the counter was 0, the visible parameter would be set to ‘1’, and the block would disappear. 


 In order to shoot, we used SW0. If the switch was flipped up, then the shooting block would move up. This is where we needed to use a state machine. We had three states, which were reset, fetch, and fire. The reset state was pretty simple, and basically just allowed for the game to restart. When the game was in the reset state, all of the blocks were set to visible, and all of the counters were reset to their original values in order to make sure that all the blocks had their original colors and strengths. The reset state was defined by KEY3, so if KEY3 was pressed down, the reset state was entered. In the fetch state, all of the colors for the different blocks were defined. The fire state was defined by SW0. If the switch wasn’t flipped up, the user could move the block from side to side. If the switch was flipped up, the fire state was entered. In the fire state was where the collisions that are described above were described. In the fire state, we had an if statement for a signal “hit”. If hit was zero, which means a collision hadn’t happened yet, then it was still possible for a collision to happen. If the shooter block went out of bounds, the game would reset, which meant the player lost. If there was a collision, which meant the counter for a specific block was zero, hit was set to 1, and the block would disappear, and a collision couldn’t happen for that block anymore until the game was reset. The fire state also kept track of all of the collisions and points for the game. When the collision occurred, the state was set to fetch again and the shooting block was placed back to the original y position. To prevent the shooting block from firing multiple times, we had the SW0 need to be flipped down and then back up again to fire once again. We also included a firing speed that was controlled by Key 2. When in the fetch state, the Key 2 button could be pressed and the speed would increase so the block moved faster. If pressed too many times the firing speed to be reset again. 


Movement of Blocks: 

In order to make the game more interesting, we decided to make the blocks move in opposite directions. By having the blocks constantly moving, the game would become more of a challenge for the player. The first step was to set each of the initial locations of the blocks. Ex. SIGNAL SQ_X2: INTEGER RANGE 0 TO 1688:= 500; SIGNAL SQ_Y2: INTEGER RANGE 0 TO 1688:=150; Unlike the shooter block, which only moved when the switch was flipped up, these blocks has to be consistently moving. Within sFetch, all of the square location X values were constantly incrementing or decrementing. For example: SQ_X1 <= SQ_X1 - 4; would make square 1 to constantly be moving left at the speed of 4. In the same way SQ_X1 <= SQ_X1 + 4; would make square 1 constantly be moving to the right at the speed of 4. The higher the number, the faster the speed. I also made the squares vary in speed and direction to make the game interesting.