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.