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.

Thank you all for the kind words thus far, and for those of you that have previously purchased one of my software-only games, and are excited for another game from me, I truly appreciate it.

Lunchtime today - added several more virtual inserts (there are a lot on this game), added new target modes (I added four new targets last night), and modified my module definition to include the new lamps + switches, revert my change to the launcher, and otherwise make some simple tweaks.

I've been thinking about the ball launch. Ball launches on the P3 are vertical. As such, if I want to redirect them horizontally, I need to have some kind of bracket or mechanism in place.

I might need to have a custom bracket bent. Not sure yet - I'm going to try a prexisting bend from another type of bracket (that I need for one of my shots anyway). From a costs perspective, there's quite a bit in this module and I'm worried I might need to make cuts - I should rephrase, I definitely will need to make cuts to meet the price point I want. That tells me my price point was too low. That's future Nick's problem, though.

When the second whitewood is being drafted, that's when I'll need to review receipts and ensure that bulk parts purchases/assembly/shipping will be covered, unless I need to make major geometric changes and build a third whitewood without cost cutting.

The P3 modules are fantastic from a whitewood perspective as well, as I can simply transplant most of the guts of the module without a lot of time or trouble. That comes down to the boardset, of course, and the SW-16, PD-16 and PD-LED are perfectly sized for a modular build approach.

I've also been thinking about t-nuts and airballs. I have a few posts which are going to get hit by the pop, and I'll want to ensure they withstand those attacks. Most other posts will be using wood screws. As a single level game with flat plastics (as conceptualized, at least), there's a good possibility for a ball to fly over the plastics and cause damage to the plastics. I'll need to figure out if there's a (nice looking) way to prevent this. All in due time.

On the plus side, I think I'll be able to do some routing tests this weekend. If I get a good process down, I should be able to start routing out spaces for various targets and inserts, and maybe my launcher holes.

I've talked about my process before, but I try to work on a project at least 15 minutes a day.

Today, I worked for an hour (at lunchtime), but was flat out exhausted when I got home from work, so I took a nap after spending some time with the family. That will have to do for today.

I started work on fleshing out the GUI Inserts. These are virtual inserts that appear (or disappear) based on your programming. They can be whatever size and whatever color you choose.

Each set of targets, when completed, will give you an award. Awards for target completion will stack, to be cashed in at the end of a mode.

The GUI Inserts will appear for a moment, showing which switch was hit, and showing the completed sequence icon (when applicable). Each completed sequence changes the background color of the inserts.

The same is true of the insert lamps, so these colors will match.

I showed the full drawing to a couple of friends to get their opinion. They were confused by a few inserts near a mech, so I may not include inserts in that area.

In other news, I did receive a couple more boxes of parts. Two 3 bank drop target mechs and a bell assembly, as well as Multimorphic rgb insert and flasher boards.

I've also reached out to a potential artist for this project. As with any contracted work for one of my games, I try to lay out everything that is potentially difficult and ensure they are still on board. This includes sending them an image or video of the P3, and laying out, in this case, all the various types of artwork necessary.

1) playfield screen animations
2) back box animations
3) playfield artwork
4) playfield module plastics
5) slingshot and side target plastics
6) insert artwork
7) apron artwork
8) cabinet artwork

I can and will work with multiple artists if there are some things this artist chooses not to do. There are also some items on the list that are optional and I may not do based on budget. Of course everything I am able to accomplish could be used to offset costs of other items... So everything is a tradeoff.

Since the theme was settled upon, I've been doing some simple musical compositions (in my head) and believe I have a good direction to start soliciting composers/musicians. I would ideally like music in between five or ten different styles focusing on a set of instruments.

So I guess I got more than that hour done in planning time.

Tomorrow, I'm likely going to start drilling and routing. I'm -not- a woodworker, but I can fumble my way through cutting stuff most of the time. Worst case scenario, I can always start over.

Pictures to follow once I do some cutting.

Whew, hours of cutting and routing and sanding later... And I'm about 1/2 done. Mistakes definitely made. 16301124637198242581598504526591 (resized).jpg

16301125272081726306325715711797 (resized).jpg

More sanding and routing ... And drilling needed, but I have the pop base all inserts and the back area of each standup complete.

I still have ball launchers, slings, and dt mechs left.

All routing complete, at least for this initial version. I have a few spots I may need to drill for GI.

Didn't order enough inserts in the size I need, so gotta get a few more of those before I can try in the machine. Of course, a lot of work left to do before then.

Some routing mistakes and issues caused by my super cheap handheld router will certainly be fixed once I have a CNC version, but this is good enough for me to tell if the core gameplay concept will work.

I've never wired up an RGB LED. Not looking forward to that. Common solution is to use a ribbon cable, but routing those is tricky. I'll have to look up or measure the spacing of the pins on the pd-led and see if there's a way to use a crimped connector. Feel like it would be easier to coil and ziptie or lace the cables that way. You can cut a ribbon cable apart, but it's easy to accidentally cut into a wire. ...just thinking out loud. I'll probably use ribbon cables.

Ava is going to help me with the copious amounts of soldering necessary for switches and mechs.

My drop target mechs are system 11-style and pin out to a sw-matrix style connector. I'm assuming I can assign gnd to the row pin and then the inputs to columns. I'm not sure if that will actually power the optos, however. Seem to recall those receive power from a 5V source.

It was very hot and I was in direct sun all afternoon cutting, drilling and sanding, so I'm going to take a break this evening. Will be in good place to do some bolting to wood tomorrow.

I got a barrel full! I have a bunch of inserts and I'm just thinking the ribbon cables will make a mess.

Finished assembly. Some issues:
1) I ordered switches with caps installed accidentally so Ava is currently helping me desolder each switch.

2) Some extra fun mechs I have installed on the underside of the playfield prevent installing some boards. Thinking about it, and looking at the MM modules, no boards are installed on the backside of the module (I was planning to make a metal cage). Makes perfect sense, but that means I need to think about mounting differently. So I printed several vertical board mounts, need to buy some heat set nuts, and some 6/32 screws.

3) The mounting brackets for these switches are very looooong. I have a few switches with different brackets that are needed. I'm thinking that I might need to change them all to the narrower type for simplicity of production.

4) I didn't order enough insert boards. (I added a couple of targets).

5) I was wrong about which launch tubes I had on hand, so I need to order some more of those...

6) I have plenty of switch wire, but no coil wire on hand. Doh.

7) I am also out of 1.5" white rubber rings. Need two more. Double doh.

noticed all the ribbon cables from pbl have four pin connectors, but mm light boards have five... So I'll need to crimp em by hand anyway. Ah, well. Lets me get exactly the length I need.

Luckily, I DID order enough inserts, I just misplaced a bag.

Should be finished, hopefully, making pigtails for all the switches tonight.

I might be quiet for a few days on the hardware front (while I wait for more stuff to come in), but I'll be working on software.

I'll probably also try dry-fitting the module in the P3 and make sure all my everything clears appropriately.

Interesting idea - there's a lot of force behind the launch, I wonder if it would need metal reinforcement - might be easy to use a brake then 3d print a sleeve.

I've been considering grabbing one for each position for prototyping purposes, but I'll need several copies of the tubes for this one - couple Whitewoods, mm submission, and beta testers. So... Maybe I'll wait for a bit on the extra tubes.

5th pin on the Multimorphic LED boards is used for stability rather than signal, that's excellent and means I don't need to crimp a bunch of small wires.

Thanks Coleman. Yeah, I was planning on cutting back to the right size, but for initial testing, I can leave the default ends crimped and roll up and ziptie the extra.

The connectors are .100, so it's not too tough, just takes time.

Speaking of time... the JST connectors and pins were backordered. Should arrive by early October. I have a few connectors I might be able to re-use to get me testing the physical build before then.

Once I have geometry concept proved out, I'll be tearing apart and converting to cad, hopefully to CNC the next version.

While I work on that, I have the other physical mechanisms for the screen area to finish prototyping.

Mechs, yes. Well, if I can make them work.

I am still new to CAD and modelling in general, but I plan to attach to the frame on the sides at multiple points. I have some posts that will be floating and can be impacted by the ball. If that happens, they will twist, so the model/attach point has to be able to absorb that twisting action. Works in my head, but once I have it attached it may fall apart instantly or be so ugly that I won't want to use it.

On the plus side, after soldering switches was done last night, I hauled the module around and was able to move very easily. It also currently stands up on its own, which is a plus.

I'll find out tonight!

It fits! Except I have the wrong launch tubes installed so it gets hung up a fraction above where it should. New tubes on the way, but I'm reasonably sure everything is great.

More building tonight - I have all the coils wired up, including the pop socket (driven from the driver board).

I've printed a set of board standoffs to allow me to mount my switch, LED, and/or driver boards anywhere on the underside of the playfield. I used brass heat set nuts to form a sturdy bond between the bracket and the board with a 6-32 screw. Pretty cool - my first time using heat set nuts and I'm very impressed. If the iron is not too hot (and it only takes a moment to heat to the perfect temperature with a brass insert), the resulting bond is very strong. Unfortunately, I ruined an entire batch by installing the nuts on the wrong side of the bracket (whoops!). New parts are printing now.

I also installed the ball gates above the launchers, decided how I was planning to use another part, and figured out the last of my post geometry (for now).

I ran a ball over the playfield module as it sits right now and... I can't wait to flip this thing. I think it's going to play exactly as I want it to.

I still have quite a wiring task left as I need to take my pigtails and start crimping them. I wanted to wait until I had the board positions mapped out properly before I started that as I'll need to cut the wires to appropriate size.

On the programming front, I continued to work on my graphical inserts. As on older games, one sling at a time will be lit for more points. I like games where you have to chase points like that, and are rewarded for risky play. Nothing you have to focus on, but it'll be neat, regardless.

Prints finished last night and I installed the nuts on the proper side of the mounts this time.

More wiring progress: I have each board's position set under the playfield. I started crimping wires to make connectors for coils and filled out 1/2 of my PD-16. The other half will be used to drive 5V items. I am still planning how I want to route the wires for those, so leaving them hanging for a bit. I ordered the crimper recommended by Multimorphic. This one works very well. Always takes me a minute to adjust to a new ratcheting crimper.

I also made the connectors for about 1/4 of my switches. I ran out of 10 pin .100 connectors... so need to order some more of those. Also turned out I didn't replenish my stock of .100 and .156 pins, and zip ties once I stopped doing service calls. I'll get those ordered soon. I also need to grab some 2 and 3 pin .156 female connectors.

Spent part of the evening reading documentation for each board. This is the third game I've wired, and I never trust my memory. Thankfully, Multimorphic has all pinouts documented on their site. In times past, I've printed out a copy of the pinouts for each board, but am trying to work from a screen this time as I can easily carry the module to my kitchen table. Quite convenient in comparison!

My task while I wait for the next parts/boards/crimp pin shipments is to read up on the optos used for the launch tubes. Those use JST connectors (which I have on the way), but each opto has more pins than I would expect.

Once I have all the switches wired up, I will be able to work on the LEDs. I mentioned above that I have a lot of premade ribbon cables from Pinball Life. Those will significantly cut down on wiring.

On the software side, I restructured my module definition file to match the wiring. I have banks of switches which are separated based on how they are wired. Previously, I had the switches separated by function.

At lunchtime, I modified all my GUI inserts to fall behind the bonus popup, and render on top of the apron display. Sounds minor, but took a minute to get just right. Also, I started testing the ephemeral and persistent inserts and made sure that they were triggered at the right time.

Worked like crazy last night and this morning before work and finished wiring the module with variety of spare/scavenged parts. I should be able to pop it in the machine and test that my wiring is correct, at least, this weekend!

I plan to spend the weekend programming while I await the last few bits I need to finish the physical build and start working on the above-screen mechanism.

I'll be sharing more as I verify geometry. Just got home and am doing final checks before plugging in. I built a copy of the app and module driver and have them installed, so getting there!

Took a break today to be with the family and finish coding and playtesting the changes to what will eventually become Silver Falls 1.0.0.1.

Back to the module for tonight! Where I left off last night, I had made a few numbering mistakes in my module definition file. Corrected those and had a couple of wiring issues. I'm working on one of the wiring issues now.

Can't seem to find my snips - I need to cut some guiderails for the left and right interface with the machine. Hopefully those turn up tomorrow.

Had a connector wired backwards. :-/

Got that sorted and coils are working!

Now to deal with a few funky things like pulse timing on drop target resets (software related).

Spent today with a hacksaw (broke two blades!) to make some ball guide interfaces. Adjusting some launch stuff and coil strengths. Super exciting to see the game react the way I expect, though.

Even the orbit and semi-orbit work properly. For those that didn't receive my newsletter, this game will have a true gobble hole. The gobble hole operates with the intended difficulty (at the moment). I was toying with the idea of a small curved lip on the outside of the hole... that would allow some pretty fun ball saves with nudging (similar to the curvature of holes on Bally bingos, but only curved in one area). I don't want to mess up this version, though, so I'll likely experiment with that for whitewood 2.

The biggest problem with vari-targets is that they take up a lot of space! I agree that they are really fun.

I spent a long time yesterday trying out various settings for coils and ensuring the game could be played as intended.

Had the flippers smack a post right out of the playfield (that'll get a t nut).

I have a couple problems right now, and they are coil related.

1) one of my drop target mechs won't reset. It moves by hand, but pulsing the coil gives a tiny shudder to the targets and doesn't actually make them move vertically.

I suspect the coil has damage. Will be metering later.

2) finding the appropriate timing for one of the mechs is really tricky! I've tried four different settings for pulse length so far and just need to keep playing around.

3) my pop never fires in game. I have it defined appropriately, but it never moves. I have a light show tied to the pop switch, and that's firing, so I guess that's something.

Messing with various combinations of these things caused the game to blow a fuse last night. I think it was probably resetting both target banks simultaneously. If the coil has damage, it's pulling more current than normal. I (temporarily) mitigated by adding a small delay between each bank reset.

The layout does (mostly) work as I intend. I'm still working on launch reliability. This will hopefully be improved with cnc'd launch holes. Nothing is exactly centered at the moment. In diagnostics, the launches work great! In game, they fail a lot. The gobble hole felt great for my first dozen or so games, then felt way too hard to hit. Gonna keep playing, but adding that lip I mentioned may be necessary.

Today I will be working on my on screen mechanism and play around with coils some more.

I've been thinking about seeing if Multimorphic will sell the angle brackets used to maintain alignment and spacing on Lexy since my game will also use launchers 3 and 5.

Balls always make it above the playfield for me, but they hit a scooped bit of metal before exiting a gate and that seems to be causing the problem. Too much power, perhaps.

I've been dealing with CAD quite a bit today. Spent 20 minutes modeling the perfect washer for my on-playfield mech, which seemed like a profound waste of time, but it certainly taught me a lot about FreeCAD. I have simple prototype targets already printed and used my trusty hacksaw and a drill to cut grooves in the metal bars and have installed e-clips on the bar.

My hands hurt... haha! I've done this before with bingo buttons to cut grooves lower to force them into the lockbar for Multi-Races. Forgot how painful it is, though!

I think this phase may require a lot of iteration. I am testing a change to one of the mounting bracket models currently, but each change requires approx. 3.5hrs of print time.

So while I wait, I am going to check into some other issues (coils and launchers).

It's neat to be able to rethink mechanisms that float over the screen. I thought I had a good idea, but it involved semi-traditional posts that would block/rebound the ball... since the whole thing has to attach above the playfield... why bother with all that? Haha

I've remodeled those posts, and I believe I have a good handle on how I will attach to the outside frame. Since ball strikes were part of the initial plan, I was dreading the amount of twist/torque placed upon the posts, even with appropriate rubber.

I'm leaving space for a circuit board, as there are several components involved.

Good news is that prototype printing times are reduced from 3.5 hrs to about 1.5 hrs (for these posts). The upper attachment plates will be separate models, ideally with a semi-traditional plastic over top of the circuit boards.

I definitely hear you. Now that I have side target plastics installed, it's pretty easy to swap them. I'm aiming for that level of complexity (two screws).

The mechanism will connect using two (at this phase) screws similarly to the ramp returns. You can remove the ramp returns or possibly leave in place. My plan is to model the attachment points at a similar thickness to the plate under the wireforms.

Mechanisms (there will be two) will each use a single AMP style connector like the smaller one on the back of the playfield, plugged about 3/4 up the module on the left + right sides. 3 switches, 3 "coils", power, ground.As I plan for the playfield plastics to cover/surround the area with the connector, hopefully the mechanism being removed (for a location that doesn't want to install/swap, for example) won't pose a problem.

... that's if it works and is fun. It's been fun to roll a ball under it in this early prototype form. And while I have game rules written to use it, I was planning to make an operator setting to disable them.

Me too! Hopefully my modelling and printing skills get a good levelling up. Haha! I built a new model for the mech to hang from yesterday and it resembles something more like a Lego brick than the intended hollow part. Didn't expect the infill to get quite that crazy. I'll make some changes to the slicer and it should print fine.

Today I am attempting to model the portion of the bracket that will hang from the side walls.

Finished modelling (for now). I'll be printing some additional parts tonight. A bit more of a slog than anticipated, and I have a feeling that I'll be tweaking these models for a long time to come.

Also... I added logic and the operator setting I mentioned above to automatically kill the mech mode if one or both of the mechanisms are unplugged. Also tweaked some of the coil pulse settings to make them move better.

I am receiving a shipment tomorrow that will include proper launch tubes, the final sw-16, and a separate shipment that will include the remaining pieces needed to test my mech. More required to complete it, but getting there.

However, I'm exhausted! I will likely take the night off rather than try to program any more.

Modelling failure - the software I am using shows that the model is several feet long (it's about 5" when printed, but should be more like 2.5") I've made some changes and hopefully my print works well tonight. No idea what's up with the scale - every software I import this model into shows the same thing.

Even if it doesn't print well, I figured out why my pop won't pop, but I'm still a bit stymied on why one of my drop target bank reset coils fires so weakly. Wiring checks out, but I'll do a deep dive this weekend... because - my last SW-16 arrives today! I'll get that installed and wired up so that I can get the last few drop target optos wired, and work on modelling up the magnet holders within the mech. 'Course, that might prove difficult because I stink at modelling, but you only get better at something with practice. Holders need to be plastic to 1) provide air gap (so they don't immediately grab the ball on a slow roller) and 2) so the field isn't altered/enhanced with a set of magnets sitting on top of some metal.

Regarding modelling, I also have to make changes to the targets inside this mech, but I feel more confident about that as I have a good model I'm using for the target itself already.

Once I have things in reasonable shape, this project is going to slow waaaaaay down as I'll likely want to get my next whitewood CNC'd, and I don't know anything about that whatsoever. I also mentioned I'm terrible at CAD, so that's going to help. On top of figuring out how to get it CNC ready, I would also like to send my ball guides off to sendcutsend or a similar place to be accurately cut (instead of with a hacksaw).

On the list this weekend: going to try to grab some cheap plexi or something to cut rough plastics. The ball currently goes flying around based on how the mechs are popping off, and I want to ensure that that is limited, or that the plastics allow the ball to safely return to play. Majority don't get caught behind anything, but I'm shooting for as few hangups as possible (ideally none, but I'm sure we all know that's not realistic ). Physically, my launchers are using some off-the-shelf parts to handle moving the ball horizontally after it makes the vertical leap up the tube. Those are working pretty well in diagnostics, but not so much in game. I need to make physical modifications of some kind. I am thinking I might need to make a custom sendcutsend order for those guides as well.

Otherwise it's programming, programming, programming. I have a lot of work left to do before an artist jumps in. Though I have a full game with progression and multiple target modes, there's some extra flashiness I want to add to game progression.

Some more details about the game rules:

Since it is a gobble hole game, by default it is going to be a five ball game (can be adjusted from minimum of 1 to max of 5 - each adjustment down will award more and more spotted targets in sequences, awarded randomly on ball start).

Difficulty modes (there will be two) will allow for quicker achievement of various spotting awards, and starting the main adversary mode on each ball.

Each ball can achieve one of (at the moment) 6 target sequences that will influence the next ball upon successful completion of the gobble mode. There will be two protagonists, but the game will choose between them at random based on performance from ball-to-ball. If you've followed my previous games, I'm not a huge fan of end-of-ball bonuses. I'm going to try to award more substantial bonuses that carry over to your next ball, rather than just some points. There might be points as well.

Initially, I was thinking about 10 adversaries, but I've reconsidered. If there is an artist that is willing to work on a lot of concepts, I'll keep coming up with new ideas. These ideas will have some effect on the ball in play, and will award their own bonuses. Each adversary is randomized after completing the previous adversary mode. Meaning: you remain on the adversary until you finish their mode, even from ball-to-ball.

There will be three ways to lose your ball: draining, tilting, or gobbling. I might make tilt with a couple of warnings (adjustable) as you will want to nudge this game. I am a person that enjoys the thrill of nudging without a safety net. Others hate it.

The screen will be a bit crowded with the mechs hanging over, but I'm planning on some small hurry-ups tied to rollovers.

The main thing that lower playfield things will do is spot targets within sequences. The lanes, when complete, will spot a random target from any of the major sequences. Side targets, when complete... spot as well. Left and right side screen mechs will spot targets on the main left and right side sequences.

The style of layout is going to be polarizing enough that I'm going to try not to alienate people with the rules. We'll see if I succeed.

When you start the main adversary mode, the two center walls will pop up simultaneously. After hitting certain targets (different for each adversary), the walls will fall, opening your direct shot to the gobble hole.

At the moment, I have each of the sequences set in the game, as well as gobbling and a basic end-of-ball bonus.

In my head, I'm scripting callouts and animation sequences. I have been in touch with a few artists, but most in the style I want are booked up at the moment. I've been toying with some musical compositions as well (and how they will fit within the animations I have planned).

Hopefully that all makes sense, but the idea is that it'll be very clear to the player what needs to happen. I'm hopeful that in another few weeks I'll have the basic programming done, and awaiting assets.

I know that's a lot of text. Photos soon, promise!

I have not! That'll come a bit later. Multimorphic doesn't require you to contract with them for the build, but it almost certainly will make the most sense to do so. Obviously there's some road between here and there - I need to finish at least a rough version of my software, ensure my initial layout is as good as I want to make it, and submit it for initial approval.

I'll likely want to take that step after converting to a CNC version. The reason being that I won't have to ship them my only whitewood, allowing work to continue on development while awaiting any recommended changes. So the one I send them will be a second copy.

Then I will need to build a few others for the beta testers (already selected), once I'm reasonably sure there will be few physical changes to post placements and the like.

Finally, I'll finish the software and seek final approval to release, and at that time will be talking terms with Multimorphic and/or another contract mfg. The deal is that I would like to keep Multimorphic stocked, or have an agreement to build on an as-needed basis. That latter is easier with Multimorphic. We shall see!

I added two targets this morning on the far left and right sides. Those targets will be replaced with narrow faced targets.

I've been playing all evening. A few tweaks needed, especially with the correct launch tubes I am losing a lot of velocity due to the shape of my exit holes.

So, I'm ready to show you the layout! Keep an open mind... (and bask in the beauty of my plastics):

PXL_20210912_013748636 (resized).jpg

This is a symmetrical layout. If you have not played many EMs prior to the late 60s, you may not have played many/any symmetrical layouts. Despite what you might hear, symmetrical layouts can be quite fun, even in a modern context.

This layout has several features:

1) an outer orbit that passes and sweeps drops - large enough you can get some speed going
2) inner orbit that is narrow enough that the pop can earn you quite a bit of points.
3) there are a lot of standup targets, but there are seven total sequences.
4) two individual banks of three drops.
5) 1 standard pop bumper (Gottlieb style - not data east style).
7) knocker
8) bell
9) two upper slings

The ball can launch from left or right. It fires either into the drops or into the upper slings. The ball launches into chaos.

I'll reveal the theme at a later date (once I have some art).

Keep in mind that this is VERY EARLY and of course the module will look quite a bit better with actual plastics and artwork (and cut with a CNC).

PXL_20210912_015516651 (resized).jpg

Correct, being smack in the center, it would be frustrating if it came back to you.

Just rubber and posts. Oh, and a flasher to indicate a ball is launching.

Thanks everyone! Hopefully I'll continue to make progress and you'll be able to play it at some point!

Interestingly, I removed the one way gates, adjusted my posts and rubbers and didn't have as many re-entries as I would have imagined. Probably going to keep it like that (for now).

I pushed a significant code update that includes a random spotting method. This method will spot x number of targets for you (based on the parameter when calling).

It determines which sequence at random to spot, then passes that off to the sequence handling mode. That in turn spots the actual target, keeping existing targets in mind (so you always get a reward from the spot method). I'm used to spotted numbers being generated from the position of a stepper, so it's a bit surreal to do this in code without the mechanical unit to fall back on. Haha

My right drop target reset needs a longer pulse than standard because of my terrible hand routing (it's very lightly bound on the right side). I'm considering adding an operator setting to reduce the strength of any coil.

I added hooks for animations and callouts to the gobble method and broke the part where it actually... Gobbles the ball. Fixed that. Definitely a fun little moment.

My adversary mode, when started will cycle walls to block/unblock the gobble. Unfortunately, end of ball didn't drop them (smart move on my part). :-/ Fixed that.

Next up is to take those random spots and abstract my lamp methods in the sequence modes so that they don't rely upon the target being hit to light the insert.

I spent a little time today composing a throwaway loop, and thinking some more about music in the game.

I fixed the spots blinking the appropriate lights and inserts on the game, and worked on my settings.

Now coils and the spotting features for side targets and lane completions can be enabled/disabled. This is pretty player unfriendly, but pretty common in games where spots are available. More to test, of course.

The only spotting feature you can't currently disable is related to the number of balls to play. If < 5, you get a certain number of spots when each ball is started.

Coils can also have their strength independently dialed in. I'm working on a bug related to the values set by default, but hope to have that squashed soon.

I don't know if I've mentioned how much I've been playing. Quite a lot - and I have a list of minor/medium changes to make for the next whitewood.

I was initially going to add full color GI to the game, but I've changed my mind. Instead, GI will be single color and tied to a driver (like the pop lamp). There will be one extra, so that won't require another PD-16 (there won't be many lamps tied to GI - probably five).

Currently I have score motor emulation (fancy word for a way to blink the pop bumper light when hit), that might also blink the GI. I can also blink the GI in neat ways during the start of a ball or the start of an adversary mode. If you look at my USPS shipping box plastics, you'll notice that there's no support in the extreme right or left. I am going to change that once bulbs are in place.

As far as other physical changes:
1) outside targets will be changed for narrow faces.
2) geometry of the front targets will be tightened up allowing (hopefully) for an outside post under the sling.
3) Posts will get T Nuts where possible - I've managed to knock out a couple that are holding down the cardboard as I'm using the wrong posts and short screws that don't extend through the playfield plywood. The P3's flippers are powerful. Ka-boom!
4) Second set of posts for plastic standoffs. Right now I am using one style of post because I didn't order any of the taller type.
5) Slight changes to the geometry of the outer semicircle of targets (adjusting angles).
6) Bigger changes to the placement of the launcher holes (they're not -quite- aligned, which currently leads to a handful of missed launches before you get a ball).
7) Changes to the inserts at the top of the playfield (in front of the two circular targets) - undecided how, exactly, these might change, but change they will. I want to stay away from backboard lamps.
8) Wire guides and nails for prevention of (worse) damage due to broken rubber.
9) Design of playfield plastics. Current design hanging over the edge of the target faces prevents some airballs, but I worry about chipping/breakage. Someone suggested shipping with plastic protectors. If it doesn't mess with the gameplay/appearance too badly, that might be the thing to do.
10) Removal of second PD-LED (I was able to squeeze the whole game on one, minus the GI).

So that leaves us with 3X SW-16, 1X PD-16, and 1X PD-LED.

Once I have the rules pretty much complete (we're getting there), I'll need to really amp up my search for an artist.

There's a LOT of stuff under the playfield. Removing that one PD-LED board will make more difference than it seems as far as repair-ability. There's a lot more that I should do in this regard as you can access everything, but moving the pop spoon back and forth is tricky, currently.

Big thanks to Multimorphic for holding my shipment until I finished changing my mind (I kept sending them messages asking for different stuff - saving me money in the end), then getting it to me in time for the weekend, that was perfect!!

Not fantastic. Problem is that either my tubes or the holes are not properly centered, so the ball doesn't always make it up the tube. That will improve with CNC. I've also thought about widening the holes, but hard to go back once you make the cuts.

The launch tubes and scoop tops properly direct the ball where I want, issue is the ball losing power as it rattles up the sides.

Takes somewhere between 1-5 attempts before the ball launches. I thought it might be the one way gates, so removed those and was able to redo the geometry around that area to remove the possibility of a stuck ball.

Operators can now disable the side targets and lanes to prevent spotting targets if desired (bugfixed and working correctly).

Other settings have been added and modified. All have been tested except for the coil adjustments.

Next, I need to work on the unique adversary modes and test the coil adjustments in the game.

Ever have one of those days/weeks? I spent almost my entire lunch break yesterday writing out requirements for the artists that will be working on the game, then the service I was using ate the message and didn't send it when I clicked 'Send'.

I rewrote the whole thing today and this time saved in a document that I can easily copy/paste from. I've managed to send specs to a few different artists for quote.

Working today on adversary modes. I have all fifteen adversaries storyboarded, and am working on progression and completion of the modes as well as basic light shows specific to those modes.

Once I have music/sound implemented, I'll revisit and potentially add new choreography and expand the shows.

When the adversary mode starts, two walls will go up and block off the gobble hole shot. They will cycle on a short timed basis to prevent trapped balls, otherwise, will remain up. When you complete the shots needed to finish the adversary mode, the walls will drop and remain down, then hitting the gobble will complete the mode (and end your ball). I have the first adversary coded and am working on some underpinning stuff (unified sound/animation triggers, and a call to the method to drop the walls.

In speaking with some P3 owners, a suggestion was made to tone down the difficulty of the gobble hole. I have it currently acting as a standard gobble, which kills your ball save mode and advances to the next ball. I'm going to ship the game with gobble behavior set to that as default, but with the option (settable per profile) to make it so that a gobble shot before the adversary is complete will return the ball. That totally changes the intended feel of the game, so I may increase the difficulty by changing the carry-over rewards. Those are not fully defined, so I have a little wiggle room there.

For example, I could multiply bonus points by 0.75 or similar penalties on points if you have a friendly gobble turned on.

The geometry is such that balls don't randomly walk into it. It's pretty 'friendly' for a gobble already, but I like having multiple ways for people of different skill levels to enjoy a game.

I've been testing the game more (I play it every day) and ordered a bundle of tnuts, machine screws, and alternate taller posts for holding the plastics up. I'm going to make that transition with this playfield version and ensure that there are no issues with screws backing out, determine if loctite is needed, jam nuts or nylocks are needed, etc. I also ordered the narrow targets to replace the outer orbits and provide a smoother exit (as it was prior to last weekend, when I added them. )

I'm talking with several artists and art studios. I'm hopeful I'll find a good match. I have a few potential art styles and everything storyboarded for animations, intros, and basically all the screen work planned out. The upper playfield and plastics I have less of a firm picture, but I'll continue to think about it. Part of it is that the art styles I'm considering are very different so it's hard to keep a clear picture. I'll get there. Or the artist(s) will.

Quotes have started to come in for art on the game. It's about what I thought it was going to be. It'll take some time to put that money together, but hopefully development will be able to continue in multiple ways while I work on that.

Very much appreciated! Thanks for reading.

By the end of the weekend, I hope to have my adversary modes fully programmed and have begun the t-nut and other physical changes to the module.

I might have mentioned(?) playing with flipper strength to change difficulty? If not, that was something I really experimented with a lot. I find the unexpected full loop a bit too satisfying to give up, though, so flipper strength, for now, remains full blast.

Every adversary mode is written. At the moment 15 unique modes exist, each with (slightly) unique light shows to aid the player with which targets to hit.

I also started on implementing the setting to change gobble hole behavior, which can be set on a machine and profile level. What I need to determine is how to communicate that this is the behavior and how "winning" the adversary mode will still eat your ball...

But Sundays are for physical changes. I replaced the outer targets with narrow faces. Replaced every post with t nuts and machine screws. Retrofitting t nuts without complete disassembly is annoying. Replaced the posts with the faceted posts that will not interfere with the target faces. Moved the bell over a tiny fraction of an inch, and this gave it enough clearance to ring true.

Spent a bit of time bending and shifting the launcher scoop forms, and I believe I have it as reliable as it will get for this version. I may end up using t nuts under these as well as I found the ball smacking it was flexing it enough that it was causing some rejections. At the moment, I've improved it from 1 in 5 successful launches to 1 in 3. There are also alignment issues which will be cleared on v 2.

I'm thinking about adding narrow posts to the left and right of the central bank, but hesitate to do so. A narrow post will fit but will slightly close the opening. It's important to get the ball to smoothly and safely transition back from the top area, and I think it will cause unneeded rejections.

In other news, I have an artist! She's starting on the backglass in attract mode first and we've been in close contact. The project is large enough that she has some trepidation about committing to the whole thing, but hopefully her enthusiasm will continue (she likes the theme and the art style).

I added the first version of the backglass artwork to the game and the artist is working on improvements.

Meanwhile, at this phase in development (once artwork is starting to arrive), I like to think more about the player interface. That includes fonts. Making something unique but readable is the goal, so I've started experimenting using a font that matches the theme of the game. I'm not sure if this one will stay... but it's important to try different things. There have been many situations while making previous games where I've been really opposed to a change then spend a little time with it and do a complete 180. I don't know if that'll be the case this time, but I remain open to the idea. I spent some time today adding credit and score displays to my liking, and am toying with a new way of displaying ball in play information.

In playtesting, I'm starting to feel like I should start scripting callouts for various voice actors, but as the artist and I have discussed various ideas for how to render the adversaries, I'm thinking I'll want to wait for a bit on that.

My light shows didn't show the way I wanted to in testing (when the adversary modes started, targets to hit would lite a solid color - whoops), so I think the next thing will be to start developing custom fades, blinks, etc. for the game and fix those existing shows...

I'm trying something new with this game. Normally I have a separate light show mode that the game pulls in once, then calls different methods to handle fades, blinks, rotations, combo lighting, and other indicators. In this game, I'm trying to compartmentalize more, and keep light shows associated with adversaries (for example) in the adversary modes. This may or may not be causing the problems I'm seeing.

For common shows (fades and sweeps in various directions), I'll keep centralized, but for mode-specific stuff, I'll try keeping it with the mode. I might not be clever enough to make that work the way I want, but here's hoping!

Here are the steps left regarding overall progress:
-Code Stuff-
1) Fix existing light shows
2) Add new general use light shows (sweeps, fades)
3) Add carry-over bonuses and decide how end of ball bonus is going to function.
4) Add artwork as it arrives (I've been playing the game with the first version of the backglass - what a difference!).
5) Add placeholder graphics for interactive screen objects
6) Script callouts
7) Music creation/addition
8) Sound effect creation/addition
9) Testing edge cases for menu open/close and ending game early, team play, other platform features.
10) Adding twitch connect items
11) Adding specialty profile interaction (that's a maybe right now).

-Physical Stuff-
1) Scan module
2) Convert to CAD (somehow).
3) CNC cut a new playfield, replacing first prototype.
4) If CNC cut works, cut additional playfields for beta testers.
5) Install artwork on each playfield (testing process and results on first CNC playfield, then expanding from there).
6) Design plastics for install on each playfield in vector format.
7) Finish prototyping mechanism.

-Art Stuff-
1) Backglass
2) Playfield screen displays (score/ball in play, inserts)
3) Playfield screen animations
4) Attract animations on playfield/backglass
5) Module artwork for playing surface
6) Module artwork for plastics
7) Side target/mechanism/sling plastics(?)
8) Apron artwork?

-Sound Stuff-
1) Effects for each point value. I ring the bell when a sequence is completed, so I'll need an entirely different suite of sounds for achieving points.
2) Music - main loop, perhaps expanded upon for each adversary.
3) Sounds for getting a sequence item spotted
4) Sounds for tilt
5) Sounds for acquiring a sequence item in adversary sequence modes.
6) Callouts - players and adversaries.
6) Maybe sounds for acquiring a new target in a sequence... might be a little overkill.

... then a lot more playtesting. I've reached out to a few people on my beta tester list, and have received positive responses, so it looks like my team is assembled.

Once I'm satisfied that bugs are squashed and things are working as I want, then it will be time to discuss with Multimorphic when module review will fit into their schedule, and what is involved. There's undoubtedly A LOT of stuff that I'll need to review when it comes to taking a build to production - I've never done this before, but I know it's going to be a tremendous amount of work. Luckily, I love working on games.

I've been working on this one:

3) Add carry-over bonuses and decide how end of ball bonus is going to function.

and this one:

6) Design plastics for install on each playfield in vector format.

I have the carry-over bonuses determined, but realized that there's a problem with carry-over. Last ball. I've got a few plans for that, but one of the main carry-over bonuses was add-a-ball on your next ball... so that won't work. I'm rewriting that to allow add-a-ball instantaneously instead.

Last night I also hopped in CAD and designed a sample plastic and threw it on the 3D printer. Worked great. So I'll spend some time and actually measure post spacing and placement for the plastic model. It'll need to be minutely adjusted when I have a CAD model of the entire module (since some post placement will shift small fractions of an inch here and there), but the general shape will be fine.

Tonight/tomorrow it's lamp time.

More time, more changes...

1) is done. Existing light shows were getting destroyed due to a script that continued to run at a different priority. I have also taken to adding a final command to the end of the script to restore the lights to a known state before removing the script entirely. I tweaked the sequence completion to add appropriate fades and other niceties when completing sequences. I also changed the GUI Inserts for the sequences to mirror the state of the existing sequence completion. I already had the inserts spread in a way that made it easy to track, but I realized having the information -right there- in front of your eyes while playing had a ton of benefits.

2) I am adding sweeps and fades. I'm particularly partial to the show when you drain, and the one when you tilt. Depending on how you drain, there's a little stinger at the end as well which I am currently working on.

I've frequently said that making light shows is the hardest thing for me. I am used to games where you have a lamp with two states: on or off. Using color to illustrate context and progression is tough, and doing it in a way that instantly communicates the intent to the player is very difficult.

For each sequence, I have a suite of colors that are used, and the game will cycle through those for each completion. At a glance, you can see which new completion you are progressing towards (the GUI Insert colors match).

Once you complete a sequence, there's a hidden GUI Insert in the apron area that will illuminate with graphical context as well. All this is done.

Starting an adversary will have its own show, and I'm still in the planning stages for that one.

After this work is finished, I'm going to go back to:
3) Add carry-over bonuses and decide how end of ball bonus is going to function.

I have thus far been adding information behind-the-scenes. Carry over happens automtically, but without communication. I need to add to the end-of-ball bonus window.

Had a friend over last night who hadn't played any of my P3 games yet... and he got to be the first person outside of my family to try the new game.

I finished one of the last of the light shows moments before he arrived, built a new version and new module driver, and... my upper playfield light shows didn't function correctly. I need to pull the game apart and take a look at the PD-LED and how I have it wired. The shows work very well in simulation, but don't display as intended in the actual game! Weird. But the shows do function on the lamps attached to the cabinet (side target modules, walls, scoops), so I suspect my wiring. Interestingly, the lamps work fine in diags, so, well, it's obviously a bit of a question mark.

At any rate, that's a bug in the todo column, but otherwise it was great to have him over and to get his input on the game and gameplay.

He also got to try my other commercial games, and many of the games from Multimorphic, but had to leave before trying QFG (that one's a bit of a time commitment). Enjoyed playing a Team Play game on Silver Falls and almost made it out of the Bathroom (room 4).

I still have one or two shows left to write, then it'll be to sequence bonus programming.

Let's take another look at where I think I am overall (note added light show task):

-Code Stuff-
1) Fix existing light shows
2) Add new general use light shows (sweeps, fades)
3) Add new one-time use light shows - 30 of 32 complete
4) Add carry-over bonuses and decide how end of ball bonus is going to function.
5) Add artwork as it arrives (I've been playing the game with the first version of the backglass - what a difference!).
6) Add placeholder graphics for interactive screen objects
7) Script callouts
8) Music creation/addition
9) Sound effect creation/addition
10) Testing edge cases for menu open/close and ending game early, team play, other platform features.
11) Adding twitch connect items
12) Adding specialty profile interaction (that's a maybe right now).

-Physical Stuff-
1) Scan module
2) Convert to CAD (somehow).
3) CNC cut a new playfield, replacing first prototype.
4) If CNC cut works, cut additional playfields for beta testers.
5) Install artwork on each playfield (testing process and results on first CNC playfield, then expanding from there).
6) Design plastics for install on each playfield in vector format.
7) Finish prototyping mechanism.

-Art Stuff-
1) Backglass
2) Playfield screen displays (score/ball in play, inserts)
3) Playfield screen animations
4) Attract animations on playfield/backglass
5) Module artwork for playing surface
6) Module artwork for plastics
7) Side target/mechanism/sling plastics(?)
8) Apron artwork?

-Sound Stuff-
1) Effects for each point value. I ring the bell when a sequence is completed, so I'll need an entirely different suite of sounds for achieving points.
2) Music - main loop, perhaps expanded upon for each adversary.
3) Sounds for getting a sequence item spotted
4) Sounds for tilt
5) Sounds for acquiring a sequence item in adversary sequence modes.
6) Callouts - players and adversaries.
6) Maybe sounds for acquiring a new target in a sequence... might be a little overkill.

Thank you! Still a long road ahead, but it's nice to knock out a few issues every couple of days.

Here's what I've been working on:

3) Add new one-time use light shows - 30 of 32 complete
4) Add carry-over bonuses and decide how end of ball bonus is going to function.
6) Add placeholder graphics for interactive screen objects 1/2 done. I've got objects rendering properly, but need to add some interactivity to them and trigger to make them interactive.
10) Testing edge cases for menu open/close and ending game early, team play, other platform features. 1/2 done - basic interactions work properly, but there may be some funkiness in display when adding coins while a menu is open that I've created.
Oh, and 13) Add high score tables and ensure proper function

I hope this weekend to get some of the sound effect work done as well as the other 1/2 of those items above.

My artist has almost finished the title treatment on the backglass, which should inform the font used in the game.

More work done...

6) Add placeholder graphics for interactive screen objects 1/2 done. I've got objects rendering properly, but need to add some interactivity to them and trigger to make them interactive.
10) Testing edge cases for menu open/close and ending game early, team play, other platform features. 1/2 done - basic interactions work properly, but there may be some funkiness in display when adding coins while a menu is open that I've created.

On the art front:
1) Backglass still is complete

There's a bit of animation that I'd like to add, so I'll revisit later. For now the artist has moved to the playfield.

Someone new!

Been a few days, lots of stuff changed/done!

I'm in discussions to hire a friend/CAD expert about converting the layout to CAD for me. This will save at least 100 hours on my side (estimated). I am now competent enough in a simplified CAD to knock something together really quickly, but in CAD, it's all about the details. Hiring an expert is a big shortcut, and my friend is very, very good.

-Code Stuff- _pretty much done__
1) Fix existing light shows
2) Add new general use light shows (sweeps, fades)
3) Add new one-time use light shows - 30 of 32 complete
4) Add carry-over bonuses and decide how end of ball bonus is going to function.
5) Add artwork as it arrives. More artwork progress every day.
6) Add placeholder graphics for interactive screen objects
7) Script callouts
8) Music creation/addition - things are progressing here, I've composed more loops that haven't quite met expectations, but hoping to get something close to what I want then work with a musician.
9) Sound effect creation/addition - Spent several hours looking for sound effects to match what I want. I'm pretty particular about sounds and music, so this takes a bit of time when I have a specific sound suite in mind. I may end up recording my own effects.
10) Testing edge cases for menu open/close and ending game early, team play, other platform features.
11) Adding twitch connect items
12) Adding specialty profile interaction (that's a maybe right now). <-- Decided that this didn't make sense.
13) Add high score tables and ensure proper function
Convert all interfaces to use custom font.

-Physical Stuff-
1) Scan module
2) Convert to CAD (somehow). - pre-emptively knocking these out.
3) CNC cut a new playfield, replacing first prototype.
4) If CNC cut works, cut additional playfields for beta testers.
5) Install artwork on each playfield (testing process and results on first CNC playfield, then expanding from there).
6) Design plastics for install on each playfield in vector format.
7) Finish prototyping mechanism.

-Art Stuff-
1) Backglass - Final backglass turned in on Monday. It's awesome!
2) Playfield screen displays (score/ball in play, inserts) - the playfield artwork is in process (not inserts or menu chrome, but the player's view). I'm super excited to share, but not quite yet.
3) Playfield screen animations
4) Attract animations on playfield/backglass
5) Module artwork for playing surface
6) Module artwork for plastics
7) Side target/mechanism/sling plastics(?)
8) Apron artwork?

-Sound Stuff-
1) Effects for each point value. I ring the bell when a sequence is completed, so I'll need an entirely different suite of sounds for achieving points.
2) Music - main loop, perhaps expanded upon for each adversary.
3) Sounds for getting a sequence item spotted
4) Sounds for tilt
5) Sounds for acquiring a sequence item in adversary sequence modes.
6) Callouts - players and adversaries.
7) Maybe sounds for acquiring a new target in a sequence... might be a little overkill.

I have specifics for all the sound items above, and determined the instrumentation I want for each.

I'm spending the evenings working with the artist to ensure they understand the requirements and approve in-process changes.

In between other steps, I have been working on a few other concepts I have planned, just to get some ideas out of my brain.

Work has continued every day - the artist has finished the main (playfield) screen background and backglass. I am currently working with them on a custom font for the game, which has required a few revisions (for readability). It's out for another revision, currently.

The CAD model is almost complete and is looking awesome!! I'll be (hopefully) creating a CNC version to test mechanism positioning and so forth.
One of the largest changes, aside from very very accurate placement of each item on the playfield is a small bevel around the gobble, which will make it a bit easier to hit when wanted, and provide some easily recoverable excitement when unwanted.

Before I cut playfields for beta testers, I'll be testing this version quite a lot. I came up with (what I think is) an excellent art direction for the physical module, and the artist and I should be starting on that after the GUI inserts (virtual inserts on the playfield or backglass).

Meanwhile, I've written another game, which has been sent for an initial round of beta feedback. I'll make a separate thread about that soon.

Regarding the gobble hole, many older games function this way, often requiring a shot to one of several holes before you are rewarded. Completing a mode is an extension of the same concept, but the layout on this module is a lot less punishing than many gobble hole games.

Eating the ball will also help prevent extremely lengthy games. You can avoid completing a mode, and you can avoid draining, but it's far more lucrative to end your ball.

The artwork is taking a bit longer than expected, -but- I am loving the work of my artist. They are booked solid through December, so I expect that I'll be able to spend that time working on the mechanical aspects of the game a bit more - cutting and building up the second whitewood, lots more playtesting, continued work on the mechanism over the screen.

I'm very excited with the CAD work - it looks excellent, and I can't wait to play the updated version cut without shaky hands!

I can also use this time to ensure that parts will be available in quantity for manufacture and putting together a final (retail) price list for parts. I have all of the parts I used to create the first whitewood, of course, but some items were on hand and I did not have a price. Also availability of some items has changed. For example, pop bumper sockets are no longer available from Pinball Resource, which may necessitate changing bumper styles.

In other news, my other new game is in release candidate stage, and I've made a thread for it here: https://pinside.com/pinball/forum/topic/p3-game-flipper-foxtrot-rhythm-explosion

That game will be (hopefully) available from Multimorphic, and will be played using the Cannon Lagoon module. I'll be submitting it for Multimorphic approval soon.

I've mentioned this person a few times that I've hired to do the CAD work - Anthony Swan (@solarvalue) has been an absolute miracle worker. I'm not at all competent in CAD and was very much dreading this portion of the work, and Anthony offered to get the module rendered.

Some minor changes have been made as I provided measurements for various targets and mechanisms, and Anthony has been an excellent collaboration partner. It's very close to finished, at which point I will be able to get another whitewood made - super exciting and realistically it would have been many months to get to this point without his help.

I really can't say enough good things about his work.

Thank you, Anthony!

Thank you for the interest! It will likely be streamed closer to general availability. I'd prefer to have Multimorphic sign off on the mechanical and software before showing anything in detail, and there is still a lot of artwork needed between now and then.

Thank you! I definitely could, though I've received initial feedback from Multimorphic and am in the process of tweaking. Soon (hopefully)! I'm typing as fast as my hands can move!

With the release of FFRE (thank you for those that have checked it out or purchased and played!), I'm back on my module game full time! With the help of solarvalue (CAD) and Cmartin1235 (CNC) and Pinball Life (lasercut proto plastics), I've received a beautiful robo-cut of the next whitewood and have been quietly assembling and documenting.

PXL_20211231_001829526 (resized).jpg

Some issues with the new assembly:
1) I forgot that I was out of .100 pins/connectors, so I had to salvage as much of the rat's nest of switch wiring as possible. That led to some fun/dumb situations that were utterly preventable.
2) I specified the wrong hole rotation for the pop bumper I was using.
3) Since I was salvaging switch wiring, might as well salvage coil wiring, right? I did and that was also a mistake.

Work completed:
1) Inserts epoxied and rough sanded (don't need this one to be pretty - testing playability!)
2) Documented physical build instructions - use post x in position y, star washers, etc.
3) Salvaging wiring made me change my planned wiring layout, which means I'll need to wait for the next build to figure out a solid plan and document properly.
4) The switch layout changed from the original whitewood both due to the salvaged wiring and the targets that I added late in development of the first whitewood.
5) The above required a new module driver build.
6) LED wiring also changed as I did preliminary LED wiring -first- instead of -last-. This allowed me to get the .100 connectors installed on all my lamp boards much more easily, and to be able to store my lamp boards in different orientations than I had on the first whitewood.

I got everything assembled physically until the pop bumper body, then realized my error. I could not figure out a solution, but thankfully solarvalue suggested adding wooden dowel plugs in place of the holes. A few minutes with my trusty handheld router and some more epoxy, and that was fixed! This weekend I plugged everything in, held my breath, and it booted up! Few quirks to work out this week, but I'm feeling good!

PXL_20220122_183147131 (resized).jpg
PXL_20220122_194827513 (resized).jpg

I plugged the module in yesterday evening, and I'm excited to build a new version of the alpha code and play some games!

I've been playtesting the whitewood every chance I get (which hasn't been much over the past week).

The couple of gremlins have been worked out regarding switches and lamps. Part of this is my own fault as I reused the switch wiring rather than starting fresh. Much more difficult than it should have been because I don't have a proper harness yet.

Switch issues were because I marked two of the switch boards incorrectly - so I put switch board 2 in place of 3, which had improper dip switch settings.

Lamp issues were more nuanced. Two connectors needed re-seating (8 lamps were out), and as I mentioned previously, the lamp numbering changed.

I've been so busy reviewing the way the module plays that I haven't addressed the couple of major bugs that existed.
1) The software will seem to get stuck when the first ball is in play for a few seconds. I've disabled the ball save and this has alleviated part of that concern. I suspect there's a recursive loop that's recurring a few too many (infinite) times. Haven't quite found it yet, and I'm still refamiliarizing myself with the code, so it might take me a minute.

2) Lamps! I noticed that all are lighting, but the wrong colors are displaying. It's pretty odd as if I track an individual LED, I can see it get the signal to change colors. Turned out I had manually set the polarity to the wrong option on -every lamp- in order to troubleshoot an issue with the prior whitewood, and completely forgot about it. Set them back this morning, and look forward to reviewing the change.

From a 'production-readiness' standpoint, there are several improvements made to the game:
1) Two sizes of nut drivers needed - basically there are these tools, a rubber mallet, and a little epoxy needed to assemble the entire game (physically).
2) T-nuts everywhere
3) Lamp board placement is no longer an afterthought. First whitewood used fische paper to insulate the lamp boards, no longer needed in v2.
4) Photos and documentation made during assembly.

To-do (production):
1) Make a wiring jig to help speed up assembly (coils, switches, lamps).
2) Update wiring diagram.

I would like to develop the above (and of course continue to refine the software) before making beta modules for the testers.

From an art standpoint, my artist got back into the swing of things and finished the custom font. They had never made a custom font before (and I haven't either), so there was an interesting learning curve. Turns out that I didn't learn enough. They made it to my specifications, but it was unusable without a tremendous amount of additional (art) effort, so I suggested that we move to other pursuits and just use a ready-made font. Kinda crushed their spirits a bit, but I'm a firm believer in learning from failure and sticking to my own internal deadlines/keeping the work moving. The font must be settled to progress much further on the remaining artwork, so we have to move on. I'm still working on finding a good font to use for plastics and module (insert) artwork - getting closer, though. The artist will be starting on plastics today (hopefully).

From a physical standpoint, the drop target placement and slot width for the drops is slightly different from the first whitewood. This means that a HARD launch into the drops will brick and bounce right back into the launcher, haha! My launch definitions take this into account, and will automatically fire out of the other launcher, but I need to go back to an idea about a skilled plunge that maxes out at a percentage of the max launch velocity that it uses currently. That should also ensure that improperly leveled games will still get the intended unpredictable/dangerous launch.

I had several lamp socket holes (and dimples) cut in this version, but have not yet installed them. I am planning to drive those as I do the pop lamp currently, and they'll function as GI. The implementation of this might change the planned screen mechanism, which I'm still pondering. The screen mechanism would add a really nice feature, and the code already dynamically enables/disables those mechs if they are present or absent. Time is all I need.

The changes in geometry have made certain shots allow the ball to take interesting paths. The ball is much more active on this robo-cut than it was in my hand-cut version (which is as I intended). I get fewer airballs now that plastics are in place (only one in about a hundred games so far - ball was launched by the upper right sling on top of the plastic, which allowed it to roll down without incident).

The best change is the geometry around the gobble hole. It now is much easier to hit (when you want to). A good thing. The post changes have also made a big playability difference. It's no longer a struggle to hit any of the targets facing the player directly. The hardest targets to hit are still those mounted above the pop (just the right angle on the ball or, better still, hitting the pop are your best bets for manually). I find that I rely on the spotting features for those most of all, but the rules don't require those (or many other) targets for progression.

I'm excited to see what some of my friends think of the changes.

On the code side, aside from the looping bug I mentioned, I have some interfacing changes to make - aside from the main font used in the game, and adjusting in every interface, I have that launch change to make. My implementation of that might change from what I've got planned at the moment, so more on that once I have it written. I also have no sounds and placeholder art in much of the game currently. I'll be excited as that develops. Once I am almost to the point where I'm satisfied enough to start building the beta modules, I'll start working on music, sounds, and voice actors.

Lots left to do, but quite a lot has already been done. The game is fun to shoot currently and works almost as intended. Those are both great things, so I'll take that for now.

One of the physical/lamp integration effects still makes me laugh every time.

Ahhh, so nice to see the full effect of the light shows last night. I played quite a few games. The odd looping behavior I mentioned is only present on the first ball of the first game played after the app has started. I'm still not sure what's causing that yet, but it can be worked around (for now).

I have a few lighting effects to tweak, and a few more font instances to replace. Today the artwork is beginning on the playfield plastics.

I did find a ball hangup, after tweaking the launch power, so a support post position will need to be modified.

The shots themselves are still really fun - I'm happy to report that a correctly angled shot can still sweep the drops on one side or other.

Thank you! A bite at a time and eventually it'll be done.

I spent lunchtime today tweaking a few light shows, though I think there is still more to be done.

I added a bit of background music, which really makes a lot of difference in any game, and some high score music. I tweaked the rest of the interfaces and applied the new font to everything, added the launcher media package (images, sounds), and a few other little touches.

I have a few other challenges left on the software front. Messaging for hurry ups and awards needs to be communicated better on screen. While I was waiting for some images to handle this, I can add the textual information now.

The spotting portion of the gameplay is really useful, though I might need to increase the difficulty in awarding a spotted shot.
As others play the game, I'll be able to properly assess.

Next up will be some sound effects. I've been considering how the suite of sound effects will allow you to understand the shot you've made. I have lots of inserts that appear on screen dynamically and support that as well.

Artwork continues to churn along. Currently the playfield plastics are being worked on and I'm really excited by what's been done thus far.

I've contracted with a composer for the game and provided the specs of the project. That process is just starting, but I'm excited by his reaction to the musical direction.

Meanwhile, playtesting continues. I'm slowly working on a couple of bugs related to lighting - namely, the walls and scoops. I've got those set to fade to black after an initial light show, but they should be coming back on afterwards. They're not! Also, the playfield lamp is not quite reacting the way I want. This illuminates the back of the module. It's staying on full blast at all times during the first ball, then turning off during subsequent balls (not the intent, in either situation). I'll find it soon enough (I hope)!

As I've been doing more managerial tasks, the amount of coding time I'm spending is less. This is a normal ebb and flow during game development (and part of why the lamp bug isn't fixed yet).

I've been working on modelling the ball guides that interface with the lower playfield on the P3. There are sample guides included with the SDK, and modifying those should be a simple task. Before sending the modified models to a laser cutter, I realized I could 3d print them to test (handy)! So I finished the models yesterday, threw them in the slicer, and started printing. About an inch too short... so I went back to the modelling program, added some more, and tried to print - half of the model vanished. So I must have deleted part of the model accidentally. I'm hopeful I can finish the model and get those sent to the laser cutter. My hand cut ball guides are pretty bad.

Once I have that handled, I plan to make a wiring jig. Part of the planning for wiring templates involves how to handle the finished setup of the switches, which I am still thinking about. I would like for it to be easy on the owner, but not ridiculous on the build. Direct soldering is probably(?) easiest on the build. If I have a good jig, either will be easy to adapt, even if a later change is needed. One of the cool things about P3 module development is that the wiring runs are super short! I expect the jigs will be pretty darn easy to put together - at least for switches and coils. Lamps require 4 or 5 wires per RGB LED and terminate in a ribbon connector on the PD-LED.

Some games with a lot of lights use breakout boards to make it easier to manage the wiring needed. Space is at a premium under this playfield, but lamp wiring is really rough at the moment. I need to find a better way to route that. Currently my boards are mounted vertically in various places on the back of the module or near the center (behind the launch tubes). Previously I had one extra board, which made mounting horizontally impossible. I wonder if I might switch back to horizontal now? I'll need to measure. That would simplify a lot of things related to wiring and make everything very visible and easy to work on for the owner.

That's where it is currently, essentially, perpendicular to the playfield. It's fine, but I'm not satisfied. The PD-LED is mounted under the left orbit, behind the launch tubes.

That would interfere with the launcher brackets (for the trough) and I'd be worried about vibration. There's room where it is currently, but I'd like it to be cleaner. I'll take a photo soon and you can see what I mean.

Thanks Zitt - I've had my proto plastics laser cut by Pinball Life.

The bumpers I'm using are opaque, single color lamp and Gottlieb/Bally style vs. Williams (shorter/squatter). Your products look great, but I'm not certain they would be right for this project. I'll definitely keep them in mind for my next layout with bumpers, though!

And I'm at an awkward point where I'm not ready to photo the game or game play as I'm not ready to display the artwork. However! I'll try to get some more photos once I have the final ball guides in place.

Ah, reading is fundamental! Sorry for the mistake.

Multimorphic's Weird Al release has been really fun to watch. Looking forward to playing it soon!

Meanwhile, I've continued to work on the game. The composer only has 14 more songs left to return (and they should arrive on Friday).

The art continues to move forward. The artist had some technical issues with larger pieces that caused some frustration, and I was able to resolve those for them and get them back on track. The center plastic is complete, and the upper plastics should be complete today. I've provided the artist with templates for the cabinet, apron, and playfield module surface.

The software continues to evolve. I've had some time to think about the player's interaction with the game, and how to add additional side goals or benefits. I'm still working on default difficulties and some other challenges within the game while thinking about the sound effect suite and how the music might shape it.

All music has been delivered and integrated. I've also hired the same composer to provide sound effects for the game (there are going to be a lot of them).

Callouts are still being scripted. I want to ensure certain visuals have an audio component, so hiring voice actors will wait for a while (until the art is near-finalized).

The upper module plastic artwork is complete and looking great! The artist is now working on the wooden portions of the playfield module.

Another couple features:

* Animated text display when the game needs to tell you something important, like, "You Tilted!". This is used to direct the player or show a big old tilt warning.

* Some of the challenges for advanced players have been added. For example, separate sweep awards for the drop target banks on either side.

I'm working on some theme integration pieces that will be nice and hopefully reasonable to manufacture.

There are only a few other changes needed before the CAD is completely finalized.
1) Launch tube scoop top angle needs slight tweaking - I need to test more using a fresh piece of metal to be sure.
2) Pop bumper hole rotation.
3) Two playfield plastic support posts are not quite far enough inward, creating a ball trap if a ball manages to land in just the right spot on -top- of the plastic (a rare thing, but happened to me once).
4) Boardset dimples to ease assembly.

I would also like to make assembling the targets easier. Currently, they require soldering after assembly. I've been doing a lot of review of other games and attempting to figure out the best way to do this that won't balloon costs. The way I see it, I could add a connector on every switch, which would decrease reliability of the switch, increase up-front costs on switches (but make them very very easy to assemble), or I can add all that cost to very skilled assembly (plus a lot more, probably). It would also be more difficult for the owner to maintain if they have to find the break using a daisy-chain approach (think Bally). If I go the connector-for-every-switch route, I will need to figure out some kind of breakout board (again, assembly). Space is so tight under the module with this layout, it might be tough to fit. I'll have a better idea once I take the module completely apart again. That may wait until the first sample whitewood arrives.

Designing a small interconnect board won't be hard, but it'll add additional costs.

Another thing I need to hire out for is the CAD for the metal ball guides that interface with the lower playfield. I do not have the time to devote to learning any CAD program, but I keep starting that process thinking 'this will be the one'. I simply don't have the time to devote to learning that skill at the moment, and don't want to do it wrong. I have not yet taken full measurements of the ball guide I mocked up in a 3D modelling program. I have the printout on my nightstand to remind me to take the measurements, but I have not been able to make the time to do it.

While I'm thinking about what it will be like to have someone assemble it, I'm 100% prepared to learn that there are millions of changes needed to actually have manufacturing work. I -am- trying to consider this, which is far different than making a traditional homebrew or one-off game (even where I've thought I've considered it before), and increases the complexity of every step by a large amount.

All this to say, thank you for continuing to read this thread, and know that though I'm not posting as frequently, I'm still working on this every day. The software is in a pretty reasonable state for a beta test, I think... but artwork and animations are a big thing. The art style I've decided upon is extremely time-consuming to produce, and requires an artist with a tremendous amount of patience and dedication. I may still need to hire a supplemental animator or animation artist to produce some of the final work (I learned with QFG that many artists are simply not comfortable drawing the same object in multiple iterations).

Once the final CAD bits are in place, I can have the samples cut. I'm hopeful to have module artwork ready to apply before that time, so that I can both document and ease my work with regard to disassembling and reassembling my own module. Essentially everything has to be done before the next everything can be done. Haha!

Huge thank you to the entire Multimorphic team for patiently answering all of my stupid questions. They really go above and beyond with support of any kind. I try not to lean on that button too often, but sometimes you tilt at a particular windmill for long enough, and it's good to get a second opinion (or a shove in the proper direction). Thank you all for your help so far (and I'm sure you'll be hearing from me again).

All of the sound effects have been composed, and about 50% have been integrated. I'm now at the point where I can hire voice actors for the callouts.

The playfield artwork continues apace - and I'm really pleased with it so far! Approximately 50% done, and I've reviewed and approved sketches of the remaining static artwork.

Thank you! I'm really excited to show people what I've been working on - I've had some pretty positive reactions from the people working on the asset creation as well as a couple of friends.

I'd say that's probably a good estimate. For a breakdown of the remaining tasks, please see the following:

1) Model ball guides. Just need to measure and send those measurements to someone familiar with laying out for a laser cutting facility.
1A) Receive sample ball guides and test fit and finish. Ensure no burrs or other issues with fit that would scratch interior walls of P3 (my hacksawed pieces of metal do).
2) Get sample of plastics printed. Ensure that lamps light appropriate places on the plastic and that the art style will work and indicators work as intended.
3) Finish playfield module artwork (lower plane) - this is about 60% done and is looking great.
3a) Sample print to ensure it looks ok when a ball is rolling on it/player can understand what's happening. Back to 3 as needed.
4) Playfield module artwork (backboard)
4a) Sample print to ensure it looks ok. Back to 4 as needed.
5) Side target plastics artwork
5a) Sample print to ensure it looks ok. My plan is to allow it to function with or without the ramp returns as they are not needed in the game, so it will have the standard cutouts.
6) Sling plastics artwork
6a) Sample slings - the artist and I have been back and forth a few times about what will be displayed on these. I think we've come to a clever compromise, but it'll be a challenge to illustrate and convey to the player.
7) Apron artwork
7a) Sample print
8) Cabinet artwork panels
8a) Sample
9) Head artwork panels
9a) Sample
10) Finish scripting callouts. New ideas present themselves all the time, and the intent is that there will be a lot of them. This is a bit complicated, as rules changes might require revisions. I've been lightly working on this for a while, but lots left to do. Maybe 20% done.
11) Hire voice actors. There are 17 characters in the game - not each of those will require a separate voice actor. Hiring voice actors and directing is really fun, I look forward to this part.
12) Edit callouts - some actors do a bit of editing on their own, but unlike the composer for the music and sfx, the callouts typically need a lot of mastering work before I can integrate with the game.
13) Add hooks for callouts to play. This is a programming task where I'll need to come up with either generic hooks (play one of 10 "Hey there"s) or specific (play "HELLO"). This has to wait until I've completed step 12.
14) Finish plan to move boardset to different locations on whitewood 2. I have a spot picked out, but I need to acquire new materials (spacers, screws) to affix to those locations. This requires rewiring the game, which is not a task I'm looking forward to. Necessary, but it'll mean that I can't playtest until it's finished.
15) Measure locations of holes for boardset and add dimples to CAD. I knew the current locations would not be final, so didn't provide to Anthony when he was developing the CAD.
16) Add dimples to CAD for system connectors (panel of four).
17) Rotate pop bumper cutout/verify in CAD.
18) Small changes in CAD for dimple locations of bell.
19) Small changes in CAD for cutout width for drops.
20) Add dimples to CAD for finished ball guides (t-nut on upper connection?)
21) Have a new whitewood cut. This will either be sample 1 or whitewood 3 depending on if there are errors. If errors, small CAD changes, then next cut.
22) Assuming no errors, produce sample games (w/ full art package). Each sample I will refine documentation for wiring and assembly.
23) Send samples to beta testers.
24) Send a sample to Multimorphic for review/comment along with build documentation, once software is in a good state (it should be by this time).
25) Integrate changes from testers and Multimorphic. This will likely include artwork, build documentation, and gameplay changes.
26) Add combo mode - these will be static combos, unlike on SF. Comboing this layout will be very tricky indeed, so a good reward is in order.
27) Continue extending light shows to match music or edit music to match light shows/expected duration.
28) Continue to add messaging as required to help player understand what's happening.
29) Add characters/animations to playfield screen.
30) Add small animation to backglass.
31) Change timings of some items which are randomized within the game to ensure that each experience is unique.
32) Add more music if needed to match with animations (there are expected durations of animations and I had the composer work to that).
33) Add more SFX if needed once callouts/any final music are added.
34) Reduce upper slingshot power (this is configurable) out of the box to prevent stuck balls.
35) Playtest the heck out of the game. Address any coil power issues that cause stuck balls. In playtesting for several hours this weekend, there were a few stuck balls caused by hyperactive slings.
36) Fix outstanding bugs with various challenges. For example, increasing the playfield multiplier works, but is supposed to present a big dramatic message. It doesn't tell you that it's happened, which is not great.
37) This kinda goes with callouts, but determining a pecking order is necessary. Some callouts are more important ("Woah there! Stop shaking the machine") than others ("Big points"). This requires a lot of consideration and testing.
38) Continue testing applications that work on all modules, like Shoot 'N Scoot and Barnyard to ensure compatibility.
39) Continue testing Twitch-connect and gather feedback on the implementation specific to this game.
40) Find a satisfactory light pipe for one of the flasher holes.
41) Add attract mode animation(s)
42) Add more custom background textures for results windows(?)

The things that I've done:
1) Make a layout
2) Create a wiring plan
3) Create a basic BOM (not final)
4) Come up with a theme for the game. As with my other games, this came after the layout. (of course in this case, I made the layout too )
5) Create software to drive the game - settings, profiles, twitch connect, challenges, high scores, game flow, mechanical integration, light shows, animations/placeholders, hurry ups, features like team play, etc.
6) Create definition/software to drive the hardware.
7) Cut a manual whitewood to prove geometry will work/wire it up.
8) Hire CAD designer to convert my napkin scrawls to something a computer can cut (thank you again, Anthony!).
9) Ask a CNC operator to cut the CAD drawing for whitewood 2, adjust CAD as required based on output from CNC (thank you again, Coleman!).
10) Hire a composer to create custom music for the game
11) Hire a composer to create custom SFX for the game
12) Hire an artist to create the insane amount of art needed for the game. Having an artist that is willing to create art for the screen(s) and physical components was one of my goals. The art style I've chosen is very, very time consuming to draw, but I'm really excited about it.
13) Create basic build documentation to ensure that someone can make these (first draft).
14) Wire up whitewood 2/playtest a LOT. Think about and address any small problem with geometry.
15) Modify build documentation.
16) Have plastics laser cut and test fit and viability (thanks Anthony and Pinball Life!).
17) Integrate custom music and sfx and program stuff like temporarily swapping to a new song based on the key in which the prior song was written.

There are a lot of steps that I'm combining or leaving out of what is already completed. As you can see, there's a huge array of stuff and a lot to coordinate. I'm excited to have people play it. I fear that the artwork will take a long while yet to complete, so I might have to hire other artists or compromise on the vision. I'm not at that point yet. I have other stuff to do with the game while I wait for art, so I'm going to truck through as much of that list as I can while I wait. As soon as artwork appears to be finalized for any component, I'll get samples printed. That will hopefully help the artist as revisions are easier when she hasn't moved to a new piece. As I haven't been through the physical game submission process for Multimorphic previously, I might be much too optimistic with my internal estimates of how long that will take. It's quite possible that I've done something really silly that will require rework, but I'm trying as hard as I can to avoid that by reviewing the existing modules.

Yes, I've worked with voice actors from fiverr and other gig sites as well as actors using a direct contract for various games.

The gig sites like (and including) fiverr have amazingly talented folks.

All of my voiceovers have been original and not sound-alikes. I have absolutely no experience with that. Quest For Glory (based on a PC game) did not have voice acting in either release, so it was a blank canvas, as were my original themes, of course.

Everything is a tradeoff - cost/benefit. I'm a little indie pinball dev that hopes people enjoy the games that I make and that they will consider playing them multiple times. Different considerations vs. a licensed theme and the tradeoffs that go into making something like that. Any manufacturer (that also makes games) - has so much to worry about in comparison to me - so many mouths to feed, so many ways the pie must be sliced.

I'm really glad that I can even exist at all in this space, and am very thankful to Multimorphic for creating a platform and supporting 3rd party development within that framework.

In other news:

This is getting closer to completion. Not quite there yet, but closer.

I also worked on this a bunch last night. Still a few corner cases to resolve, and a couple of tricks I'd like to try with regard to how music starts and stops.

All of this is now done (he said, foolishly):

27) Continue extending light shows to match music or edit music to match light shows/expected duration.
28) Continue to add messaging as required to help player understand what's happening.
31) Change timings of some items which are randomized within the game to ensure that each experience is unique.
36) Fix outstanding bugs with various challenges. For example, increasing the playfield multiplier works, but is supposed to present a big dramatic message. It doesn't tell you that it's happened, which is not great.
34) Reduce upper slingshot power (this is configurable) out of the box to prevent stuck balls.
38) Continue testing applications that work on all modules, like Shoot 'N Scoot and Barnyard to ensure compatibility.

I have a few more things to do before I'm just waiting on assets. Pretty exciting!

I've been working on programming and really polishing the experience. Inserts are pretty important in this game, so I went ahead and made my own slightly nicer-than-placeholder insert art and set that up.

Many of the bugs I've found have been related to multiball and some of the more nuanced rules. Not really a surprise, multiball that allows for other features to run simultaneously can be hard to get right, especially when multiball modifies the normal game flow.

Back to stuff that's on the list:
1) Model ball guides. Just need to measure and send those measurements to someone familiar with laying out for a laser cutting facility.
Just got the instructions sent to someone this morning, so hopefully I'll have samples some time next week.

I've got one or two small bugs I found in hours of playtesting that I'm ironing out, then it'll be time to break everything again with the addition of a combo mode.

For the curious:
1) Battle that flashes pop lamp is flashing too quickly - the state change is invisible, with the net effect that the lamp is just off in this mode. Timing tweaks should correct this.
2) Check a light show override when a battle is finished in multiball. The next-to-last remaining potential issue (ha!) from that set.
3) Move Ball Save indicator lower on the screen - currently it renders underneath the tips of the flippers.
4) On-screen message doesn't fade when completing battle in multiball. This is the last issue from that multiball set.
5) Add attract music - this will be optional, similar to FFRE. There will be an associated operator setting that will immediately disable it if desired.
6) Flesh out intro/credits text
7) Pause addition of indicator lamps for battle mode until the battle start light show has finished playing (depending on timings, there can be a split second where the shots are shown before the color is temporarily wiped out - pretty picky stuff).