Iteration 3 did not provide an interaction pattern. How did you approach designing this iteration? If you did not get to Iteration 3, reflect on how you think you would've approached the design and problem solving process.
- We read through iteration 3 and decided upon this general layout for a Game.rb file based on the requirements. We drew a general outline for this workflow and described the helper methods needed to accomplish it. We then coded the methods needed (with nothing in them), and then slowly added the code to each method until we eventually had something that worked for part of the program, and then built on that. Here is the general workflow of the game:
- First, we start at main_menu, where the user is shown a description of the game and prompted with whether or not they want to play. If they choose to play, then setup_game is called, and when that is completed, play_game is called. Setup_game consists of two helper methods: first place_computer_ships is called, and then place_player_ships is called. Place_computer_ships creates two ships for the computer, stores them, then randomly places these ships at valid coordinates (as determined by the valid_placement? method) on the computer's board. Place_player_ships is a method that creates two ships, stores them, and then prompts the user for coordinates for where to place these ships (if valid coordinates are given, then the ships are placed on the player's board).
- The play_game method is the primary loop that the game operates through. It loops until the game_over method returns true (when either all of the player's ship or the computer's ships have been sunk) and it first calls display_boards (which shows the current status of both the player's and computer's board in the terminal), then it calls shoot_player and shoot_computer. Shoot_player allows the player to pick a coordinate on the computer's board to shoot. After shooting, results_player is called and whether that shot hit/missed/sunk a ship is reported. Shoot_computer calls .sample on an array of player_board's cells to randomly pick a place on the player's board to shoot. This process is repeated in the play_game loop until a winner is determined, and then a message is displayed on the screen with the result. Play_again? is then called and if the user wants to play again, the main_menu is called.
If you had one more day to work on this project, what would you work on?
- It would be really interesting to learn how to code a more robust shoot_computer method. Currently our method has the computer randomly select a coordinate on the players board to shoot at (the only requirement is that the coordinate hasn't previously been fired_upon?). As long as the player can select better than a completely random placement, they will likely beat the computer. It would be nice to have logic that allows the computer to select their next coordinate based on whether the previous shot was a hit/miss. This would have the effect of making the game more competitive.
- It would be nice to have a dynamic board and dynamic player options. If we had more time, we would possibly create a grid class and either add or create additional methods to the player and ship class. We would then have to update the #render and make it more dynamic based on the grid sized selected by the player as well.
Describe the pairing techniques you used while working on this project.
- We filled out the DTR and discussed our current life circumstances and when/how much time we would have to dedicate to this project. We both have families and we have a two-hour time zone difference between us, so we had to consider those things when we made a game plan.
- We used both paired programming strategies. We started off with the Driver/Navigator strategy on the first two days and switched to Ping/Pong over the weekend.
Describe how feedback was shared over the course of this project.
- We both agreed to share feedback directly and in a timely fashion, and this is what we did over the course of the project. When we weren't working together over Zoom, we would send Slack messages with what we were working on and any feedback. We also left feedback on the code submitted in pull requests.