The start-up algorithm is the list of commands that get sent when RGS receives a commsOnline command from an EGM to initiate G2S communications. The list of commands is automatically filtered by the devices present in the EGM’s descriptorList. In the standard RGS, you can include or exclude G2S commands in the fixed start-up algorithm list, which is useful if your EGM doesn’t support one or more of the commands in the list, but you cannot reorder any of the commands or change any settings within any of the commands.

In the Tester Toolkit, the Start-up Algorithm editor is enhanced to provide you with complete control over the order of commands and their contents, to customize the algorithm as needed to simulate any host.You can also save a copy of the modified algorithm, making it easy to switch between different versions to meet various test environments.

Why would you need that much flexibility, you ask? Let’s take a look.

Whether you are an EGM developer coding against a particular host, a tester trying to improve integration with a specific vendor or trying to troubleshoot an issue in the field, being able to recreate the start-up algorithm accurately can save countless hours in tracking down issues. In any case, the process efficiencies and product improvements spell big savings.

If you are pre-testing EGMs before moving them to the slot floor, not only can you find issues before they happen in a live environment, you’ll have the information you need to better communicate issues back to the vendor. This means faster issue resolution and easier installs.

Creating custom algorithms in RGS is easy with a simple drag-and-drop interface.

Once you’ve created a custom algorithm, just make it the active RGS start-up algorithm and start communications with the EGM. You can choose to run the algorithm to the end or to step through the algorithm, which lets you choose when to send each command or to skip commands altogether.

For more information on the Tester Toolkit, head over to the RGS product page. If you’d like to try it out, just let us know.

If you are at G2E this week, stop by the Gaming Standards Association booth (#5028), and say hello to Russ and Marty. They would be happy to answer your questions on RadBlue tools and the GSA protocols!

If you are interested in the Operating Hours extension for the G2S protocol, we’ve added support for it in RST, RGS and RLT. Another great feature in this release is Message Sizing Analysis (in RAS), which lets you see message sizes. If you have GZIP enabled, you can see the pre- and post-compressed message size.

If you have questions or would like more details, let us know.

But getting there is a serious challenge. We have five kids, one van and at least 17 hours on the road. So there is a great deal of planning that is done up-front. We plot out where to get gas, what rest stops to hit, what snacks to bring and where to find the first Chick-Fil-A once we cross into Tennessee. The goal is to have no surprises; to know exactly what we are doing.

And that is how we used to build software as well.

Not too long ago, we would sit down at the start of a project and write down everything we were going to do. We would plot out the bugs we were going to fix, the features we were going to add and how much time each step would take. We would spend weeks or months creating documents and charts filled with details. The final schedule would be meticulous in detail and brimming with confidence.

And then the van would crash into a ditch just outside of Indianapolis.

I’ll get into the hows and whys of that particular phenomenon in another blog, but first, I wanted to touch on how we do scheduling at RadBlue.

At the start of each development cycle, we have a short list of issues that we want to tackle. All of these issues relate to our goal of making our products better for our customers.

Then, we get in the car and start driving.

Going into a development cycle, we know that the journey is never going to be a straight shot. In fact, we know we aren’t going to get to the original destination. Our customers are great at voicing their opinions – on both the current products and on sneak previews of the work in-progress. And all of that input helps steer the car.

Our development process is a fluid one. We are constantly revising the schedule and feature set based on the latest information. Sometimes the input changes our direction by a few degrees. And sometimes the input completely changes our direction. Sometimes we head toward Disneyland, but end up at Disney World.

For a small, agile company like us, this is the best possible way to respond to the needs of our customers. It allows us to focus on what is needed and deliver it in a timely manner.

It’s probably the worst possible way to pilot a family to the ocean. But it’s a great way to build software.