That is the question being discussed by casino operators worldwide. To facilitate the discussion, it may be useful to step back and take a look at some of the pros and cons of the typical slot floor network on most gaming floors today. As a point of reference, most casino slot floor networks currently look something like this:

The Pros

Comfortable

Like your favorite sweatshirt, your current network may have a few holes, but you know it well and it still serves its intended purpose.

Well-Tested

Most existing slot floors have been around for nearly 20 years, so many of the problems have been found and (hopefully) corrected.

Avoids the Awkwardness and Frustration of Dating

When you commit to a vendor that uses a proprietary slot floor system, for the most part, you only have to focus on that one relationship. Whether it’s calling support, getting training for your team or inquiring about new features, having a single point of contact (and responsibility) can be reassuring. Of course, marriage can have its own share of awkwardness and frustration, but I’ll leave that for another time.

Less Regulation

Since all traffic on a proprietary slot floor goes through a Slot Machine Interface Board (SMIB), new functionality that does not affect the game does not require regulatory approval. (Well, it didn’t until Ticket In/Ticket Out was added to slot floor systems. After that, the system was considered a gaming device, so any change is now highly regulated.)

Less Expensive

By far, staying with your existing slot floor network is the less expensive option in terms of up-front costs because you already have the system and network in place. Your costs for an existing proprietary network mainly involve new features, minor upgrades and maybe a bit of training.

The Cons

Overly Complicated

If the new feature is going to be initiated by your enterprise data warehouse or marketing system, and includes an interaction with the player and an update to the credit meter on the EGM, there are potentially five different protocols that need to be modified (some of which may not even be controlled by your system vendor). With so many moving parts, the possibility of issues creeping into a feature increases for each protocol on the network.

Inefficient

There are as many as six different program environments that must be modified, tested, approved and deployed to your gaming floor in order for a feature to be available to your players. No wonder the typical development cycle is 18 months or more! This lengthy and complicated development cycle presents significant challenges to the rapid development and deployment of new features.

Slow, Limited Communications

The final connection to the EGM uses a slow, polled serial communication link running a protocol called SAS (created 20+ years ago). This SAS link works pretty well over a local connection with the SMIB, but it can’t be used to move large amounts of data to or from the EGM, nor could it ever be used to talk to multiple hosts. Most player interactions are done using player peripherals hung off a third-party SMIB that is supplied by your slot system vendor because player interactions can’t happen across the SAS communication link.

Discourages Innovation

All of the protocols in use (other than SAS) are developed by the system vendor with an eye towards securing their floor network environment (an incredibly important concern when processing vouchers, transferring money and doing other important business functions). However, most don’t employ off-the-shelf security mechanisms (like TLS or SSL) as those types of industry standard solutions are not really available for custom-developed communication protocols. Plus, due to the proprietary nature of the interfaces, any innovation must come from or be sanctioned by the slot system vendor. While slot system vendors are very capable, network lock-in as well as proprietary/non-standard protocols discourage standard Internet technologies and new ideas from moving easily to the slot floor.

In a nutshell, there is certainly a case to be made for proprietary networks. Each casino will have its own set of considerations when deciding how to move its slot floor into the future.

What do you see as the pros and cons of proprietary slot floor networks?

In the earliest slot floor management systems (circa 1975), accounting and security were all that was important, so system manufacturers came up with the concept of the Slot Machine Interface Board (SMIB), which they could stick into every slot machine (many were mechanicals or electro-mechanicals). These early SMIBs connected to a wiring harness that would detect when hard meters incremented, and had a number of mechanical door switches to tell when doors were opened. SMIBs worked and life was good.

A bit later (mid 1980’s), gaming machines got a bit more advanced and were able to start sending data through a serial connection to the SMIB. Even today, most Electronic Gaming Machines (EGMs) speak an old (but good) protocol call SAS (IGT’s Slot Accounting System protocol). This protocol, created over 20 years ago, uses a slow serial link (19,200 bits per second) in which the host polls the EGM for information multiple times per second. For example:

HOST: “Do you have anything to tell me?”

EGM: “No”

HOST: “Do you have anything to tell me?”

EGM:“No”

HOST: “Do you have anything to tell me?”

EGM “No”

HOST: “Do you have anything to tell me?”

EGM: “Yes. Here’s a hex poll code that you need to understand so you can send me other hex codes to request more detail. If you get it wrong, or don’t get back to me at exactly the frequency that I’m expecting, I’m going to stop talking to you.”

These serial protocols (like SAS) worked fine for getting meters and tilts from the EGM, but they didn’t have the capacity to allow you to interact with your player or send configuration data to the EGM. So, system vendors were compelled to react by beefing up their SMIB and adding a card reader and a small display to identify employees and display tilt codes. In the late 1980s, SMIBs were expanded again to allow the casino to track players at the EGM. Over time, new and more advanced player peripherals were added to the SMIB – first keypads and buttons, then bigger displays, followed by lighted bezels around the card reader. Once again, life was good.

More recently, however, the general public has become tech savvy (especially with all of the cool new stuff happening on the Internet), making the rather static player experience supplied by the SMIB vendor a bit boring. System vendors have reacted with snappy 3”x6” displays that allow secondary games on them and menus of choices for the player. While these changes mark continual improvement, they’re not really up to the experience I get through my browser or on my iPhone. It really is time for another radical change.

And that’s where G2S comes in – a protocol that, from the ground up, was designed to communicate all of the accounting and security information from SAS, handle all of the player tracking communications that are currently happening with your SMIB, add in remote configuration of the EGM (downloading and installing new software) and access to all of the data that’s been locked inside the slot machines (you know, all of those metrics you now have to read at the EGM). Plus, it has been designed to run over a high-speed network that also accommodates streaming media, video conferencing, instant messaging, and anything else you can do on the Internet. And coolest of all is that the interactions with the player can occur on those two really big high def displays that are on most EGMs.

That concludes the history lesson. Next time, we’ll dive under the covers to see how easy G2S really is.