Skip to content

Commit

Permalink
Merge pull request #54 from turingschool/15-review-m1-projects
Browse files Browse the repository at this point in the history
15 review m1 projects
  • Loading branch information
hfaerber authored May 20, 2024
2 parents 1c8fba7 + 42d5b1f commit bcc9a21
Show file tree
Hide file tree
Showing 42 changed files with 1,385 additions and 183 deletions.
Binary file added module1/projects/connect_four/c4.jpg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
39 changes: 39 additions & 0 deletions module1/projects/connect_four/evaluation.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
---
layout: page
title: Connect Four 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. This project did not provide an interaction pattern. How did you approach the design and problem solving process for this project?
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?

29 changes: 29 additions & 0 deletions module1/projects/connect_four/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
---
layout: page
title: Connect Four
---

![Connect 4](./c4.jpg)

## Background

Connect Four is a classic board game where players take turns trying to create a line of four of their own pieces without being blocked by their opponent. The game ends when one of the two players successfully lines up four of their pieces horizontally, vertically, or diagonally and wins, or in a draw if the 7-column, 6-row grid is filled without either player successfully connecting four pieces. For more information, see the [wikipedia page](https://en.wikipedia.org/wiki/Connect_Four).


## Learning Goals / Areas of Focus

* Practice breaking a program into logical components
* Testing components in isolation and in combination
* Applying Enumerable techniques in a real context
* Practice implementing a useable REPL interface


## Overview

In this project you'll use Ruby to build a command line implementation of the classic game Connect Four. More detail can be found in the pages below:

* [Setup](./setup)
* [Technical Requirements](./requirements)
* [Peer Code Share](./peer_code_share)
* [Evaluation Presentation Requirements](./evaluation)
* [Evaluation Rubric](./rubric)
39 changes: 39 additions & 0 deletions module1/projects/connect_four/iteration_1.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
---
layout: page
title: Iteration 1 - Game Board
---

_[Back to Connect Four 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.

## Printing the Board

When a user runs the command to start the game, they will see a welcome message, followed by an empty board. The board itself will represent empty spaces with periods and column names with a letter A-G.

```
ABCDEFG
.......
.......
.......
.......
.......
.......
```

Player pieces will be represented by X's, while computer pieces will be represented by O's. A board later in the game might look something like the following:

```
ABCDEFG
.......
.......
O......
X.O...O
XXOX..X
XOOXOOX
```

For Iteration 1, students should have a program that will print out a welcome message and an empty board.
33 changes: 33 additions & 0 deletions module1/projects/connect_four/iteration_2.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,33 @@
---
layout: page
title: Iteration 2 - Placing Pieces
---

_[Back to Connect Four 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.

## Placing Pieces

Update your program to request user input and allow them to place an individual piece.

Your program should ask the user to enter a letter A-G.
Update the board to display the player's piece in the lowest available position of the selected column with an 'X'.

The computer takes its turn by selecting one of the 7 columns at random. Update the board to display the computer's piece in the lowest available position of the selected column with an 'O'.

The player and computer should be able to repeat this sequence and continue taking turns.

### Invalid Column Selection

Neither the player nor computer should be able to play in an invalid column. An invalid column is defined as one of the following:
1. Outside the range A-G
1. Full, i.e. there is no available position in the column

If an invalid column is selected by the player, the program should display an error message and ask the player to select a valid column. The program should repeat this process until a valid column is selected.
* The one exception is when there are no valid columns available; i.e. the game board is full. In this case, the game is a draw, an endgame condition.

If an invalid column is selected by the computer, the program should repeat until a valid column is selected. No error message should display to the user when the computer selects an invalid column.
77 changes: 77 additions & 0 deletions module1/projects/connect_four/iteration_3.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,77 @@
---
layout: page
title: Iteration 3 - Playing the Game
---

_[Back to Connect Four Home](./index)_
_[Back to Requirements](./requirements)_

Now it's time to put together the components you've built in the last two iterations to make a working game. You are allowed to build any additional classes or methods you think may be useful to accomplish this. However, this project will be assessed on the spec outlined in the last two iterations, so don't remove any of the functionality from previously built classes.

You are not expected to test anything related to user input and output in this iteration, but try to use TDD as much as possible to help you design your solution.

You are not expected to follow the Game described below *exactly*. If you want to give your computer player more personality, feel free to do so. However, the information relayed to the user and received from the user should not change. For instance, when either the player or computer places a piece, you are not allowed to omit displaying the board to the user. For your convenience, at the end of this page you will find a checklist that summarizes all of the functionality you are expected to build.

You are expected to build at least one additional class to complete this iteration. This can be a single class that is responsible for running the game. You should have very little code that is not contained in a class.

## Main Menu

When the user starts the game, they should see a welcome message that asks them if they want to play or quit. Whenever a game ends, they should return to this message so they can start a new game, or quit.

```
Welcome to CONNECT FOUR
Enter p to play. Enter q to quit.
```

## Setup

Once the User has chosen to play, display a new game board and ask the player to place their first piece.

### Placing Pieces

The player starts the game by placing their first piece in a valid column. The computer then places their first piece in a randomly selected valid column. The player and computer should repeat this sequence and continue taking turns until an endgame condition is met.

### End of Game

The game ends when one of three endgame conditions is met:

1. The player connects four of their pieces horizontally (in the same row), vertically (in the same column), or diagonally (in consecutively adjacent rows and columns). In this case, the player wins the game.
1. The computer connects four of their pieces horizontally, vertically, or diagonally. In this case, the computer wins the game.
1. The player can no longer place a piece. This occurs when there are no valid columns available; i.e. the game board is full. In this case, the game is a draw.

When one of the end game conditions has been met, an appropriate message should be displayed. The player should be given the option to play again or quit via the Main Menu.

## Functionality Checklist

This checklist summarizes all of the functionality you are expected to build. This will be used to assess the completion of your project:

**Welcome**:

* A welcome message is displayed
* can be combined with Main Menu

**Main Menu**:

* User is shown the main menu where they can play or quit
* can be combined with Welcome

**Setup**:

* A new game board is displayed
* The player is asked to place their first piece.

**Gameplay**:

* The player places their first piece in a valid column.
* The computer places their first piece in a randomly selected valid column.
* The player and computer take turns placing a piece until an endgame condition is met.
* The game board is updated after each piece
* A player attempting to place a piece in an invalid column prompts user to enter a valid column, except in the case of a draw

**End Game**:

* The player connects four of their pieces horizontally, vertically, or diagonally.
* The computer connects four of their pieces horizontally, vertically, or diagonally.
* The player cannot select a valid column.
* The program reports the appropriate endgame status
* Game returns user back to the Main Menu
41 changes: 41 additions & 0 deletions module1/projects/connect_four/iteration_4.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
---
layout: page
title: Iteration 4 - Additional Features
---

_[Back to Connect Four Home](./index)_ |
_[Back to Requirements](./requirements)_

Add to your Connect Four game implementation with one or more of the following features:

### HTTP

* Make it so that a player can play over HTTP against a computer opponent.
* Use [this](http://backend.turing.edu/module1/projects/http_tutorial) tutorial as a starting place for creating your server.

### Ruby Gem

* Wrap the project in [Gem](https://en.wikipedia.org/wiki/RubyGems) using [Bundler](https://bundler.io/v1.16/guides/creating_gem.html) that can be run from the command line by typing `connect` anywhere on your machine rather than `ruby ./lib/connect_four.rb` from your project directory.

### Intelligent Computer

* Win: The computer always selects the column that would connect four of their pieces
* Block: The computer always selects the column to block the player with three connecting pieces
* When presented with Win vs. Block, the computer makes the decision to Win
* When presented with two or more different Block scenarios, selecting any Block is acceptable

### Two Human Players

* Give players the option of playing with two players.
* Each player enters a unique name.

### Win/Loss Record Keeping

* Track win/loss records for players based on a name that they enter that persists between plays (consider writing to CSV).
* Give players the option of seeing a list of the top ranked players based on their win percentage.

### Time Keeping

* Record the time it takes for a player to win a game.
* Track their fastest wins and fastest losses.
* Provide an option for users to view their personal statistics once they have entered their name.
73 changes: 73 additions & 0 deletions module1/projects/connect_four/overview.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,73 @@
---
layout: page
title: Connect Four - Overview
---

_[Back to Connect Four Home](./index)_

## Project Requirements

You are to build a playable game of Connect Four that runs in a REPL interface. The game will allow a single human player ("player") to play against a (simplistic) computer player ("computer"). The game will run from the command line with the following command:

```
$ ruby ./lib/connect_four.rb
```

From there, players will be asked to enter column names to place one of their pieces in a column. The computer will also place its own pieces. The player and the computer will continue to take turns until either one has won the game or they have played to a draw.

Here is a representation of the start of a game.
```
ABCDEFG
.......
.......
.......
.......
.......
.......
```

The Game is over when either the Player or Computer connects four of their pieces as described below, or the game ends in a draw (also described below).

Here is a representation of the human player (the 'X' player) winning the game with four connected pieces horizontally (in the same row).
```
ABCDEFG
.......
.......
...O...
...X...
..OXO..
XXXXOO.
```

Here is a representation of the human player (the 'X' player) winning the game with four connected pieces vertically (in the same column).
```
ABCDEFG
.......
.......
...X...
...X...
.OOX...
XOXXOO.
```

Here is a representation of the computer player (the 'O' player) winning the game with four connected pieces diagonally (in consecutively adjacent rows and columns).
```
ABCDEFG
.......
.......
....OO.
...OXX.
..OXOX.
XOXXOOX
```

Here is a representation of a draw game. Neither the human player ('X') nor the computer player ('O') achieved four connected pieces horizontally, vertically, or diagonally.
```
ABCDEFG
OXOXOOX
XOOXXOO
XXXOOXX
OXOXXOO
OOOXXOX
XXOXOOX
```
23 changes: 23 additions & 0 deletions module1/projects/connect_four/peer_code_share.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
---
layout: page
title: Connect Four - Peer Code Share
---

_[Back to Connect Four Home](./index)_

## Peer Code Share

You and your partner will team up with another pair to review each other's code and provide feedback.

First, exchange Github repo links with the other team.

Then, with your project partner, take 25 minutes to review the other team's code. You should write down answers to the following questions:

1. Can you play the game? Is it easy to figure out how to play the game? Do you find any bugs as you play?
1. Discuss the code for the endgame conditions (`Player Wins`, `Computer Wins`, `Draw`). Is the logic easy to follow? Do the variable names make sense? Could this method be improved by creating additional helper methods?
* In the case that the other team did not write code for endgame conditions, discuss the code for the player and computer selecting a valid column. Answer the same questions above.
1. What classes and methods did the other team include that were not described in the project? How do these classes help organize the code? Are there additional classes or methods they could consider adding that might improve their code?
1. What other feedback do you have for the other team?
1. What other questions do you have for the other team?

Once both teams have finished reviewing code, set up a 40 meeting with the other team. During that meeting, both teams should share their answers to the questions above.
20 changes: 20 additions & 0 deletions module1/projects/connect_four/requirements.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
---
layout: page
title: Connect Four - Requirements
---

_[Back to Connect Four Home](./index)_

The specifications give you ideas for some classes to help you start breaking this problem down, but you will also have to create some additional classes and methods to build an Object-Oriented solution to this problem. This means that there should be very little code outside of a class and you are using your classes to create objects that interact in some way.

Additionally, this project will require you to use Test Driven Development for all methods that do not **rely** on user input. *Very few* methods should rely on user input.

As a pair, you are both expected to commit frequently and use Pull Requests to merge your code with your partner's. Remember that there are many ways to contribute to a group effort - review the topics we discussed in your [Learning to Pair](https://docs.google.com/presentation/d/1SB65R2PkUBHoNHk3z5Q71D-ZVHPLdQ7wBagGjd6_AUU/edit?usp=sharing) lesson.

Please read the [Rubric](./rubric) before getting started so that you know what is expected of you.

* [Overview](./overview)
* [Iteration 1](./iteration_1)
* [Iteration 2](./iteration_2)
* [Iteration 3](./iteration_3)
* [Iteration 4](./iteration_4)
Loading

0 comments on commit bcc9a21

Please sign in to comment.