Very cool. Looking forward to seeing what you do with the DM Layout.

Marcus

Wow! Great job. Wish I could do something like that. Good luck the rest of the way.

Watching.

(insert Stern code joke here)

I really want to dive into this when I get some Some time.

Phenomenal.
I have seen your website and read a little of the documentation. Exciting stuff for sure and an impressive proof of concept. MPF really facilitates rapid iteration.

Do you have any idea how long it would take to getting to play the full Demolition Man ruleset?

Very cool

I would actually skip the entrance requirement and just score on the made switch, unless there's something odd like the ramp having two entrances. Otherwise, you miss scoring slow entrance-rattlers that make it but not in the allotted time, or shots that sneak under the entrance. Sequence is necessary for scoring orbits though.

Maybe to really up the challenge factor you should take people's rule suggestions, and see if you can implement them.

Awesome, I'd love to do something like this someday if I ever have some time.

I've seen Brian demo his software in person last January at Arcade Expo, and it's really an impressive project. I have to say though Brian, I'm pretty curious how it all works when the rules start getting complicated. I totally get how you got this far so fast, your demo was very convincing.

But what about when you're really implementing rules, and are stacking modes, and things become complicated? That's not something that seems configurable with a text file, you're going to have to be really coding at that point I presume.

Uh............

I assume there is no trouble shooting either, which is at least 80% of the battle. I'm not against you, I'm just putting it in perspective.

I watched while Brian debugged a hardware problem at Chicago Expo. His framework looked like an excellent platform. I'm really excited to see how far you can take this. I'm sure you will exceed just about everyone's expectations. Good Luck!

Hmm, I really don't know Demolition Man, but I'll think about it.

I've got to find time to mess with this. Too busy with other projects, but maybe after you're done with the core I can make time.

Thank you for sharing. I hope to have a custom table at some point down the road. Slowly accumulating the parts. I don't know if I've got the skill, but I'm willing to give it a shot.

A fully-custom machine is what got us started on this, and we realized that it was really hard to pull it off. Even with the tools that were available (which have been used to make really great machines), it required a ton of work to get a game playable.

So we started making the code we were writing more generic so it could be used on other machines, and eventually MPF was born. Now you don't have to worry about coding nearly as much, and can focus more energy on building an awesome physical game.

Maybe someday we'll get back to our custom project. There are soldered copper habitrails and crudely vacuformed ramps just waiting to be tinkered with again, but we're not done with MPF yet, so it will have to wait!

As a fellow programmer, I applaud you.

Basic pseudo-complicated game for a challenge, threw in a bunch of independent timers and some objectives so that modes need access and control over shared timer and variable shot value data:

1) Right ramp claw is available at the start of game. Drop the ball into one of the five available positions to light a "mode" on the major shot (besides the claw ramp) left-right corresponding to the position (left orbit, left ramp, center mini ramp, center ramp, right orbit.)

2) Each of these "modes" lights a shot for value advance and starts a timer. When a lit shot is hit it scores the current shot value and increases the value of that shot by 100k, increases the value of all other lit shots by 50k, and decreases the value of any unlit shot by 10k, or something along those lines. Any number of "modes" can be active at a given time but expire after 30 seconds of non-multiball play. The value of each shot should be tracked on the DMD in some way that shows the relative value of each shot (bar graph or something). Each mode/shot timer is independent and can be extended by hitting the claw and selecting the same drop location multiple times. Shot value progression is stopped when any of the other shot values drop to some minimum value, say 50k.

3) Qualify multiball by "locking" balls in the computer scoop (virtual lock) up to five or six balls, whatever the game allows. I believe it's five. Relight lock by hitting car crash. After hitting the computer shot, claw ramp is disabled/diverted for 10 seconds x number of balls locked. Major shot timers are paused during this period and shot value advance is disabled. Hitting the claw ramp and then the left orbit to the rear saucer combo starts the multiball.

4) Major shot value is locked and timer stopped after ten seconds of multiball play or after one additional advancement of the shot value and cannot be advanced further during multiball.

5) Multiball Jackpot scored when a given shot reaches a point threshold scored during multiball. Let's say 1 million base points scored to get a jackpot worth 10 Million x #of balls in play. Getting those shot values up ahead of time means more frequent jackpots in addition to higher base value per shot.

6) Super jackpot on claw ramp when all five other major shot jackpots have been awarded.

7) "Mode" timers resume after multiball.

Yellow Standups start 10-second shot doubler timers on a corresponding major shot, but corresponding shot is reversed left-right from the claw positions. Leftmost standup doubles right orbit, etc. Hitting a shot while the doubler is lit also advances that shot value by 20k. This is active during multiball.

9) If all five standup timers are activated at the same time , 15 second playfield doubler. If an odd number of balls are in play (not including eye scan held ball but including single ball play), playfield tripled instead. Hitting standups during the doubler time adds ~10/(#balls in play) seconds to the timer.

10) Eye Scan holds a ball during multiball as long as all major shot timers are inactive and shot values are locked. Ball is released via car crash or when only one ball is live.

11) Eye scan during single ball play holds ball and cycles the standup target lights. Launch button or topmost thumb buttons releases ball for a hurry-up shot with only one attempt allowed by timer. Hitting the lit standup awards mini-jackpot with base value determined by the standup's associated major shot value. Something like the T2 cannon shot but spread across the separated standups and requiring a flip after ball release.

12) Combos and pop bumper hits advance bonus value. This should be roughly equivalent to the existing demoman combo bonus rules so that there is a valid non-jackpot strategy available.

13) Upper lane rollovers advance bonus multiplier

The idea is that single-ball play should be pretty quick and on the fly, you have more time to breathe and shoot specific shots towards a major payoff only during multiball. Progression is limited by the need to hit all major shots occasionally, but you can go all in and get the value of one shot up if you want to try that approach. You can also "spot" value on shots you're not that great at by lighting them while another shot is lit. Not all features are used adequately. The claw shot is overly important, but this is also true on the normal Demo Man ruleset.

I can clarify or polish if you think it's intriguing enough to proceed with. It might be crap, I'm just making this up.

Again, I applaud you. However, this has little to do with programing (and trouble shooting) a game from the ground up.

While this is awesome progress, how long it takes You to do this is far from a 1 mapping for how long it will take someone new to the framework. I can also get a barebones game working in PyProcGame in this amount of time (and I know you could as well), but the point is a new person will take longer.

You have 500 pages of documentation. It will take someone hours to read that and longer to fully digest it.

Do know that I applaud your work and I love the progress toward an epic goal that we both agree on, I just don't want you to set expectations to a point that are beyond reason. I think if a non-programmer could get to where you did in a few hours (yaml and flipping) in about a day, that'd still be a win for that person.

Well, compared to learning 6809 Assembly programming, MPF should be considerably quicker...

First I want to say I find this all fantastic and your a genius.

I know nothing of programming at all so my question is this.

Are you also programing for when a switch or assembly fails and you can still continue gameplay with some sort of work around even if limited?

Are you programming for the safety issues such as locked on Flashers,Coils etc?

Just curious about all of this and will be following this thread like a hawk.

Making things accessible and open source is the path to success in projects like this, as long as the main trunk is maintained appropriately. Lots of eyes and an active community to ask for advice goes a very long way. Sure, troubleshooting can be rough, but the same can be said of troubleshooting an already coded pinball machine. Good thing we have people around on pinside that can sniff out a bad transistor from two thousand miles away.

Out of curiosity, and mostly because you list support for the P3-ROC, do you have any plans for supporting the P3 platform in a more comprehensive fashion? How easy is it to incorporate arbitrary peripherals or communicate with the Unity engine in the MPF? Would that sort of feature be something you guys would host?

I'm a little confused, but once completed this will be a completely new set of rules, animations, calls outs, etc? If so, what hardware do I need to install or is it just a chip like some of the others?

Awesome!

Brian's just doing this as a proof of concept for his python based pinball framework. If this Demo Man project ever got released, you'd need a PROC board (or similar) and a computer to run it on. Just like any existing PROC style project.

And Brian, call it whatever cute name you want, but that claw control 'mode' is python code. Games take code. Config files (which is really a new programming language you made up, too) alone will end up with boring, linear, flat games. Quickly built, sure, but dull.

I should point out that I think the MPF project is great. It's no small feat to write a whole framework to build games on. Hell, I couldn't do it, and I've written a whole game in a different framework already. I just think it's being oversold a bit.

Obviously some of what he's doing right now is just for show. No one is going to code their custom game in a handful of hours. But it's obvious once you understand the tools that the barrier to entry is very low.

There's a huge difference between being a good enough programmer to set up everything he's done so far from scratch, vs being able to handle writing some simple code to make switches on a custom toy work.

I don't even know Python, and I'm not a real coder, but I've built a lot of code heavy Flash websites in my time for instance, I'm a decent ActionScript programmer. I'm totally confident I could pick up Python well enough to add custom bits to a MF project.

That's a lot of leverage for someone like me. If you have more coding skills that I do then you're even more set.

Does that mean everyone can churn out a commercial quality code rewrite in a week? No, of course not. But if you're interested in trying to learn to write your own rules, or making a retheme or 2.0 style game? There's now something very accessible for you to start with.

To be fair, there's always been pyprocgame, which is extremely accessible as well. MPF is just taking a different tactic on some things, but procgame has a lot of the same built in parts, comes with a 'starter' game that you can have up and flipping very fast, etc. You may not be able to make an EM clone in it with just a few config files, but you could do it with pretty simple python in very short order.

So it's not that "There's now somehing .." more "There's now another option to join the existing ..."

Hey Brian,

I like what you've done, and the documentation is fantastic.

Keep going the path you are on, and don't slow down.

You should! You're not making product comparisons, I was the one who inadvertently brought that up I guess. I think the work you're doing is fantastic, and very accessible, and you should continue to tout and promote it!

awesome resource, will be diving into this in the near future, thanks so much for your efforts

Watching your progress here is inspiring. Thanks for sharing a practical application of the Mission Pinball Framework, Brian. Following along with lots of curiosity and interest in my own future project.

Haven't checked it in a while Brian but wondering if you have any support for servos/motors included at the moment? I imagine you can probably control them to some extent using the PROC or a PD16 but support for higher level control out to an Arduino for other devices would be great.

FAST Servo Controller Daughterboard w/ FAST I/O 0804

I am so stoked to get the FAST Servo Controller Daughterboards (and the rest of the boards) back from manufacturing!

I have seen Brian work his magic in person and on videos plenty of times, but I still get stoked seeing games coming to life so quickly!

Aaron
FAST Pinball

This is awesome and I want it on.My.demo man

nice