Zision Interactive

While doing some gameplay test I had my first 3D printing casualty... Luckily it wasn't from the ball hitting it, but from a design flaw. My shooter lane diverter gate is using a regular ball gate (what bally tended to use in its outlanes), and they aren't too accurate since they just use a relay to spin the gate. When the gate is resting against the side rail it's fine, but when it's energized and out in the playfield it can have a lot of variance. In this case it ended up stopping above the 5 bank of drop targets:
You can guess what happened next...

I've now added some software compensation to prevent this from happening:

You'll also notice my new gate is orange. I ran out of my original spool of white PLA plastic, so now I'm trying out some orange PETG; recommended to me by by another homebrewer as being much stronger than PLA and good for pinball mechs. It took me five prints to get a usable gate though, and it's still a bit messy, so I need to work more on dialing in the settings for printing with the different material.

Still alive! Been distracted by other stuff but I've been slowly making code progress on the game.

I had started by trying to code the first multiball, but I was making lousy progress due to running into a lot of bugs and having issues debugging them. After a few days making no progress like that, I decided to put a halt on game coding, and focus on making the dev/testing/debugging workflow better.

Testing the game physically was a big pain. Originally I was trying to run the code from my desktop, but the game was at the other end of the house. Then I tried doing remote desktop from my laptop, but it still wasn't too good. So I started planning on how to rearrange my office to accommodate the machine, so I could have easy access to it while developing, but I couldn't really come up with any good layout. There's just no comfortable way to be sitting in an office chair near a desk but also be able to reach a whole playfield. Plus, I realized that my projector mount is too tall to fit in my office

So cleaned up my work area, cleared out my livingroom (which has a high ceiling), and set up a new testing/work area there, with all the best comforts available :

As cushy as this is, I still would prefer to do my coding from my office workstation as much as possible, so also worked improving my 'visualization'/'simulation' more. Even then though, I still found that every time I deployed new code to the machine I was running into tons of hard to reproduce bugs, so I spent some more time adding a ton of logging to the code, and improving how the logging works to make it as easy as possible to examine different subsystems, etc.

The real big change though came after that. I captured some weird bugs on the machine, and then took the logs back to my desktop to investigate, but it was slow going reading the logs and attempting to figure out what was important when trying to reproduce the issues virtually. In particular I had one log file that contained nothing but a log of every switch closure/opening that I was staring at since there were some weird switch issues (flickering, etc) going on.... and I thought to myself, with this info, couldn't I just play back the entire game?

So I spent a weekend writing a 'recording'/'playback' system that could read any log I give it and run the game on my PC to recreate the exact sequence of events. With that, I could add tons of breakpoints, pause and step through the code, etc, and pinpoint the issues. Plus, the recordings make perfect automated test cases, so I now have a growing collection of recordings of resolved issues that can be automatically run to verify the game is functioning properly when I change more stuff.

This had further benefits too beyond tracking down bugs too. When developing new bits of the code, I no longer need to click through the game to access the areas I want. I have premade scripts for "complete a hand", "qualify multiball", etc that I can just run whenever needed, which has made development much nicer.

Plus, since it's a recording, I can speed it up. Here's a video of the game playing back a recording of collecting 5 cards, starting multiball, and then lighting a jackpot:

Overall, I'm still spending a lot of time working out bugs, and figuring out how to handle various standard game things like various priorities overriding each other while I develop the game code, but it's been worth the time to slow down and improve my workflow. The game is going to require a lot of code, so if coding the game isn't fun by itself, then I'm in trouble!

Not much progress lately, all my time has been taken up by other things

I installed an up-post next to the magnet to catch the ball as it comes around the left orbit

Was a bit nervous about the installation since this wasn't at all planned for, and I had to just eyeball the location, but luckily it did barely fit

The post itself is a bit smaller than the sleeve, but the sleeve itself is nearly touching the magnet, so I definitely can't really get much closer

Sadly, even with this set up, the magnet still couldn't grab the ball. In retrospect I should have just screwed a regular post in at this location and tested the magnet with that first. If I pushed the ball even 1/4" closer to the magnet, then the magnet had no trouble grabbing the ball, but with the ball leaning against the right wall, there was just slightly too much distance. I can't move the wall, since it's part of the shooter lane, and I can't move the magnet, since it has to be aligned to drop to the upper flipper.

Again, I wondered about having an exposed core, and whether that would be enough, but I didn't want to drill the playfield to find out. Before setting up some test cuts on my spare playfield, I decided to test out the best-case scenario: instead of an exposed core, just expose the whole magnet! I stuck the magnet under the lexan sheet on my test playfield, and ran some wires to test it:

No problem here. The magnet easily grabs the ball from at least 1-1.5" further than it does with 1/4" of plywood in the way. I'm now very curious how this compares with the large exposed cores Stern uses now, but still don't want to spend $50 to find out. Even that wouldn't be needed though, if I do end up going the route of just covering the entire playfield with a plastic sheet, which is looking more and more enticing as a solution to many of my issues.

The main problem right now is actually cutting the sheet. Circular holes shouldn't be a big issue, but I'm not sure how cleanly I can make the slots for the target banks. My biggest worry is all the star rollovers. I'd have to cut holes for each of them that align very well with the holes in the playfield, and then raise the rollovers up to be flush with the sheet. I'll need to practice some more with my spare material and see how cleanly and accurately I can make all these cuts. Long term I'd probably need to get this laser cut, but I haven't had any luck finding a place to get a cut this big made yet

Last month I picked up a world cup soccer, and while shopping it I noticed that it had the same style one way gate as one of my spares, with a second wireform to hold the gate open, and that this was the type used by TNA, so it's available from PBL. I did a rough mockup of the part from measuring it on WCS, and it looked like it'd fit, so I ordered the mech from PBL for $30, rather than making another custom mech.

Of course, it didn't quite fit, but I was able to make due. I ended up having to move the mount for my support rails in a bit, and then mounted the gate mech on top of the rail at an angle. I could have put it in a nicer position, but I'd mounted the switches for the lanes in the way. As I probably could have predicted when I decided to do all my switch wiring with one mech still missing, it was a bad idea.

When I hooked it up to test it first, the gate didn't work. I could hear it buzzing, but it wasn't quite strong enough to pull the flap in. If I gave it a small nudge it'd work though. Once I turned the playfield over, gravity did the work for me and it worked fine. In retrospect I realized that this is another mech designed for 50V, not 25V, so I guess I should be happy it works at all. On the plus side that means that it's pulling such minuscule power at 25V that it'll probably never overheat, even without any PWM. I left it on for two minutes and couldn't even feel any warmth from the coil. I like the idea of being able to just have gates and diverters constantly energized, vs having them react when they know a ball is coming at them. There's a lot of times in other games where I get caught by surprise by the orbit coming around or not coming around, etc, since there's no indication on the playfield. At a minimum I think it'd be nice to have a little stop sign insert or something if you're going to do that...

Using a transformer that only outputs 25V seems to be my single biggest mistake so far with the whole project.... It's just continually messing me up since it's not something I ever really thought about before. As much as I like the gottlieb flippers and the general retro feel I think that, if I do another homebrew after this one, I'll either switch to all 50V, or at least get a transformer that can support both, and just use williams mechs...

In order to prevent the arcing from destroying my relay contacts, I switched to driving the magnet using a TIP36C that in turn was grounded via the relay instead. That way, the high current is switched by the transistor, so there's no possibility of arcing, while the relay still allows me to control the 50V coil via my 25V driver FET. I mounted the TIP36 on a small bracket made from left over aluminum to act as a heat sink.

With this, the magnet functioned properly, no more locking on, but it also somehow managed to blow my 50V supply's fuse. Even upping it all the way to a 10A slow blow didn't help; I couldn't energize the magnet for more than 1 second. I think this must have something to do with the caps on my voltage doubler, as the lower rated fast blow fuse directly powering the magnet isn't blowing...

Regardless, none of this seems to matter since the magnet still can't grab the ball from the orbit very well. Even with, a medium speed ball thrown by hand, the magnet seems to have almost no effect, let alone being able to grab it. At this point, seeing how bad even 50V is suited for this task, I'm going to stop bothering with this approach for now, and just install a diverter of some kind, as I can't see any of my other ideas improving on it enough for this to be a reliable function in the game. I'm hoping to have at least one multiball be all upper flipper based, inspired by classic lawlor layouts, so having a reliable way to feed the side flipper is a must...