Add M1 project files

module1/projects/battleship/evaluation.md

@@ -0,0 +1,39 @@
+---
+layout: page
+title: Battleship Evaluation
+length: 2 week
+type: project
+---
+
+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:
+
+1. 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.
+2. If you had one more day to work on this project, what would you work on?
+3. Describe the pairing techniques you used while working on this project.
+4. Describe how feedback was shared over the course of this project.
+
+## 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?
+

module1/projects/battleship/index.md

@@ -0,0 +1,27 @@
+---
+layout: page
+title: BattleShip
+---
+
+<img src="https://m.media-amazon.com/images/I/81H1SmquoXL._AC_SL1410_.jpg" alt="game cover art" width="550"/>
+
+## Background
+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](https://en.wikipedia.org/wiki/Battleship_(game)).
+
+## Learning Goals
+
+* 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
+
+## Overview
+
+In this project you'll use Ruby to build a command line implementation of the classic game Battleship. More detail can be found in the pages below:
+
+* [Setup](./setup)
+* [Requirements](./requirements)
+* [Peer Code Share](./peer_code_share)
+* [Evaluation Presentation Requirements](./evaluation)
+* [Evaluation Rubric](./rubric)

module1/projects/battleship/iteration_1.md

@@ -0,0 +1,174 @@
+---
+layout: page
+title: Iteration 1 - Ships and Cells
+---
+
+_[Back to Battleship Home](./index)_
+_[Back to Requirements](./requirements)_
+
+## Test Driven Development
+
+In this iteration, you are required to use TDD to create your classes. Use the interaction pattern to determine what a method should do and write one or more tests to verify that expected behavior. Then you can implement the method. You should always write code with the purpose of making a test pass.
+
+## Ship
+
+A Ship object will represent a single ship on the board. It will be able to keep track of how much health it has, take hits, and report if it is sunk or not. A ship should start off with health equal to it's length.
+
+The Ship class should follow this interaction pattern:
+
+```ruby
+pry(main)> require './lib/ship'
+#=> true
+
+pry(main)> cruiser = Ship.new("Cruiser", 3)
+#=> #<Ship:0x00007feb05112d10...>
+
+pry(main)> cruiser.name
+#=> "Cruiser"
+
+pry(main)> cruiser.length
+#=> 3
+
+pry(main)> cruiser.health
+#=> 3
+
+pry(main)> cruiser.sunk?
+#=> false
+
+pry(main)> cruiser.hit
+
+pry(main)> cruiser.health
+#=> 2
+
+pry(main)> cruiser.hit
+
+pry(main)> cruiser.health
+#=> 1
+
+pry(main)> cruiser.sunk?
+#=> false
+
+pry(main)> cruiser.hit
+
+pry(main)> cruiser.sunk?
+#=> true
+```
+
+## Cell
+
+A Cell object is a single cell on our board. A Cell can either contain a Ship or nothing.
+
+```ruby
+pry(main)> require './lib/ship'
+# => true
+
+pry(main)> require './lib/cell'
+# => true
+
+pry(main)> cell = Cell.new("B4")
+# => #<Cell:0x00007f84f0ad4720...>
+
+pry(main)> cell.coordinate
+# => "B4"
+
+pry(main)> cell.ship
+# => nil
+
+pry(main)> cell.empty?
+# => true
+
+pry(main)> cruiser = Ship.new("Cruiser", 3)
+# => #<Ship:0x00007f84f0891238...>
+
+pry(main)> cell.place_ship(cruiser)
+
+pry(main)> cell.ship
+# => #<Ship:0x00007f84f0891238...>
+
+pry(main)> cell.empty?
+# => false
+```
+
+Additionally, a cell knows when it has been fired upon. When it is fired upon, the cell's ship should be damaged if it has one:
+
+```ruby
+pry(main)> require './lib/ship'
+# => true
+
+pry(main)> require './lib/cell'
+# => true
+
+pry(main)> cell = Cell.new("B4")
+# => #<Cell:0x00007f84f0ad4720...>
+
+pry(main)> cruiser = Ship.new("Cruiser", 3)
+# => #<Ship:0x00007f84f0891238...>
+
+pry(main)> cell.place_ship(cruiser)
+
+pry(main)> cell.fired_upon?
+# => false
+
+pry(main)> cell.fire_upon
+
+pry(main)> cell.ship.health
+# => 2
+
+pry(main)> cell.fired_upon?
+# => true
+```
+
+Finally, a Cell will have a method called `render` which returns a String representation of the Cell for when we need to print the board. A cell can potentially be rendered as:
+
+* "." if the cell has not been fired upon.
+* "M" if the cell has been fired upon and it does not contain a ship (the shot was a miss).
+* "H" if the cell has been fired upon and it contains a ship (the shot was a hit).
+* "X" if the cell has been fired upon and its ship has been sunk.
+
+Additionally, we will include an optional boolean argument to indicate if we want to reveal a ship in the cell even if it has not been fired upon. This should render a cell that has not been fired upon and contains a ship as an "S". This will be useful for showing the user where they placed their ships and for debugging.
+
+```ruby
+pry(main)> cell_1 = Cell.new("B4")
+# => #<Cell:0x00007f84f11df920...>
+
+pry(main)> cell_1.render
+# => "."
+
+pry(main)> cell_1.fire_upon
+
+pry(main)> cell_1.render
+# => "M"
+
+pry(main)> cell_2 = Cell.new("C3")
+# => #<Cell:0x00007f84f0b29d10...>
+
+pry(main)> cruiser = Ship.new("Cruiser", 3)
+# => #<Ship:0x00007f84f0ad4fb8...>
+
+pry(main)> cell_2.place_ship(cruiser)
+
+pry(main)> cell_2.render
+# => "."
+
+# Indicate that we want to show a ship with the optional argument
+pry(main)> cell_2.render(true)
+# => "S"
+
+pry(main)> cell_2.fire_upon
+
+pry(main)> cell_2.render
+# => "H"
+
+pry(main)> cruiser.sunk?
+# => false
+
+pry(main)> cruiser.hit
+
+pry(main)> cruiser.hit
+
+pry(main)> cruiser.sunk?
+# => true
+
+pry(main)> cell_2.render
+# => "X"
+```