Hi Everyone!

Just in time for CAX I'm happy to share details about the Mission Pinball Framework (MPF) project, an open source (MIT License) python-based pinball machine framework for writing your own game software (for either custom games or new software for existing games).

One of the goals of the MPF project is to be platform-independent. It supports the P-ROC today and we'll support the FAST controllers as soon as they're available. (The game code is 100% the same across both.)

We've been using pyprocgame with the P-ROC for awhile and while we love it, we felt that pyprocgame was more like a development environment for creating your own pinball game and had a steep learning curve. So when we started writing the software for our own game, we tried to make it generic enough so that other people could use it.

Then time moved on and we had a pretty hacked-up version of pyprocgame that wasn't really compatible with the core anymore, and then all of the sudden FAST announces that they're releasing hardware too so we thought, "You know, we should just take everything we've been working on and make it into its own project, make it hardware independent, and go for it."

So we did that.

So MPF is not a fork of pyprocgame or anything. It's totally new code written from scratch (though we were able to leverage the extensions we'd written for pyprocgame and to adapt them to MPF, like our LED controller, OSC interface, keyboard interface, ball controller, etc.)

The current status of MPF is that it's probably about 5% done. You can use the config files to get a machine up and running. You can start games and cycle through players and it knows where the balls are and everything, but that's about it. No DMD. No lights. No sound. No scoring. But hey, it's a start. (And really we just decided to write our own framework on June 1, so it's been a fast process.)

We're working like crazy on it (well, in our "spare" time outside of our day jobs in IT) and we hope to have a more complete version ready for the Chicago Expo in October.

Here's a quick look at our goals:

• Support all the “traditional” pinball components, including ball and game handling, ball search, ball save, tilt, drop targets, lane change, pop bumpers, credit and coin counting, audits, service menus, etc.
• Support the “new” pinball concepts, like player profiles, web-based reporting and control for operators, social media integration.
• Support as many different types of pinball machines as possible, from EM-games through DMD through modern LCD-based games. (JJP, etc.)
• Be easy enough for non-programmers so that anyone without programming skills can get a machine up and running.
• Bulk of the configuration should be done via text-based config files.
• Game creators should be able to specify their own fonts, language strings, dots, and sounds for common components, all without “real” programming.
• Be extensible so the framework can be used to power more advanced and customs things.
• Be well-documented, both in terms of step-by-step “how to” guides for beginners, as well as more advanced references for hard-core programmers.
• Be extremely modular, allowing game programmers to subclass, extend, and replace certain built-in functionality without breaking the rest. (Hopefully without requiring forking which would make future updates difficult to integrate.)
• Code should be hardware-independent. (Literally you should be able to swap hardware platforms and have all your code run.)
• Robust enough to run on commercially-available games, including games that are in revenue service in public locations.
• Ensure that the more advanced configuration stuff doesn't interfere with people who want to do more manual stuff on their own.

So check it out at http://missionpinball.org.

We also have a PDF version of the documentation (102 pages so far!)

Thanks!

Hey Everyone,

Thanks for the feedback and encouragement!

A few thoughts on some of the questions people asked:

1. For gfx stuff, yeah, we'll add full DMD and alpha-numeric support, and if you want to have a full on LCD then that should be easy enough to add (though I don't know if we'll write that... we'll see). Right now I'm waiting to see how FAST handles the DMD so I can write a module that will be compatible with both platforms. But as the general concept it will be similar to how pyprocgame handles it. You can send it text strings with fonts. You can have it show images. You have have it play animations. I do know we'll change a few things, like making transitions standalone and easy to use, as well as making it easy to sync external events (like driver actions, audio, etc.) to specific frames. But like I said we'll wait until the FAST hardware comes out before proceeding.

2. For Visual Pinball and PinMAME, I would imagine we could create platform modules for them (just like FAST and P-ROC) so you could run your own MPF code agains them (either for testing or for flat out using MPF as a way to write VP games). I haven't looked into how this would work exactly but I can't imagine it's too difficult.

3. For the modes, I like the general concept of the way pyprocgame does modes, though there will be some differences in MPF. Mainly we don't want (well, we won't allow) individual modes to see switch activities, since we want everything that modes do to be triggered based on events. (So we have a switch controller that will post events for switches based on switch tags, shot configurations, etc.) But we have a Task concept which can be used in a similar way to modes which we'll flesh out. At the end of the day, I guess I should say that yeah, we'll make it easy to implement game modes, but they will be a bit different than pyprocgame.

4. For the documentation & getting started, yeah, that was a huge thing for us. This is just the tip of the iceberg. I literally cranked all the documentation out in like a week, and it's not even proof-read. But we'll keep going with it and create lots of guides that are easy (step-by-step, getting started, hello world, etc.) And like we said in the docs already, we really feel like anyone ought to get a game to like 90% completion without "real" programming.

5. For Big Shot, dunno if I mentioned that before but we'll be bringing that to Chicago in October and will have it in the P-ROC booth. There are so many fun things to do with an EM game in the modern world... we can't wait to share it!

6. FAST versus P-ROC: This is going to come up a lot, but based on working with P-ROC for awhile and talking to the FAST guys about how their stuff will work, I really don't think it's going to matter which platform you use. So let them price war and let us win. I'm sure I'll be posting detailed blogs about this moving forward, but the general concepts for how these two platforms work is fairly similar. I view it like AMD versus Intel. Same general concepts for both platforms. Little differences if you really dig in. 99% of people won't know the difference. Buy whichever one you feel more comfortable with.

So thanks again for your thoughts! We're working like crazy on this thing and will keep on pumping out new revs every week or so.

Next I'll build the light controller (which will be similar to the LED Controller I wrote for pyprocgame, but it will be expanded to handle incandescent matrixed and RGB LEDs together). Then hopefully we'll have the FAST drivers and we can start on the DMD code.

Brian

I know this isn't quite your point, but remember the classic P-ROC (and FAST controller) has its switch matrix built-in to the board themselves, so you get switches for free. (The P-ROC can support a matrix of 8x16 plus an additional 24 direct switches, all built in.) In our case that's why we went with the P-ROC over the P3-ROC, even for Big Shot where we don't need the P-ROC's DMD support. But that said, yeah, it seems crazy that with a P3-ROC you're paying almost 4 bucks per switch.

Assuming yes. I just haven't actually looked at it yet.

Definitely no. There are just too many differences. But the "hard" work really will be designing the modes conceptually, and creating the DMD dots, light shows, and audio files. This might be an audacious thing to say, but it's our intention that we build so much into the framework that you can code an entire game in just a few weeks. (Again, talking about the actual coding, not building the dots, light shows, and audio.) So we want to make this as easy as possible for people, and we'll be happy to help. We can probably write a migration guide too.

And, yeah, since this is Python, if you worked your way through pyprocgame, MPF will be a breeze.

Regarding switch matrix wired to the P-ROC versus PD-16 boards, Gerry & Roy make great points which I didn't consider. The fact that you can put your SW-16 boards "locally" near the switches also means a lot less wiring. (Since every "local group" of 16 switches only requires a serial connection back to the next nearest board.)

Also, not having to deal with bad diodes which cause weirdo switch problems.. ok, if I'm building a one-off machine, that's worth a few bucks per switch right there. My comment about that pricing being crazy is hereby withdrawn.

Now, as for a few of the other questions that were brought up:

I talked to Ben about this at the NW show last month. As a general concept he's on board. Right now the architecture of his hardware is that there's a PIC32 microcontroller that runs the game code 100% on hardware. (So it's more like a WPC or Stern system in that sense.)

That said, Ben's hardware does have a host computer interface, and there's no reason someone (not me, as I don't know C) could write drivers which we could interface with the MPF. We'll keep watching that and write the platform interface when we can. But yeah, I'd love to add support for PinHECK board system, and I believe it should be possible.

Oh, and I forgot to mention that if you're doing a totally custom game, then yeah, you have the choice as to whether you use the P3-ROC or the P-ROC. Pyprocgame and/or MPF don't care which you use as they're seen the same from the driver level. So just pick what makes sense.

Really the only major differences are the fact that the P3-ROC requires SW-16 switch boards, and that the P3-ROC doesn't support a DMD.

We did the same cost/benefit analysis for our Big Shot EM conversion, and we went with the classic P-ROC even though we don't have a DMD. So you can do the same, and if the P-ROC wins out, then go for it. Again, yay for choice!

To jump back in to address the various questions about how realistic it is to make MPF usable by non-programmers (or, perhaps more appropriately, how fun of a game can be built by non-programmers), I'll answer like this.

I don't know.

It's our goal though, so we'll keep chugging away and see what happens.

I know for sure we can get all the hardware devices defined—not just hardware like coils, lights, and switches, but pinball-related things like ball devices, drop targets, bumpers, lane changes, kickbacks, flippers, switch sequences for shots, etc. I know we can have advanced options for built-in modules like keyboard interfaces, ball search, ball save, etc. I know we can have text-based files to control light shows (even for RGB LEDs) and that we can hook in with video editing platforms to make cool shows. I know we can handle all the player rotation, cycling through balls, games, etc. I know we can award points (by tying them to game events). I know we can show text on the DMD, play audio, and play DMD animations. I know we can allow the game designer to specify which of all these options are exposed in the service menu. I know we can create advanced usage, audit, and maintenance reports. I know we can replace the service menu with an iPhone app... really there's a lot that I know we can do no prob.

Then when it comes to actual programming, I know we can make snippets of code that run that are triggered by events (basically when anything in the above list happens), and I know we can provide a clean and simply interface for all these pinball things when the game designer actually has to write code.

So at the end of the day, I agree that we will never get to the point where the game is totally "no programming," especially once we get into game modes that do who-knows-what. (Though a lot of those are pretty similar too. Shoot x target y times in z secs. Play animation a with sound file b while doing it.) I also recognize that we can't make our config files *too* complex, since at that point we've essentially written our own pinball language.

But I do honestly believe that with a few hours or days of effort stepping through our configuration file reference that we can get people to a game that passes as functional.

Obviously time will tell. But those are our goals.

I love the enthusiasm from everyone though! Thanks for that. It's very encouraging for us.

I'd just like to provide an update on MPF since it's been a year since we've posted here. We've been busily working on MPF with about 2500 man hours on it in the past 12 months. We're now on version 0.20 (versus 0.9 at Expo 2014).

We're making good progress towards the original goal of creating a pinball framework that's both easy to use for non-programmers as well as easy to extend for people who want to write "real" code. Most people so far use the config files to get about 90% of the way there and then they finish it up with 10% "glue" written in Python to do the custom stuff for their machine. (Though that's still not strictly necessary. The guys who created the Pitchfork Music Festival machine haven't written a single line of Python. Really it's just a personal preference of the people creating the machine.)

Listing out all the features would take up too much space here. But at this point, MPF has modes, shots, scoring, game logic, lots of different device support, FAST and P-ROC support, many sample modes & devices (ball save, tilt, high score, multiball, bonus, credits & coin support) which are all highly extendable and customizable. We support LCD, color DMD, and physical DMDs. We support games with multiple playfields (even head-to-head). We have separated the pinball controller and the "backbox controller" (display, audio, etc.) into two processes (which is great for small, multi-core systems), and we've developed a communications protocol that lets you replace the built-in backbox controller with whatever you want. (One group has already created a Unity3D-based option.)

Here's the full list of what's been added in the past year: https://missionpinball.com/docs/version-history/

Anyway, I just wanted to give a quick update. I'll post here each time we do a new release (every 6-8 weeks). In the meantime, we have hundreds of pages of documentation, and, most importantly a step-by-step tutorial for getting started (even if you don't have real pinball hardware yet). https://missionpinball.com/docs/tutorial/

We will be at Expo next weekend along with I think 4 or 5 games in progress using MPF. You can also follow the progress via the many other awesome projects on Pinside using MPF: (The Pitchfork Music Festival Machine, Nightmare Before Christmas, Minions...)

New MPF feature: Support for "real" color DMDs (RGB LED matrix instead of LCDs).

Sorry for the registration troubles. Our current spam blocker is overly-aggressive I think, so I just updated that now and we'll see how that goes.

I see you register now and get your question posted there. (I'm just responding here for completeness for future people who read this thread.) I think this issue is related to running the installer out of the zip package versus unzipping it first and then running it out of the newly-unzipped folder. Looks like we need a doc update!

Good question. There have been 3 complete machines done with MPF so far, so by some counts you could say that it's all there now. (Here's the current feature list.) That said, I literally have a 50 page document of bullets of things I want to add, so you also can't wait until it's "done" because it will never be.
Probably the biggest thing missing today is there's no service mode. So if you want to change settings you have to edit the config files directly with a computer. Second is that there is no bonus mode which you can setup via configs. I wrote a How To guide on how to do the bonus mode in Python, but I definitely want to get it to the point where you can just do it without Python.
The bigger question is about the pain of moving between releases. To us it's important that we don't cause too much pain by making changes between versions, while at the same time we don't want to box ourselves into a corner limiting some functionality due to some decision we made 10 versions ago.
That said, the minions guys have 2000 lines of config, but it's not like going to 0.21 broke all 2000 lines. Really it's lots of little things. We have a new setting for ball device (things that hold balls) timeouts, so you have to change one line in each of your ball devices, or we combined "shots" and "targets", so you have to combine those two sections of your config files. If someone spent 100 hours making those configs, I don't expect it would be more than a few hours to update them for the latest version. (Kind of like how you need to update all your apps and stuff when you move to a new OS on a computer, except that MPF comes out every 3 months instead of every 3 years.)
We also have a config file migration tool that will update your config files automatically to the current version. So even all the little find & replace type stuff and easier changes are done automatically.
Broadly-speaking, most new releases of MPF (there have been 21 so far) have added functionality rather than broken existing functionality. So a lot of the changes people need to make are where they manually coded something in Python before and then in a later release there's an automatic way to do it with MPF config files, so they have to make the decision as to whether they throw out their hand-coded versions or not.
Also one thing we just put in place in 0.21 (which hopefully the minions guys will take advantage of moving forward) is for game projects that are public (on GitHub), we can actually download the latest configs for all the MPF projects out there and then run unit tests on them against the next version of MPF (along with the migrated config files). So the idea is that as we're adding and changing stuff, we can keep testing against all the known MPF games out there to make sure we don't break anything. That functionality is in place now, but I haven't written a How To guide on it yet. But I expect to have all that up and rolling in the next few months.
So.. sorry that was a bit long-winded. Basically MPF is still alpha/beta/work-in-progress, so things will keep changing, but we're doing everything we can to make sure our changes have as minimal impact as possible. Even though MPF is new, there are almost 50 projects on it (that I know about), so we are definitely interested in not pissing a lot of people off!

Added over 7 years ago: Updated link for MPF features.

I think we'll treat the P3 hardware platform like any other. Once the specifics of the dev kit are released then we can take a look and see if it makes sense and/or how it would work. The architecture of MPF which separates the core engine from the media/display engine does allow for events to be sent in both directions. So conceivably there could be a Unity-driven component based on the P3 dev kit that acts as the media engine for MPF and also handles the ball tracking and stuff and sends that data to the core engine.

I suspect the challenge will be around which component "owns" the USB connection to the hardware. In MPF, the MPF core engine is what's connected to the hardware, and in the P3 platform that hardware connection also includes all the communication to the IR transmitters and receivers that do the ball tracking. So we'd just to see if that logic can be handled by the MPF core engine or whether there's code in the P3's Unity project for that or what.

Bottom line I guess is I have no idea, but we'll definitely take a look when the dev kit is released.

Hi Everyone,

It's been 2.5 years since the original post, and MPF is going strong. We've recently changed the website to ".org" since we're just a group of hobbyists and not a commercial company. New URLs are:

http://missionpinball.org (For general info on MPF)
http://docs.missionpinball.org (For documentation)
https://groups.google.com/forum/#!forum/mpf-users (User forum, since the one we ran on our own was too hard to manage)

Happy pinballing!
Brian

Today is the 3rd birthday of MPF!

We're still going strong with almost 8,000 commits across the various MPF repos on GitHub and almost 1200 pages of documentation and tutorials. The hardware support list is getting pretty long: P-ROC, P3-ROC, FAST Pinball, Open Pinball Project (OPP), Stern SPIKE, LISY (for Gottlieb System 1 & 80), plus lots of different stepper, servo, LED, I2C, and DMD boards.

And we're seeing that it really is possible build complex game logic with MPF's config files. (And of course for those who want to do more "real" programming, you can do that too. We recently created a developer documentation site: http://developer.missionpinball.org/en/dev/

We're now working on MPF v0.50 in time for Expo this coming October. (The current version of MPF is 0.33.)

All still completely free & open source!

Thanks for the support and use and helping create more pinball in the world!

Hi Everyone!

I'm not sure if anyone is still following this thread, but I figured I'd post this here just in case.

The MPF team is looking for the next generation of volunteer project maintainers, coders, and documentation writers. If you're interested in helping keep MPF alive, or you want to give back to the community that created the pinball software you use, please reach out!

It's wild to see how far MPF has grown since I started the project over 8 years ago. And it's cool to see how MPF flourished to meet most of the objectives I originally outlined back in Post #1 of this thread. That success is based on thousands and thousands of hours of volunteer time, primarily from Jan, Quinn, Anthony, and me, but dozens of others have contributed in meaningful ways too, especially as MPF grew to support additional hardware platforms. (27 at this point!!!)

Ideally we'd find someone who knows Python, though I didn't know Python before I got into the homebrew pinball space so you can definitely learn as you go. There's a lot of growth ahead for MPF, though frankly there's also a lot of "maintenance" type things which need to be done too. (For example, in August I spent about 100 hours re-writing all the installers and cloud build environments from scratch.)

So if you, or anyone you know, is interested in helping maintain this massive (and massively important) project, please reach out!

Thanks!!
Brian

Wolfmarsh is correct. It looks like all the files needed to support P-ROC/P3-ROC for all the latest versions of MPF and Python are in there.

The background on this is those pinproc libraries gstellenberg mentioned need to be recompiled (and sometimes lightly updated) for each new version of Python. (They are linked to Python versions, not MPF versions.) The Python foundation releases a new version of Python each year, and drops support of the 5th oldest version. MPF tries to match that the best it can.

There was a period for a few years while no one was updating those pinproc files, meaning P/P3-ROC wouldn't work on the more recent versions of Python. But luckily those were updated by P/P3-ROC users last year and it looks like there are versions to support the 5 current versions of Python (3.8 - 3.12). These are the same Python versions that MPF targets.

https://github.com/missionpinball/mpf/tree/dev/mpf/platforms/pinproc/windows

So, P/P3-ROC should work in theory for all the latest MPF versions. You can post to GitHub or the MPF Google Group if you're having issues and hopefully the people who maintain those can help out.

All that said, most of the additions / changes to MPF for the past few years have been to update it for new pinball hardware, the latest OS and Python versions, and bug fixes. So if you'r running an older version of MPF and it's working fine, I agree you can just stay on that and not deal with updating anything.