Soren Sabet Sarvestany

 

         The first thing I did was read through the assignment very carefully, to get a clear idea of what I was being asked. I broke down the problem into requirement, so that I could get a general idea of how I would approach a solution. Then, I proceeded to rewrite the requirements with more detail, essentially rewriting the assignment, so that I would not miss anything. This can be seen in pages 1 through 3. 

 

          Once I understood both the overall problem and had broken that problem down into more maneagable parts, I generated a mental approach for solving each part. Sometimes I recorded these approaches (as can be seen above), but at other times I began coding right away. At certain points (e.g. in the check_move function), I would realize that parts of my code weren't working the way I had intended, and I had to step back, diverge, re-examine the requirements and what I had written, and try to generate new solutions. 

 

         For example, when I was first writing my check_win function, I planned to create a copy of the game matrix, enter every single value into every single square, count the number of moves that were accepted and moves that were rejected, and proceed accordingly. However, at some point during the writing of this code, I realized that I did not need to create a copy of the game_matrix, I could simply use an if statement and a counter, which made my code far more efficient than I had initially planned. 

 

           When I was stuck, I drew grids to serve as low-fidelity prototypes to better understand how the computer would be executing the code (Page 9).  By doing so, I was able to generate approaches for solving problematic parts. In the check_move function, I had to find an efficient way of checking each cluster for an existing move, but I didn't want to take the brute force approach and write out if statements for every possible cluster. I spent a few hours thinking about it, and eventually I realized that I could use multiples of the square root of the grid size and compare it to the user's input to determine which cluster to check. 

 

          This program took a relatively short time to write, much shorter than I expected it to take. After I had addressed the requirements of the program, I began adding safety features to it. I gave myself the challenge of making the program uncrashable. During the first iteration, the program took the user's input and split it into 3 variables simultaneously. I had made these variables integers, since I the check_move function could only accept 3 integers as per the requirements. Oftentimes when I was testing the code, my finger would slip, the input would be something that the computer didn't like, and the program would crash. I decided that I wanted to prevent this from happening, so in later iterations of the program, I redesigned the code so that the program would continue running no matter what the user entered (unless of course, they wanted to quit, in which case they could press 'q'). 

 

The program can be found here. ​