F. Discussion

In this section we want to discuss our experience coding these games, what worked for us and what did not, and what we would do differently to improve these games.

Hangman:

We programmed the main game logic, that is program hangman as if both players played with no errors or mistypes, and then programmed logic checks from there. We found we needed to provide checks for many parameters of both inputs including: length of the word, whether the word contained valid characters and that player two inputs only one letter. During testing we found specific circumstances where our checks did not always work and had to be revised accordingly. Our code started by displaying the word into an array in the command window, after refining our code and implementing all of our checks, graphics were programmed to display the hangman visuals. One of the obstacles we faced was figuring out the number of checks we needed. Some of the logic that we needed to program for is very intuitive  when playing hangman on paper, but needs to be thought out and programmed so that the game can function realistically.  For example, normally a player would not use a guess on a non-letter like an “exclamation point” but for needed to be checked for consistent logic. To resolve this, we continued testing and each piece of code was added to ensure that our solutions were correct and did not affect our existing parameters. Another obstacle was figuring out the position of the correct guesses into the word array.  After figuring out how to assign the first guess to the correct position, we also had to figure out how to assign the guess to each instance of the letter in the word, not just the first one (for instance, a “p” for apple). To fix this issue specifically we created a for-loop to replace the existing while-loop so that the guess would be applied to every component of the word.

In the end programming the main game logic first seemed to work the best because we always had that foundation of code that we could fall back on with every subsequent check. While this worked very well, we had the most trouble with programming the checks following the main code because we did not necessarily know what checks to program or where they should be placed. Going back we should have planned out what parameters we needed before testing because then we would have had a better idea of what code still needed to be added.

Over/Under Seven:

During the testing of this game, we encountered some obstacles that needed to be addressed. One of the major problems had to do with character length. When the program checked to see if the user’s guess matched the dice condition, it would crash because the length of the character arrays were not always identical. This issue was resolved by treating the values as strings instead of character arrays. The other issue involved the game’s graphics. When drawing the dice roll animation, the program would only draw one frame and then freeze until the while loop ended. This issue was resolved by using the pause() function in favor of tic and toc. We started development of this game by programing the basic logic. From there, we started implementing fail-safes to make sure the game didn’t break in specific circumstances. We finished development of this game by implementing the visuals.