Zision Interactive

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!