From zero to a flipping game in 1h45m with the Mission Framework

(Topic ID: 121809)

From zero to a flipping game in 1h45m with the Mission Framework


By BrianMadden

3 years ago



Topic Stats

  • 69 posts
  • 36 Pinsiders participating
  • Latest reply 2 years ago by pinballrockstar
  • Topic is favorited by 29 Pinsiders

You

Linked Games

Topic Gallery

One image has been uploaded to this topic. (View topic image gallery).

IMG_0201.jpg

There are 69 posts in this topic. You are on page 2 of 2.
#51 3 years ago

Unfortunately I didn't have too much time to work on this today. I just put in an hour right now but I have to stop, so I wanted to post this update.

I started implementing Law's game rules, and I'm part way through Step 1.

I made it so the claw is lit when the game starts. Shoot the right ramp, diverter activates, ball to claw. Select your drop point to pick which ramp you want to light. I only have the left ramp setup so far, but you can drop it, music starts back up, ramp is lit with a countdown. (A lot of this stuff is handled by MPF.. like the diverter.. you set it up in your config file, and then whenever the elevator wants a ball it will automatically activate the diverter on the ramp entrance switch. It knows the timeouts, etc.)

Demo here:

I spent an hour on this right now, bringing my total game programming time to 6 hours, 15 min.

Everything here was done with our config files "language"

Here's the config for the mode where the claw is lit which is active when the game starts

-----
Mode:
    start_events: ball_starting
    end_events: start_mode1_acmag
    priority: 200

LightPlayer:
    mode_claw_lit_for_major_mode_started:
        lights: l_claw_ready
        script: flash
        tocks_per_sec: 4
        repeat: yes
    balldevice_elevator_ball_enter:
        lights: l_claw_ready
        script: off

LogicBlocks:
    Accruals:
        enable_the_claw:
            events: mode_claw_lit_for_major_mode_started
            events_when_complete: light_claw
        start_acmag:
            events: sw_acmag
            events_when_complete: start_mode1_acmag

SlidePlayer:
    balldevice_elevator_ball_enter:
        type: text
        text: PICK YOUR MODE
-----

Any here's the code for the left ramp lit countdown mode:

-----
Mode:
    start_events: start_mode1_acmag
    end_events: timer_mode_countdown_complete
    priority: 300

Timers:
    mode_countdown:
        start_value: 30
        end_value: 0
        direction: down
        start_running: true

SlidePlayer:
    timer_mode_countdown_tick:
      - type: text
        text: "COUNTDOWN: %ticks"
        font: small
        v_pos: bottom
      - type: text
        text: SHOOT THE LEFT RAMP
        decorators:
            type: blink
            repeats: -1
            on_secs: .3
            off_secs: .3

LightPlayer:
    mode_mode1_acmag_started:
        lights: l_left_ramp_arrow
        script: flash
        tocks_per_sec: 4
        repeat: yes
-----

Obviously a lot more to do, but I'm just showing that yes you can do timers and modes and all that just in config files.

#52 3 years ago
Quoted from BrianMadden:

I suspect that people using a P-ROC will add an additional USB-based servo controller? I've got a few different ones from Sparkfun and Pololu. Which ones are you thinking?

I have an Arduino working with this motor shield https://www.adafruit.com/products/1438 and this servo shield http://www.adafruit.com/product/1411.
Controlled via USB from a PC to the Arduino at the moment using adafruits code but I'm thinking I'll roll it into my own framework soon.

That FAST servo daughterboard looks pretty good.

#53 3 years ago

I think epthegeek is just jealous MPF wasn't around when he started CCC!

#54 3 years ago
Quoted from jwilson:

I think epthegeek is just jealous MPF wasn't around when he started CCC!

Nah. Not at all.

I realize reading it back that I may have come across more harsh than I intended. I think MPF is a fantastic project. People are absolutely going to do cool things with it. I just worry about the hype part. I mean, look at the config file Brian posted above. That's a programming language. It's pretty complex, because it has to be. Pinball code is complicated.

If you spend too much time telling people how super easy it's going to be, they'll be irritated when it's not.

#55 3 years ago
Quoted from epthegeek:

If you spend too much time telling people how super easy it's going to be, they'll be irritated when it's not.

Maybe it's not the easiest thing...

But in my experience When i first got the P-ROC and went through the many hours of just installing that mouthful (libpinproCgame etc...)(this was before Compy's one click installer), I quickly realized without a "P-ROC for dummies" I was not going to get very far.

Two weekends ago i installed MPF on my machine and went through the tutorial to step 11 or so and had a very simple machine running on a virtual desktop. It took 3-4 hours. it was not frustrating in any way.

I applaud Brian and Gabe's work here. to put in the kind of work they have and distribute it for free is pretty damn selfless...

Well Done!

#56 3 years ago
Quoted from Law:

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?

Sorry I forgot to answer this today. (For those who aren't familiar, the P3 platform from Multimorphic is that thing where the playfield is a giant LCD screen and there's a grid of infrared beams across it that track the ball.)

EDIT: To be clear, the P3 platform is still physical pinball with physical things to shoot at.. flippers, slings, targets, ramps, toys, etc. It's just that the lower two-thirds of the playfield is an LCD screen instead of painted wood. (The flippers and slings ride on top of it.) I just wanted to clarify so people don't think the P3 is like a virtual pin cabinet. /END EDIT

We have no plans to support the P3 platform at this time. That may change of course, but I know nothing about it other than playing it at Expo. (For me I'm a "pinball" purest, and the P3 feels too much like a video game to me, so I'm going to focus the next few years on more traditional pinball development. But if someone who loves the P3 thinks MPF would be a good fit, I'd certainly help them out!)

For arbitrary peripherals, it depends what it is. Really if there's a Python wrapper for it, then we can do it. We've already experimented with standalone USB-connected LED controllers, servo & stepper controllers, and some little USB displays, and those seem like they're all easy enough to get hooked in. The real question is how well we can integrate it into our config files in a way that's logical to use. But overall MPF is very modular, with almost every component being pluggable and/or replaceable. So I think just about anything can be integrated pretty easily.

For communication with the Unity engine, we did a proof of concept a few months ago for an environment that needed to communicate with a standalone graphics rendering system, and that all seemed fine. So really as long as we can send the display system messages about what's happening or what we'd like to see on the display (what to display, positioning, size, animations, etc.), it should be fine.

Our "ideas list" has about 3 years worth of stuff on it, but we're happy to prioritize based on demand. So if anyone reading this thinks up some cool feature they're like to see, let us know!

#57 3 years ago
Quoted from epthegeek:

I mean, look at the config file Brian posted above. That's a programming language. It's pretty complex, because it has to be. Pinball code is complicated.

I like this (and what you said before) about the MPF config files really being like a programming language that we made up.

The advantage of the MPF "language" over Python (in the context of pinball) is that MPF is higher level and pinball-specific. MPF is to Python what Python is to C (and what C is to assembler). But yeah, even with a step-by-step guide to getting started, there are still multiple ways of doing everything. (Is that a shot or a logic block? What logic blocks should be in which modes? Is this a script or a show? Should this mode do two things and block what's below, or should it be two modes?)

That said, I will still try to write as many step-by-step tutorials and examples as I can and to make MPF as easy as possible for newbies while keeping it powerful and flexible enough for someone more experienced. And if people get irritated because it's not as easy as they thought, well, it's Pinside. People irritate easily.

#58 3 years ago

Can this be used to make a stand alone Stewie Pinball machine to Play?

Not a trick question, I have a NIB Stewie Pinball and it would be cool to make it it's own machine without installing it into a FG.

#59 3 years ago
Quoted from Eddie:

Can this be used to make a stand alone Stewie Pinball machine to Play?
Not a trick question, I have a NIB Stewie Pinball and it would be cool to make it it's own machine without installing it into a FG.

You would need hardware to drive it and an adapter wiring harness, iirc. Dave (hardware designer w/ FAST) has wanted to do this too. Would be pretty cool to see!

Aaron
FAST Pinball

#60 3 years ago
Quoted from Eddie:

Can this be used to make a stand alone Stewie Pinball machine to Play?
Not a trick question, I have a NIB Stewie Pinball and it would be cool to make it it's own machine without installing it into a FG.

You have got to make this happen!!!

#61 3 years ago
Quoted from jwilson:

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

Best comment so far!

#62 3 years ago
Quoted from BrianMadden:

Sorry I forgot to answer this today. (For those who aren't familiar, the P3 platform from Multimorphic is that thing where the playfield is a giant LCD screen and there's a grid of infrared beams across it that track the ball.)

Ack, Brian! Not looking to derail the thread... just want to correct this description. This misconception about the P3 is common from people who have never seen it in person, but you know better and hopefully didn't mean to perpetuate this misconception.

The playfield in the P3 is not a giant LCD screen... just the lower part of the playfield is. That lower part is, you know, the area that's traditionally a painted piece of wood with very little but blinking insert lamps. One could argue we just replaced what is traditionally 20-30 insert lamps with 2,073,600 RGB-lit rollover switches!

The upper portion of the machine is, just like most modern ('80's and up) machines, purely mechanical pinball (wooden playfield with inserts, ramps, targets, pop bumpers, etc, etc). The beauty of the P3 is that this entire physical playfield is modular and can be swapped with other physical playfields, making the P3 a true multi-game platform with easy to manage (ie. not unwieldy) modules. (http://www.multimorphic.com)

Quoted from BrianMadden:

We have no plans to support the P3 platform at this time. That may change of course, but I know nothing about it other than playing it at Expo. (For me I'm a "pinball" purest, and the P3 feels too much like a video game to me, so I'm going to focus the next few years on more traditional pinball development. But if someone who loves the P3 thinks MPF would be a good fit, I'd certainly help them out!)

A pinball purist coding in python instead of assembly? That's sacrilegious! Wait, you're the guy who took an EM, ripped out the guts, replaced them with a P-ROC + PDBs, and re-implemented the rules in python. Don't get me wrong, that was a fantastic project and very well executed, but it's most definitely not pinball purity! (I'm of course just messing with you - I'm a fan of your efforts.)

OK, back on topic... the cool thing about getting DM flippable in a couple of hours on MPF is that it means MPF is far enough developed to be discussed as a viable framework for people developing new pinball machines. That's a testament to all of the hard work Brian and Gabe have put in over the last couple of years as well as a nod to all of the foundation work from others in the community who have supported Brian and Gabe as well as pyprocgame over the years.

One of the primary reasons frameworks like MPF, pyprocgame, netprocgame, FreeWPC, etc are developed is to make new pinball programmer's lives easier. We all owe a tremendous amount of respect to Adam Preble and Brian Dominy, two absolutely brilliant software engineers who developed the foundation of pyprocgame and FreeWPC, respectively, which serve as the primary inspiration (and blueprints) for all of the high level framework development being discussed here.

Quoted from BrianMadden:

I like this (and what you said before) about the MPF config files really being like a programming language that we made up.
The advantage of the MPF "language" over Python (in the context of pinball) is that MPF is higher level and pinball-specific. MPF is to Python what Python is to C (and what C is to assembler).

Just a little bit of caution from somebody who's been through this before. The concept of developing pinball rules in config files is interesting and sounds great to the layman, but when you get into the details, the complexity grows and the advantages disappear. In order to make the config file 'programming' approach attractive to non-programmers, the format has to be very simple and therefore the available feature-set has to be severely limited. Otherwise, the 'programming language' you're creating becomes complex enough that it's actually easier for developers to program with python inside of MPF than with your config files on top of MPF.

There's a wealth of resources, tools, and communities for python developers, none of which exists for MPF config files. Suggesting that non-programmers learn to 'program' using YAML-style config files is probably fine for EM-style game rules, but is likely doing them a disservice for more complicated rulesets. I'd suggest doing your best to continue enhancing the feature-set in MPF to make programming rules in python easier, rather than spending time making the config file 'programming' more capable and therefore more complex. Just my $.02.

Either way, keep up the good work. Your efforts are clearly helping people understand these high level frameworks can help even non-professional programmers be successful developing new pinball games.

- Gerry
http://www.multimorphic.com

#63 3 years ago
Quoted from gstellenberg:

The playfield in the P3 is not a giant LCD screen... just the lower part of the playfield is.

Yeah this is a better description. I didn't mean to give the wrong impression. P3 is still real physical pinball with real targets and stuff. I forgot that with virtual pin cabinets people might think that the P3 is just virtual pinball, which it's most definitely not. I like the description of replacing 20-30 single color inserts with 2m RGB inserts that also know when the ball is on them. I'll edit my original comment to point this out too.

Quoted from gstellenberg:

Suggesting that non-programmers learn to 'program' using YAML-style config files is probably fine for EM-style game rules, but is likely doing them a disservice for more complicated rulesets. I'd suggest doing your best to continue enhancing the feature-set in MPF to make programming rules in python easier, rather than spending time making the config file 'programming' more capable and therefore more complex

Yeah good point. I guess this is kind of all semantics really. What's "programming" and what's not? What's a "configuration file" versus a "program code"? We're trying to build a platform that makes it as easy as possible for people to program a full machine, including all the most complex rules they want.

So far it seems that we can do everything we need via the config files for game logic and whatnot. But if someone thinks that's a horrible idea, then they can write all their game logic in Python and just use the config files for the base hardware and device config. (The API is heavily documented at http://mpf.readthedocs.org .) They'd still get all the other advantages of MPF, and really that'd be fine by us.

Really the config files just expose stuff that would be manually created in code anyway. (Timers, logic blocks which track progress towards goals, playing display shows, sounds, or lights based on events, etc.) So they're there, use them or not. Doesn't matter to us.

As for our efforts, yeah, also a good point. We focus on adding features first, then exposing them to config files. But everything we add to MPF is available directly via the API without the config interface if people want it. We'll definitely continue to do that and not make a big deal about "no programming."

#64 3 years ago

I think the MPF is f**king awesome. Let's not let this thread dissolve into semantics or go off track. Brian can do shit in an hour you can't, fine. But it's still an incredible tool. Keep it up man, I love it.

#65 3 years ago

Thanks everyone for the encouragement, feedback, and ideas. Here's an update on our future plans for our Demo Man game:

First, today I'm going to go back to working on core features of developing MPF rather than spending my full pinball time on developing this game. This exercise was an experiment to see what I could do in a day with a new machine, and now it's done.

One thing we realized from this process is that while MPF has a lot of "big" features, there are also lot of little things missing that we need as the "glue" to tie together all the pieces into a complete game. Since we really like @Law's game rules outline, we want to continue to work on building a Demo Man implementation of it, as it will be good guidance for us to make sure that we have everything we need in MPF. (And, if I'm being honest, his ruleset sounds really cool and I just want to be able to play it!)

So as we knock out features for MPF that will be useful in Demo Man, we'll continue to update our Demo Man game code and post the progress and videos here. I don't know how often those will come. Every few weeks maybe? Some of the things we really need to do in MPF are boring behind-the-scenes things or things that don't come into play with Demo Man. (Today I'm working on a better config file processing engine, and Gabe is working on our Windows installer. Wooo.)

But we'll keep chipping away at Demo Man. Once Law's ten ideas are in place, it might be cool to get some dots and sound guys (not us) to contribute some stuff (all new, nothing which uses licensed content) and then maybe we can create community-built open source pinball game code that people might actually want to play! (And since it's written in MPF with much of the config in config files, anyone who doesn't agree with anything can just download it and change the config for their own machine to whatever they want.)

One step at a time though since MPF is still version 0.15 and we haven't even gotten through Item #1 on Law's list. Stay tuned...

Brian (me) & Gabe (bulldoggk)

1 month later
#66 3 years ago
Quoted from gstellenberg:

Just a little bit of caution from somebody who's been through this before. The concept of developing pinball rules in config files is interesting and sounds great to the layman, but when you get into the details, the complexity grows and the advantages disappear. In order to make the config file 'programming' approach attractive to non-programmers, the format has to be very simple and therefore the available feature-set has to be severely limited. Otherwise, the 'programming language' you're creating becomes complex enough that it's actually easier for developers to program with python inside of MPF than with your config files on top of MPF.
There's a wealth of resources, tools, and communities for python developers, none of which exists for MPF config files. Suggesting that non-programmers learn to 'program' using YAML-style config files is probably fine for EM-style game rules, but is likely doing them a disservice for more complicated rulesets. I'd suggest doing your best to continue enhancing the feature-set in MPF to make programming rules in python easier, rather than spending time making the config file 'programming' more capable and therefore more complex. Just my $.02.
Either way, keep up the good work. Your efforts are clearly helping people understand these high level frameworks can help even non-professional programmers be successful developing new pinball games.
- Gerry
http://www.multimorphic.com

From my own perspective with freewpc (which also uses config files) the config files doesn't have to be the end ability. The code is open source so if there is a specific rule, device or whatnot that is needed but not in the framework, then just write it in the framework yourself.

5 months later
#67 2 years ago

I am not a programmer at all. Learned some Turbo Pascal 20 years ago, but that was then. This mission pinball framework + all the documentation that is available are the reasons I bought a P-ROC to experiment with. Without these I would not have considered starting a custom pinball project.

Plan of attack:
1. Replacing a WPC CPU and having a flipping machine.
2. Experimenting with rules and programming / scripting.
3. Getting help online.
4. Building a whitewood.
5. Getting help online.

But first, let's get my Evel Knievel restored (and finish the house).

1 month later
#68 2 years ago
Quoted from Avatar:

Learned some Turbo Pascal 20 years ago

LOL! me too! turbo pascal!

I have been trying to recall what that system was called (that i forgot for the full 100%)from high school!

Thanks avatar.

#69 2 years ago

So we tried pyprocgame first for our WCS/minions retheme pinball and switched to mpf because it simply has a tutorial.
It was agonizing to use pyprocgame,we felt so stupid?
But Mocean is a supernice guy and got our game flipping in a heartbeat from the other side of the ocean(Inner voice:"Mocean...from the other side of the ocean").
But there we were stuck again and nothing seemed to roll.
So we had to switch to MPF cause that was simply what we needed at that point in time.
Don't choose side for pyprocgame or mpf...choose pinball.
I think everybody should basically realise that everything that helps building a pinball is golden.

Promoted items from the Pinside Marketplace
$ 269.99
From: $ 16.95
$ 28.00
$ 9.99
Eproms
Matt's Basement Arcade
$ 129.00
Lighting - Led
LED OCD
From: $ 9.99
Eproms
Matt's Basement Arcade
$ 229.99
Lighting - Other
Lighted Pinball Mods
There are 69 posts in this topic. You are on page 2 of 2.

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