Obstacles:
Beginning:
In the very beginning of the project, we all had difficulty trying to split up the sections and actually get started. We planned on only doing one game, so each of us had to take one aspect of the game to do. Jackson got the set-up of the game, Charlie got the board set-up and images, Ryan got the game play/logic, and Zach got the computer AI. Jackson and Charlie had some help in the beginning from the files on Carmen, but Zach and Ryan faced the challenge of starting code from scratch. What really helped everyone truly get started was the creation of flow charts. These charts allowed everyone to get their thoughts and ideas down concretely and then manipulate them. In this way, the logic was already complete, it just needed to be converted into MATLAB notation.
Middle:
Each part of the code had different difficulties. Jackson’s greatest difficulty came from trying to figure out how to get the user to input their ships which he fixed with a horizontal/vertical plus a coordinate approach. Charlie’s greatest difficulty came with getting the correct images in the correct places which he did by creating a matrix of parts of each ship so he knew if it was the middle or the ends or the ship. Ryan’s greatest difficulty came with figuring out if any ships were sunk which he overcame by using additional matrices to denote specific ships. Zach’s greatest difficulty came with creating a smart computer player, which he did by setting the initial hit as a reference point and then having the computer guess around that point.
End:
After spending weeks each creating our separate aspects of the game, we finally came together and put it all together. The biggest problem here was the fact that everyone wasn’t on the same page. Zach needed Ryan to have variables in his code that weren’t there, and Ryan and Charlie referenced different things with the same variable. Most of the class times were spent creating uniform variables, making sure everyone had not only the variables they needed, but also any variables any other section might need. This vetting process took a while, but the biggest help was continually running the code to see when the errors would pop up and fixing the errors. This debugging process eventually led to our completed code.
Testing:
One problem we had in testing was the fact that Charlie and Ryan thought they both had the same boards being referenced but in actuality Ryan needed and extra board that wasn’t in Charlie’s code. That was an easy fix, but then we started having problems with the AI. We kept getting an error that the array was too large whenever the computer tried to guess a position. After pouring over the code in the last class, we couldn’t find any mistakes. Ryan started trying the code on his computer and it worked perfectly without any of the errors that were appearing on the other computer. We tested on Ryan’s computer with no problem and never got the error again, so it must have been a fluke in the MATLAB program, not our actual code.
What Occurred during Testing
The testing process was overall successful, but there were a few errors that emerged. Small errors were fixed early on, like variables not matching, and errors in the AI, but there were some that are not fixed. First off, text boxes appeared after each turn was completed, and it was discovered that pressing enter in the middle of one of these timed-text boxes prompted an error and ended the game. Another error would completely show up randomly out of nowhere in the middle of the game. This would be during a computer turn, and would end the game. This only happened to about a third of our tests, the rest of the tests made it through without any problems. One more small problem noticed. When user ships are compacted tightly next to each other, and a computer guessed across multiple ships, it would get confused if it hit more spots than spots on a ship. This caused the AI to give up and guess randomly until it hit again. This was only occurring in very specific situations, and it would’ve taken a very long time to locate and fix this, so it was decided among the group to leave that alone.
Progression of Code
Game Play:
The first step of the game play section was to create loops. There had to be a loop for the user’s turn and a loop for the computer’s turn. Since the loop had to run until the game was ended, a while loop was used. Inside the while loop was the user’s turn followed by the computer’s turn. Once this while loop was set up, the user’s turn could be developed. Firstly, the user was asked for the x and y input of their guess. The guess coordinate was cross-referenced with the initialization computer board to see if there was a ship through an “if” loop. If the condition was met then it was hit, if the condition wasn’t met, then it was a miss. The computer’s turn was created next with the computer randomly guessing an x and y on the board. The same “if” loop for the user was then used to see if the guess was a hit or a miss.
In the next look through the code, the user’s turn was developed more. A matrix with all of the previous guesses was created and combined with a “while” loop nested inside an “if” loop in order to check to see if the user had already guessed that position. If that was the case, then the user was asked to input new x and y values for their new guess. As the code stood, the “while” loop would never end. To solve this issue, an “if” loop was created to see if any ships were sunk if the guess was a hit, and then an “if” loop was created to see if any ships were left. A positive result from that “if” loop would result in the termination of the “while” loop. These changes were then applied to the computer’s turn as well.
The third iteration focused on additives and cleaning up the code. After each action (guess again, hit, miss, sunk, win) for both the user and the computer, a dialog box was made to appear and tell the user what happened. Music was added for the hit, miss, sunk, and win actions to fit the recommendations from User Interview #1. The computer’s guess was also printed out to the screen so the user could see where the computer guessed.
Finally, the code was adapted to fit all other parts of the code. When combining all parts of the code, variable names were changed to fit the variables from the initialization and setup sections, while a few variables were added in order to accommodate the AI function file. Lastly, the red and white dot images were added to the “if” loops when seeing if the guess was a hit or a miss so they would appear on the board so the user can see.
Initialization:
The end goal of the initialization process was to place the user and computers boats. The matrix containing the ship information needed to be set up before plotting the ships on the board. The code starts with a for loop, 1 through 5 for each of the five ships. At first, we just had the user input their orientation, row, and column of the ship. This data was used to set up a matrix of the ship information. The code was written so that the user could not put in decimals, or values outside of 1 through 10.An obstacle was realized early on that ships could go out of bounds or overlap each other with this matrix, so much more code was added to ensure this did not occur. For example, for ship1, which is length 5, the column or row value could not exceed 6, depending on the orientation of the ship. To deal with overlap, a matrix of the plotted points of ships was created to update as soon as a ship was placed, so that if a value was placed in that spot again, it would prompt the user to re-place those values. This initial matrix was then used to place ships on a different plot, which would correspond with the gameplay board. The values on the gameplay board were assigned different images, so that the graphics also loaded correctly.