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...

3D printed some brackets for the screen. It's funny, prior to getting a 3D printer "how do I mount a screen under the playfield?" was a really big question mark on my project's todo list. With a 3D printer, I had it mounted just fine with 5 minutes of modeling.

Made a test screen hole in my testing playfield plywood. Messed up the cut spectacularly somehow, my whole rectangle was like 1/4" skewed. Not sure how I managed that when I made it by tracing the screen, but oh well.

I also tried mounting a test piece of 1/16" lexan over the hole, to see how much it deformed. I screwed it in at the same positions that the nearest posts are on the real playfield, to get an idea of how well it'd be held down. I had problems instantly with a bit of warping, since my holes weren't placed perfectly.
I think that to use this on a real playfield I'd need to pre-drill all the screw holes with a slightly larger bit, so it has some room to slide around while I'm tightening everything down. Then I'd have to work from the center outwards as I attached everything to try to keep it taut.

My initial test of 'pressing it down with a finger' didn't seem very promising. I could flex the hole down way more than I can on my Black Hole. I still don't understand how the super thin window on black hole is so sturdy when every plastic I've looked at is so much more flexible...

In the end though, I realized I shouldn't be testing with my finger, but with a ball. Setting a ball in the middle of the hole has almost no effect on it, and it seems to roll across it fine. At worse, I can always make a second layer of plastic just for the screen, to bridge that section if it becomes an issue, so this approach still seems viable.

Another benefit I thought of is that I could conceivably mount my magnets way closer to the ball. With wood on top of the magnet, it seems like most playfields are still retaining 1/2-3/4 of their thickness to keep the wood solid, which means the magnet is probably about 3/16" away from the ball in the best case. With a plastic covering, I should be able to cut that down, which should make the magnet stronger, and might help with my issues on the upper magnet. I'm not very familiar with the physics of magnets though... I'm curious how this would compare to the large metal cores on games like TWD. Is a 3/16 thick, 3" wide metal core on top of a magnet generating a larger field than the entire winding itself does?

Next I need to figure out if I can use my star rollovers with it. I used them a lot in the design since they're easy to cut the holes for (compared to a rollover switch slot), but I know I've heard about issues with them and playfield protectors...

Received my replacement screen today:

Will try to hook it up this weekend and get it displaying some images, then do some text cuts on my spare plywood to figure out mounting, and see how well my lexan sheet will work.

In other fun, my flippers have suddenly gotten very weak (can barely make it up the ramp). I hadn't actually had the game on in the past week or two since I'd just been working on code, so I have no idea how long it's been like this. Always a fun issue even on regular machines, so I'm sure it'll be fantastic trying to track it down here...

I wish there was a reliable way to quantify flipper/coil strength so I could really check on stuff like this, make sure I'm not going crazy, etc...

Finally tracked down my weak flipper issue... I replaced the bridge, no change. Replaced the capacitor, no change. Checked signals with a scope, everything looked okay. Cap smoothed the signal out well, peaks were proper height, everything seemed proper. Then I realized... the fuse was blown. I never even considered checking that, since obviously the flippers were working. Something about the way I hooked up two bridges in parallel, one with a smoothing capacitor on it, must have allowed enough voltage to build up through just one side of the AC, through a common ground or something, that allowed it to still get the flippers enough power to flip. Not really sure how that could be, but. I thought I had replicated the circuit gottlieb used on black hole accurately, but the one difference was that I had a separate fuse for each bridge (although I only fused one side of the inputs) while Gottlieb had a shared fuse for both bridges.
I assumed that was just a cost saving measure, but maybe it's actually because of this?

I also realize now, looking at the schematics, that they don't actually fuse the DC side of the bridge, which is interesting. I guess they figure that the per-coil fuses will usually catch those issues? I guess they usually do, at least in my experience. I definitely didn't fuse my solenoids enough overall. I put separate fuses for each flipper and bumper, but the controlled coils only have the one shared fuse on their driver board. More concerningly, I've never blown the on-board fuses for some reason, but I have blown the rectifier fuse when a coil locked on, despite the rectifier fuse being 8A slow blow and the on-board being a 4A fast blow. Hopefully that doesn't become an issue.

I've also designed another iteration of my driver board since my rev 7 that I assembled still had mistakes, though I haven't ordered it yet since I'd like to get some more boards done for a combined shipment. This time, I restarted from scratch. My previous schematic had been carried over and repeatedly modified since my original rev 1 board back when I started learning how to design boards, and was a bit of a mess.
Before:
After:

I'd also been repeatedly running into issues when designing the boards trying to fit them in a 2x4" footprint. Over time I went from 13 FETs to 16, added driver chips, fuses, test points, indicator LEDs, etc while still using the same size board, and it had gotten really hard to layout. This time I scrapped the voltage indicator LEDs, and dropped from two fuses (one for each bank of 8 drivers) to one fuse. Originally, I had designed the board so each bank could be operated completely separately, and could be configured with pullups for PNP transistors or pulldowns for NPN transistors, so that it could also be used to drive an 8x8 lamp matrix, but that use has sorta disappeared in the intervening years.

Those part removals combined with some tricky layouts let me finally get all the transistors layed out neatly. This also means that I can now stick both solenoid connectors on one side, and keep all the low voltage signals on the other side of the board, to clean up the wiring a bit more

Rev 7:
Rev 8:

Yesterday my second screen shipped out, so of course today my original screen I ordered from China arrived out of the blue.. Only took 2 and a half months. This one included a USB power cable, which is nice since now I won't accidentally fry anything by using -12V, but it's also weird, since USB is 5V. As far as I can tell, the boards are identical. Not sure if there's something I can't see that's different or if one of the sellers was wrong about the supply. Was also able to confirm that my first screen is still good, so I must have only damaged the driver board, so now I've got a backup. And soon I'll have two boards and 3 screens. My attempt to get a cheaper screen from china has now cost me about $130 I guess that's what I get from ordering something from overseas during a pandemic though

My screen still hasn't arrived, so I gave up and ordered another one. Hopefully it will arrive eventually..

In the mean time, I tried out an idea I'd been toying with for a while. I don't know where any of my lights will go, or how the art will look, and it's hard to play with that, so why not make some temporary artwork?

I dug out an old projector, and hung it from a 2x4 sticking out from my upstairs landing, and lined up the game underneath, then I loaded up a quick mockup:

I expected it to be a bit hard to play like this but it was actually surprisingly easy to ignore and play like normal. The quality isn't very good though; the cards aren't readable even at 1080p. With a 4k projector this might be workable beyond rough prototyping, but it'll probably work for now. I also had to put the projector really high up, probably 10+ft off the ground. Gets to be a real pain turning it off and on without a remote

With this I'm hoping I can get the game much more fleshed out before needing to commit to making a new playfield and moving everything over

Coded the logic for actually determining which hand won, and displaying the best 'hand' from each hand of 7 cards. The code for finding pairs, straights, etc was surprisingly simple and fun to write.

Since it can identify what hands you got, I can now tie that into what modes/multiballs are enabled at that point. Unsure what I should do if you manage to get multiple different hands.

For instance, what if you manage to get three pairs? Technically only your better two pairs will count as far as the poker game goes, but if each pair qualifies a mode, should you have the choice of which one(s) to play? Should only the higher two pairs' modes be lit, effectively making lower cards' modes harder to get?

If you get a straight and a pair, and then you play the mode you get from the pair, does the multiball you got from the straight go away, or could you go play it after finishing the mode?

If you qualify a mode, but then immediately go into the shooter lane to start another round of poker, should you lose that mode, or should it still be available? Should you be able to start a mode mid-way through a hand?

So many questions... Luckily the decisions on these aren't really hard to change the code for, they could even be settings technically, although I'm not going to bother coding any settings menu or anything since I can just edit the code I'll probably go with the most restrictive options for now (if you take a mode you lose your multiball, etc) just so I don't have to deal with coding a mode select screen yet.

Coded some initial spinner rules. First time you shoot the spinner, it stops it in the upper lanes. Next time it orbits around back to the left flipper for a 2x spinner shot, and stops it in the lanes. Then you get two orbits before it stops it, etc.

Coding this was way harder than that sounds, due to me not really thinking about 'shots' and such when I designed the playfield. A ball shot through the spinner could go in one of six lanes. Or it could fall back through the spinner. Or fall down the shooter lane. Or it could manage, theoretically, to go below the left one way gate and continue on to the left. When the gate is open, it will usually go all the way around, triggering the left orbit switch and the left inlane on its way down. But it could also fall short into the upper eject, or go under the ramp, or fall even shorter into any of the lanes, etc from before.

Originally I figured I didn't need to care about this too much. I'd just consider a shot to the spinner as whenever the spinner suddenly spun a few times. But when I'm purposely designing the code to let you repeatedly rip the spinner, it's very likely the spinner will still be spinning somewhat by the time you rip it again, or you could even go right under it while it's spinning, so I ended up with a ton of code for different edge cases trying to detect when the player does a successful orbit or not, multiple timers going on, etc. It's a bit of a mess, and it's going to be even more of a pain to debug if something goes wrong.

It would have been really nice to close up some of the areas a bit more so I could know 'for sure' whether a ball passed through there, rather than having a big open area up there for the ball to bounce around in. Too bad big areas for the ball to bounce around in are fun...

Scoring wise, I'm trying to sorta take a page from Meteor, since I like the way its spinner value is continually fluctuating. For the first iteration of that, my attempt is to make the spinner score more when you having matching numbers of drop targets down on each bank. For instance, the spinner starts at 10 points. You knock down one target on bank A, that goes up a bit. You knock down one target on bank B as well, that number goes up even more. Two targets down on each bank is better than one, etc. I'll try to balance it so you can get the spinner up really high, but at the same time if you hit one stray target it may ruin it completely.

Hopefully this will also encourage people to 'shoot around' more, instead of finding one or two banks they feel safer on and just picking targets off those