Group 4 Design Portfolio:

Creating a new rendition of the classic board game Othello!

This portfolio documents the process of designing, building, and improving upon a version of the board game Othello using an Arduino to power it. Included are different entries detailing our progress on different days, marking certain accomplishments in the process of creating the game. Additionally, the process is shown through a project task list, and a report on the efforts that went into this project are presented in the Maker’s Manual.

Project Task List

Plan/ prototype:

• Brainstorming (All)
• Materials (all)
  • Neo pixels 6×6
  • 1 button
  • 2 potentiometers
  • Long wires to controller
  • Wood
  • Cardboard
• Figure out logistics (all)

Assembly

• Solder the Neopixels (Eliza)
• Create circuit with neopixels, potentiometers and button (Sam H.)
• Cut out board most likely cardboard (Sam C)
• Attach neopixels, potentiometers, and button to the board (Sam H)
• Create controller for potentiometers, and button  (Sam C)
• Decorate board (Eliza)

Code (all)

• Selection method
• Dimmer for guessing, brighter for already placed cells
• Alternating between players
• Switching cells’ color after turns

Testing/Improvements (all)

• Test circuit, check for power limits, and functioning parts
• Troubleshoot code, check every direction around selections, and invalid conditions
• Direction of potentiometers, navigate cells in array, input choices
• Game start animation, Display winner at end of game

Timeline:

 

Progress Blogs

Day 1: Initial Prototyping

Today we prototyped how to make our game Othello! We started by writing out a rough plan as to how the game will operate. We brainstormed different styles of making the boardgame to compare how we would want the game to be played, and what would be the best way to construct the game. One option which we discussed was making a board with physical pieces that the players would place down on the board. They could have sensors to show which player they belonged to, and activate LEDs to light up to the corresponding colors. This would be much more intensive on the components it would require and more complex to create. A second option we thought about would be to have a grid of LEDs and the players would use a controller with two potentiometers and a button to navigate the board and input their choices. If we continued with this second design, in a later iteration of the game it could be expanded to allow for remote play so that two players could have boards in separate locations and send the moves they make to each other.

We constructed two very low fidelity prototypes to represent how the game could be constructed. We sketched the game as an 8×8 grid with each box representing a neopixel. In one prototype, the little clear tiles represented the game pieces which could be placed on the board and activate the LEDs underneath. In the second prototype, it showed how the LEDs could be covered with a semi transparent covering so that they would not be visible, but they would shine through to look more visibly appealing.

 

Day 2: Project Planning, and Initial Coding

In the second day of lab we talked through prototyping ideas, outlined code and ordered materials. We started with talking through how we wanted the board to look and how to maneuver through it. Some options were force sensors or buttons on each tile or two potentiometers one for vertical and the other for horizontal navigation paired with a button to place a tile. We decided to go with the potentiometer option as there is limited inputs in the Arduino. Next we decided to use an 8 by 8 grid of neopixels for the board itself. We then started researching the code. Pretty quickly we realized we needed a special library to work with the neopixels. We tried multiple ones out and found one that would allow the entire board to be one large matrix so we stuck with that one. Next, we talked about the basic outline of the code. Some challenges we knew we were going to run into was the flipping of the board pieces especially in the diagonal direction and having the piece that was in play switch colors depending on who’s turn it was. Finally, we went through and added the neopixels to the order form so we could begin to create the board once the parts arrived.

We began by writing a general outline for what we would need to incorporate into our code:

 

Day 3: Assembling and Testing Components

Today in lab we finally got the Neopixels so we got right to work soldering them. We accidentally soldered each Neopixel the wrong way so when they were plugged in none of them worked. We thought the Neopixels didn’t work or there was a problem with the Arduino. After some investigation we figured out we had soldered the wrong end and we fixed the problem by resoldering the other end. Next we got to building the circuit for the two potentiometers, button and the Neopixels. We then started experimenting with the code. We had written some basic setup code before we showed up on that day to try and scroll through the potentiometers. After some minor bug fixings we were able to get the code mostly working for scrolling horizontally and vertically with the two potentiometers.

Here are two pictures of the working neopixels and the circuit:

 

Day 4: Working Through Code

In this meeting as well as during day 5, we focused on finalizing, troubleshooting, testing, and improving our code. We had to focus on several main issues that were challenging to work out in our code. The most challenging was the process of getting the correct colors to switch after a player input their turn. In Othello, when a player places a tile, they switch any of the tiles that they have captured from their opponent, which can happen in any direction as long as it is bounded by two tiles of the player’s color.

In our code, we had to determine the best way to check every direction around a chosen cell to ensure that:

1. it was adjacent to a tile of the opposite color
2. in the direction of the tile of the opposite color, there was a tile of its own color

When these conditions were met, the code would then backtrack along that direction and switch the opponent’s tiles in that series to capture them for the player who made the turn. One particular challenge for this process was figuring out the logic required to check in the diagonal directions around each placed tile. In a section of the code for switching tiles, shown below, it shows how we worked through this challenge. For a given selection, we checked along the diagonal direction (up and right). First, if it found an empty cell, it would stop checking that direction, otherwise if it found one of its own color, then it would go backwards along that direction, switching the tiles to the player’s color.

Once we had the code working for each player’s turn, we implemented a counter to check if the board had been filled, which would denote the end of the game at which point the board would display which player had won the game. Additionally, we added some aesthetic features such as a startup animation which would play each time the game began.

Day 5: Building The Board

Today we continued finishing the physical components of the board game. First we attached the neopixels onto a sheet of cardboard so they were secured into the correctly sized grid. We wanted to make the finished product look presentable, and resemble a traditional board game which players would be familiar with.we folded the cardboard over the top of the neopixels, and cut a hole the size of the board and attached a game surface to cover the board.

Next, we printed out an 8×8 grid with the same spacing as the lights on the neopixels which made it more clear which lights corresponded to each space on the board. Attaching this over the top of the board of LEDs also dispersed the light slightly so they shined evenly and were not too bright. We then sealed the pieces of cardboard together so it made a coherent game board, but allowed us to still access the neopixels if need be.

 

 

 

 

 

Presentation:

After completing the finished project and testing all of its functionality, we prepared to present it. To accompany the product, we made these slides for the presentation:

othello-final-presentation

Maker Manual

A. Overview

The final product is a workable game of Othello. The game consists of 64 Neopixels, two potentiometers to maneuver the board and a button to place a tile. During a play, a player will select a cell where they want to place their tile in order to capture the tiles of their opponent. When the player makes a move, any lights of the opponent’s color that are in a straight line and bounded by the tile just placed and another tile belonging to the current player are turned over to the current player’s color. The game continues until the board is entirely filled, and the player with the most tiles of their color on the board is the winner. When the game ends, the board will light up to show the winning player with a prominent letter (either R for red or B for blue). Afterwards, the board will be cleared and a new game can begin. 

Below is a video which shows how the game works, as well as the animations for start of the game, and the display for the end of the game depending on the winner:

https://vimeo.com/user75681416/review/305731964/96c379d0a9

B. Required Supplies

Tools:

• Soldering Iron
• Wire cutters
• Scissors
• Wire strippers
• Tape

Components:

• Neopixels
• Cardboard
• Two potentiometers
• Button
• 10 kΩ Resistor
• Arduino
• Breadboard
• Wire
• Paper

C.  Layout and Circuit Diagrams

For these diagrams, the displayed components for the Neopixels are represented by standard 3 pin parts, however each strip of neopixels contains 8 LEDs which can each display a full range of RGB values.

D. Build Section

There were three main stages to the building of this project, making the array of neopixels, making the controller, and finally creating the outside of the board game.

First, to make the array of neopixels, 8 strips, each with 8 lights per strip, need to be soldered with wires for power, ground, and input. There is a small directional arrow on the strip of neopixels which represents which side should be soldered. Each of the wires for power and ground can be grouped respectively in order to have only one external wire for each, while the remaining control wires will each go to one input on the Arduino. The strips can now be laid out so that they are evenly spaced to make an 8×8 square and secured to each other or to a surface like a sheet of cardboard.

Next, the controller can be created with two potentiometers and one button. The potentiometers will be used to navigate the board ad input choices for moves in the game, with one potentiometer scrolling through the rows, and the other scrolling through the columns. The potentiometers have three pins each: power, ground, and an analog input which will go into the arduino. The button should be soldered with one pin going to ground, and a second pin with 10kΩ Resistor which goes to power as well as a wire going to an input on the arduino. These three components can be placed into another piece of cardboard so that it can be held like a controller and passed between the two players as the play the game.

 

Lastly, to make the finished product more presentable, we created a game surface to cover the neopixels. We printed out a grid which would have cells the same spacing as the lights on the neopixels so that they would fit evenly. Covering the neopixels helped make it more clear which spaces were which and dispersed the light from the LEDs so they were not as bright and shined more evenly. We then attached the neopixels and the grid to pieces of cardboard so that they could stay together and look more like a typical board game. We tried to make it look like a normal playing board that users would recognize and feel familiar interacting with.

E. Coding Section

This is an example for the Red player’s turn, though there is another similar version for Blue

Again this checks for the red player, another similar function checks after the blue player. It goes in each of the 8 directions around the chosen space, but this image simply shows the first direction.

After each turn, this function checks if the board has been filled and if the game should end

When the game ends, the Board shows who won with a big letter of the their color. There is R for red, B for blue, and T if the players tied.

F. Testing, Troubleshooting, Shortcomings

When we were building and testing our project, we had several stages throughout the process where we had to try different tests to ensure it would function properly. First, once we got the neopixels, we had to solder each of the strips so it could be input into the arduino. Initially, we did not notice that they had a specific direction for current, so when we tried to test them to see if they all worked, none of them did. Once we soldered them correctly, we checked each of them to make sure they would light up, and that the arduino would not have any power issues when they were all being lit.

Once we got further along in the code, we had to test the functions that we had made in order to scroll around the board with the potentiometers and take the choices for a player’s turn. It took a long process of trial and error to get all of the logic in our code correct so that a player could only place their choice in a valid space, and it would react properly by switching the proper colors.

Lastly, when we had the all of the code for the gameplay finished, we tested the final functionality of the game by playing it all the way to completion multiple times. We had to make sure that it would remain consistent and there were no errors as the board got filled up all of the way. Additionally, we wanted to show each of the ending conditions for which player won, or if there was a tie between them.

In looking more critically at our design and the finished product, there were a few places that could be improved for the sake of user interaction, gameflow, and clarity. Toward the end of the game, we noticed that as the board got filled with more lights, it was hard to tell where the player’s selection was. This could be fixed by making the selection of the player blink or flash while they are moving around, and then switch to full brightness once they finalize their choice. Additionally, using the potentiometers seemed to get tiring, and could even make our fingers sore by the end of the game. This could be improved either by using better potentiometers or changing the input mode for the players. One option that could improve the selection of the choices would be to make the board have sensors or buttons so that the player could just press directly on the space where they want to place their color.