Description

Battleship is a CLI game where players can play the classic board game against a computer player (which uses random moves).

Iteration 3

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.

Iteration 3 indeed proved to be the most challenging for us. We approached designing this iteration in a couple of ways:

• The first was to draw from the work we had already completed in war and peace and to try to look at those interaction patterns and the way that game functioned to get a better idea for how a Game, a Turn, and a Player and Computer would all work together. That being said, one of the things that we quickly noticed was that the turn types in battleship seemed to be much more simple than in War.

• After having reviewed the work we did on War, we began jamboarding to get a better idea for how our classes might interact with one another and what functionality was going to be required of each of our classes.

  

• We ultimately settled on creating four additional different classes:

  1. Turn
  2. Computer
  3. Player
  4. Game

• After deciding on those classes, we started with the things we knew that we needed, which were the player and the computer, as we were still a little unsure exactly what belonged in the Turn versus what belonged in the Game. Getting some encouragement from Erin that we were on the right path helped nudge us along and continue making progress.

• Additionally, we reached out to our support network for help: rocks, mentors, #code-help, google - we tried many numerous different ways of problem solving, even though at times some of the questions we posed seemed to be too complicated (eg, asking a rock for help but him not quite knowing how to sift through what we had created with different classes versus the way he had designed iteration 3).

More time

If you had one more day to work on this project, what would you work on?

Given one more, there are a few things that we'd go back to:

gets and puts Tests

• gets proved to be quite challenging when it came to using rspec, especially as we were beginning to puts things to the terminal. With puts giving out a nil value and gets requiring inputs, we felt as though some of our test in our game_spec especially failed short of really proving that we had tested through things, though we had - just that we had done so in the only we we really understood how - to run the runner each time and see how the game was working.
• This method of testing proved to be time consuming and tedious, and if we had more time we would like to continue researching how to tests when requiring user input and make our tests for the Turn and Game more in line with TDD about what we were seeing when using puts

Flakey Test

• We noticed a small error that pops up about once every 30 or so times. We can run our rspec and pass all tests nearly every time, but every once in a while the methods that go into random placement of a computer submarine fails (overlapping a previous placement). Further reading and drilling down into the methods and how they're working allowed us to solve this bug with a small addition to a method.

Teamwork

Describe the pairing techniques you used while working on this project.

The pairing techniques we used the most were driver/navigator. We made time for one another to accomplish everything we needed by working simultaneously together on the project. At times, we made minor adjustments to the codebase asynchronously, but by and large everything was done together, which proved to be incredibly helpful for working through the complexities of how to organize iteration 3 especially.

Feedback

Describe how feedback was shared over the course of this project.

Feedback was something that we shared nearly everyday with one another. We celebrated each others successes at the end of each coding sessions and did a great job helping each other to work through frustration. As we got more comfortable with the way one another worked, it was easy to give feedback in the moment (eg, telling the driver to delete a line of code, going to the whiteboard to discuss, critiquing whether a certain though process would work for how our classes would interact, etc.).

Daily Standups

In addition to in the moment feedback, we also made it a point to do daily (or nearly every day) standups to check in with one another about how we were feeling, what we were going to try ot work on that day and also carved out some time at the beginning of each to try to get to know one another.