Definitely watching this thread.

It'd be great to have the CAD designs, components list, and software all open source (maybe a GitHub repository?) so that anyone that wanted to make one could get past those bigger hurdles quickly and then spend the majority of their effort on their custom theming and special game rules.

From the other thread, my idea was to make an X-Men themed ICB:

I was thinking the outlines of the holes could be illuminated as rings rather than a bulb in the back of the hole. On the Taito machine, the holes, especially Hole 1 is kind of hard to see lit up because the bulb is behind the hole and far enough back to allow the ball to pass between it and the playfield. It's a little confusing for new, tall players at first because they have no idea what their goal is supposed to be.

I'd like to see every hole, not just the targets, lightable as rings with RGB LEDs. That would give you the opportunity to do things like animate a path across the playfield to the next goal, for instance. With my X-Men example, you could easily make Wolverine claw slices across the playfield, or draw an X across the whole thing, etc.

The way it could be done is to press the LED against a ring (tube, really) made of thick white, slightly translucent plastic. The plastic ring would act as a diffuser to spread the LED light throughout itself.

Would certainly look cool, but there are a couple issues. The first is that the parallax between the playfield and the LCD would probably be so great that players wouldn't be able to tell the difference between a random hole and the goal hole. The second issue is related to the way the Taito cabinet senses successful scores and how it routes the ball back to the bottom. I'll post some photos later, but to do a translucent back would require some mechanical redesign of all of this akin to what Le Chuck did for Space Base.

You can find the operator's manual on KLOV: http://www.arcade-museum.com/game_detail.php?game_id=10592

I've attached the important diagrams regarding the mechanics of the ball system below.

Here's the description of the Theory of Operation. I imagine this will be a helpful guideline when programming, especially for those that have never played the real unit, or don't have ready access to one.

The game objective is to move the ball up the playfield using the motorized bar and roll it into the illuminated target hole. There are ten numbered target holes amongst many trap holes. The target is advanced as the player successfully reaches the illuminated hole. The star on the score board is illuminated when the player finishes the tenth hole.

The start button flashes after the game is coined. When the START button is pushed the bar descends, opening the gate, and releasing the ball. The bar then rises to the "Start" position on the playfield. During this time the joysticks are disabled.

The bonus for the target appears on the scoreboard. The bonus begins decrementing when a joystick is moved or after 10 seconds if no action is taken. A "heart beat" sound is heard during countdown followed by a "straight-line" sound if the bonus reaches the minimum. When the target is reached the remaining bonus points are added to the player's score. The countdown rate is adjustable via the dip switch.

Should the joysticks be inactive for a while the bar will automatically begin stepping upward. The stepping rate is adjustable via the dip switch.

After playing through the first frame (all 10 target holes) the scoreboard start is lit and play continues at HOLE 1. Game difficulty is increased by shortening the time from the last joystick command and the onset of automatic bar stepping. The difficulty increases with each frame.

If the ball is not at the gate (BALL GATE SWITCH open) when the game starts the search program will be initiated. The bar will sweep the playfield and the ERRANT BALL SOLENOID will be pulsed. The search ends when the ball closes the ball gate switch. The search program will terminate and the "OUT OF ORDER" message will be issued if the ball is not found.

When the ball falls below the bar (usually by bouncing out of a trap hole on its way down) it is funneled to a hole at the bottom of the playfield. Upon entering the hole the ball activates the ERRANT BALL SWITCH and comes to rest over the ERRANT BALL SOLENOID. The solenoid then kicks the ball up to the gate closing the BALL GATE SWITCH.

Each target hole is monitored by a switch. These switches are part of a scanned switch matrix including the tilt/slam, coin, start, ball gate, errant ball, ticket vend, hopper cycle, hopper empty, and free play switches. Each switch must be closed for at least 20ms to be recognized. When a switch is replaced it must be adjusted to meet this requirement.

Manual-Playfield-Front_(resized).jpg

Manual-Playfield-Back_(resized).jpg

Manual-Playfield-Pulleys_(resized).jpg

You can't really make it out in the operators manual diagrams, but behind the playfield is a large, vacuum-formed single piece of plastic that routes the ball from a hole to the bottom, serves at the mount points for the bulbs and switches to detect valid holes, and pathway at the bottom for a vertical upkick from the errant ball hole to the return gate.

Without changing the existing design, this is what would prevent the ability to use an LCD panel behind the playfield. Le Chuck obviated the need for this complex routing system in Space Base by embedding magnetic sensors into the playfield wood: http://vid479.photobucket.com/albums/rr155/vonjett/Space%20Base/MagSwitchTest_zps0e87d90c.mp4

s-l1600_(resized).jpg

That sounds really promising. Is that intended to be a one-off project or a sellable product? Could you give us some guidance on how you've achieved the telescoping rod?

This doesn't require a new gameplay mode, rather serves as a supplement to the existing one, but what I think would keep the challenge alive for as long as possible is a timed tracker for each hole. When you own ICB, it doesn't take too long before you "master" the game in that you can put the ball into any hole you want. I usually beat the game whenever I play it, but with its simple programming, the Taito cabinet doesn't recognize skillful playing beyond a bigger bonus when you put the ball into the right hole really quickly. For the first three holes, I can sink the ball before the round beginning music stops playing.

It would be great for the game to not only acknowledge skillful playing, but to keep track of it, so people can be competitive on multiple dimensions of the game. Maybe "ACE" is the only one at the party that has sunk the ball into Hole 10, but "KEV" has the undefeated lowest time getting the ball into Hole 7. Now, instead of only one person having a recognized accomplishment to beat, at least two people do.

The pressure to speed run provides an incentive to take risks that's not there in the normal game. Like I said, you can quickly "master" the game in that you can beat it, but there's no good reason to not take your time. The bonus is generous enough that you're still going to reach 4,000 points after Hole 9 to gain an extra ball. Time tracking would compel more advanced players to make dangerous moves like driving the ball vertically through the lower holes on Hole 10 rather than carefully and slowly attacking it from the left or right side. That keeps the game as an adrenaline rush rather than something you can get comfortable with.

For some additional reference, I've taken photos of my cabinet. This set is for the control panel.

1_(resized).jpg
2_(resized).jpg

The control panel is held on with clamps on the left and right undersides, like some video arcade cabinets.

3_(resized).jpg

The joysticks use two leaf switches each and their restrictor gate only allows vertical movement.

4_(resized).jpg

The glass is slotted in place, and lifts out from the bottom.

5_(resized).jpg

6_(resized).jpg

As you can see on the exposed playfield, there are guide rods on both sides for the bar mechanism to ride.

7_(resized).jpg

Below the bar is the release mechanism for the ball. It has an arm sticking out of it (I'm pressing it down in the second photo) that is moved by the bar as it lowers to the bottom, the ball behind the mechanism is compelled to roll forward because of gravity, so when the bar moves to the bottom it automatically loads itself for the next round. There is a hole at the very bottom of the playfield, this is to capture the ball if it happens to fall below the bar. Sometimes a ball will go into a hole and then fall out of the front of a lower hole.

8_(resized).jpg

Next is a close-up of the piece connecting the bar to the pulley system. The attachment piece is hinged to allow it to rotate as necessary. The post on the bar prevents the ball from rolling off the side of the bar. It's positioned just so, so that you will always be able to see the ball without it getting blocked by the screened graphic on the playfield glass.

Here is the back of the cabinet.

9_(resized).jpg

This is the vacuum formed back piece with everything connected.

10_(resized).jpg

The hole lightbulbs and the hole sensors (switches) are mounted directly to the plastic.

11_(resized).jpg

This is the "errant ball" recovery pathway. When the ball falls below the bar and goes into the hole at the very bottom of the playfield, a vertical upkick solenoid will launch the ball up the loop so that the ball returns to the release mechanism above.

12_(resized).jpg

Here is a close-up of the motor, gear assembly, and bottom of one of the pulleys. I don't know anything about mechanical engineering or associated costs, but I think it would be beneficial to us if we could eliminate the use of the gears and attach our motors or servos (or steppers?) directly to the pulleys. The gears would be difficult to accurately fabricate (likely couldn't 3D print) if there isn't an off-the-shelf solution for them, and they are noisy. Not quite as bad as the clock in TZ, but still noticeable if you're not in a loud room.

13_(resized).jpg

At the top and bottom of each pulley is a limit switch. When the carriage attached to the bar rides the pulley to the top or bottom, it will hit one of these switches, letting the game know not to attempt traveling any farther in that direction.

Definitely. The more off-the-shelf, the better for everyone.

As a side note, the ICE version of ICB plays a lot smoother than the Taito version. You can tell they went without a gear assembly on the unit.

I found the manual to the ICE version here: http://forums.arcade-museum.com/showthread.php?t=332822

You can see that ICE managed to simplify the system significantly:

ice1_(resized).jpg
ice2_(resized).jpg
ice3_(resized).jpg
ice4_(resized).jpg

Edit: Todd Tuckey shows the inside of the ICE version of the cabinet in this video:

Perhaps switches on every hole is overkill. A handful to a dozen additional switches could be added to a number of the other holes, and that could be enough to give the player the impression that literally any hole could be a goal if the game wanted it to be. An I-PAC from Ultimarc would have between 32 and 56 inputs available, depending on which model you chose. 10 of those inputs would be needed for joysticks, start button, limit switches, and errant ball recovery, but the rest are free for holes.
https://www.ultimarc.com/ipac.html

I would still want to put an RGB LED at every hole in my game. I don't think this should be too great of a problem for a Raspberry Pi or the like. Rather than wiring each LED back to the Pi, you could use individually addressable string LED lights like this:

HTB1lvDxJXXXXXXpXFXXq6xXFXXXH_(resized).jpg

Each string has 50 RGB LEDs, so you would only need two bundles to light every hole. That's not saying anything about the power requirements though. I don't know anything about that.

That's a great idea. It's a little disorienting in ICB to try to lower the ball safely after going too high with it. It would be interesting to make that kind of maneuvering a regular part of the game.

I may not have clearly explained what I meant. I meant to say that you use 10 inputs for joysticks, start button, limit switches, and errant ball recovery, then 10 more inputs for sensors for standard holes 1-10, then whatever inputs are left over go only to specific other holes outside of standard holes 1-10. If hole X is lit for the goal, there is no situation where getting the ball in hole Y will ever count as a false positive for hole X. Hole X's sensor only counts for hole X. And hole Y will never be lit as the goal, but the typical player won't know that it won't ever be.

I agree. I've done a little Python scripting in the past, and I'd like to take advantage of Raspberry Pi's power for audio, potentially video, etc. and easy updating.

I think the alternative is to let the player do the work for you. The game could have a general idea of how high the bar is up the playfield by keeping track of the number of milliseconds up commands have been sent to each motor (and subtracting for downward movement, obviously) and averaging between the left and right sides.

When the player gets the ball up the playfield a certain amount, say 60%, trigger the special mode where they need to go down in the time limit for a bonus, or extra ball, or whatever. It would be more of a surprise that way, which can be good or bad depending on your taste.

Earlier today, Riptor in another thread linked to brand new, redesigned motors for ICB with enclosed gear assemblies that supposedly run quieter:

That sounds great. Any idea yet on price range for one of these units?

Did you have to fabricate the two rods yourself for your games or were you able to make use of off-the-shelf components to assemble the telescoping rod? OLDPINGUY mentioned potentially using brass rods sold at hobby stores of slightly different diameters. Is this the method you used or were you able to find a different source?

I created an account on BYOAC and posted in the Space Base thread asking for guidance from Le Chuck and his partners. Let's hope they see it and provide their help. http://forum.arcadecontrols.com/index.php/topic,140466.msg1581811.html#msg1581811

I looked around a little bit for resources for steppers with Raspberry Pi.

I found this hat (like an Arduino shield): https://www.adafruit.com/products/2348

2348-02_(resized).jpg

Luckily, it can control two stepper motors by itself, and it has all the needed protection and stepper management circuitry built-in. There is also a Python library to simplify interacting with the steppers. According to the video, you can basically just tell it which direction to spin and at what speed. Sounds easy enough. It is designed to be stackable, so you can add another hat on top of it. That will be necessary for the errant ball solenoid. I don't know yet how to drive that. The steppers will require some external power, since the Raspberry Pi cannot provide enough on its own.

Tutorials for everything: how to assemble, wire it up, add external power, and program for it are available here: https://learn.adafruit.com/adafruit-dc-and-stepper-motor-hat-for-raspberry-pi

It's compatible with these steppers: https://www.adafruit.com/products/324

324-03_(resized).jpg

I'd have to assume these are strong enough to move our ICB bar, since these exact steppers are used in CNC machines like the X-Carve.

Adafruit also sells handy mounting brackets for these steppers.
https://www.adafruit.com/products/1297

1297-00_(resized).jpg

One less piece to have to figure out how to fabricate, thanks to off-the-shelf components.

Promising update from Le Chuck!

Hey everyone, I'm glad to see this still has some interest. It certainly isn't dead but it has been moving slowly for the last year or so. A lot of life changes for several team members that had to be sorted out before work could resume, myself included!

All that said, I will be getting back into this shortly. I'll be fabbing up a second playfield (the first is with IDS) and I'll do a step by step build up on that. I can't put a deadline on anything past that but I'll be starting the playfield in August as soon as I finish the panel I'm building for my boys.

Once complete everything will go open source, the reason we aren't do releases as we go is because things are still in flux and I personally don't want to put out bad poop, have someone spend money, get ahead of me only to find out it doesn't work as advertised. Plans, parts lists, music, code, the works.

As it stands now the only truly custom fabricated bits are on the ball the return (which is simple) and the circuit boards (which is supposedly simple for those in the know but might as well be rocket surgery for me). Everything else is off-the-shelf modded or tooled.

Regular updates to recommence soon. Thanks!

TL;DR: They were able to build nearly everything out of off-the-shelf components, and he will start a step-by-step build detailing the entire process in August.

Definitely keep an eye on the BYOAC thread.
http://forum.arcadecontrols.com/index.php/topic,140466.0

Sounds like a good solution. Hopefully we can source a rod that is the proper length and won't require any cutting.

I'm not at home at the moment, so I can't check. I also don't have calipers so I'd have to eyeball with a measuring tape. Also, I don't know anything about metals; I don't have a clue what it's made of. Can anyone else that owns ICB chime in?

I like the idea of making the bar out of another material than metal. Colored (or white) bars open up possibilities for blacklight illumination, or simply just better integration with the builder's theme of choice.

I think we need to figure out a good solution for sensing the balls passing through the holes. Taito used switches, Le Chuck uses magnetic sensors, and I can't tell what ICE is doing. I would like to avoid magnetic detection, if possible. If you look at my Taito cabinet photos on the first page of this thread, you'll see pock marks in the playfield glass at the holes where the ball has dinged into the glass over the years. I'd like for it to be possible to opt for a ball of different material, maybe just a marble if the builder wanted. Also would provide options for theme customization.

According to Phoenix Arcade, the ICB playfield glass is 33.75"x23.5".
http://www.phoenixarcade.com/art.htm#ICE_COLD_BEER_

I think we could design our own restrictor plate for standard-shaped arcade joysticks in CAD, then either 3D print ourselves or post on a site like Shapeways to let anyone order a print.

Yeah, I understood, but I think the movement definitely needs to be restricted to up and down, despite whatever input capability. Looks like there are readily available 2-way restrictor plates for Japanese joysticks. There's probably something similar for HAPP/EL as well: https://www.focusattack.com/sanwa-gt-2f-2-way-restrictor-plate/

I worry that the programming complexity and especially the added cost of analog joysticks may outweigh their benefits in the end. You already get a surprising amount of refined control and smoothness even on the Taito cabinet with digital joysticks, and even more so on the ICE cab with the motors connected directly to the pulleys.

Due to the nature of controlling a ball on an inclined plane, there's a bit of "lag" and a gradient of speed as gravity pulls the ball at an increasingly faster speed toward the earth. That alone already gives you subtle speed control over the ball; the nature of needing to make more dramatic movements on the edges of the bar to influence the movement in the middle.

That's a good point. I suppose some sort of acceleration could be programmed into the game, and your game mode idea sounds like it could be an interesting dynamic: to switch it to a more extreme movement speed, or alternating one side stronger than the other, etc.

Yeah, wood surrounding the already obscured parts will be necessary considering the thinner glass. The issue becomes the maximum length the bar is able to extend needs to be greater than the hypotenuse of a triangle made from the bar being at its lowest possible point on one side and the highest possible point on the other. If the bar is less, its two parts will just unsheathe themselves and the bar will fall apart. So the taller the playfield becomes, the wider the wood siding and obscured parts become.

That's a good price, but I'd recommend short shafts so the ball top won't have to travel as far, which will feel more responsive. To change that one to 2-way, unscrew the green restrictor plate from the joystick, move it to the right, then screw it back in.

I can't speak for winteriscoming, but I know very little about electronics and motor systems. I assumed you could PWM a motor to reduce the speed, but I worried that would kill the torque, and I wanted to avoid a complicated and noisy gear situation, like the Taito cabinet. The stepper solution is relatively inexpensive, videos have shown they move how I want, the brackets we found make them easy to mount, and the Python library with included documentation and example code appear to make it as simple to control as a regular motor. That's been my logic on steppers so far.

This thread is meant to be a call to the community for ideas on how to accomplish a DIY ICB; we aren't saying that these ideas we're putting forward are the One True Way, we're just throwing them out there to see what seems reasonable and what doesn't, as demonstrated in how we already killed the analog joystick idea through discussion.

This looks really promising. Is there any info on when they will be available outside of the Kickstarter, and a timeline for documentation for us newbies? I love the price, but this seems a little too advanced for me to not have any examples or documentation to work from.

That sounds like a good plan. I was thinking the tubes could be 3D printed, and aside from serving as the lit ring, they could have mount points to hold the RGB LED and opto sensors in place. Just print, cover the sides with glue, and push through a hole until flush with the front, then clip in the LED and sensor.

Consider that we're not building turnkey kits for people here. These things need to be as straightforward as possible, not just for us design and program, which is also important, but for other people to source the same parts we used and build.

Like has been said earlier, the steppers are a known entity for winteriscoming, seem reasonable to operate for a newbie like me, and are easily mountable in the threaded rod system that we're planning to build.

I need a computer in my project because I want to make it more of a multimedia experience than the original ICB. I want RGB LED light shows, sound effects, custom game modes, and a display of some sort. It makes sense for us to build this with a computer base so that people that just want the vanilla ICB experience can put it together with minimal soldering and circuit design, and then for the rest of us, to have a good base to build forward from.

Right, which isn't our audience. We want an easy to purchase and assemble system from off-the-shelf electronics, not necessarily the best system, just the one normal people will be able to put together with some amount of confidence.

Actually, you still do need a computer. The game auto increments the bar upwards when either joystick hasn't been touched after a certain amount of time. It also more aggressively increments the bar up even while you're actively playing it in the second round after beating it the first time to add to the difficulty. When the ball is lost, the bar has a routine it performs to try to help dislodge it from wherever the game can't find it (lowers all the way down, raises one side all the way up, then raises the other side until the ball hits a switch). It may do other things I can't remember at the moment.

That's true, but again, the more limiting. winteriscoming and I have been discussing other possibilities in this thread that would benefit from the computer beyond the vanilla stuff, like spontaneously alternating joystick controls or varying the movement intensity for a game mode.

The steppers are wired directly into the HAT on the Raspberry Pi anyway. This is the simplest way for everything to be connected for us and any other inexperienced person trying to assemble their own. We don't need to worry about blowing circuits with reverse current or H-bridges or anything else. It's just plugin and go.

I have to admit, this is a lot more sturdy of a solution than I was expecting. I assumed for the left and right sides of the cabinet, there would just be a stationary guide rod on the front side of the playfield running parallel to the threaded rod on the back side, and the carriage would have the threaded rod running through the ball screw actuator on the back of it and the guide rod running through a hole toward the front of it. Sort of like the existing system in the Taito cabinet, as in it would keep the guide rod as is, just replacing the pulley system with the threaded rod.

I've been trying to figure out how to accomplish the hole sensors in a reasonably inexpensive way that may be compact enough to allow builders to throw sensors on as many holes as possible. So far, I'm thinking the answer is the IR emitter and detector route. IR is necessary because RGB LEDs at each hole will likely put out a lot of light that would interfere with a standard photodetector.

The most compact pair I've found on a hobby site meant for through-hole mounting is this one:
https://www.sparkfun.com/products/241

00241-02_(resized).jpg

The next problem: what to mount them to. You could have custom PCBs made, but that's pretty expensive, and since I'm not an EE, I wouldn't feel confident designing a circuit to send out to a board house to fabricate. You could etch boards yourself or CNC engrave them, but that's also a huge process. My next thought was to solder everything to perfboard and then cut it to the desired shape. A quick Google search shows that because it's made of fiberglass, that's a messy and difficult process as well. Luckily, Adafruit sells perfboard made out of Bakelite that you can cut with scissors, and they are super cheap:
https://www.adafruit.com/product/2670

bakeliteperf_(resized).jpg

I haven't done any measuring of the holes in ICB yet, but it seems like each of these boards could turn into 2-4 hole boards. I am imagining using an X-acto knife to cut a hole through the center to allow the ball to pass through, like this:

perfhole_(resized).png

I'm looking forward to hearing about the results of the proof of concept. The thing that I'm wondering about is cutting these t-slots, should that be necessary. Are they cuttable without too much warping?

Yeah, I was thinking perhaps if the LED light rings are 3D printed, they could have a hood on the back to protect the components from above and help prevent balls falling back out the front of a different hole than they entered (happens sometimes).

Yeah, when ready to order, I'd buy in bulk from Mouser, Digikey, etc. if the price difference is significant. I'm focused on trying to find things available on Adafruit and Sparkfun for that clear documentation and example code.

I have no idea. If hole boards are the way we go, I'm going to buy Adafruit's because they explicitly advertise being scissor cuttable, whereas most perfboards are pretty difficult to cut. The Adafruit ones are $5 for ten 2.8" x 3.6" boards. If you can get 4 hole boards out of a sheet, a $5 pack would net you 40 hole boards.

Micro switches are the natural answer. Taito used them on the original machine. Our problem is that we're over-complicating our goal by trying to make it possible to have a switch on as many (every?) holes as we can fit, haha. I had the same line of thought before I grew too ambitious: I-PAC and microswitches would be trivial to interface with the Raspberry Pi. Hole switches would just be keyboard presses. You could even test the game outside of the cabinet using a real keyboard. And like you say, there's plenty of leftover inputs on an I-PAC to add way more holes than the original game offered.

Perhaps we should just scale back...

I don't know that we would be able to make an ICB style game with swappable playfields if it has multiple target holes, if you consider the ultimate weight of the "playfield cartridge" with a backbox behind the playfield to protect the electronics inside.

However, it would be possible for us to design a new game that is literally just a board that can be swapped in and out. If we only need to worry about one hole for the finish, then we only need one other switch, for the failure at the bottom. Segregate the middle from the goal hole at the top and the ball loader and errant ball recovery at the bottom, and the middle doesn't need to have any electronics in it. You can make a new obstacle course just by drilling some holes in the right size sheet of wood, or lightweight plastic, or whatever.

Forgive my uninspired designs, but here's a quick example. First, the cabinet loaded with an extreme ICB style field of holes.

1_(resized).png

Then unload the ICB board (ignore that the ball bar is missing, I should have had it lowered to the bottom of the playfield).

2_(resized).png

Then grab your new labyrinth style board.

3_(resized).png

Slide it in and start playing.

4_(resized).png

If you'd rather just have a labyrinth style game, forgo the swappable fields and then you can do really dynamic things like have rotating "platforms" (edit: rotating walls, I suppose) that you have to carefully guide the ball on top of from one to the next.

The pulley system is fine by me. It seems to work reliably well, seems like it'd be cheap to replicate, and hasn't failed on my machine for as long as I've had it.

For reference, here's the Real Bob Roberts' fix for belt replacement in Ice Cold Beer:
http://arcadecontrols.com/BBBB/coldbeer.html

And here's Todd Tuckey replacing the belt in a cabinet (about 2min in):

Any concern about back-EMF or anything like that? That was one of the benefits of the stepper HAT from Adafruit, that it had built-in protection.

Something I wasn't aware of concerning stepper motors is their efficiency. I found this page on Adafruit discussing steppers https://learn.adafruit.com/all-about-stepper-motors and they say:

"Low Efficiency – Unlike DC motors, stepper motor current consumption is independent of load. They draw the most current when they are doing no work at all. Because of this, they tend to run hot."

If we get these things built, there are situations where I'd want to be able to have it running all day long, maybe without people playing it for hours at a time as they play other games. But if the steppers get hotter in inactivity, that's a concern for me. Servos might be better for us just to limit our risk of building a fire hazard.

I'll take a look when I get home. I won't be able to get a precise measurement on the rods because all I have at hand is a ruler.

Verifying Fortytwo's statement. I just checked my machine and there's no taper. The larger of the two rods seems to be 3/8" in diameter.

The pulley wheel diameter is about 1.75". The thickness is 1cm, with an inner groove of 8mm. The center of the top pulley wheel is separated from the center of the bottom pulley wheel by 28".

The guide rail is 0.25" in diameter, and it seems to be 28" in height.

I agree. If the weight, reliability, or quality of the bearings become an issue, I recommend we go with the hole in the block method. I think the piece that connects the pulley to the telecoping rod should be 3D printed, whether in full or with screw points for these cheap bearings winteriscoming has found.

I did a little searching around for a good light solution a few days ago, and what I've been thinking is using FadeCandy from Adafruit to control the lights:
https://www.adafruit.com/product/1689

Plugs in by USB, and it takes the 3 pin WS2812 lights from your Amazon link and any others made to that specification, including those string lights I linked earlier, and the RGB ring someone else linked. You don't need to worry about potential timing problems, because this thing can operate 8 separate strips of 64 RGB LEDs, so 512 RGB pixels. You can add more FadeCandy PCBs for even more lights, but I think 512 would already light up my entire house, haha.

BYOAC has new accounts' permissions locked down hard. I didn't have permission to private message other users, or even view their profiles. Wouldn't matter though, because he said in his response to me:

Once complete everything will go open source, the reason we aren't do releases as we go is because things are still in flux and I personally don't want to put out bad poop, have someone spend money, get ahead of me only to find out it doesn't work as advertised. Plans, parts lists, music, code, the works.

So we're not going to get that specific information from him until the new machine is done.

A grid of detectors and emitters has been suggested a few times, but I don't think it's viable. The problem is that your emitters need to have laser-like accuracy because their beams need to travel a relatively long distance, at least 20" in each dimension, and they will probably have to be spaced out 1" or less from each other because of how clustered some of the holes are.

That's a good point that I don't know that we considered yet (I didn't), but we've already decided to go back to the pulley method.

Already decided on digital joysticks.

Yeah, you're going to miss some stuff that way and maybe give outdated advice.

This is true. I think the original cabinet is built out of particle board.

Yeah, that's in the plans.

I've only had a cursory look at FadeCandy, so I can't speak with any sort of authority on its merits over anything else. I don't know that it's necessarily the best option available, but I do think we need some sort of interface board like this with a supporting Python library for light management vs. wiring LEDs directly into the RPi. Maybe not necessary for vanilla ICB builds with only 10 holes to light in a single color, but games like ours that would light every hole in RGB are probably going to need it, especially for complex light shows. ICB has 83 holes; FadeCandy could easily support an RGB LED on all of them.

FadeCandy simplifies the process of interacting with a large number of RGB LEDs. It also has some integrated processing features that automatically enhance the colors (temporal dithering for color correction and depth) and it has a lot of code examples for how to operate it. FadeCandy is also compatible with the Mission Pinball Framework, in case we decide we are going to program our game using that system (if it can support that).

I haven't started thinking about displays much yet. I was almost thinking maybe we should start the vanilla code with a segmented LED display, but realized that would probably be more expensive than using one of these touch screens and just emulating the look of segmented LEDs. I wouldn't worry if the screen has touch interface built-in, we simply won't connect it and pretend the functionality is not there. I was thinking for my game that I would use an automobile rearview mirror with an ultra widescreen LCD built-in, which would be closer to the ratio of a pinball DMD.

I'm in the process of mapping out the coordinates of the holes on my cabinet, but they are all one of three sizes: target holes have diameters of 3/4", the rest of the holes have diameters of either 1" or 1 1/8". These measurements would be the inner diameters of the tubes we buy so that we don't change the gameplay.

I'd recommend connecting by HDMI. It will be a little more expensive for the monitor, but I think to connect composite on RPi requires a separate dongle, so that narrows the price difference a little bit. Aside from that HDMI is going to allow using the maximum clarity and full resolution of the LCD panel.

I think the IR detectors' output is analog. I don't think we'd be able to connect them to an I-PAC.

This IR detector is digital, unlike the Sparkfun model. https://www.adafruit.com/products/2167

Yeah, fancy animations and stuff is why. I already own an Ice Cold Beer, so just a replication of the existing game is of little interest to me. I want light shows and sound effects and video screens, and Arduino won't cut it for all that. RPi might be overkill for just an ICB replica, but the base code being written for that rather than Arduino means that winteriscoming and I won't have to rewrite everything again for RPi when we go to build our custom features. Might as well start with what we already know we're going to use.

For the I-PAC, will transistors be necessary? Forgive my electronics naivety, but I figured you could plug the IR sensor's data pin into one of the I-PAC's inputs and then connect the sensor's power pin to an external 5V power source, then share the ground with the I-PAC, and it would just work without any other components (maybe a resistor).

Edit: Based on this example, it looks like my thought process wouldn't work. Bummer. https://learn.adafruit.com/ir-breakbeam-sensors

Second edit: Haha, okay I understand now. The IR sensor IS a transistor itself. I suppose for I-PAC, we would need it to operate the opposite of a microswitch. When IR is detected, the circuit should be open. When the IR is not detected, the the circuit should be closed.

I can't make an assumption on the I-PAC, but there is a shared ground for all the pushbuttons. I assume the answer could be found with a multimeter? One probe on ground, the other on an input pin. If there is current, then it is normally LOW and when the button is pressed it becomes HIGH; if there is no current, then it is normally HIGH and when the button is pressed it becomes LOW. Is this correct? I have an I-PAC, and I believe I have a multimeter somewhere that I can dig up.

That's a great point.

That's a clever solution. I was trying to figure out this transistor nonsense to make an inverted circuit so the IR detectors could interface with I-PAC so that we could maintain a simple keyboard link to RPi, when the real solution is using a Teensy to emulate the keyboard directly, bypassing the need for the I-PAC and more complicated wiring at each hole. I'm going to get a Teensy++, which like you said, is cheaper than the I-PAC.

Here are some additional ideas for custom game themes:

Pinball games: My original idea before X-Men was to make an ICB that is Bally Addams Family themed. Addams Family has lots of great Gomez callouts and pinball related DMD animations that could easily be repurposed for ICB. This is true for a lot of pinball machines, and along with DMD animations and sound effects, the artwork from the cabinet and playfield could be traced, rearranged, and reprinted for for your cabinet.

Pokemon: I'm thinking instead of X-Men, I might make a Pokemon themed game. Random holes would light up on the playfield representing a Pokemon to capture ("a wild Pikachu appears!") and the difficulty of the hole and the amount of time available to sink it would scale with the level and rarity of the Pokemon. The Raspberry Pi has built-in Wi-Fi, so I would save the game data to a web server and make it persistent. So players will be able to create an account (probably just a simple number password or something of the like) and they could keep their progress and continue the next time they come to play. I was hoping there would be Pokeball marbles so I could use a Pokeball for the ball inside the game, and there's actually a huge line of Pokemon marbles, but somehow it never occurred to the creators to ever make a Pokeball marble. Oh well, I can just pick a random monster to stick in there, and settle with making some Pokeball balltops for the game's joysticks.

Haha, practically all of my friends are obsessed with PokemonGo at the moment. I somehow missed out on Pokemon over the years, and I've never actually played one of the games aside from catching Pokemon in Go for my friend while he's driving, but I understand its appeal.

Yeah, I was talking for peoples' personal game customizations, not so much the thing we're putting together. For the main project, the more generic the better, but I think for what we each do for ourselves, go wild.

Yeah, I assume as we get closer to realizing this project that we should come up with some kind of retheme for general use. A haunted house theme could be great.

This could be a great boon for us: Ben Heck has all the source code, artwork, sounds, and animations from America's Most Haunted freely available for download on his website: http://www.benheck.com/amh/

I don't know know what the license is for these assets, but if it is open source or permissible, that could save us a lot of effort. Already filled with funny campy humor!

Indeed. This is the same Python library I've been looking at. This is a good overview tutorial series I went through to understand the gist of it:
http://www.nerdparadise.com/tech/python/pygame/basics/

I created a GitHub group to host our code and other media as we create them. It is simply called 'welovepinball'. Lemme know your GitHub account names and I'll add them to the group. This is only necessary if you're intending on contributing code; you can browse and download the code without an account.

I've committed an initial bit of code to the group as well:
https://github.com/welovepinball/ball-balance

Please forgive me if it sucks. I'm relatively new to Python, and I'm not a programmer anyway.

This is just some very basic, foundational level code at this point. My intent is on building a modular system with a game mode focus and configurability.

There are three modes in this first commit: Attract mode, Game mode, and Game Over mode. Attract and Game Over are just proofs of concept of switching modes; they only show a blank screen with a different background color. Press Enter to switch modes.

The Game mode has a little bit of interactivity. You can simulate the use of the joysticks and limit switches. Pressing "W" and "S" will control the left side bar carriage, and the Up and Down arrows will control the right side bar carriage.

arm1_(resized).png

The left side limit switches can be activated with the "[" (left bracket) and ";" (semicolon) keys, and the right side switches can be activated with the "]" (right bracket) and "'" (apostrophe) keys. Activating a limit switch will prevent the carriage from moving in that direction on that side, and it will also change the color of the carriage to orange to indicate that something happened.

arm2_(resized).png

The keys I chose for switches and joysticks are configurable in the config.py file. I've also included some other keys that haven't been implemented yet, including the start button, tilt switch, and hole switches.

I haven't integrated any of the FadeCandy light stuff in the code yet, but I've been playing with OPC, which is an LED simulator for your computer that interacts the same way the FadeCandy will, and I've been running the Python demos through it. It has me excited for the possibilities.

I made a grid of the ICB target hole pattern and dropped it into OPC. It looks good! Especially with the raver_plaid.py demo. Obviously the screenshot doesn't show it, but the LEDs transition through different colors and sometimes fade to black in a cascading pattern.

opc_(resized).png

To get this hole pattern in your OPC, copy the text below into a new file in OPC's layouts folder, I named mine icb.json, and then load it into OPC following the directions in its install steps:


[
{"point": [0.0, 0.0, -2.0]},
{"point": [-1.57, 0.0, -1.8]},
{"point": [1.56, 0.0, -1.35]},
{"point": [-0.78, 0.0, -0.86]},
{"point": [0.63, 0.0, -0.03]},
{"point": [-1.46, 0.0, 0.80]},
{"point": [-0.13, 0.0, 1.21]},
{"point": [1.34, 0.0, 1.68]},
{"point": [-0.88, 0.0, 2.28]},
{"point": [0.44, 0.0, 2.66]}
]


After I get the holes mapped out in my cabinet, I plan on making a new version of this so we can see some really nice light shows.

Just pushed another code commit. No functionality change, I just added a bunch of comments for how the whole thing works so that it's easier for an inexperienced programmer to jump in.

In case you'd still like analog joysticks for your custom game, I see that Adafruit just added one that looks like it would be decent with our new Teensy keyboard setup: https://www.adafruit.com/products/3102

3102-01_(resized).jpg

Restricting to vertical moment seems like it'd be easy with this joystick. Either cut a slit in your control panel to restrict movement from the top, or from the bottom you can pull off the bottom plate, then insert some barriers (maybe 3D print this piece if you want it fancy) to prevent side-to-side movement. Another option is to 3D print a new ring for the top to act as the restrictor plate.

They are already out of stock, but if you Google the model number "JH-D202X-R4" you'll find them available on Amazon and other places, and cheaper.

It's just a couple of potentiometers, so you could do something like map one joystick the X movements of a mouse and the other joystick to the Y and send that to the RPi, or you could send different keyboard buttons mapped to different servo speeds as the joystick moves past increasing resistance thresholds. Not sure if you can emulate a mouse and a keyboard at the same time on the same Teensy, so I'd probably do the keyboard method if I were to use these.

Whoops. Accidentally submitted instead of edited.

Nice work! I'll see if I can try to help debug it. I'm going to do a small update in a second. I'm moving the logic for the service mode button to game.py, that way we won't have to add the service menu button logic to each mode we add. My update will also have the very start of trying to add sound support. There are sound effects when you move the bar up and down. Because we don't have any open source sounds yet, I'm keeping them in a directory outside of folder captured by Git. I just wrote the logic to handle a situation where PyGame is asking for a sound file but it doesn't exist. That way the new code won't crash when you try to move the bar.

Edit: Took me a little longer than expected. When I tried to submit my changes, I accidentally blew them away locally and had to rewrite them! Still new to this Git stuff...

Looks like there might be a bug with PyGame: http://stackoverflow.com/questions/27470730/how-to-get-the-descriptive-name-of-the-key-constants-using-the-key-constant

What might be the solution instead of a menu showing the current settings is to ask the user to move the left joystick up, then set it, ask to move the left joystick down, then set it, right joystick up, set it, etc.

Well, now that I think of it, there's no pressing need to have the switch configuration embedded in the menus. It only needs to be set once and then forgotten. Anyone putting one of these cabinets together is going to have to do woodwork, RPi configuration, circuit assembly, soldering, and more, so I think they can manage to type in the switches into a config file.

Maybe that menu item should instead just show the key number of any switch that is currently active. So when the user presses up on one of the joysticks, the key number appears on the screen. Then they can copy that in their config file themselves.

We don't want to go crazy on component costs, but we want to maximize our ease of development and that comes at a price. We wouldn't have made the progress we already have if we were trying to squeeze every penny out of the build because there would have been more of a learning curve for us. I don't think we've gone too crazy yet even with pushing past $200. Like lpeters82 said, we're building a better version of a $1,500 game, and I feel pretty confident we're going to keep the final cost below that. A decent amount below that hopefully.

At this point, I think what winteriscoming's inventory is missing is: the IR detector and emitter pairs, a bunch of wire, clear tubing, a tilt plumb bob, solenoid, something to control the solenoid, 3D printed, CNC'ed, or otherwise developed carriages and ball gate plate, the telescoping rod, the playfield glass, two microswitches, a spring, a small LCD panel, speaker system, an arcade pushbutton, a service button, and the cabinet and playfield that he will CNC himself. After that is all the normal stuff that would go into the costs for a MAME cab, like graphics, T-molding, etc.

That's great! I'm surprised how small the code is for this. Pretty cool. Not that it matters much, but is there any way to set which keys each pin emulates? I'd love for the Arduino and my actual keyboard to be easily interchangeable, but for that I'd need to know which key does what. I picked the keys that I did in the Python config because they made some sort of intuitive sense to me, I'd love to be able to retain that.

I just checked the ICB manual and the solenoid part number is listed. It is Taito 23-00004-001.
http://www.marcospecialties.com/pinball-parts/N-26-1200

I can't cleanly take a single photo of the errant ball return assembly. It's actually just a path molded into the plastic backboard behind the playfield. Here are some photos.

I don't think it'd be possible to design it in a way to eliminate the errant ball return, because there's always a risk of the ball from falling below the bar.

IMG_0461_(resized).JPG

IMG_0463_(resized).JPG

I like this out of the box thinking. The ball falling to the errant ball area is rare, so if a 5V solenoid isn't strong enough to pump the ball back up, I don't want to waste electricity having an extra 12V-24V supply in the cabinet just for those emergencies. This lift seems like the right kind of alternative. Maybe we can do a little scooped conveyor belt that is attached to a motor that carries the ball up?

Edit: Here is the obvious, easiest solution to the problem.

Okay, maybe not, but it is hypnotizing to watch.

It'd be cool to figure out a dispenser mechanism, and if it could be done simply and inexpensively I'd love to do it. But you're right. These are just going to be HUO machines with the owners probably not far away in case something goes wrong. Not really much different than pinball machines in the house in that way. Can't completely avoid having to take the glass off once in a while.

Found a good ball dispensing mech:

We can make the errant ball hole just dump the balls into a tray or bucket inside the bottom of the cabinet. For the dispenser, after the game attempts a ball search and fails (telescoping rod travels from the bottom limit switches all the way to the top limit switches), the motor for the dispenser is activated. The game will know to stop spinning it when the new ball passes over a switch right at the dispenser's exit point.

The game can keep track of how many times it's had to do that, then give a warning to the operator in the service menu and on boot that the ball dispenser needs to be reloaded.

There are multiple ways. Sometimes, when the ball goes into a hole, it will bounce against the backboard and then pop back out to the front through a hole lower than the one it entered. Another way is if a ball gets lodged between the bar and the edge of a hole, sometimes it will pop below the bar. I've witnessed both of these things, and there are probably more ways.

Clever!

Oh good. I've been using Python 3 for future proofing, but I haven't set up my RPi yet and didn't know how good its compatibility is with 3. The OPC demos are written in Python 2, but they will work with a little bit of changes. Just alter the syntax or delete any line that uses print() and they will work. I believe FadeCandy has been made Python 3 compatible. Can you think of any other libraries that we are going to need for our code aside from PyGame and FadeCandy?

pygame.mouse.set_visible()
http://www.pygame.org/docs/ref/mouse.html#pygame.mouse.set_visible

The thing that stops me from using this and fullscreen yet is that fullscreen initially reacts poorly on my monitor and makes my audio cut out for a moment. Really annoying. We haven't made the real LCD output yet anyway, so I don't think it matters much.

Yeah, exactly. I think the I-PAC expects normally open switches, so we'd have to invert the signal from the IR detector in order to make it work correctly. Would have complicated the wiring. The Arduino/Teensy way is going to be much cleaner and simpler.

Sure, in game it shouldn't matter too much, but this is acting like a keyboard device. That means even when the game isn't running, all the keys paired to each input are going to be held down. That wouldn't be very helpful at all. The Arduino solution lets us control the input in a way the I-PAC will not, and it's cheaper.

I made a little drawing of the existing holder for the rod along with the carriage that attaches to the pulley and slides along the guide rail. This was from memory, so it's not to scale.

carriage_(resized).png

Edit: quick explanation of the mechanism.

The back of the carriage has a clamp to attach to the pulley cable. It is tightened into place with a screw (that I didn't draw). In the middle of the carriage are the holes for the guide pole. In the front of the carriage is an arm. Connecting to the arm with some sort of unthreaded screw is a plastic piece. The plastic piece acts as a hinge to the carriage arm. The plastic piece connects to the telescoping rod with a rivet in the back of it. The telescoping rod is stationary in relation to the plastic piece; it's not able to move or rotate at all. The plastic piece handles all of the rod's movement with the carriage.

One thing to think about still is tubing for the hole LEDs. The plan as discussed so far is to carve out the holes on the playfield a little larger than the original game so that tubing can be inserted. It will be pushed all the way in so that the front is flush with the playfield. An LED will be pressed against the tube, which should illuminate the tube, and more importantly, the front edge of the tube, creating an outline around the hole for the player. With the FadeCandy PCB and the tubing, we will be able to create all kinds of neat lightshows, similar to a pinball machine.

For reference, the diameters of the holes in ICB are:

Target holes: 3/4”
Medium holes: 1”
Large holes: 1 1/8”

In order to not change the gameplay, these dimensions will need to be the inner diameters of the tubing we select. Whatever outer diameter we choose is the size of the hole that will be drilled into the playfield.

I’m still in the process of mapping out the holes on the playfield, but I can tell you that space is going to be tight. If we were to choose tubing with 1/8” thick walls, there are holes that wouldn’t work. Everything is fine with 1/16” tubing though.

I’m thinking that because the target holes are small, the most difficult shots, and there’s space for it, we should choose tubes for those holes that are 1/8” thick, and then 1/16” thick tubes for every other hole.

If we can decide on specific extra holes that we would like to add sensors to, we could bump those ones up to 1/8” as well, assuming space accommodates it.

From my experience, tubes that are milky white in color rather than clear are significantly better for diffusing light through the tube. Clear tubing allows the light to stay too directional, so you don’t get optimal light transmission.

One product I can recommend with first hand experience is this:

SiliconeTubing34ID-2_(resized).jpg

https://www.brewhardware.com/product_p/siliconetubing34id.htm

This tubing would perfectly fit the target holes with its dimensions of 3/4" ID x 1" OD.

My friend takes his artwork to conventions and he was on a mission to find the best possible inexpensive tubing for LEDs to line his booth, and this is what he chose. This tubing is made of silicone rather than PVC.

I’ve seen the same LED strip he puts in this tubing in other clearer tubes, and if the LEDs weren’t facing forward, you couldn’t see the light at all. With this tubing, it doesn’t matter which direction the LEDs face, the entire tube is evenly illuminated. You can see this tube lit up from hundreds of feet away. Here’s a photo:
booth_(resized).jpg

For the larger sized holes, I haven’t found a good product yet. Optimally, we could find slightly white silicone tubing of these sizes:

1” ID x 1 1/8” OD
1 1/8” ID x 1 1/4” OD

Ah, good point.

Hopefully they will be sufficiently bright. If not, perhaps sanding the entire outer surface of the tube in addition to the edge will help bounce the light around it.

I'd like to not have to cut any metal at all for this project if I can help it. Do you have suggestions for 8mm guide rods that are ~28" (~700mm) long and inexpensive? I found this part made for RepRap 3D printers that looks like it might be suitable, at 800mm (~31.5"):

ebay.com link: 8mm x 800mm Precision Chromed Rod for RepRap Rostock Prusa 3D printers CNC O1
$12.99 each + shipping

I haven't measured inside the original cabinet to see if it could accommodate a bar with that extra length, this is just the first thing I've found.

I also found this:

ebay.com link: CNC Linear Rail 2 pcs 8mm 700mm Cylinder Shaft Optical Axis Smooth Rod Bar

A much better fit, and $35.50 for the pair with free shipping (from Slovenia).

Great idea with the AMH assets! I sent Ben Heck a message through Pinside days ago asking about the license on the AMH media, but I haven't heard a response yet. I'll let you know when that comes.

For the main distributable package of our game, we definitely shouldn't do something with IP that we don't have rights to, just so we don't get a C&D on our project. Simpsons Ice Cold Duff Beer sounds like a great personal retheme for anyone that wants to customize their game build though. If we were to still go with the beer theme, it would be prudent for us to create new unlicensed media and give it a new name, like Frosty Mugs.

Yes! Looks amazing! This project is really starting to feel real for me now.

Without looking at my machine, that bump seems more significant than the original game, but it will probably be fine. If not, eventually Le Chuck will unveil his solution in his new build and we can transition to that.

Thanks, that will be helpful for me. I'm going to buy a CNC machine to produce my wood parts, but I don't have any tools aside from a Dremel otherwise. Nice thing about the rods is that we'll only need to produce two pieces, so even if we mangle the side we have to cut, the original edge should still be nice and clean.

Beautiful!

This is going to be a struggle, especially with how holes are clustered at the top. You're right on your hunch with the through-hole LEDs. Someone linked to some earlier in the thread, but they do not include the capacitor and resistor. The strip cut with scissors may still be good for us though. Maybe we leave more tube on the back side, then flex the LED strip around the tube similar to how you've done in the photo, then tape around it with electrical tape after soldering its connections in. It may be that the best solution is some sort of 3D printed or CNC'ed mount that gets glued or screwed to the back of the playfield behind the hole and it can hold the strip piece, IR emitter, and IR sensor securely in place, and maybe even help make wiring each hole more convenient.

After that is figuring out how to deal with all the wiring with so many components. Should we route tunnels into the back of the wood to help manage them? Should we daisy chain our grounds? Is there any way to share wiring between the RGB LEDs and IR pairs? Etc.

At least we don't need to worry about orientation of our LEDs. Top, bottom, left, right, it looks like the tube is so well lit it wouldn't matter. I worried too much about light transmission it seems.

I intend on wiring following the data cable arrow on each pixel. You could probably swap incoming and outgoing power and ground and it'd be fine, but you might as well go in the same direction as the data line, just for consistency.

I assume the limit starts at the data source (FadeCandy), so I think we will need to mount the FadeCandy either right above or right below playfield to minimize that distance, and yeah, there will probably have to be some wasted pixels that are just acting as signal repeaters inside the machine. Perhaps the FadeCandy should be mounted TO the back of the playfield, so that you could just disconnect its USB cable when you want to pull the playfield out, and at least the RGB LEDs will be disconnected quickly.

Yeah, it'd be great to consolidate everything for the final build, but if necessary or safer, I'm not opposed to having a power strip inside the cabinet with various wall warts for each device connected to that. That's frequently done for MAME cabinets. For testing, I bought a 10A 5V supply for my LEDs, and my Arduino and RPi have separate power plugs. Hopefully someone with circuit designing experience will help us with the load calculations as we get closer to fleshing out the final circuit requirements.

About these servos, I just received mine yesterday and they are pretty small. Do you think they will be sufficient to move the pulley with the rod and carriages attached, or do you think we may have to upgrade to beefier metal gear servos?

That would be nice. With ATX PSUs, I'd recommend not going cheap on them. At least with my understanding on PCs, you get a reduction in life of your components with a lower quality PSU, and better models are 80 PLUS certified, which are more energy efficient and generate less heat.

Definitely.

Ah, it looks like I ordered the wrong ones. I bought the same model sold on Adafruit: FeeTech FS5103R. I'm not terribly worried if these ones don't work out, they will at least be good test servos until something is nailed down for sure.

I guess we need to decide whether to add more holes or stick with the original layout. It looks like adding the three extra to the I.C.E. ICB didn't add more than a handful of vertical inches.

That's an option, but I don't know if it's ideal. The glass would be a little unwieldy to get in and out of the machine due to length and the amount that would be down in the machine, but a standard piece of glass definitely beats a custom cut. If we were to go pinball glass, I think designing for wide body would be better since that would give the potential to take advantage of the extra vertical height to add more holes. How about finding a source for a 24"x36"x3/16" tempered glass sheet meant for a table top? That's closer to the original dimensions of the glass, and a relatively standard size. Might even be able to find that on Amazon or in IKEA.

I agree. I think saved high scores (lowest times) per hole will add the most entertainment value over extra holes or any extra game modes we come up with. It will be like ghost cars in racing games. The difficulty is always there because you have to do better than your previous best.

There's always some way to rationalize a feature like that into your theme. Reversed/inverted flippers could be voodoo from a witch doctor on a treasure hunter theme, for instance. If we come up with gameplay ideas, someone will have an idea for how to integrate it in a good way.

One game mode I was thinking of is a sort of flood mode. Basically, the bar smoothly moves up at a steady rate and you have little ability to drastically change the right and left carriage movements from that, so you will need to have expert control of the ball. Basically, the goal could either be to get the highest lit hole you can reach or to keep the ball on the bar as long as possible (so just a timed event). Tying that into a theme, you could light up the holes below the bar in blue to signify the water filling up the room, or green for toxic waste, or tan for a rocky floor that's raising to the ceiling to crush you, etc.

Genius! I'm hoping to use a marble for the ball in my game, otherwise I'd love to explore this method. If the IR emitter/detector system doesn't pan out, this looks like the next best option, marble or no marble.

I just made a big merge to the Github repository:
https://github.com/welovepinball/ball-balance

Screen_Shot_2016-08-04_at_11.25.45_PM_(resized).png

The game mode is mostly fleshed out, aside from lights. You can switch from attract mode to game mode, then play all ten holes, win an extra ball if your score gets to 4000, beat the game, or lose it.

I've only done procedural code writing in the past, so coding for a game is a new experience. Rather than let the program run from top to bottom, you have to code based on event triggers. It's not something I'm used to. I eventually figured out that I can't have any loops in my code in order to make it work. It's weird to program looping behavior without the actual loops. I first started trying to build the game using custom user events in PyGame, but that was too restrictive. PyGame only allows 7 total custom user events. I finally figured out that I needed to do state management. Now that the code is all written out, it looks like the obvious solution, but it took me a while to arrive to it on my own. At least the code is easy to follow. I think it should be simple at this point to build on, now that there's a base.

I intend on going through and commenting the code eventually, but I think I'm going to be busy this weekend and won't be able to work much or at all on this project.

There are some bugs in the code, some that I'm already aware of: when you earn an extra ball, the logic tells the game not to play the starting song for the next round, but it also doesn't play for any future round either. Sometimes, after the ball is loaded onto the rod (you have to simulate by pressing the X key), it doesn't go up a little bit. When you win, the game doesn't go on to the second round; I haven't programmed it yet, so it just hangs there.

I also did some code refactoring. winteriscoming, I'm sorry, but I partially broke your service menu config writer. The file it generates is not correct anymore. It adds "\nKey Code: " or something to that effect in the config txt. I didn't want to muck in your file too much before you get to check out all the changes to everything, so I just left it. I think the config reader might have an unrelated bug as well. If there isn't a blank line at the end of the txt file, it won't capture the last item in the txt (it's the failure switch).

I also merged the servo functionality into a new rod handler file, rod.py. I don't have my servos or RPi hooked up yet so I couldn't test it, but I suspect the stop command doesn't work in my code. The joystick logic in rod.py will probably need to be tweaked.

Sounds like I have a lot to look forward to when I get a CNC machine, haha. What are you using? I plan on getting an X-Carve with 31x31" workspace: https://www.inventables.com/technologies/x-carve Obviously not big enough to cut a full cabinet on its bed, but I think I could probably drill some registration holes to accomplish cutting a piece of wood larger than the work surface, just in multiple passes. I'll have to investigate some strategies for that. For software, I have Autodesk Fusion 360.

Nice. I'll have to investigate this company's 2'x4' machine as well. My original purpose for wanting a CNC machine was to make smaller scale arcade machines, so 31"x31" was a fine option for me. My house doesn't have a garage, so I need something kind of compact and storable when not in use. I was planning on hauling the X-Carve onto my patio or driveway whenever I'm going to make some cuts.

Do you know if there are any guides or tutorials for doing two or more passes on a cut that's larger than your workspace?

I agree, if for no other reason than making the game easier to CNC on a smaller machine.

Yeah, it's getting harder to find little LCD panels that don't include the touchscreen.

I realized a concern with having the LCD in the original location is viewing angle. Those little screens probably aren't optimized for viewing at such an extreme angle.

I just uploaded SVG files with the playfield measurements. The holes are already resized to include 1/16" thick tubing (so each hole diameter is 1/8" larger than originally). I chose SVG so that you can use the CAD program of your choice to prepare for CNC. There is a flattened and unflattened version to make it easy to alter holes or change LCD size and placement, since that probably won't be the same as the original game. The flattened SVG imports fine into Fusion 360.

https://github.com/welovepinball/ball-balance/tree/master/measurements

Thumbnail_(resized).png
Test_Playfield_(resized).png

Thanks. Yeah, I did some investigating and apparently this is called 'tiling'. I found an informative video that demonstrates the process basically the same way you described it:

We were initially going with steppers, but decided at some point to switch to continuous servos. We found inexpensive servos that are already full rotation, we didn't have to modify them ourselves.

This is the method I'm planning on using. I have a friend that will let me use his 3D printer, so I'd make housings for each of the target holes and then mount all my pieces into them. I don't intend on doing any board swapping in my cabinet, but I guess that would make that process simpler.