Nice, I can't wait to see where this goes.

I read through your PDF over the last couple days. Quite a lot of potential! Makes me want FAST Pinball to get their boards out even more!

Hope we see more on the Big Shot conversion soon

MPF looks to have P-ROC support built in already, or at least mostly started. So go buy a P-ROC (and/or driver boards if you need to) and check out the Mission Pinball Framework and, even better, CREATE GAMES!

P-ROC is an option. But I'd like to see how the Fast board handles

The first thing I have to say is well done on the docs because pyprocgame manual is not good compared to this already. It was a steep curve having been new to Python, at times very confusing , even though the simplest thing is staring you in the face half the time.

I was racking my brains for ages learning that in 2 months on/off. It's definitely not good for the people that don't have the time I had to do that.

While I'm no way near a master at python/pyprocgame I have & can finish a whole tables rules now, which is enough for me, that's all I really wanted. Basically to jump in, do this, do that, use pre made modules (which I do a lot of), currently sort of not possible unless you're prepared to put the hours in to try & fully understand it all. Looking back it hasn't been all that bad but the time it's taken is.

Can/will you use some more advanced gfx libraries/hooks that can be used out of the box?

Let's see the price and let's see if it comes with a 8x8 switch matrix. The P-ROC bits I need for the whole custom game I have going is $942.82.

This is very cool. Cudos to you guys for pushing custom game development further into the mainstream. Best of luck, and I plan to follow closely

This is kindof my hangup with P-ROC as well. I tried looking through their forums and research what I'd need to do to get a game programmed, and I felt like someone shoved me into the deep end of a pool.

Mission's setup says it's 'event driven', and if I understand what I've read, it sounds like a framework I've been hoping for,

This will be cool to see. I hope there is a good mode architecture like P-ROC has. Hell, I wish that was available in Visual Pinball.

But yes, documentation can make or break an API. It might be powerful, robust, awesome,but if it can't be taught, nobody can utilize it.

Unfortunately this is a problem, there is no real "dummies guide" to follow. There's not really a good base like they're trying to achieve here.

There is no step by step to make you feel comfortable to learn it. Instead you have to ask questions, you have to search, you have to pester people, you have to go through existing code, which half the time felt like spaghetti to me unless the main code is mainly in one file like JD.

I'm making it out to be the impossible? it wasn't so bad in the end and it's actually pretty easy once you start to click, but not sure it was realized how much of a curve it could be and expect you to dedicate a lot of time developing the same old things that should be standard, instead of developing rules & your game.

Did no-one set you up for VP yet? :/

Huh? The way for creating modes in P-ROC is done with individual switch hits in its own class. That's not available in Visual Pinball. I even tried making a hack for it, but not sure if you can directly call a method(through a string) in a class in VP.

I thought you wanted to run pyprocgame with VP.

Love it. Just give me at least 64 switches that doesn't cost the same price as one p3-roc board and I'm going FAST.

With the VP thing, surely you can use Micheal's existing edited bridge?

I know it's early but would like to know if I could use all these modes I've written for pyprocgame to use with a fast. It's not too much trouble anyway I suppose , it could all be re written as you're using Python here too.

Nice.

Thank you for this effort. As someone who has sat on the sideline trying to decide to make a game, this is helping to tip the scale to yes!

sounds really cool. Will this also work with Ben Heck's borad/ hardware?

Is python responsive enough for these things? Interpretive language thru a USB widget against a real time system (pinball system) seems a bit awkward to me; or at least driving a computer requirement well beyond what would really be needed if it were c/c++ / embedded.

Sorry, been holding on to that question for a long time, nothing specific to your efforts.

I think he has his own for that...

Well, this is something I'm going to have to admit that I obviously never truly understood. Why it's not clear to me I still don't know, is it just "easier" to use a few switch boards than direct off original p-roc?

This basically cuts £140 off my estimate for 64 switch.

_{Post edited by ForceFlow: nevermind, the specs acutally aren't all that clear between p-roc and p3-roc}

I can only speak for the P-ROC / P3-ROC, but all of the real-time control logic runs in the hardware. The host runs the game rules and sends various high level commands to the P-ROC / P3-ROC. python game code running on a fairly low-powered host (ie. R-Pi, BeagleBoneBlack, etc) is plenty fast enough for most pinball games. Those that require more processing power are typically doing something more advanced (like rendering full-res graphics or something).

For those not wanting to program in python, the P-ROC is completely independent from the framework. The low level hardware interface was written in C, and some are writing their game apps in C and java. In addition, pyprocgame was ported to C# by Compy.

The large majority of our users are writing their games in python for a couple of reasons. pyprocgame offers a mature framework with a big community of support, and python is a fairly easy language for non-programming experts to learn.

With one of the stated goals of MPF being to make programming pinball machines easier for non-programmers, Brian and Gabe's choice to use python makes perfect sense. Plus, they can make use of various functional elements and paradigms that have already been flushed out in pyprocgame.

If you have suggestions for improving the P-ROC specification to make it clearer, I'm happy to change them.

Our original product, the P-ROC, can be used in a WPC/Stern machine or in a fully custom machine. It therefore has built-in support and all of the necessary connectors to scan an 8x8 or 16x8 switch matrix as well as 32 direct switches. If you're using a P-ROC, you don't need to buy any additional switch scanning hardware. Just connect your direct switches and your switch matrix straight to the board. All switch inputs and matrix outputs are socketed for your convenience as well.

The P3-ROC was designed with a completely different pinball machine architecture in mind. You'll soon see the entire pinball industry move away from switch matrices, and the P3-ROC led the charge to do so. Matrices are much less expensive to scan, but they're significantly more complicated to wire and debug.

The P3-ROC connects to chains of serial switch boards, which each have 16 switch inputs. The current P3-ROC firmware supports up to 16 switch boards (or 256 individual switches). By using small, modular boards for switch inputs, you can put the boards directly near the switches to which they're connected, thereby saving significantly on wire lengths and wire harness complexity. This also eliminates the need for diodes on each switch and makes debugging faulty switches simple.

I agree that the total cost of just the system hardware increases if you opt for a P3-ROC with switch boards versus a P-ROC, but the cost and complexity of your wiring decreases. That's the trade-off to consider. Hardware component cost is just one piece of a much bigger puzzle, and a lot of custom machine designers and a few new pinball manufacturers prefer the advantages the P3-ROC plus switch boards provide.

If you decide the P-ROC, with its built-in switch circuits, is the better choice for your product, that's completely fine. The P-ROC is a long-term product, and you'll receive all of the support we can provide.

Feel free to contact me at any time with questions: [email protected]

I'm sorry pyprocgame's documentation doesn't cover your needs. pyprocgame started out as a project developed by a brilliant software developer, Adam Preble, and he fully documented the basic operation of the framework. http://pyprocgame.pindev.org/manual.html

Since then, it's grown somewhat organically as users, including me, have built games on top of it and pushed various core machine modules back into the main repository. Those are the modules that are lacking deep documentation. Despite that, I'm proud to say that hundreds of people have successfully written pinball software for their custom machines and/or rethemes on pyprocgame and the P-ROC, and the large majority of them are not professional programmers.

Brian and Gabe's efforts are similar to Adam's original goal, though they're planning to expand the framework and the documentation effort much further in order to make it as easy as possible for people to write new games. I applaud their efforts and will continue supporting them in any way possible. If Brian and Gabe have the bandwidth to deliver on their goals and support the efforts of custom game programmers, the resulting framework should be fantastic. I certainly hope they do... just as I hope more people get involved in building new pinball machines.

Thank you, Brian and Gabe, for taking on this project!

- Gerry
http://www.pinballcontrollers.com
http://www.multimorphic.com

Just wanted to back up Gerry here on the switch matrix vs direct switches topic. Direct switch wiring to localized modules is MUCH easier to implement, debug, and repair.

> Direct switch wiring to localized modules is MUCH easier to implement, debug, and repair.

I'm afraid if you can't get your head around a switch matrix, then you are going to have bigger problems when it comes to designing and building your own games.

That said, I've been talking to Gerry recently about what I see as massive gaps in pyprocgame, both in terms of documentation and features. If this can fill the gap then I'd be much happier to use it in my projects.

It's not a matter if not understanding a switch matrix. I have been working with them for many years across much more than just pinball machines. It's a matter of what is better.

They used switch matrices largely because of hardware limitations, not because it was preferred.

Until someone starts producing an off-the-shelf, serially addressable switch, then I'm afraid then you'll be stuck with the switch matrix that we all know and love.

I'm in the same position as others where I feel that the cost of switches on the P3-ROC is simply too great and am using P-ROC over the P3-ROC in my projects specifically due to this. If the switch board read 32 switches then it might make more sense to me.

Watching with interest. Now that I'm through the learning curve I'm quite happy with pyprocgame at the moment but having looked around your site and read this thread it looks like you have some cool ideas. Keep it up

The only thing which always worries me from any software supplier of something complex like this is :

How do you plan to achieve that? Will someone without any programming skills truly be able to do much more than get the flippers working, or will they actually be able to get a multi-mode based game with multiball and all the rest working. Curious to see how that might work.

Good work guys!

Don't take this the wrong way mate but it's taken you 2-3 years, maybe more and you've had to resort to building off a pre-made table.

I know you wouldn't of spent all of that time learning it. It's just an fine example of how difficult it could be without proper docs/walkthrough/clear code base.

I don't mean to step on anyone's toes here, but this isn't really an apples to apples comparison. Personal interests and timelines are just that... unique to the person. The Cactus Canyon Continued project was completed rather quickly by someone who isn't in the software industry. Also look at projects like Wrath of Olympus. I completed DM2000 as well as The Addams Family RPi project in practically no time.

Having said that, I agree with your last point: Lacking proper documentation and examples (for any software API) can really make things difficult and drive up development times.

Just submitting my two cents with respect!

_{Post edited by Compy: Adding WOOLY kudos!}

There are excellent switch matrix drivers that don't require diodes. Take a look at a chip like the MAX7370.

http://datasheets.maximintegrated.com/en/ds/MAX7370.pdf

If you put some thought into your wiring, rows and columns can be taken to local points to get split out to switches, which is what I am doing for Spaceballs.

2-3 years, kinda/sorta but kinda/sorta not too. Most of that time was on the 3 revisions of the driver board and getting pinmame working for Sys11 and then some pinball downtime when my wife insisted that I tackle some other things around the house . Actual pyprocgame coding is probably not more than 6 weeks in all that time (sadly).

But don't take this the wrong way either. Although F14 will stay as pyprocgame since I'm comfortable with that now, if I do something else in the future I'm really interested to see what other options are out there, especially Mission Pinball if they can keep up this traction. Choice is a good thing. Documentation too

Someone needs to get some hardware sorted out for a simple hook-up to the older machines. There are some old SS games with awesome playfields that would be ripe for rework (Vector and Centaur spring to mind) but we have no way to control them at the moment.

But anyway, back to the subject of the thread. Brian and the gang - this is looking really interesting, people are following with interest, keep it up!!

The diodes in a switch matrix aren't a requirement of the driver (The P-ROC and serial switch boards have protection diodes on their switch circuits too). The switch matrix diodes prevent phantom closures. The only way to avoid phantom closures without using diodes on each switch in a matrix is to add processing logic to algorithmically qualify real and phantom closures in an attempt to filter out the phantoms. Good luck if you choose to do that; you'll need to be happy with occasionally missing real switch events.

There are some specific reasons why I wouldn't recommend any pinball designer use a MAX7370 or other device commonly used in keyboard-like devices. I'm quite sure you'll regret it. Contact me privately or start a new thread if you want to discuss details.

- Gerry
http://www.pinballcontrollers.com
http://www.multimorphic.com

The "Resurrection Kit" is what we have been calling that! Many games out there have decent enough cabinets and playfields but toasted boards, etc. I think that there is a great opportunity to bring back old games or fasttrack getting the playfields functional for rethemes.

Aaron
FAST Pinball

I am so stoked that word is out now about the Mission Pinball Framework! When we started designing and building our hardware, the software framework was not something we were focused on. We wanted to make interfacing directly with the hardware as simple and solid as possible. As development moved along, we felt that it would make sense to have a basic framework to help jumpstart game development. Around that time, Brian had reached out to us with the idea of porting another Python framework to run our hardware. We didn't feel like this was the right approach to take with our new hardware. A little time passed and as I learned more about the many projects Brian was working on (yeah, I was checking the guy out! ) that I reached out to talk about some ideas. It was not long (I think it was almost the next day that he was coming to town) before we were sitting face-to-face with Brian at Some Random Bar (that is actually the name) in Seattle. Dave and I were very impressed by Brian's plans and his enthusiasm, not to mention his attention to detail! (have you seen the extent of the documentation of the MPF so far!?! NICE!) So we decided it would serve the community better to focus on providing the resources and drivers and lend the support needed for frameworks like the MPF (and other not-Python frameworks coming in time). Brian wasn't quite ready to announce things when he came back to Seattle for our NW Pinball Show in June. Some of you saw our presentation and how I alluded to a software framework in development... well here it is!

All right, I won't highjack your thread but I wanted to comment and congratulate you on all the hard work that has gone into the MPF and I CANNOT WAIT until people are running FAST hardware on the latest and greatest in Python pinball frameworks.

Aaron
FAST Pinball

Build a system where you can install a default program that runs a basic game:
3 ball game, trough support for optional multiball
Flippers already set to go full force for half a second, then run 25% hold
Both Slings fire

Allow easy variables for:
Assigning wait values for specific solenoids
Assign bonuses for combos
Assign extra balls
Assign multipliers
Make it super easy to assign point values to switches, randomize sounds attached to those switches

You do all that, and you'll finally see every serious hobbyist attempting a custom pinball. I personally think P-ROC is a huge barrier to entry from everything I've read. Most of us don't want to learn programming, they just want to build pinball and choose options.

Honestly, if a company were to supply a kit where you have a basic whitewood playfield with flippers, trough, slings, and a shooter lane carved, and everything wired up to shoot into emptiness (can start fabbing a layout with foamcore right away), and a 64 lamp matrix controlled easily with software (when that builder is ready to start laying out inserts) it would sell like hotcakes.

You could actually write a basic skeleton game in pyprocgame that could do this. It would just need a few config files for assigning points and sound effects to switches and such. It would be pretty boring though, unless you were trying to make an EM style game. Pinball is a lot more dynamic these days than something like that would allow. You'd want music to change under certain conditions, sets of swtiches in groups or in an order that cause some secondary level thing to happen, fancy light shows, etc.

Procgame already comes with a stripped 'basic game' system that given a proper config file to assign things like trough switches, slingshots, pops, and flippers to the proper coils and switch wiring and you can flip the table in very little time.

Its easy to sit by and say "if only there was x, I'd make a custom game" -- but if you really want to do it, you'll figure out what you have to. Like Scott with Wrath, Matt with Deadpin, Mark with F14, and so on.

This has been one of our top requests since we started building hardware, except swap lamp matrix for RGB LEDs.

This is a video I made for some friends showing my portable pin running the FAST I/O 1616 (16 drivers, 16 direct input switches) with only a config. There is no computer controlling any of this. For people wanting to prototype their playfield before writing any high level code, it is awesome!

It was fun to show people at our booth at CAX this year how quickly you could bring your playfield to life and start working on shots.

Aaron
FAST Pinball

I'm curious to see how MPF plans to cater for this (Brian mentions appealing to the non-programmer), as I really don't see how anything which allows you to "just choose options" is going to create a pinball machine that holds the interest for more than a few minutes. As soon as you want to start adding custom animation, multiball modes, lock options, hurryups with custom lightshows, switches that do different things depending on whether you are playing the base game or some kind of mode (the list is endless, but you get the idea) then like it or not you're going to have to end up programming at some level. The framework can hide a lot of the complexity, but you've still got to control the framework itself with code of some kind.

P-ROC a barrier? Don't see that really. Without it there would be no BOP 2.0, no CCC, no Demo Man on Steroids, no Predator, no Wrath of Olympus, no Buffy etc etc. Now for sure another option for programming it like MPF are working on will be cool, as Gerry says there are already options other than pyprocgame for the P-ROC. MPF will be another. I can see it getting more folks to look at new code for old machines, but in my opinion (and it is just an opinion) designing and building of completely new custom games will always be a real niche needing a lot of effort both hardware and software wise. P-ROC and FAST will be 2 hardware control options (I expect there will be others), MPF, pyprocgame, FreeWPC (to an extent) give you software options. But I can't ever see it being something easy. I'd be very happy to be proved wrong someday though

This statement makes no sense. The P-ROC (and the FAST system) are not barriers to entry. They are in fact removing a barrier to entry - hardware development.

Your barrier to entry (from your statements) is software (or something akin to assembly code on really old machines) and that barrier exists with or without P-ROC.

Portable pins, could be onto something there...

Completely agree there! We designed our hardware and its interfaces to not require a framework to make is approachable. A framework is a great way to get started though. Don't reinvent the wheel when you don't have to.

Usually when you start working on your games you will come up with the way you like to do them. Your own programming style influences this. Whether that is starting with a framework and creating a reusable set of functions for the rich game dynamics that you can tailor to each of your games, or rolling your own code base completely. Its really up to the person writing the code to determine the best approach for them and their games/business.

Our mission is to ensure that the way that software would interface with our hardware is going to be the same whether it is on the FAST WPC Controller or the FAST Core Controller or any other form factor we may dream up. So no matter what FAST hardware you are using, your code moves between each without issue.

The MPF is a great thing for those using frameworks to create games. Say for example, we release our hardware and people buy it up and start making games. If we decided to throw in the towel, users could buy hardware from another vendor whose hardware is supported by the MPF and not be left stranded when they decide to do a new game. The individual's or company's investment in their game development isn't at the mercy of a hardware vendor and the feature set that they choose to support/integrate.

Most importantly I want to say, the MPF shouldn't be FAST vs. PROC battleground from a designer/programmer standpoint. What's better than universal framework that lets the game designers/programmers create games for multiple hardware platforms? It let's hardware vendors provide options without forcing users to abandon the code they have invested lots of time into to use hardware that might better fit the current project. FAST, PROC and others can compete to provide cool product and great value and let the market decide.

I totally respect the loyalty one has to the people they have worked with and hardware they use, I really do. So I hope that nobody feels that FAST coming on the scene is meant to be an assault on other hardware vendors. Frankly, the only goal I have stated before is that I want PROC market share to go down ONLY because so many new people came into the market and picked up our hardware to start! ( trying to keep this light hearted Gerry )

I look forward to our hardware hitting the streets this summer and seeing what people make with it. More options to draw more people into pinball design/development is good for all. That is something anyone on Pinside can rally behind!

Aaron
FAST Pinball

It has flown with me to the Chicago and Texas pinball shows.

Aaron
FAST Pinball

IMG_6682.jpg

IMG_6817.JPG

IMG_6821.JPG

IMG_6704.jpg

IMG_6708.JPG

Hah, that is pretty great!

I have that same luggage too.

Cool! Wish I could be there.

Very nice! Great idea, thanks for sharing pics. What's the length?

I started a separate thread so this one can stay on topic.

https://pinside.com/pinball/forum/topic/fast-portable-pinball

Aaron
FAST Pinball

Snux,
I can't imagine a fully featured game being done without some programming (if not a LOT of it). However, It would be nice if all the basic stuff was covered/handled with just a small amount of configuring.

Having a framework base that can play a simple game of pinball on your playfield with just a config file defining what your playfield has and some other basic info, would be a great start. It would get people to a point where they can experiment with ideas by doing a small amount of programming. There are a TON of things that are part of every pinball game, and those can all be part of the framework you start with when making your custom game. It's also possible to have modules of code that handle most of the common pinball components (ball lock, drop target bank, etc.), and in order to get one working in your game could be as simple as adding some stuff to your config file. You could then go into the code and extend/change it's functionality when you are ready.

Right now, in order to get anything going at all, even the most basic things, requires a fairly significant amount of coding work.