I'm glad to see that you've considered some of the complications that you will face with this concept. I like the idea of a gravity return and would like to see this more fully developed in later models, and I see that you've thought about what to do with the false positives that you'll inevitably get with the current design.
Have you tried actually tossing a ball at this model? I think you will need to address problems where the ball hits one of the vertical dividers before hitting the base of the model. You don't want the ball to bounce wildly and land in a square far away from the initial landing point - if players can't see what's going on, the game will feel broken even if it's not. I have the same comment about a ball that bounces in and then out of a box without hitting the contact closure. You may need to explore methods of damping the ball's motion as it contacts the board.
I'm not convinced that a gravity return system requires that the ball pass through other squares on its way back to the user. I can picture a two-level board where instead of a contact closure in the downhill corner, it has a hole for the ball to drop through. The ball could drop down to the lower level, which would use the same tilted-floor concept to funnel balls back to the start, but there are no dividers and no sensors on the second level - just a flat surface. This adds a bit of complexity to your build, but simplifies the code.
Matt is concerned about the I/O count, but I don't personally believe that 24 optical sensors and 24 lights is out of the question. Especially when a game looks like it might be as much fun as this one!
I would go with optical sensors rather than switches, and have the boxes be more of a box that drops out into an open slanted area. This means a ball would simply have to pass through the grid, be seen, and then could roll back to the start on its merry way (basketball hoop games in an arcade.)
This would be an entirely non-moving part, very robust system. And yes, people might wander off with the balls. The staff will find them in all sorts of strange places. But I think we simply provide them with enough that it isn't an issue.
I like the design and usability of the board. Having it slanted preferentially to the switch is a brilliant idea to ensure the switch activation during game play and bring the balls closer to the next player to re-use. However, I'm not totally convinced on the workings of the switch.
The concept explored by this model is one of the cruxes of making this game work; robust hit detection is necessary to make the game function properly without frustrating participants.
I think you've done a good job of using your sketch model to think through some of the challenges that you'll have to overcome with the full-size model. Ball return is obviously going to be a significant challenge, as well, and you've thought about how that mechanism will interact with the hit detection mechanism.
I love the cleverness in this design of how to trigger a hit in a relatively simple manner. It doesn't seem like it'd be too costly to implement, and also would be relatively robust because there aren't moving parts.
Looks good! I would be curious to see what you could learn from this model about the different types of balls you could use. One small thing I would have liked to see represented is how the balls will "escape" from the squares they land in and roll back to the start. That would make your gravity-return system clearer.
One minor point: this is not a criticism because I know that MIT probably provided you with the board, but it's a bit of overkill to use a Mega for this project. You could save $30 and use a Trinket instead.
Most of the aspect of the model are effectively, well-executed however, the internal workings of the switch are not clearly described in the model. Not sure what type of relay is being implemented to activate the switch since and its circuit integration is not present in the last image of the arduino and breadboard. For the working model, I believe its essential to have well described the switch mechanism in order to be implementable and reproducible.
The model you've built seems like it's at the appropriate fidelity for the sketch model phase of developing the 5-wits room, but I think it does leave some open questions. For example, how do the balls actually travel between cells to get to the return point? Do force sensors actually work best, or should optical sensors be considered? Regardless, it seems like this model has given you some sense of the feasibility of the design.
My question about this setup is what you envision it looking like over a much larger board. Will this setup be elevated, so there is a gap underneath the game where all the balls can slide into to be returned? Specifically, would every four squares have a slot that the ball drops from into a lower section to be returned, or would the entire game panel be tilted somehow?
