This week most of the time was spent on the final presentation content. Additionally, I tested all the pegs to ensure they were aligned with the buttons and would press securely. I also worked on glueing the boats, flags, and magnets with the team. We also spent time fixing some small visual aspects like the tiles, water, etc. In terms of schedule, we are ahead of our planned timeline and are exploring further software features, however, the final video and report will be our main focus.
Rhea’s Status Report for 12/06/25
We finished all the final touches for our boards this week (focusing on the aesthetics). I mostly focused on debugging the code and making it more robust to any errors, as there were a few inconsistencies with the save state and multiplayer features. Additionally, I spent most of my time preparing for my presentation on Wednesday.
We spent the second half of our week planning our final video. Because we are ahead of schedule, we hope to implement some basic rule checks in our code before our demo. For example, a player shouldn’t be able to place a settlement on a corner adjacent to another settlement. Our main focus for next week will be the final video and report.
Team Status Report for 12/06/25
We had three different components needed to test: the switch matrix, the LED strip, and the dice detection. As we built the switch matrix and LED strip, we would test connectivity with a multimeter. Once we ensured all connections were secure, we tested the components’ functionality. To test the switch matrix, we ran about 720 total presses and saw over 99% reliability and no issues with ghosting or double-counting. For the LED strips, while soldering, we tested every 2–3 strips at a time to ensure there were no dead pixels or loose connections. Finally, we validated the indexing between each switch position and its corresponding LEDs with a 100% correct match.
To test the dice algorithm, we followed the TA recommendation to evaluate performance over three full games rather than doing isolated 100-roll tests. Across those three games, the system achieved an average of 93% accuracy, which is more than our 90% goal. We also measured the rate at which the system falsely detects rolling motion and triggers a token light-up. Over the same three-game test set, the misfire rate averaged 5%, which is within our target threshold. The time it took for a token to light up after the dice came to a rest averaged to be around 55ms for the same board and 95ms for the other board, both of which are within our target times.
The main idea for synchronization is ensuring both boards have identical game states at all times. To ensure all messages were sent and received as expected between the boards, we tested all possible inputs: a single button press for settlements and cities (3 different times to ensure it would first turn one light on, then all three, then turn them off), adjacent button presses for roads (twice for turning it on and off), non-adjacent button presses to ensure nothing would happen, robber tile presses (ensure that that correct resource token lights up), and finally the dice roll also lights up the correct resource (if that resource isn’t currently being occupied by the robber). We tested each type of button press 25 times on different locations on the board and saw 100% accurate synchronization with only about 40ms latency.
For our demo and user study, our goal was to evaluate whether our synchronized boards actually recreate the feeling of playing an in-person board game with someone who isn’t physically there. We tested the system with about 20 users. We ran one 5-minute game with two different pairs of participants, and after each game, the players completed a brief post-game questionnaire. The survey used a 7-point Likert scale and assessed tactility, sense of co-presence, responsiveness, and how easy it was to differentiate players based on color and LED feedback. Our goal was for at least 80% of users to rate the experience as good as or better than online play in both tactility and co-presence and that players were easy to distinguish. The results were very positive. 95% of participants said the tactility of the system felt better than online play, and 100% said the sense of co-presence was better than online play. Responsiveness had a median of 6 on the 7-point likert, and the ease of differentiating players has a median of 7. We also collected open-ended feedback about any confusing interactions or moments where latency felt noticeable, and those comments helped us refine our transitions and LED cues.
This week we worked on final touches on the two completed boards such as refueling some pegs. We glued the boats onto the board, and also assembled the flags for it. In terms of software, we fixed some small bugs prior to our presentation and recorded demo videos. The bulk of our time was spent on preparing for the final presentation. In the later half of the week, we met as a team to begin the final video and planning out our storyline. We are ahead of our schedule so in addition to the final video and report we are hoping to implement a couple additional software features.
Rhea’s Status Report for 11/22/25
This week, I focused on integrating the two boards. Last week, both boards could independently detect button presses and light up the corresponding LEDs, and we had a simple dice detection algorithm, so this week, I worked on synchronizing the two boards.
I wrote the code that sends messages between both game boards to ensure they are in sync. Whenever a button press or dice roll is detected, it now sends a message to all connected peers (in this case, only one other board). Each board currently stores its peer information (hostname, IP, etc.) in a configuration file. When the program starts, it reads this config, opens a socket that listens on all ports, and spawns a thread dedicated to receiving and processing incoming messages. Two other threads handle checking for button presses and dice rolls (and sending messages whenever anything is detected). This way, both boards can update each other in real time.
I also implemented a save state system. When a player stops playing, the board records its current state (which LEDs are on, whose turn it is, etc.) and writes it to a file. When the board is powered on again, the script automatically loads this saved state so gameplay can resume exactly where it left off. To complement this, I added a clear board button that resets all LEDs so users can start a new game at any time.
Since we decided to downsize our prototype to six tiles, I also worked on remapping the dice rolls. Normally, Catan uses numbers 2–12, but we only use seven of them (six resource tiles and 7 for the robber). We decided to turn the remaining four numbers into ports. Players can choose what resource will be gained from each port, and when a port’s number is rolled, they can take that resource. This ensures every resource appears at least twice across the six tiles and four ports, keeping the game balanced but flexible.
Finally, we added support for more than two players, even with only two boards. Instead of assigning each board to a fixed player color, I added an “end turn” button. When pressed, it cycles through the colors based on the number of players (2–4) entered at the start of the game. This means four players can now play together using the same board, increasing the overall usability.
Finally, we also finished the visual design: gluing down the printed resource images on each tile and adding the blue water background to make the board match the real Catan aesthetic.
Next week, I plan on thoroughly testing our boards and fixing any minor bugs in the code. I also plan on spending most of my time working on the presentation, as I will be working from home and won’t be on campus to work on the actual game boards. Once I come back, I hope to spend time working on making the RPi start running the script immediately upon it being powered on (so you don’t need to connect a computer to start the script). Any information the user needs to enter can be entered directly through a connected keyboard.
To implement board synchronization, I had to learn more about socket programming and managing multiple threads in Python. I previously took Distributed Systems in Go, so I reused the structure I would normally write in Go, then translated that into Python by reading library docs and small code examples online.
I also had to learn how to debug NeoPixel strip issues that only showed up as segfaults in the terminal. At first it wasn’t obvious that the problem was the LEDs at all, or that it was caused by multiple threads writing to the strips at the same time. I went through a lot of Stack Overflow posts and videos about driving multiple NeoPixel strips from one Raspberry Pi. That’s how I realized the NeoPixel library itself isn’t thread-safe, and that simple locks around the strips weren’t enough. In the end, I fixed it by creating a single dedicated thread whose only job is to update the NeoPixels. All other parts of the code just push “update requests” into a queue, and that one thread processes them in order. This removed the race condition without needing complicated locking and made the LED behavior much more stable.
Team Status Report for 11/08/25
This week, we focused on getting one full board to a usable, testable state. That meant rebuilding the switch matrix with sturdier parts, reshaping and mounting the LEDs to match the hex layout, and writing the software path from “button press detected” to “specific LEDs light up.” The goal was to complete a reliable build for the interim demo.
1. Switch Matrix
We rebuilt the matrix with new buttons mounted in a rigid base and used thicker copper wire. This setup reduces flex on solder joints, which was our biggest reliability issue before. The new assembly is a lot stronger, and I think the second board’s matrix will go a lot smoother.
2. LEDs
Because the board requires LEDs to be placed in a hex shape, we had to cut and re-solder the straight LED strip at every turn to wrap each game tile. We also left physical clearance for the dowel attached to each house piece so it can press the button underneath. This step was definitely one of the most time-consuming parts of building the game board.
We initially used duct tape to keep the LEDs attached to the game board, but it didn’t end up being strong enough, so we decided to hot glue each section of the LED strip to the board. Additionally, we wanted to use a single GPIO pin for the entire strip; however, the joints kept breaking, so we ended up splitting the strips and using two GPIO pins.
3. Software
On the software side, we now have a script that reliably detects button presses and another that can address specific LED indices. We’ve verified that all buttons can be detected and all LEDs light up as expected. We also have a script that will take the button press and light up the corresponding LED index. The only thing that is missing is the mapping table from button press to LED index. Once we assemble the boards on top of each other, we will be able to record the correct mapping and test the code.
4. Dice Plate
The dice plate currently reads faces on a black-and-white die using our computer vision pipeline. It works, but it isn’t consistent due to noise and lighting variation. We believe we need to train a small, task-specific model (or at least collect a dataset under our exact conditions) to improve robustness. This is currently our biggest technical challenge. Once we assemble the boards with the camera, we will collect images and label them, so we can train the model on the actual conditions of our game board.
Plan for next week:
- Align the game board (with the LEDs) with the buttons below it
- Record which button maps to which LEDs
- Ensure that pressing a piece on the game board accurates presses the button on the switch matrix
- Begin working on the second game board
- Finish the switch matrix
- Finish restructuring the LEDs
- Start working on training a new model for the dice plate
Rhea’s Status Report for 11/08/25
This week, I focused on completing the switch matrix and writing core software for button detection and LED response.
May and I built the full switch matrix from start. We started by gluing all the tactile buttons to the baseboard, then soldered copper wire across each column. We had to solder a diode to the other leg of each button, and then another copper wire connecting all the rows. We used electrical tape along every connection to strengthen joints and prevent short circuits between adjacent rows and columns. After finishing the matrix, I worked on the Python code for button press detection. I implemented software debouncing to make sure a singular button press didn’t register as multiple presses. This took most of Tuesday, and by the end, we had a working, stable 11×11 switch matrix that could detect multiple presses simultaneously.
May and Tanisha handled most of the LED re-soldering (I mostly just held wires down for them). I took the strips they finished soldering and taped them in the correct positions around the board to form hex shapes. This took most of our Wednesday work session. The duct tape I used initially wasn’t strong enough, as the joints kept flexing. We decided to switch to hot glue for all sections. On Thursday, May and I secured all the LEDs in place and thoroughly tested them to make sure the connections were strong enough to withstand normal gameplay and movement.
I also wrote the main LED control script, which links button presses to specific LED indices. The program continuously scans the switch matrix, and (1) lights up “house” LEDs when a single button is pressed, (2) lights up “road” LEDs when two adjacent buttons are pressed, and (3) moves the “robber” light when a specific tile button is pressed again. Right now, the code framework is complete: we just need the final mapping between buttons and LED indices once the boards are physically aligned. After that, I’ll test and tune the system for full responsiveness.
We are slightly behind schedule on finishing the second board because the LED re-soldering and mounting took longer than expected. Before the interim demo, we hope to have the first board assembled completely and the mapping between buttons to LED indices recorded. For next week, I plan to work on tuning the software components, as I am out of town for half the week. Once I am back, I plan to help finish the second board and start working on synchronizing the two boards together.
Rhea’s Status Report for 11/01/25
I worked with Tanisha to finish setting up the Raspberry Pi with SSH so we could control the board remotely. I also tested the LED strips with the Pi and played with different brightness levels to see what would be most visible on the board and what would work best for roads, cities, and settlements.
I worked with May on the baseboard layout. I took measurements on the actual LED strip and cube pieces to figure out spacing/tolerances, and May translated that into the SolidWorks design so that all the components would line up.
I also set up the switch matrix and did the initial wiring. Tanisha helped with the soldering so everything was secured. While we did connectivity checks at each step, we believe some connections broke as we transported the components or as we continued building upon each piece, as there were still a few flaky connections once we finished. We will be switching to sturdier and bigger buttons and laser cutting a layer for the buttons to prevent all the pieces from moving around next week.
Team Status Report for 11/01/25
This week, we focused on refining the physical layout of the board and integrating all the pieces of the board.
1. Dice tray plate
We laser-cut multiple versions of the dice roll plate to test wall height (short vs. tall walls, and outward-tapered walls). After testing with actual dice, we decided to use tall, straight walls since they keep the dice contained better and look cleaner when integrated into the board.
2. Revised house vs. city indicator design
We changed how we represent houses vs. cities on each tile. To make our game board look cleaner and symmetric, we decided to have three LEDs at each corner. We will light up one for a house and all three for a city. This also works better with the LED strip spacing, as it is easier to route and gives a clearer visual distinction for the player.
3. Base board laser cutting
Our biggest accomplishment this week was finalizing the design we would laser cut for the baseboard. It took multiple iterations to get the dimensions for the cutout for each LED correct so that the wiring is hidden underneath. We are now ready to restructure the individually addressable LEDs to match this layout.
4. Switch matrix wiring
We also finished wiring and soldering the switch matrix. However, during continuity testing, we found intermittent connectivity issues on some rows/columns. The pinouts for the push buttons are very weak, so a few of them broke during soldering. We fixed those and then fortified the connections with electrical tape. Unfortunately, we think there were more issues with the soldering and maintaining connectivity. Rather than continuing to work with the small weak buttons, we decided to just order bigger and sturdier buttons. We also plan to laser cut a dedicated base plate with holes for each button so they are constrained, and hopefully, the solder joints don’t break.
Plan for next week:
- Rebuild the switch matrix with the new buttons.
- Laser-cut the switch base board to mechanically support the matrix.
- Restructure the LED strip to match the board
- Integrating LEDs + switches (so a button press leads to an LED lighting up)
Rhea’s Status Report for 10/25/25
This week I focused on the switch inputs (and finished the ethics assignment). I tested the buttons we ordered with copper wire to check feel and basic continuity to the Pi. The buttons are tiny (as we had intended), but after testing them, we realized some usability trade-offs. First, direct finger presses are finicky, it is easier to press using something harder (such as a fingernail). Second, pressing through a thin sheet can potentially nudge nearby buttons and cause accidental triggers.
Given that, we are considering changing the design to place each button directly under a settlement/city game piece so the piece helps localizes force. While this is different from our original design where we wanted all the electrical components of the game board hidden under a layer, it still keeps the top surface clean (as the buttons are hidden under the game pieces). Therefore, it still aligns with our “invisible wiring but still tactile” goal of the design.
For the full board, we are planning an 11×11 switch matrix. I haven’t built the 3×3 yet, I only validated parts and wiring, but I outlined the scale-up path. Next week, I’ll wire a 3×3 and test for simultaneous presses without ghosting (with per-switch diodes if needed) and verify the press to LED mapping.