OVERALL PROJECT REQUIREMENTS

[jaxonavena]

Just putting this here so we can check the boxes as we go.

Requirements

1. Game Setup

   a. Board size

   • [x] i. 10x10
   • [x] ii. The columns are denoted by letters (A-J)
   • [x] iii. The rows are denoted by number (1-10)

b. Number of ships (per player)

• [x] i. Given by user
• [x] ii. Minimum of 1 and a maximum of 5

c. Types of ships

• [x] ii. If a total of 1 ship is chosen, then each player gets a single 1x1 ship
• [x] iii. If a total of 2 ships is chosen, then each player gets a 1x1 and a 1x2 ship
• [x] iv. This continues up to 5, where each player will a 1x1, 1x2, 1x3, 1x4, and a 1x5 ship

d. Ship placement - Jaxon

• [x] i. After the number of ships is chosen, players need to be able to secretly orient and place the ships on their board.
• [x] Place the ships (can currently pick one spot per ship, needs #2 to be resolved)
• [x] #5 (Need to be able to lay out the rest of the length)
• [x] Refactored and fixed and validated coordinates for ship placement (see #9)

2. Playing the Game - Ach

   • [x] a. Taking turns, the users pick a space on the opponent's board to "fire" at. - Game already calls Ship.attack_ship() in the flow, but it doesn't do anything. I think that's where it would be though. Might be wrong.
   • [x] b. They must then be informed if the shot was a "hit" or a "miss".
   • [x] c. The player's view should be updated to reflect this (see Player's view below).
   • [x] d. After each shot, it is the other players turn. - Turn handling should be handled by Game

3. Destroying a ship - Timi

   • [x] a. Once a ship has been hit in every space it occupies, it is sunk. - Ship class has self.hp and self.sunk attributes that do nothing right now
   • [x] b. For example, if the 1x3 ship occupies spaces B3, B4, and B5.
   • [x] c. Once the opponent has shot those three spaces, that ship is sunk.

4. Player's view - Pete

   • [x] a. A player should have full view of their board and where their ships are placed.
   • [x] b. Show how many times each ship has been hit
   • [x] c. A player should have a board to track all shots they've fired and whether they were misses or hits. - Player.opps

5. Game End - Peter

   • [x] a. Once a player has sunk all the opponent's ships, they immediately win.
   • [ ] UI?
   • [x] Debug random issues
   • [x] Look nice.
   • [ ] Unit tests?

Misc.

• [ ] Stability - GTA will stress test your application; crashes, memory leaks, or other things that you also hate in bad software will be met with a penalty
• [ ] User interface - your product should be intuitive to use; good rule to stick by: If I need a manual to use your interface, you have a bad interface.
• [ ] Modularity - your code should be easily extensible and divided into logical components (i.e. not one class that does everything)

System Documentation

• [x] On your GitHub repository, have a folder called "documentation" that contains all the system documentation described below.
• [x] Estimate of person-hours for completing the project (this should be done as soon as possible – 10 points)
  • [x] Provide the details of how you arrived at the estimate
• [ ] Actual accounting of the person-hours required to complete the project (10 points)
  • [ ] This needs to be a day-by-day accounting from each team member on how many hours they spent on the project, including team and GTA meetings, coding, testing, documenting, etc. Do not include time attending 581 lectures, working on in-class problems.

Documentation of your code

• [ ] Write it like you would like to receive it from the team whose code you get for Project 2.

Comments

• [x] The software must be adequately commented with:
  • [ ] prologue comments
    • [ ] Name of program contained in the file
    • [ ] Brief description of the program
    • [ ] Inputs
    • [ ] Output
    • [ ] Other sources for the code ChatGPT, stackOverflow, etc.
    • [ ] Author’s full name
    • [ ] Creation date: The date you first create the file, i.e., the date you write this
  • [x] comments summarizing major blocks of code
  • [x] comments on every line.
    • [x] You may comment each line of code and/or provide a multi-line comment that explains what a group of lines does.
  • [x] Each block of code must indicate whether you authored the code or you obtained it from one of the sources listed in the prologue, or if it was a combination of both.