https://backend.turing.edu/module1/projects/battleship/
Battleship is a classic board game where players place one or more ships on a grid board, and then take turns trying to “sink” the other player’s ships by guessing their coordinates. The game ends when one player’s ships are all hit and “sunk”. For more information, see the Wikipedia page.
Utilize Test-Driven Development (TDD) Practice algorithmic thinking Create an Object-Oriented solution to a problem without being given full specifications Work in a pair, using Pull Requests to collaborate
In this project you’ll use Ruby to build a command line implementation of the classic game Battleship.
Battleship Evaluation For the project eval, you should prepare to speak to the presentation points listed below. You are also required to provide some written reflections as well. There is some overlap between the written reflection and oral presentation. This is intentional. If you have questions about the presentation or written reflection, please let an instructor know before the time it’s due.
Written reflection: In your README reflect on the following:
Iteration 3 did not provide an interaction pattern. How did you approach designing this iteration? ** We approached Iteration 3 similar to an Interaction Pattern. We actually ended up breaking down the paragraphs into their own patterns. For instance when we needed to create the main menu method we knew we could create a test to show the String of Welcome to Battleship and then the next interaction pattern we could look at was the setup method. We followed the paragraphs closely and let them guide us into computer placement and then our placement all while creating tests and code. **
If you did not get to Iteration 3, reflect on how you think you would’ve approached the design and problem solving process. ** NA **
If you had one more day to work on this project, what would you work on? ** If we had one more day to work on the project we would have really liked to try creating the custom ship methods or maybe even a custom board. After trying either of those 2 method creations we definitely would like to clean up some of the code and try refactoring anything possible.**
Describe the pairing techniques you used while working on this project. ** We always worked together through zoom sessions. We would go back and forth to walk each other through what was going on. We felt the driving and navigating techniques really helped us grow as developers. **
Describe how feedback was shared over the course of this project.
** We would text each other or call one another after sessions to go over what we did well or what we could’ve saved time on. We also would talk about a small overview on what needed to be done the next day to stay on track with the due date.**
Presentation points: [ ] Demonstration of functional completeness
Run your runner file, and demonstrate how the game is played in the terminal. If you’ve considered edge cases, make sure you demonstrate that functionality in your demo. [ ] Technical quality and organization of the code
At a high level (not line by line), describe how you broke out this game. What classes did you create? What is the responsibility of each class? Why did you choose to design your code in this way? Is there a design decision that you made that you’re particularly proud of? [ ] Identifying code that should be refactored and how it would be refactored
Identify a piece of code that you’d like to refactor. How would you update that code? Are there any parts of your code that you’re unsure/hesitant about? Why? [ ] Discussion of test coverage
Show examples of a unit and an integration test that you wrote. Run your test suite and open coverage report (if you were able to implement simplecov) [ ] Discussion of Pairing/version control
How did you all work together? Did you use a particular pairing technique? Walk us through your GitHub insights. How many pull requests did you make? How many commits did you make? Can you identify a PR that was made that demonstrates good commenting/partner review workflow?