E. Conclusions and Recommendations

             Before beginning the coding process, we brainstormed multiple game ideas. This was a pretty successful part of the project because all of the options were promising.  However, we came to the conclusion that Flappy Brutus would be the game that would challenge us the most; we realized its difficultly through creating a general pseudocode.  Coding Flappy Brutus was a difficult task. We performed well in creating a menu screen that led to four possible outputs: Credits, Instructions, Game, and Scores. These outputs are able to successfully lead to the screens that it specifies. However, the game itself was not meeting the expectations that we had set. One aspect we struggled with was figuring out how to make the tube move across the screen. This was overcome by consulting with peers and leader who gave guidance regarding the syntax of making figures not he Proteus appear to  be moving.

Once we made the tubes, another issue we ran into was how to detect that Brutus had hit a the grey tube which would have lead to the game ending. We attempted to use the distance formula to calculate when Brutus would theoretically come into contact with the tube. However, in the end we created a logical if – statement that set a range of  “x” and “y” coordinates that would consider Brutus “hitting” the tube.

Some recommendations that we have for the future is to create a more detailed pseudocode that would allow us to realize the full scope of the game. Doing so could have eased  the process of writing the code in a timely matter. Furthermore, the game function did not get enough testing and reworking as we had hoped, and in the future we would have decided to begin here rather than the menu, instructions, credits, and score board functions. We were very pleased we were able to randomly generate the tube’s hole position for each new game, however if given more time, we would  try to code a single run of the game to randomly generate tubes with different holes as they appeared on the screen. If every other part of the required functions of the game worked, we would shift our focus to additional features. This includes not using a scarlet circle and instead have real brutus as the game icon.  More so, we would change is the way that scoring works. We would figure out a way to make scoring based on the number of tubes that you successfully travel through, rather than scoring based on the number of seconds the user lasts before losing. This is how the original Flappy Bird game did scoring and we hope to implement similar concepts.

Additional Future Adjustments:

1. Non-functioning features – basic and additional:

  • The user is only able to complete 1 tube. After the first tube the icon and tubes function properly, but the game randomly stops before the two share coordinates.
  •  In addition, the “Play Again” and “Back to Menu” buttons do not work for more when more that 4 games have been played.

2. Issues that prevented functioning features.

  • One of the main issues that we encountered was the network shutting down on Tuesday. We had the code ready without any errors, however, not being able to visually see it implemented on the Proteus inhibited us from being able to make the necessary changes. For example, the parameters that we used to create the collisions did not work as we had theoretically planned. The original plan was to test it on the Proteus Tuesday, make changes, and have the game finished for Wednesday. Being set back a day did not give us enough time to finish it completely in class on Wednesday.
  • Another issue we encountered was the lack of understanding of the Proteus Syntax. We realized later on that some of the work printed to the screen was sloppy, or not the way we imagined, due to the fact that it did not follow the Proteus syntax correctly. This also led to complications and difficulty in figuring out how to produce objects that appear to move at the same time, and have multiple random tubes entering the screen at one time.

3. If given more time on SDP…

  • We would solve the issue of the collisions by changing the if statement to have parameters that would create the correct collisions. This could have been done by drawing out the possible cases with our current if statement and see what was being left out.
  • By looking at the game function we would be able to point out why Brutus is able to pass through the first tube but not the second. This may have had to do with the while loop within a another loop, we could check to see that no lines of code are being skipped, or repeated, after one tube passes.
  • Lastly, we would focus on the Game-Over function as well as the main function, to see why tapping the screen doesn’t work after four games have been completed.