Announcing the Mission Pinball Framework: hw independent, python-based game sw

(Topic ID: 96996)

Announcing the Mission Pinball Framework: hw independent, python-based game sw


By BrianMadden

4 years ago



Topic Stats

  • 134 posts
  • 41 Pinsiders participating
  • Latest reply 1 year ago by desertT1
  • Topic is favorited by 40 Pinsiders

You

Linked Games

No games have been linked to this topic.

    Topic Gallery

    There have been 10 images uploaded to this topic. (View topic image gallery).

    Capture2.png
    Capture.png
    3bvqn-bh.png
    IMG_8104.JPG
    IMG_8007.JPG
    IMG_6708.JPG
    IMG_6704.jpg
    IMG_6821.JPG
    IMG_6817.JPG
    IMG_6682.jpg

    There are 134 posts in this topic. You are on page 1 of 3.
    22
    #1 4 years ago

    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 pull in a lot of 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!) from http://docs.missionpinball.org.

    Thanks!
    Brian Madden & Gabe Knuth

    #2 4 years ago

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

    #3 4 years ago

    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

    #4 4 years ago
    Quoted from travisbmartin:

    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!

    #5 4 years ago

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

    #6 4 years ago

    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?

    #7 4 years ago
    Quoted from travisbmartin:

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

    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.

    #8 4 years ago

    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

    #9 4 years ago
    Quoted from horseypin:

    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?

    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,

    #10 4 years ago

    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.

    #11 4 years ago
    Quoted from travisbmartin:

    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,

    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.

    #12 4 years ago
    Quoted from s1500:

    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.

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

    #13 4 years ago
    Quoted from horseypin:

    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.

    #14 4 years ago

    I thought you wanted to run pyprocgame with VP.

    #15 4 years ago

    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

    #16 4 years ago
    Quoted from BrianMadden:

    So let them price war and let us win.

    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.

    #17 4 years ago
    Quoted from horseypin:

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

    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.

    Quoted from horseypin:

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

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

    Quoted from horseypin:

    would like to know if I could use all these modes I've written for pyprocgame to use with a fast

    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.

    #18 4 years ago

    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!

    #19 4 years ago

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

    #20 4 years ago

    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.

    #21 4 years ago
    Quoted from Whysnow:

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

    I think he has his own for that...

    Quoted from BrianMadden:

    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.

    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.

    #22 4 years ago

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

    #23 4 years ago
    Quoted from sd_tom:

    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 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.

    Quoted from horseypin:

    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.

    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.

    Quoted from BrianMadden:

    it seems crazy that with a P3-ROC you're paying almost 4 bucks per switch.

    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: gstellenberg@multimorphic.com

    Quoted from travisbmartin:

    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.

    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

    #24 4 years ago

    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.

    #25 4 years ago

    > 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.

    #26 4 years ago

    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.

    #27 4 years ago

    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.

    #28 4 years ago

    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:

    Quoted from Whysnow:

    Will this also work with Ben Heck's board/ hardware?

    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.

    #29 4 years ago

    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!

    #30 4 years ago

    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 :

    Quoted from BrianMadden:

    Be easy enough for non-programmers so that anyone without programming skills can get a machine up and running.

    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!

    #31 4 years ago
    Quoted from Snux:

    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.

    #32 4 years ago
    Quoted from horseypin:

    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!

    #33 4 years ago
    Quoted from BrianMadden:

    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.

    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.

    #34 4 years ago
    Quoted from horseypin:

    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.

    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!!

    #35 4 years ago
    Quoted from Wolfmarsh:

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

    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

    #36 4 years ago
    Quoted from Snux:

    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.

    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

    #37 4 years ago

    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

    #38 4 years ago

    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.

    #39 4 years ago
    Quoted from toyotaboy:

    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.

    #40 4 years ago
    Quoted from toyotaboy:

    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.

    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

    #41 4 years ago
    Quoted from toyotaboy:

    Most of us don't want to learn programming, they just want to build pinball and choose options.

    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

    #42 4 years ago
    Quoted from toyotaboy:

    I personally think P-ROC is a huge barrier to entry from everything I've read.

    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.

    #43 4 years ago
    Quoted from fastpinball:

    This is a video I made for some friends showing my portable pin

    Portable pins, could be onto something there...

    #44 4 years ago
    Quoted from Snux:

    But I can't ever see it being something easy.

    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

    #45 4 years ago
    Quoted from horseypin:

    Portable pins, could be onto something there...

    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
    #46 4 years ago
    Quoted from fastpinball:

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

    Hah, that is pretty great!

    I have that same luggage too.

    #47 4 years ago

    Cool! Wish I could be there.

    #48 4 years ago

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

    #49 4 years ago
    Quoted from horseypin:

    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

    #50 4 years ago

    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.

    Promoted items from the Pinside Marketplace
    $ 134.95
    Lighting - Other
    Hookedonpinball.com
    $ 9.95
    Playfield - Protection
    ULEKstore
    £ 20.00
    $ 53.00
    Cabinet - Shooter Rods
    ModFather Pinball Mods
    $ 259.99
    $ 175.00
    Lighting - Interactive
    Professor Pinball
    From: $ 20.00
    Playfield - Toys/Add-ons
    ModFather Pinball Mods
    $ 14.95
    Playfield - Toys/Add-ons
    ULEKstore
    $ 106.95
    Cabinet - Shooter Rods
    Super Skill Shot Shop
    $ 71.99
    Lighting - Interactive
    Lee's Parts
    $ 48.00
    Cabinet - Other
    ModFather Pinball Mods
    $ 229.99
    $ 239.99
    Cabinet - Toppers
    Tilttopper
    $ 69.99
    Playfield - Toys/Add-ons
    Lighted Pinball Mods
    $ 495.00
    Cabinet - Armor And Blades
    MI Pinball Refinery
    $ 48.00
    Cabinet - Other
    ModFather Pinball Mods
    $ 99.99
    Lighting - Other
    Lighted Pinball Mods
    $ 2.00
    Various Other Swag
    Project Pinball Charity
    $ 25.00
    Boards
    German-Pinball-Modular
    $ 35.00
    Cabinet - Decals
    Bright Lights Pinball
    $ 12.00
    Lighting - Led
    Bright Lights Pinball
    $ 9.99
    Eproms
    Matt's Basement Arcade
    $ 11.99
    $ 86.95
    Cabinet - Shooter Rods
    Super Skill Shot Shop
    There are 134 posts in this topic. You are on page 1 of 3.

    Hey there! Got a moment?

    Great to see you're enjoying Pinside! Did you know Pinside is able to run thanks to donations from our visitors? Please donate to Pinside, support the site and get anext to your username to show for it! Donate to Pinside