For this milestone, we focused on organizing our React app in terms of components and state. This was very helpful in conceptualizing which methods we need to write, where they should live,  and what information will be sent between components. We now have a static version of our game that we can build on to develop Pentago functionality!

Component Hierarchy

Here is a sketch of our component hierarchy. Essentially, the App component will hold two instances of the Player component (one for each) and four instances of the Quadrant component (which collectively make up the “board”). The App component will be responsible for most of the mechanics of our game and own most of the app’s state, and it will pass information about state to Player and Quadrant components (which passes info to the Marble components). A more in-depth explanation of state can be found in a later section of this write-up.

Each Player component displays the amount of marbles that each player has remaining. Each player starts with 16 marbles, and this number will decrease as the game goes on.

The “board” (basically a white square in the UI) is made up of four Quadrant components. Each Quadrant component is responsible for holding an array of 9 Marble components in a 3×3 grid, which players can add marbles to throughout the game. Quadrants have the ability to be rotated 90° once in either direction per turn.

Marble components can exist in 4 different ways: as an empty marble space, a Player 1 marble (black), a Player 2 marble (white), or a “hovered” marble (which just darkens the empty space on Mouseover to show players where they can place their marbles). The appearance of each Marble is passed in as props from each Quadrant component, which is passed from the App component.

Note: In our sketch, we actually had Board as its own component. However, we realized that Board wasn’t actually accomplishing in terms of state, it simply served as UI appearance, so we ultimately merged Board’s design with the App component’s design to maintain the UI but make our process more streamlined.

Thankfully, the layout of the Pentago game board is very conducive to visualizing how we need to render components within components. So we started by rendering each component just to get an idea of where things would show up and make progress design-wise.

 

Static Version

Since we had a clear idea of which components needed to be where to create a visualization of our game, creating the static version was very design heavy. My project partner Nate is a React-wizard and did a great job developing this!

Here are some progress screenshots:

Ultimately we were able to organize the components of our page in a static version. Here is a link to the static version of our app.

Minimal Representation of State

Marble state is the primary state operation in our entire game. Instances of Marble are either empty, or filled with a color from one of the two players. Basically, our App component will hold the state of Marble (empty, White, or Black) and will send that information to Player and Quadrant. Below are the four visual variations of the marbles:

As players take their turns, App will keep track of how many of their sixteen marbles a Player has left in their arsenal, and changing the state of specific Marble spots in the 3×3 arrays within each Quadrant. (App will be the parent containing four 3×3 arrays of Marbles, and each Quadrant will have its own 3×3 array out of those four). App will also have the rotate functions to send to the Quadrants, to enable players to turn a specific Quadrant 90° either clockwise or counterclockwise.

Another use of state in our game will be determining if there is a winner or not. So, each time a player makes their turn, we will check to see if there are any 5 same-color marbles in a row.

If there is no winner yet, the last use of state that App will control is keeping track of which player’s turn it is. Meaning that every time one player completes their turn (places a marble and rotates a quadrant), App will update whose turn it is and the gameplay will continue.

Team Members and Responsibilities

Originally we distributed the workload in terms of components, but realized that was not the best way to do things after thinking in terms of state. At first I was going to work on the Board and Quadrant component and Nate was going to work on Marble and Player components. Now that we know that most state and methods will live in App, and there is no longer a Board component, we are delegating the tasks in a new way. We set up a collaborative Githup repo to push / pull from to work in tandem effectively. Here is our new task breakdown:

• Nate Bennett
  • Keep track of Marble’s state. This state will live in the App component, because Player needs to know how many marbles they have left, each Quadrant needs one array of 3×3 Marbles, and each of those instances of Marble will either be empty, or filled with a black or white marble.
  • Write a method to handle when a Marble component is clicked in one of the Quadrant arrays. This method will highlight the component gray before it is clicked so the user knows where they are placing the marble, and then once clicked it will color the Marble (update its state to either Black or White) and update the amount of filled Marbles left in the Player’s arsenal (update one Marble’s state to empty)
• Elsa Roeber
  • Write the rotation function. This will live in the App component but will be sent to the Quadrant components when the arrow buttons are clicked. Once the rotation is finished, App will update state of which player’s turn it is. Also, call the checkWinner function once the rotation is over. If there is no winner, the game will continue.
  • Write the method in Quadrant to call the rotation function when any of the eight arrows are clicked on a player’s turn.
• When finished:
  • We will combine our progress and lastly develop our checkWinner method.