Protocolo SAS del lado EGM: guía práctica para que tu máquina funcione con cualquier sistema de casino

SAS (Slot Accounting System) es el protocolo que usan las máquinas electrónicas de juego (EGM) para hablar con el sistema de gestión del casino. Lo creó IGT y hoy es el estándar de facto en la industria. Tiene una especificación pública y detallada, así que en teoría implementarlo es seguir el documento.

En la práctica, lo más difícil que me tocó no fue la especificación. Fue probar la máquina con los distintos sistemas de casino y lograr que funcionara con todos. Este artículo es una guía de SAS del lado de la EGM con ese aprendizaje al centro.

SAS en cinco minutos

Enlace serial. La EGM y el host se conectan por un puerto serial. El host es el maestro: la máquina nunca habla si no le preguntan.
General poll. El host pregunta periódicamente a la máquina “¿qué pasó?”. La EGM responde con una excepción (un evento pendiente, como una puerta abierta o un billete aceptado) o con nada.
Long polls. El host pide datos o da órdenes concretas: leer meters, validar un ticket, iniciar una transferencia AFT, deshabilitar la máquina. Cada long poll tiene un código, datos y un CRC.
Tiempos estrictos. La EGM tiene una ventana muy corta para responder. Si llega tarde, para el host es como si la máquina no existiera.

Qué implementa la EGM

En la plataforma en la que trabajé implementamos SAS del lado de la máquina con:

Eventos y excepciones: una cola que no pierde eventos aunque el host tarde en preguntar o se desconecte.
Meters: entradas, salidas, jugadas, premios, billetes y tickets, siempre consistentes con lo que hay en NVRAM.
TITO: impresión y redención de tickets con validación del sistema.
AFT: transferencias electrónicas de fondos entre la cuenta del jugador y la máquina.
Progresivos, handpay y legacy bonus.

Lo difícil: un estándar, muchas interpretaciones

Cada sistema de casino implementa SAS a su manera, dentro de la especificación o no del todo. Las diferencias aparecen en lugares como:

Qué long polls usa cada sistema y cuáles ignora.
Frecuencia de polling y cuánto tolera una respuesta lenta.
Orden de los mensajes en flujos de varios pasos, como validar un ticket o una transferencia AFT.
Configuración de TITO y AFT: tipos de validación, registro de la máquina, límites.
Qué hace el host con una excepción que no espera o no reconoce.

Una máquina que funciona perfecto con un sistema puede fallar con otro, aunque las dos implementaciones digan “SAS”. Nosotros probamos con sistemas de distintos proveedores, entre ellos WinSystems, muy usado en casinos de México, y sistemas de Konami e IGT.

Cómo lograr que funcione con todos

Lo que nos funcionó y lo que recomiendo:

Estricto al enviar, tolerante al recibir. Lo que manda la máquina sigue la especificación al pie de la letra. Lo que recibe se valida con cuidado, pero sin romperse ante variaciones razonables del host.
Configuración, no forks. Las diferencias entre sistemas se resuelven con opciones configurables desde el menú del operador, no con una versión del software por cliente. Una versión por sistema es una pesadilla de certificación.
El juego nunca espera al host. Un host lento o desconectado no puede congelar la máquina. La comunicación SAS corre aparte y los eventos se encolan.
Registro completo del tráfico serial. Cuando algo falla en un casino, el registro de cada byte enviado y recibido es lo que permite saber si el problema está en la máquina o en el host.
Pruebas con cada sistema real. Un simulador de host sirve para el día a día, pero no reemplaza probar con los sistemas de casino reales. Mantén una matriz de funciones contra sistemas (meters, TITO, AFT, progresivos, bonus) y repítela con cada versión.

¿Necesitas implementar o diagnosticar SAS?

Somos un equipo en Ciudad de México que trabaja con fabricantes, estudios de juegos y operadores en la integración de SAS, periféricos y certificación GLI. Puedes ver lo que hacemos en desarrollo SAS y periféricos EGM, o leer también sobre autenticación GAT para GLI.