Episode 607 Reboot request

You may need to start by sharing some pictures of the version of the game that you are after creating, as they vary quite a bit.

Over here in my youth it was known as the 'Donkey Derby' but that I believe that was a copy of George Valentine Tonner's 'Kentucky Derby' game. Some had animatronic horses on a Scalextric type track whereas some were pulled along by ropes wrapped around pulleys more like Lorrainbow's design. Some were controlled by rolling balls into pockets, and others by tapping switches alternately. Horses have been replaced by camels and rabbits as well.

I recall that some were based on linear tracks like Lorrainbow's Strava version whereas some were based on oval tracks.

Size varied a lot as well from the large arcade versions like this Blackpool Pier Entertainment - Donkey Derby to small table top toys like this Desktop Horse Racing Derby .

The ball-rolling ones tended to be at the larger end of to scale so not clear as to how large a build your were thinking of ?

I think you are going to be around 2' shoulder width, then you need extra for the elbow movement when picking and rolling the balls.

One way to maximize space may be to make it dodecagonal as that way it's wider at the player end of the slope and then you have a triangle toward the top of the slope for the pockets. 

You could also use a circular track which means the horses never have to rewind to reset the game as the finish line and the start line are now one in the same.

If you keep the design modular, then you can reuse the ball roll part of it as an input for different games. Twelve of these connected up to your HO slot car track and you then have a Kentucky Derby game.

The beam break sensor only has a single 'switch' per hole. The other half of the pair is the light source that creates the beam to be broken. Some sensors have both parts in the same device but it then needs a reflector at the far end rather than a light source. Depending on the target, you may be able to reflect off it instead. Retroreflective sensors are often used as they send the beam back in the direction it originated from and you get a predictable level of light to sense.

If you want to do it off a single sensor, then you would need one that can give you a measurement back. A time of flight sensor could do that assuming you only have one ball in play on the table at a time. It will give you a distance to target so your code could be set up to detect measurements falling between pairs of values to associate with which hole the ball fell through. Ultrasound distance sensors may be another option and can be used in a similar way. Be sure to check their recommended range of operation.

With either of these approaches, you may need to do some experimentation to make sure that you get reliable results before doing your final design. Also perhaps be aware that some of these sensors may give back an analogue voltage proportional to distance and some may work on a trigger and pulse arrangements whereas other may give you an actual distance value rather than a simple switch output, so may depend on your programming ability.  

The single sensor per hole approach may make your life easier even if it does mean additional wiring. 

Some people use lever microswitches but remember that the ball may bounce around a bit and trigger the switch multiple times as it passes, so your de-bounce logic needs to accommodate for that. Two balls could in theory pass through the one hole back-to-back so you need to try differentiate that from a bounce.

If you are making the scoreboard digits from pixel strips, then you may want to take a quick look at this Ninja Timer video from John Park first, as he has a rather nice demo of how to get the diffusion just right to avoid pixel hotspots.

It can be tricky to get it to look good as shown here: testing different diffusers and even more so if you are wanting to use it where daylight may be a factor.

I'm going to reply to both.  I'll have to read up on the break beams. Only one ball would be in play.

Maybe having chutes at the low end with beam sensors would work best. 3 on one chute,  1 on one, and 2 on a third.

The ball has to roll past them to go in the hole. Roll the ball down with dowels for it to bump against,  then the ball returns underneath.

I think I'll use the eight digit counters for scoring but I'll definitely check the video out, if just to learn from.  Thanks my friend. 

Mikeatencio said:

I'll have to read up on the break beams.

Diffused, through-beam and retroreflective sensors - what's the difference?

Mikeatencio said:

Roll the ball down with dowels for it to bump against

This is where you can add your own twist to the game play by borrowing features from other ball based games as well as introducing your own. If you stick a sensor on the dowel then it can trigger a sound effect or a light animation or affect the scoring anytime it gets bumped.

You may need to consider chance vs skill to keep people entertained with the game play. Also options to make it enjoyable by both young and old.

I was going to make colorful speed bumps instead of dowels.  Easy to light up.

If you are going for lots of discrete switches and LEDs, then you may want something like the Arduino Mega2560 which has quite a lot of GPIO connectivity.

I have an an ESP32 I was going to use.

Well that was a quick and easy decision...

You can get GPIO expanders if you run out or you can just add another microcontroller, like has been done here where 200 buttons are being used:
   https://www.youtube.com/watch?v=ypBI0wJYfcQ

If you are using RGB pixel LEDs then that can greatly reduce the pin count.

Some sensors are available with I2C interfaces, however some have fixed addresses which may require extra work.

Well that was a quick and easy decision...

You can get GPIO expanders if you run out or you can just add another microcontroller, like has been done here where 200 buttons are being used:
   https://www.youtube.com/watch?v=ypBI0wJYfcQ

If you are using RGB pixel LEDs then that can greatly reduce the pin count.

Some sensors are available with I2C interfaces, however some have fixed addresses which may require extra work.