You should have a few modes or easter eggs paying homage to a few of his other films . . .

Silent Movie -- a mode with no sound or music.

Blazing Saddles -- a 'Waco kid quick draw' hurry up mode or a mode based on the 'farting scene' (pop bumpers)

Young Frankenstein -- "It's Alive"

The P-roc can basically do all of this. In some cases you would need to replace some of the software in the core framework (which you don't have to use at all, but certainly speed development up). There are folks using P-roc, and some of the other pinballcontroller boards to do RGB, use an LCD instead of a DMD and control Servos -- not saying all of that is directly done on the P-roc, but all of that is being done in conjunction with using a P-roc. You might want to go look through the forum at pinballcontrollers.com to see what is being done, even if you go it on your own, you may find some valuable tidbits.

Obviously if you are a electronics/software engineer and feel you can create all the needed interfaces, driver boards, etc. more power to you. I look forward to seeing your progress.

the new set up with P3-ROC and the sw-16 is nice, but makes it that much more expensive then the original P-roc, since that has the switch matrix built in. It is cool how you can put them near the switches (like the driver boars, which I did), but that benefit does not out weight the cost, at least in my mind. The original also has the DMD support, which is nice, but you have no use for that, and since I am moving to LCD for a colorDMD, does me no good either, but, his original design was for it to interface with B/W and stern pins and it was very cool that was one less thing to deal with when I was getting started.

One of the nice things with the P-roc is the ability, via the software, to directly map a switch to a solenoid in the P-roc itself, which eliminates any delay of having software need to respond to the switch event, which is critical with flippers, slings and pops. The event still goes to the main process so you can handle scoring, etc. The reality is if the CPU is fast enough there is no latency, but if there is any risk of that, you need to be careful and that is one challenge you will have to watch for as you do your design. Obviously your plans to have multiple processors for different tasks will help that.

Be careful on the 'release to public domain', that can still get you into trouble, depending on what you release.

Feel free to PM to chat more on this stuff. I've learned a few things about building a machine from scratch over the last 18 months.

I think your scale is off

I like the retro feel with the saucer locks, makes sense since the movie is from the late 80s.

19 balls, huh, that should be pretty crazy.

Be cool if the tractor beam window went both ways, the caddy going towards the ship and the Eagle 5 leaving the ship, during their respective modes.

I believe the P^3 uses an interesting approach of a single massive trough at the back of the machine, with a reverse gravity feed, so balls can easily be routed back there from anywhere. It then feeds balls via a VUK back down to the flippers via a return (and maybe also on to the play field from other locations, can't remember). You could use a similar approach with just a single large trough in the bottom portion of the game, not sure why you would need the second "standard" trough, just going to create more complexity. Regardless, the challenge is keeping accurate counts on where all the balls are, which gets a little more complex when you lock balls on the playfield and needing to know which player those locks belong to and how many locks the current player has "earned" and how many they have "achieved". I'm sure I don't have to tell you the problems a game will have when it does not have an accurate count.

I'll send a PM with some thoughts on 'trough management', since I'm sure most on this thread aren't interested.

You asked for it, but this will likely rank up there with one of the longest posts. I can get long winded when I write, I guess it has to do with my typing speed. I've removed a few things that were on other topics related to development and added and clarified a couple of items, so Wolfmarsh, you should read this again. So, you asked for it . . .

I Like the concept of two different types of ball balls. Given the idea that only one or the other type is in play, you will have to figure out how the locked balls fit into your scheme, your trough management needs to know where they are regardless, so you could either just dump them, with the flippers disabled to clear the locked balls or you can leave them alone, and know that the rest of the balls are in the trough. Either way you end up with two troughs to manage, since you need to know where both sets of balls are, but not is not that different from managing a multiball trough (or physical locks) in addition to the main trough. However, since the balls are 'different', I take back what I said, it probably would be a good idea to dump locked balls, otherwise you will need more code around managing the locking and saucers (more on that later). So, having said that, I would dump those locked balls. You also have to keep track of balls locks earned and achieved, since you need to carry that across players, unless you are letting them steal locks.

The root of my comment was around that fact that many of us have experienced a game with a bad trough opto, and how the game will do all sorts of odd things, like put two balls in to play, since it is confused on where the balls are. So keeping accurate count of where all the balls are, is pretty key to game logic. In general a lot of switches if they fail to register will have minor impacts on a game, but switches involved of knowing where balls are are critical.

'Trough management', is something that took some effort to get right. I started with the code in the Procgame framework, and the modified it. I know Eric on CCC did the same thing, but I think he gutted it even more.

The management of the trough and multiball are tightly linked. I keep track of balls in play, based on increasing a counter when I put one in play or at the start of mulitball where it gets increased whether locked balls are being released or balls are going to be put into play via the trough/autofire. That can be a little tricky too, since as balls roll down troughs (either type), it will trigger code to evaluate where the balls are. I'll come back to this in a minute.

On a drain (or a ball going into the ball lock trough) I figure out where all the balls are (main trough, multiball trough/locks) and see how that compares to the number of balls in play, and take action accordingly. The timing on some of this is key, as the balls roll through either trough it will re-trigger code for evaluating the ball counts, so knowing that the game is in the 'start of multiball' was key vs in mulitball or not in multiball, especially if a ball drains while the balls are still being kicked out, with your saucers this will be less of an issue. In general, on those switches I use a delay before doing the analysis. Each switch hit will then restart the delay counter, so as a ball rolls down the trough, the clock resets until it has reached its destination. If mulitball is running, I just kick out anything that hits the MB trough with little to no delay, like I image you will be doing with the saucers, unless you are doing a jackboot based on re-locking the balls within some time frame, which can be a cool feature (ala I500).

As a side note, the opto closest to the drain, not the shooter, is the one I watch to see if a ball has drained in the main trough. As I said I then pause for a couple hundred milliseconds, before 'analyzing', giving the ball time to get down the trough and for the balls to settle (a bigger issue with mechanical switches). As I indicated, for the MB trough I reset that timer if other trough switches trigger, since the design of that trough (ending in a saucer) requires some time for the ball to settle down on the switch. If I do the analysis too quickly I can get an incorrect read on the number of balls in the MB trough.

On a drain event I check if multiball is running and how many balls are still in play (validating ball counts in troughs, locks, etc), this check will then result in removing this from the count of balls in play, e.g. 6 balls in machine, 4 in main trough, none locked, 3 supposed to be in play, but four accounted for so only two are in play, so one must of drained, so now adjust to be 2 in play. Now figure out what the new situation is, if multiball was running and now only one ball is in play, do the end of multiball processing, if more then one still in play, ignore it (well, unless ball save is active, which adds some other complexity), or is this the last ball that was in play, so now do end of ball stuff.

Ball saves also have to be handled whether for the start of a new ball or start of Multiball. If you support a quick launch ball save (e.g. when a ball hits an outlane switch you serve up the saved ball immediately vs waiting for the drain), that then adds a touch more complexity, since when you go to do your math, that ball is not in the trough. Basically I'll just put a ball from the trough into play, and then when the ball that was coming down the lane hits the trough, the system will do its math and decide, there should be one ball in play, and there is still one ball in play, so life is good.

A ball save is basically a timer, so the code checks if save is currently enabled, and if so, if the number of balls in play is less then what the ball save object was told to 'keep in play',then it serves it back out. Ball save can have two attributes really, how long the save is active and the maximum numbers of balls to save, which typical applies to MB as either just the first drain, up to X times, or for the given time frame (I do the latter).

Oh, one thing I forgot to mention to wolfmarsh, is you also have to handle a ball falling back into the trough, you don't want that to be viewed as a drain. IN theory it should hit the 7th opto, but since it can push the balls and back and trigger the opto closest to the drain, you have to know this was a fall back. This is one of the things that brings the shooter lane into the trough management equation, more on that in a moment.

Ball locking is tied to trough management. If a ball enters a lock, you have to decide should it be locked (e.g. was the lock lit), or kicked out, if it is a lock should a new ball be put into play from the main trough, the multiball trough e.g. this is the third ball in the trough, but only two locks earned, so need to remove one to leave space for another lock, or in your case, potentially unlocking a ball in a different saucer, or does mulitball need to be started.

The shooter lane switch is also tied to trough management. First off, if there is ball in the shooter lane, you don't want to serve up another ball. This is primarily an issue with MB when you are serving up a bunch of balls from the trough. The shooter lane in my case, during game play, also monitors if a ball has somehow found its way back there and will auto fire it out, but you don't want that active until your balls save as timed out and your are not in MB or at least I don't, I want to let the user still have control of that plunge. Also the 'opening' of the shooter lane switch is when you start the ball save timer. The closing of the shooter lane switch is also important, since that is how you know the ball made it out of the trough correctly, and how you then would deal with a fall back, e.g. you serve a ball, but if the shoot switch did not trigger, then you need to know that if a ball drains, so not to treat it as a drain, but more like a ball save, but a save that does not end the ball save, in theory we have not started the skill timer yet, or the ball save timer, since that happens after the shooter switch opens, so if ball save active and timer not started, then ball never reached the shooter lane.

So, by now you have a headache, and realize that this is a little more complicated then you first thought.

My sister's family has the last name of Schwartz, and they just had a bunch of T-shirts made up with this phrase. Back when my nephew turned 13, he had a Mel Brooks themed Bar Mitzvah.

parts availability and finding parts is a factor you need to consider. I went with a WPC cabinet since that is what I am most used to, and I was able to get a free cabinet to at least start with. I lucked into some of the necessary playfield mounting hardware on ebay, which was a lot cheaper then buying new. Lockdown receivers, lockdown bars, and hangers are definitely available, not sure if anyone sells the slides that mount the playfield to the game.

Betting right now you are also thinking " . . . and not quite as easy as I thought it would be"

I did that, well more masking then stencils on an EM re-theme I did. I then used water slide decals for labels and for some images. Worked reasonably well. I then sprayed several coats with varathane. For my custom game, been leaning towards an overlay, but still have no even designed the art. Been focused on re-doing the animations for the larger, color screen, I am now using.

these guys . . .

http://greatpinball.com/services.html

will do a custom one, $200, and they provide a mask for where you need to paint white before applying it.

Hopefully Brian will figure out and re-code all the trough and ball tracking stuff before you get to that point. Sounds like that is creating a variety of issues with losing track of where balls are, skipping from ball 1 to ball 3, etc. Games will certainly mis-behave when it is confused on where balls are located. Trough management and ball locking can be very tricky to get right, which I think I've talked about before in this thread. I'm sure Brian will get this figured out quickly, I know he was talking with MOcean (HD-pyprocgame), Keith (JJP) and others to asses options. He knows he can always pick my brain as well. But since it seems you are not moving all that fast with the playfield, waiting on your CNC, you probably don't have to worry about this yet

I switched from physical to optical switches in my MB locking area to reduce potential problems. Using virtual locking vs physical locking of balls can minimize troubles, but a lot of us to like a physical ball lock. Two things for you to think about as you work through your design.

Totally Disagree! Multiple people have created complete machines by themselves in year or two. And others are well on their way. And there are a few two man teams who have done the same. It is certainly common for them to continue to improve the machine, but games with art, sound, music, rules in a year or two is certainly possible.

So, have you now started on your own game, or is this in reference to your work with heighway?

There are several resources to look out, including the forums on http://www.pinballcontrollers.com/forum/index.php?board=17.0 where you should check out the 'user projects' section to see various projects and their history and there are tons of ideas and tips. You can also check out https://missionpinball.com/forum/f/mpf-users/ but since it is newer, I don't think you will find quite as many projects to look at.

I did a presentation at expo 2013, on "building a machine from scratch with P-roc". As of right now, both the audio and powerpoint slides (pdf) are still available, and you may find this informative.

http://www.pinballnews.com/shows/expo2013/joshkugler.mp3

https://docs.google.com/file/d/0B8mfLC9vLbKAR2NXWjNULXpsQmc/edit?usp=drive_web

In addition, many folks starting out have found the Joe Shabadu thread to be very helpful (link below), but as I said, many of the user project threads have a lot of great info on all sorts of things. Both the pinballcontrollers and MPF forums have tons of folks who are happy to assist.

http://www.pinballcontrollers.com/forum/index.php?topic=578.0

I did not mention either FAST or P-roc at all, but just pointed the user to the two forums out there that offer the most help in doing this. The majority of what is in the user projects section on pinballcontrollers, which is the link I provided, has little to do with the electronics or software, but much more around all of the other challenges in building a machine and has tons of tips on designing a playfield, cad, routing playfields, vacuum forming, doing art, etc. I also included the appropriate link to MPF and I also did not in any way promote MPF vs HDpyprocgame or P-roc vs Fast vs Heck, etc.

Just as I provided you a ton of thoughts, ideas, and tips when you started out, I do that for anyone who is starting on this journey, and I do that regardless of what tech or software they may use.

If my post truly offends you, let me know and I will delete it.

When I hear years, I'm think four or five, so good we agree that two years is possible.

No doubt it really helps to have a least some of the skills, wood working or software or art, etc. but maybe not all. But look at deadpin, buffy, kuglers, the matrix, predator were all done in under two years, Nightmare before Christmas, is less than two years and well on its way. Wooly was turned from a virtual pin to a custom machine in about six months. Heck, Matt who did deadpin, had no software skills and actually very little pinball knowledge when he did his, and it was done in about a year.

Not saying it does not take a ton of work and time, but if you are motivated, it is amazing how quickly you can do it.

beers are always good, but as many in the pinball world know, I am more of a tequila guy.

I don't think we are stupid at all, crazy yes, but the good kind of crazy. Even better is that I have met some really great people through the homebrew community. I think we are all also very passionate about our projects. The fact that pinballlife now has a homebrew section just shows the growth of this subculture within the pinball community.

it is worth pointing out, that building a machine is typically going to ultimately cost more than buying one, and I'm not in anyway talking about the value of the time you put into it. But when you build one, it truly is a limited edition. And I will tell you it is incredibly gratifying to have people play your machine and see them really enjoy it. I was amazed at expo this year at folks playing it and them being able to spot what had changed from the previous year, as well as how many people commented that they had been looking forward to playing it.

And here I thought you were going to recommend the heck board

As far as aurichs post, I agree we need some photos of progress on this machine.

DMD stuff is cool, but how about we see some progress on the playfield!! Lets see that X-carve in action.

True of just about every single aspect of doing a custom machine. Some "learnings" are just more costly then others

give he his in his late 80s and has not directed anything in almost 20 years, and has done almost no acting, other than voice work for the last ten years, hard to see this happening. If he has one more movie left in him, not sure it would be a sequel, especially considering he has never done one, other then moving his movies to broadway. I suspect he is happy doing a little voice work and a little writing here and there, but just hard to see him wanting to take on the grind as directing and writing a full length motion picture.

I think "spaceballs The animated series" is the closest we will see to a sequel.

Not sure anyone thought we were would see a zoolander 2 (and it would probably have been better had they not) so I guess anything is possible.

In the meantime, still waiting for some playfield photos

So what motivated yo ufo go with the EM style of accessing the head from the back?

What is your plan for the bezel? will it be a single piece/graphic or two pieces as the wood is now?

Seems like you have become quite the expert at making 3D Printed brackets, e.g. power supplies, monitors, circuit boards. Are they all properly labeled/themed as "Spaceballs the power bracket", "space balls the monitor bracket", etc.?