Hello all!

If you're unfamiliar with my work, I am the developer behind a few homebrew games:
The Multi-Bingo (reverse-engineered 142 bingo pinball machines to play in a single cabinet with swappable playfields using the P3-ROC) https://pinside.com/pinball/forum/topic/multi-bingo-machine

Multi-Races (reverse-engineered 36 one ball horserace games to play in a single cabinet with a single playfield):
https://pinside.com/pinball/forum/topic/multi-races-the-multi-one-ball-horserace-game

Robo-Frenzy (a new EM arcade game developed with Ryan Claytor): https://pinside.com/pinball/forum/topic/new-em-arcade-game

and three P3 games!

Quest For Glory (the point and click PC masterpiece completely rebuilt for the P3 platform): https://pinside.com/pinball/forum/topic/p3-game-so-you-want-to-be-a-hero-quest-for-glory-pinball

Ranger In The Ruins (an online-connected roguelike pinball experience): https://pinside.com/pinball/forum/topic/p3-game-ranger-in-the-ruins

Silver Falls (populate a house and complete various tasks as a custom avatar you design, with beautiful chillhop music by Scott Danesi): https://pinside.com/pinball/forum/topic/p3-game-silver-falls

--Edit 1/2022--
Flipper Foxtrot Rhythm Explosion (a unique rhythm action game) was also just released for the Cannon Lagoon module on the P3: https://pinside.com/pinball/forum/topic/p3-game-flipper-foxtrot-rhythm-explosion

I am also the long-time host of For Amusement Only: The E.M. and Bingo Pinball Podcast - https://pinside.com/pinball/forum/topic/new-pinball-podcast-with-an-em-and-bingo-focus-for-amusement-only

and one-half of the creative team behind Coin-Op Carnival, the unique, E.M.-focused zine developed with Ryan Claytor - https://pinside.com/pinball/forum/topic/coin-op-carnival-a-new-em-focused-publication

For my next game, I decided to develop a full playfield module for the P3!

This thread will document what and how, along with the challenges I face.

I use fairly old-school methods when it comes to design. As you'll see from some of the above threads, I draw schematics on vellum, and take the same approach when it comes to playfield design. I create a scale or full model on vellum, then make manual copies and use as templates for marking the actual module.

Please follow along for updates on the process. I'll be updating this thread as the module progresses (or as inspiration strikes)!

I also have a quarterly newsletter I've started. If you're interested in that newsletter, please sign up here: http://eepurl.com/hFW5aX

OK... that's enough links. Now to the game.

This game will (hopefully) pass Multimorphic approval and be sold through Multimorphic's store, available to all current and future Multimorphic customers!

My game is going to be a bit of a throwback in design, single level. I am doing this because the goals of my game do not require ramps to achieve. If I added them, I would want them to feel great to shoot and seem meaningful within the context of the game's rule structure.

The layout I'm working on requires visibility into the back of the playfield.

My family and I have discussed the theme for this game and have settled upon one. I've also determined an art style, and found an artist that will fit within the context of the theme. I've also settled upon the type of music required, and am working through the rules to determine how many voice actors will be required.

I am in the process of developing and refining a mechanism that will float above the playfield monitor. This mechanism features ball interactivity and allows for mechanical impacts lower on the playfield. Obviously there are challenges associated with that. For example, the graphical layouts will have to take this extra feature into account. Players of varying heights will need to be able to see past/through the mechanism in order to see the graphics or inserts.

Huge thank you to my friend Coleman for cutting a blank module for me! I do not own a CNC and therefore, my process on creating a playfield will be pretty manual - hand tools and pencil markings.

I will soon be transposing my vellum markings onto the horizontal part of the playfield module and ensuring tolerances are correct (distances between edges and other mechanical features on the P3) before I start routing out insert and switch slots. This process will likely require a bit of a rethink in some aspects of design.

I have a variety of mechanical features and need to assess their impact on the vertical space of the module, as well as think about the wiring process. As someone that works on games, and appreciates just how maintainable Multimorphic games are, my module will have to achieve at least that (excellent) standard.

So I have a box of shiny new parts on the way for the playfield features I am adding to the module! (They should arrive tomorrow).

Once I have finalized geometry, I will be working to get the layout into CAD. This is exactly opposite of the process of many, but while I can make a rectangle in CAD, I'm by no means an expert. I am also not an expert in woodworking, metal working, or heck, anything. But hopefully it'll be fun to follow along.

If only! Nah, I'll be working on work stuff. Very sorry I won't be at York this year.

Hopefully next year, though, this will be ready to show!

Thanks everyone!

Haha, yeah - that's the really old school type! Nowadays a heavy duty tracing paper sold in rolls is called vellum as well. It is not made from hide. I believe you can also buy sheets bound in sketchbooks (of the paper variety).

Thank you Coleman, very much appreciate the offer! We'll have to see if v1 is even worth scanning by the time I finish making holes.

...not enough... haha!

I'm finishing up a little coding exercise while I wait on my box o' parts and a replacement for the two sets of calipers that I've misplaced... off to a good start!

I did take the opportunity to upgrade my calipers to a digital model, so that should make my measurements more accurate.

The first version of the design has a small area that I expect will change dramatically. I'm attempting to figure out if a mech will fit or not... we'll see!

My appreciation for games from the 1950s and 60s agrees!

Not -inline- drops, but something kinda sort of similar. Warning that this may not work out at all and I may have to totally scrap the idea.

I'll do my best! In this case it'll be a theme that many can appreciate without the need for a license. More on that to come once I have some of the software hooks in place and get my artists/composers nailed down.

Thank you! Your ghosts shall be of service to many other P3 fans.

Some part teases while I sort out exactly which bits I forgot to order...

PXL_20210818_221224444 (resized).jpg

There's a lot of these

PXL_20210818_223625726 (resized).jpg

And one of these (so far) in the design. What theme might be appropriate with a black, white and red color scheme?

Appreciate the feedback - no need to guess if you don't want to. Posting a rhetorical question gives me a moment to do the hard bits and give you something to read/think about while you wait.

This is going to be a time intensive project. I don't have something finished and ready to show you, and likely won't for a while. My last game released last month, but it took me about 8 months to develop, does not have its own module, and I work quickly. I'll be releasing bits here and there and try to hold your interest.

You may not like the way I release information, and for that I apologize. Hopefully you'll give the finished game a shot at some point, or check in here and let me know what you think once there's more to see.

Thank you much - I hope you love RITR and your P3!

I sat down with my daughter last night, who wants to help build the first whitewood, and showed her the playfield drawing as I measured parts.

In the area that a traditional playfield arch occupies, I might have additional room to add two more mechs, but I may be more space constrained than I think due to other mechanical aspects. Being able to easily work on the game is very important to me, and keeping the cost low for you all, the end consumers. I have a price point that I would dearly like to hit, so will be working towards making the game hit that point.

I am also conscious of the weight of the module. I am shooting for something that is pretty easy to lift and store.

I've got another little software project that I'm temporarily putting down, so I'm going to start writing the module driver definitions today.

The module driver, for P3 modules, tells the system what hardware is included on the module and where it can be addressed (via PD-LED, PD-16, or SW-16). Writing a definition file is pretty convenient - it's just JSON, and you can do cool things with groups of mechanisms to make software addressing easier.

The piece that I need to investigate is how to write a module driver that is compatible with all other software. I want to ensure that if you choose to play Barnyard or ROCs that the game will function, if possible. ROCs may be a challenge due to the way I plan to serve the ball (onto the playfield instead of the habitrails). I may end up having to weld some habitrails as well, but would prefer serving to wood.

This driver will need to change if I end up adding mechs in, for example, in the top of the arch area, but that's not a big deal. I have a backup plan for that area if mechs won't function there.

Once that is done, I can continue in my planning for the software. I have various sequences planned and think I have a good balance of risk/reward on one of the mechanical features from years past that I am bringing into the design. Time in alpha/beta testing will tell, but obviously a ways away from that point.

I have plans for the playfield and screen artwork. I am still designing rules around the screen interactivity. The new mechanism I have planned, as mentioned, will cover portions of the screen (but float above), so I will be able to easily sense the ball without additional maths. Players of my previous games know that I like to utilize the walls and scoops, sometimes in simple ways, and sometimes in unique ways. I have not yet determined what effect a scoop or wall might have in the rules, but I believe I've determined a trigger for them.

My new calipers should arrive today (still can't find either set... but I know I will find both as soon as this set arrives), and will be able to begin penciling mech/post locations on the whitewood.

The mechs I'm making will have magnets in them! We'll see if I can make them work. These are not traditional magnet cores that influence the path of the ball.

Spinner might make the cut depending on positioning of some other elements. On paper there is not one (currently).
Spinners are my fall-back if my mechs can't be made to work.

Each component of the module is included in the module definition file, some specialty mechs, when defined, receive automatic parameters from the base platform. For example, adding additional flippers automatically allows them to respond to a flipper or button press when flippers are globally enabled.

I was able to define the basic switches, coils, and some lamps yesterday.

I've got several devices in the bumper definition. These devices are all automatically enabled when bumpers are globally enabled, and will fire the associated coil automatically when switches are hit. Further rule processing can be added, but this ensures immediate firing of the device. Think slingshots or pop bumpers.

Lamps require a little more planning. I have my insert lamps planned out, but I'm working on some lamps for under playfield plastics. I will hopefully have them basically mapped out at lunch today.

I picked out a name yesterday, and passed it by the steering committee: two trusted pinball friends and my family. All approved!

I've been coming up with rule and theme integration ideas and throwing them in a notepad. This is my typical process once a theme is determined, and has been going on since before this thread began. Picking up a little steam, though!

I'm a big proponent of geometry that's fun to shoot. I also prefer having options from both flippers at most times (if not all), or the ability to get a shot from the opposite side to loop to the area where you need additional targets for a sequence. As such, this layout may be polarizing. Most modern games (not all, but most), have lots of shots which are inaccessible from one of several flippers. This makes for a challenging layout quickly, as the player must be able to adapt to hitting from a particular spot on one particular flipper. Having shots accessible by both flippers only makes an easy game if the ruleset is lacking. I am a fan of difficult games (but not unfair ones). I am also a fan of simple rulesets that do not require intense study to grasp. Complete a sequence, get a reward. Straightforward, with multiple goals for differently-skilled players.

There's also a perceived complexity to modern games - seeing a layout which has lots of inaccessible shots makes a game less friendly in appearance for a newcomer. Not every game is for everybody, and this will be no exception, but the intent is to make something approachable, humorous, and fun/unique in a group of modern or older games.

**Edit** Oh yeah, and my calipers arrived yesterday! This weekend I should be able to hopefully get my mechs penciled onto the first whitewood blank, or at least in progress. It is supposed to rain for most of the weekend, so routing/drilling might need to wait for several evenings next week or the following weekend.

Module definition file: written! Additional hardware needed: purchased!

I also spent my lunch break fleshing out the game's ruleset. This weekend, when I'm not drawing and cursing geometry, I'll be programming!

I have a plan for the art and sound and will be implementing placeholders to make it easy to replace assets with finalized ones. Animations are always a bit more complicated, but I should be able to knock those out pretty easily (and last).

At a minimum, what this will do is give me the full ruleset to knock around once the playfield is assembled. That will tell me pretty darn quickly if the game is fun to shoot and the goals are relatively achievable.

I can also bake in lighting effects which will be usable immediately.

Of course, that slows down the physical build and I'd like to start building some momentum there.

I did spend more time drawing than coding this weekend (so far) - here's where things currently stand:

1) Basic Unity scene with virtual inserts and communication boxes for the player are ready for use.
2) Modes specific to the on-screen mechanism are written.
3) Playfield wood has basic elements drawn for geometric accuracy. I am using drafting tools (squares, triangles, circle templates, calipers, etc.) to divide and subdivide the playfield. On paper, some elements were a bit different than when I started laying out on wood. There are a few reasons - the spacing has been adjusted to make some cuts tighter, the angle of certain mechanisms has changed, and the ball eject has been completely redrawn. As such this has effected multiple areas of the playfield.

Good news: the changes to geometry allow several more targets and mechanisms to be placed. They will also make the shot paths a bit more challenging as I am narrowing the ball entry to the left and right side.

Bad news: my sequence rules need rewriting/expanding, and I need to rewrite some triggers for specific events to be randomized per mode/stage of the game. This means my ruleset needs a bit more tweaking, but I am excited to add more.

Good news 2: I may be able to fit more targets along the area where the playfield and sidewalls meet, allowing for extended sequences and even more ball randomization. I plan to build the first version of the module and see how it shoots before attempting to add those lower targets. Ball rebounds might become problematic in that area otherwise.

I'm really excited by the sequences and rules I already have in place. Cannot wait to shoot this first version, but want to make sure everything is well drawn before routing anything. I'll be continuing to measure and code today.

More work!

Each bank of targets has its own mode along with virtual inserts to help convey when you are completing various sequences.

For the next bit, it's important to understand a bit about the P3 module layout. Each module can have launchers in any of 7 different positions. Other mechanisms, subways, etc can feed the trough, but launchers themselves are very specific mechanisms that measure a particular amount.

In any game I've made previously (and any I've played from Multimorphic), there are multiple launchers available. This allows the game to recover from a (mechanically) failed launch by moving to another launcher.

I've confirmed with Multimorphic that a single launcher game is something that they might approve. As I initially conceived the game, there were to be two launchers. Unfortunately, using launchers in positions 3 and 5 changed the angle of two playfield mechanisms severely. There would also not be enough room between those launchers and the pop bumper to fit a post or series of posts to protect the ball gates, and thus I would have to compromise the (projected) rebounds and angles from the mechanisms below the launchers quite a lot.

So! My game will have a single launcher in position 4. This is smack in the center of the playfield. I need to create a scoop exit or bracket to feed the ball gate.

I also believe I can fit in two sets of 3 bank drop targets in the ball arch area. Doing so pushes the number of switch boards I need to 3, but I have more standup targets needed, so I'll find a use for them.

I've managed (so far) to keep all the drivers needed to a single PD-16, but as the design phase continues, more may be needed.

Current board count: 3x SW-16, 1x PD-16, and 2x PD-LED.

Each mode is keeping track of number of sequence completions and reporting back to the main mode. I plan to use this to feed sequence high score tables as well as to provide the benefits of the sequence completion within the main controller mode. With that, I can remove the target mode and add a secondary mode easily that completely changes the scoring, etc. of those same targets.

Likely those pieces will come after I get the basic geometry done and tested.

More drawing tomorrow, most likely.

Yes, I'd thought about using a s-curve or multi stage launcher, but I definitely want to avoid failed launches as much as possible. The more straightforward action of up & (slightly) over should be more reliable for this game, and the position should work well.

I'm not certain that another launcher will make this more reliable (because it would need to be a complex launcher), and it will definitely cut into the space that the ball can travel through.

Keepin' it simple.

I'm not great with pictures but I'm trying to be better...

Spent my lunch adding tons of new virtual inserts. I've also finished drawing target and insert representations for most of the new targets and mechs.

Currently working out the launch.

PXL_20210825_010913725 (resized).jpg

I've added several representations of launchers and am attempting to find the best fit for the geometry.

Prior to tonight's additions, I would have sworn it was the center.

A couple days ago I would have said it was the left/right vuks.

I think I'm back to left and right. The launches themselves will funnel out through a tiny scoop with a one way gate. If I use left and right vuks, I not only regain the ability to mechanically recover from failed launches, but also can launch onto the playfield to the upper slings. Oh yeah, there's upper slings. . What you can't see from this photo is where they are. This just shows the launcher holes and a boxed representation of the launch tube underneath.

I'm not super sold on the idea yet, and this might require a second whitewood if the first brush with launchers doesn't meet my playability standards.

It's fine if the launches are randomized by the slings, but I also don't want you waiting forever to get your ball to the flippers. Based on the angles, this has the potential to bounce for a bit.

PXL_20210825_013628608 (resized).jpgI think I have that solved. The ball will launch up on left + right. Back to the definitions... Haha

I added that third SW-16 to handle some extra targets and I'll be using more of it for the switches on these VUKs.