Game board by Bobwhites: Final Documentation

In our project, we consulted Mike, who is a Mason at Carnegie Mellon University's Facilities Management Services. In this project, the goal was to create a physical computing device to benefit Mike in his work. In this, we had an initial meeting with Mike about what we could make to assist him. Initially, we built a prototype and concept involving automatically cleaning a paddle, but we pivoted to creating a game board so that while the FMS employees are in the shop, they can see who is going to be playing the game they decide to play.

For more information on our first plan and meeting: https://sites.google.com/andrew.cmu.edu/60-223-s26/project-3-documentation/fms-mason-interview-documentation?authuser=0

Our project is a way for the people at FMS to actually know if there are enough people to play Left Right Center. In this project, there is a digit displayed on a screen. This number will be set with a button, and can be changed before it is set with a dial. The days are connected with our 24-hour day cycle, and the numbers will go down after each day. The light is normally white, but if there are at least five different players in the game, there are lights that light up green. Once the day countdown goes to zero, if there are enough players, the lights become rainbow. If there aren't enough players, the lights become red. Additionally, if the dice are in the designated storage area,  there is a light above it that illuminates white. If the dice are not present, the lights become rainbow.

When the employees at FMS want to start setting up for their weekly Left Right Center Game, they will go to the Gameboard. Here, one of the employees will turn the giant dial, and the days until gaming screens will go through different numbers. Once it is appropriately synced to how many days until they will play, they will hit the button above the dial. 

While waiting, if any of the employees, like Mike, walk by and want to play, they will move their card into an empty slot. If enough people say they are playing before the countdown hits 0 days, the lights on the gameboard will turn green to tell everyone we are playing left, right, and center! Once it hits 0 days the colors will be rainbow if they are playing, and if there are not enough people, the color will turn red. 

How we got here (prototype and process)

Prototype

This prototype asked whether we can physically make a solution to clean the paddle with brushes.

Our prototype combined a motor that moves up and down and a nylon brush. Here, we powered the motor and used cable ties to hold the nylon brush in place. Thus, once we powered the motor, the nylon brush moved up and down in an attempt to remove the remaining paste on the paddle.

Through our prototyping process, we found that it was not really feasible to clean the paddle with brushes. Since this was really our only idea, this revelation caused us to decide to pivot. The feedback we got from our prototype was that this was an incredibly hard idea, and we should consider pivoting. Ultimately, we took this feedback and talked with Mike as to what other issues related to his work, but not the actual process, could be improved. Through this conversation, we discovered Left, Right, and Center and how they aim to play more but ultimately don't. Through taking this feedback, we ended up ignoring other feedback suggesting possible ways to fix the problem, but even this feedback did say that while there is a potential option, it may be better to scrap the idea completely.

Our biggest surprise during this prototype phase was how difficult this prototype would be to work with. We figured there would be a reason that this would not be solved easily, as otherwise this wouldn't be the only issue Mike the Mason would have after over two decades of being a mason, but the specific ideas we were optimistic about ended up falling short. 

Process

Conclusions and Lessons Learned

With feedback from our final crit, one thing that was mentioned we really liked was the idea of having “permanent dice in bubbles”. This could be an idea that, if we further iterate on, we would include. Dice are super easily lost, so having the dice be physically attached to the game board would be a nice way to have everything be more connected. Moreover, in our feedback, another thing that was mentioned was that the project “needs a carrying handle”. While we feel the project works decently on its own, the inclusion of a carrying handle could definitely improve the overall experience of the gameboard. 

One thing that our project was repeatedly praised for was the “pivot when problems with the profession were too complex to tackle during rapid design and prototyping”. This was an incredibly difficult decision to make as we felt we were throwing away work that we had already done, but in retrospect, this was definitely the right decision. Not only were we able to see the project through to completion, but people far more experienced in this domain seemed to think that this was the correct option to go down as well. Another form of feedback we repeatedly got was how the device was good at  “encouraging participation”, and the fact that evaluators noticed this aspect was very satisfying. This was something we really wanted to focus on, as FMS flaking last-minute playing is a problem Mike mentioned, so by incorporating active commitments through moving the piece, we aimed to reduce its occurrence.  By having the players physically move a card to say they are playing, we hope that this will help them actively commit to the activity, compared to just stating that they will play.

Working with a client was a different experience than we anticipated. Our client, Mike the Mason, has been in the field for an extremely long time. This made it hard to think of ways to improve their workflow that wouldn't add convoluted steps, as he has basically mastered his own workflow over the years. In our crit, the only thing he really mentioned was finding a way to clean a paddle, and as such, we went with this as our initial goal. This turned out to be quite hard, and definitely not feasible within the given time frame, so we had to abandon this idea after the prototype evaluation. Thus, if we could go back in time, we would not have spent all of this time on this specific concept and instead tried to pivot earlier. Our idea of landing on helping the FMS people play the game that they seemingly all want to play, but end up not playing, was a pivot we are proud of. 

Overall, due to our conflicting time schedules and the pivot we made towards the end of our project, we are decently proud of how it all came together. While we could have changed our direction earlier and started working on troubleshooting before the last day, we still managed to complete the project in a way that will hopefully make Mike and the rest of FMS happy. Mike, in particular, during the final crit, was ecstatic and loved it. He stated how amazing it was, and he was so happy with how it turned out. Mike’s opinion trumps our own personal grievances with the project, and his excitement towards the project is something that we are very proud of. Hopefully, this project will be used for semesters to come and enable Mike and the rest of FMS to create a stronger bond together.

Here is our code: