Mad Props to Dick for coming out with such a really cool system!

I've been collaborating with him and some other developers and we've got a lot of good stuff in the works.

My first custom game using the tech will be Bally Paragon.

Here's a demo of my progress (an impromptu livestream I did the other day). I've now got the entire base game ruleset implemented in BSOS and will be working on custom sounds and additional features:

My plan is to develop several other customized game versions, including: Kings of Steel, Silverball Mania, Spectrum, Futurespa, Hot Doggin, Seawitch, Supersonic and some others.

Also, I've been focusing on creating light routines that are optimized for LEDs. I think Dick has been working mostly with incandescents and he can do some really cool effects with those that aren't as easy/possible to do with LEDs. (What he's done with his version of Mata Hari takes bulb lighting to another level I haven't seen in other Bally games - really nice dimming effects).

Certain techniques for doing light routines need a different approach with LEDs than incandescents. For example, with regular bulbs you can turn them all off, then turn the ones on you want to enable and it's not noticeable. But if you use that technique with LEDs they strobe. So extra care needs to be taken with LEDs to not turn a light off that should normally be on, even if it's for a few milliseconds.

Here's an example of a small routine I created for Paragon that is "LED-friendly" and will work on other games. A simple attract mode function that flips half of the lights on, half off at 500ms intervals:

unsigned long BlinkTimer=0;

void AlternatePlayfieldLights() {
static byte flip=1;
if ((CurrentTime-BlinkTimer)>500) {
BlinkTimer=CurrentTime;
flip=1-flip; // alternate between 0 and 1
for (byte x=0;x<40;x++) {
BSOS_SetLampState(x,(x+flip)%2,0);
}
}
}

On Paragon, there are some backbox lights above address 39 so I stop there and just alternate playfield lights. This code could be different for incandescent by simply turning all lights off, then turning every other light on, but with LEDs this would cause strobing. This may not be the best example of code optimized for LEDs but it works well with either. And should be usable in other games too.

This is what I did. My plan was to emulate the game (Paragon) as the original. I would actually recommend this to anybody wanting to take a crack at things, because the base rulesets are fairly simply and doing so puts all the systems in place to make a more elaborate game operate. It also lets you "cut your teeth" on the idiosynchrasies of this type of work (of which there are plenty... typically when you're programming you're not likely to set something on fire if you make a mistake.. lol)

Then again, I'm working on a game that is already beloved in the community and is often used for competition, so I didn't want to make my version significantly different. I picked Paragon because I recently picked one up and planned to restore it. And it was a good example to learn on.

I've been wanting to redo certain games for awhile now. For example Spectrum is such a beautiful, unique game that has some fatal flaws in its design. I would really like to make that game play like it should. And other games would be just plain fun to mess with.

I think it's possible for anybody to approach this tech and get into it. Being more experience in programming definitely helps, and unfortunately, the more "old school" you are, probably the better. It's hard to compare C/C++ to the high level languages modern programmers use like Python, Java, etc. It's significantly different. The IDE doesn't hold your hand and check everything, so you have to be super diligent. If things go wrong, stuff blows up or the game just reboots with no errors or indication. On top of that the Arduino IDE is pretty awful with very limited features.

Luckily I've been working with this tech for quite awhile. I've been programming for 30+ years and have written a bunch of software systems that have been running on the Internet in C (where bugs will be found pretty quickly when you have thousands of people using stuff). So I'm used to doing mission critical work. One of my worries is if there's a ton of code for this technology floating around from varying levels of programmers who might not have fully-debugged their work - this can cause nasty things to happen with hardware if not handled properly. I completely understand why game makers don't want to give people easy access to mod the program design of their machines.

However I wouldn't discourage anybody from trying. But the coding skill is higher level because the program code is lower level than what most people are used to, and on top of that, the way the coding is implemented on Arduino is a lot different from typical coding. (The Aduino and pinball machine is in a constant loop and you have to program all the interrupts manually in such a way that it runs smoothly - at times it can melt your brain a bit because everything feels recursive).

That being said, the hardest part is just getting up to speed with the OS and the topology of the system. I spent probably 1-2 months just studying sample code. I took PinballMachineBase, and studied that. Then I picked a finished set of code and started poking around in that, moving and copying and forging my own set of routines into a framework. I think the base framework is a good start, but it doesn't include a lot of basics that you need to make the game do all the things you expect.

Do you mean save high scores or something else? It does all that and more. I'm looking forward to adding additional functionality with more powerful Arduino/RP versions (especially ones that can talk to the Internet.

If you or anybody has any questions, feel free to reach out to me. IMO, one of the best parts about this project is how everybody gets to collaborate. We've got a really supportive community.

I'll try to make a separate post about my Paragon project soon. I am getting close to having it finished and am anxious to work on some other stuff, but we're also addressing some minor glitches with different versions of hardware/software.

This is 150% something I want to do too. And I have the resources to be able to develop the cloud/server side that could receive the data. We just need to fill in a few missing bits technologically. One issue is, with the current version of Arduinos we're using, there's not as much program space to do much, and they don't support internet connectivity, but some other Arduino versions do. There's also the possibility of using Raspberry Pi versions too.

I've been messing with the Mata Hari version too. Dick's code has some pretty cool features, including some very unique strobing/dimming techniques that look really cool (but probably wouldn't work with LEDs). This is probably one game I would keep with the original lights because of the neat effects the BSOS version does.