Cuando a un estudio se le pide «añadir un modo social», normalmente se le está pidiendo algo mucho mayor que un ajuste. En una plataforma que publica títulos de dinero real y de casino social, la edición social es una versión de front distinta, con sus propios textos, su propio conjunto de monedas, sus propias reglas de idioma y su propia revisión. Tratarla como una bandera en la compilación existente es la forma más habitual de que un juego encargado llegue a su fecha de envío con una segunda revisión todavía por delante.
La distinción no es pedante. Las directrices de aprobación publicadas por Engine indican que cada solicitud de aprobación cubre una versión de front y una versión de matemáticas, revisadas juntas, y que tras la aprobación solo se permiten actualizaciones menores para corregir problemas visuales: no se admiten cambios en el modelo matemático subyacente, la incorporación de nuevos modos de juego ni modificaciones de las mecánicas. Si la edición social necesita nombres de modo distintos, textos de tabla de pagos distintos o una presentación de moneda distinta, esas decisiones tienen que existir antes del envío, no después.
Este artículo está escrito para las dos personas que tienen que tomar esa decisión: el responsable de contenido de un operador o de una plataforma que valora si un título puede servir a un casino social, y el productor del estudio que decide qué debe incluir el encargo. La parte de certificación de una edición específica de mercado se trata aparte en la guía de evidencia de certificación localizada; esto es la parte del alcance de la compilación.
El interruptor que ves es un banco de pruebas, no una estrategia de compilación
La documentación de Engine describe un ajuste de modo social dentro del modal de juego, y es fácil leerlo como prueba de que el modo social es un conmutador. Es una superficie de prueba: permite comprobar cómo se comporta una compilación cuando la plataforma la carga en un contexto social. El comportamiento que expone es real, y lo dirige la plataforma, no los ajustes del propio juego.
El RGS envía un parámetro de consulta social=true o social=false para indicar si el juego se carga en un casino social. Se espera que el juego gestione ambos casos. Ese único parámetro cambia más que una etiqueta: cambia qué archivo de idioma es adecuado, qué códigos de moneda llegan y qué palabras están permitidas en cualquier lugar que el jugador pueda leer.
Así que la primera pregunta del brief no es «¿podemos soportar el modo social?». Es «¿cuál de las dos ediciones es la compilación principal y qué hereda la segunda?». Un estudio que responde «la misma compilación, con otro archivo de idioma» ha descrito un enfoque real y viable, pero solo si los textos, los nombres de modo y el tratamiento de la moneda se diseñaron para ello desde el principio.
La superficie de textos restringidos es trabajo de contenido, no un buscar y reemplazar
El ejemplo publicado más claro de hasta dónde llega una edición social es la lista de frases restringidas que Engine aplica para stake.us. El requisito es que un juego aprobado para ese mercado no pueda contener los términos listados cuando se ejecuta en modo social, y la lista no es corta: bet pasa a play, buy a play, cash a coins, deposit a get coins, wager a play, stake a play amount, total bet a total play, withdraw a redeem, credit a balance, currency a token, bonus buy a bonus o feature, y place your bets a come and play o join in the game.
Lo que convierte esto en un problema de contenido y no en un buscar y reemplazar es el alcance. El requisito cubre todo el texto visible para el jugador: etiquetas de interfaz, botones, tablas de pagos, páginas de ayuda, pantallas de carga, ventanas emergentes, diálogos de confirmación, mensajes de error y menús de ajustes. La propia guía de Engine nombra los fallos que ve con más frecuencia: un botón de apuesta que sigue etiquetado como «Bet», «Auto Bet» o «Total Bet» dentro de un menú de apuesta automática, y «Buy» que permanece en un botón de compra de bonificación o en su diálogo de confirmación.
Esas son exactamente las cadenas que viven fuera del documento de textos principal. Una tabla de pagos se genera a partir del modelo matemático. Un menú de apuesta automática es un componente con sus propios valores por defecto. Un diálogo de confirmación suele escribirlo quien construyó la función, tarde, y nunca se revisa como texto. Un estudio que planifica la edición social como una pasada de traducción encontrará estas cadenas después de que la versión de front esté congelada, que es el peor momento posible.
La respuesta práctica es un inventario de textos como entregable: cada cadena visible para el jugador en la compilación, su archivo de origen y su reemplazo en modo social, revisados como una lista en lugar de descubiertos en una prueba. Ese inventario es también el artefacto que un revisor de la plataforma puede comprobar, lo que lo hace más valioso que una garantía de que la compilación «se ha revisado en busca de términos restringidos».
Los nombres de modo son la trampa, porque viven en el archivo de matemáticas
El requisito que atrapa a equipos con experiencia es el de los nombres de modo. La guía de Engine dice que los nombres de modo no pueden contener términos restringidos como «buy», «bet» o «pay» y —la parte importante— deben llamarse igual en el juego, en la ventana de repetición y en los archivos de matemáticas.
Esa última cláusula convierte una decisión de nombres en una decisión de versiones. En Engine, un juego es un conjunto de archivos estáticos: una versión de matemáticas que contiene todos los resultados posibles, generada de antemano y comprimida por modo, y un front que reproduce esos resultados. El RGS selecciona un número de simulación con una frecuencia proporcional a su peso y devuelve los eventos de ese resultado en la respuesta de /wallet/play. Los nombres de modo forman parte de esa estructura, no son una cadena de visualización superpuesta.
Así que un modo llamado «Buy Bonus» no se arregla renombrando un botón. Hay que renombrarlo en los archivos de matemáticas, en el juego y en la ventana de repetición a la vez, y si el juego ya está aprobado, las reglas posteriores a la aprobación no permiten añadir modos ni cambiar el modelo matemático. Una edición social que necesita nombres de modo distintos es, por tanto, un envío distinto, planificado desde el principio, no una corrección aplicada después.
La ventana de repetición merece su propia línea en el brief por la misma razón. Es una superficie visible para el jugador que reproduce una ronda pasada, y la guía de Engine exige que también esté libre de términos restringidos. Una pantalla de repetición que muestra el nombre de modo original incumplirá un requisito que nadie pensó en probar, porque la ventana de repetición suele construirse una vez y no revisarse nunca.
Moneda e idioma son configuración que el brief tiene que nombrar
Otros dos parámetros pertenecen al brief porque son baratos de especificar y caros de añadir después.
El primero es la moneda. La guía de Engine exige que el juego cargue y se muestre correctamente con las monedas sociales XSC (SC) y XGC (GC), y en concreto que no se prefijen esos valores con el signo del dólar. Es una regla de formato con un fallo real: una compilación que formatea todos los saldos con un único formateador de moneda mostrará un saldo social como importe en efectivo, lo que es a la vez incorrecto y, en un casino social, un problema de cumplimiento y no cosmético.
El segundo es el idioma. El inglés es el único idioma admitido en modo social en esa plataforma, y la guía recomienda un archivo de idioma adicional con el prefijo sweeps_ para gestionar los cambios de frase. Esa recomendación es la diferencia entre una compilación con una segunda tabla de cadenas y dos compilaciones que se separan. Un estudio que mantiene los textos sociales en un archivo aparte puede actualizarlos sin tocar el texto de dinero real; un estudio que edita las cadenas principales en su sitio ha hecho las dos ediciones mutuamente excluyentes.
Ninguna de las dos cosas es motivo para rechazar una edición social. Ambas son motivos para escribirlas en el encargo antes de construir la versión de front, junto a las comprobaciones de aceptación de front de Engine que ya cubren combinaciones de idioma y moneda.
El contrato de sesión forma parte de la compilación, no es un problema de la plataforma
Una edición social sigue teniendo que cumplir el mismo contrato de RGS que cualquier otra compilación, y el contrato tiene comportamientos que un front puede equivocar de formas que solo aparecen en juego real.
Todo flujo empieza con una llamada a /wallet/authenticate cuando el juego carga por primera vez. Esa llamada autoriza el identificador de sesión para /wallet/play, /wallet/balance y /wallet/end-round. Si el juego nunca la llama, las llamadas posteriores devuelven un error 400 ERR_IS porque la sesión no es válida. El flujo básico recomendado abre una ronda con /wallet/play y la cierra con /wallet/end-round cuando terminan las animaciones.
Para una ronda más larga —una bonificación de tragaperras, por ejemplo— la guía sugiere guardar hasta dónde ha visto el jugador y, en la siguiente carga, usar el valor round.event de la respuesta de /wallet/authenticate para reanudar las animaciones desde ese punto. Es un requisito de reanudación, y se relaciona con la edición social de una forma que conviene nombrar: una ronda reanudada muestra el mismo nombre de modo y los mismos textos que la original, así que un cambio de textos que no se aplique a la ruta de reanudación produce una pantalla que incumple la regla de términos restringidos solo para los jugadores que abandonaron a mitad de ronda.
El contrato de URL también importa. El juego se carga con un identificador de sesión, un idioma, un valor de dispositivo mobile o desktop y un rgs_url. El identificador de sesión es obligatorio en cada solicitud, y el rgs_url no debe codificarse de forma fija porque puede cambiar en tiempo de ejecución. Una compilación que fija el endpoint del RGS funcionará en el estudio y fallará en un entorno que el estudio no controla.
Qué debería decir realmente el brief
En conjunto, un encargo que incluye una edición social necesita seis decisiones registradas antes de que empiece la producción.
Qué edición es la principal. La compilación de dinero real o la social. La edición principal fija el documento de textos, los nombres de modo y la estructura de la tabla de pagos; la secundaria hereda y adapta. Decidirlo tarde significa reescribir los nombres de modo del archivo de matemáticas, que es el camino caro.
El inventario de textos. Cada cadena visible para el jugador, su origen y su reemplazo social, como una lista revisada. Incluye las superficies generadas: tablas de pagos, menús de apuesta automática, diálogos de confirmación, mensajes de error, pantallas de carga y la ventana de repetición.
Los nombres de modo, acordados una vez. Nombres que sobrevivan a ambas ediciones, comprobados contra la lista de términos restringidos antes de generar la versión de matemáticas. Es la decisión con más probabilidad de forzar un reenvío.
La presentación de la moneda. Cómo se formatean XSC y XGC, y dónde vive el formateador, para que un saldo social no pueda heredar un símbolo de efectivo.
La estrategia de archivos de idioma. Una tabla sweeps_ separada en lugar de ediciones en el sitio, para que las dos ediciones se mantengan de forma independiente.
El comportamiento de sesión y reanudación. Autenticación antes de cualquier otra llamada, cierre de ronda tras las animaciones y una ruta de reanudación que muestre los mismos textos que la ronda original.
Nada de esto requiere una relación con la plataforma ni una aprobación especial. Requiere que el comprador pregunte por el alcance de la segunda edición en el momento del briefing, cuando los nombres de modo son todavía una decisión de diseño y no un formato de archivo. El coste de esa conversación al inicio es una reunión; el coste de descubrirlo después de la aprobación es un segundo envío con un modelo matemático congelado.
Para un estudio, la posición honesta es que una edición social es un segundo producto con un núcleo de arte y matemáticas compartido. Es una afirmación de alcance, no una negativa, y es la que permite a un editor planificar un lanzamiento en ambos catálogos en lugar de descubrir la segunda revisión el día en que se aprueba la primera. El brief de proyecto de Engine es la vía para fijar ese alcance, incluida qué edición es la principal y qué hereda la segunda, antes de que empiece la producción.
Preguntas frecuentes
¿El modo social es un ajuste en la misma compilación del juego?
No. La plataforma envía un parámetro social=true o social=false para indicar si el juego se carga en un casino social, y se espera que el juego gestione ambos casos, pero la edición social lleva sus propios textos, presentación de moneda y reglas de idioma. Las directrices de aprobación de Engine indican que cada solicitud cubre una versión de front y una de matemáticas revisadas juntas, así que una edición social con nombres de modo o textos de tabla de pagos distintos es un envío separado, no un interruptor.
¿Por qué un estudio no puede simplemente renombrar los modos después de la aprobación?
Porque los nombres de modo forman parte de la estructura matemática, no son una etiqueta de visualización. La guía de Engine exige que los nombres de modo estén libres de términos restringidos y que se llamen igual en el juego, en la ventana de repetición y en los archivos de matemáticas. Tras la aprobación solo se permiten actualizaciones menores para corregir problemas visuales; añadir modos de juego o cambiar el modelo matemático no está permitido. Un cambio de nombre que toca los archivos de matemáticas es, por tanto, un nuevo envío.
¿Qué palabras hay que cambiar en una compilación en modo social?
Engine publica una lista de frases restringidas para stake.us que incluye bet por play, buy por play, cash por coins, deposit por get coins, wager por play, stake por play amount, total bet por total play, withdraw por redeem, credit por balance, currency por token y bonus buy por bonus o feature. El requisito cubre todo el texto visible para el jugador, incluidas tablas de pagos, páginas de ayuda, pantallas de carga, ventanas emergentes, diálogos de confirmación, mensajes de error y menús de ajustes.
¿Cómo debe gestionar una compilación social la moneda y el idioma?
La guía de Engine exige que el juego cargue y se muestre correctamente con las monedas sociales XSC y XGC, sin prefijo de signo de dólar, y afirma que el inglés es el único idioma admitido en modo social. Recomienda un archivo de idioma separado con el prefijo sweeps_ para los cambios de frase, lo que mantiene los textos sociales mantenibles sin editar el texto de dinero real en su sitio.
¿Qué espera el RGS del front?
Todo flujo empieza con /wallet/authenticate, que autoriza el identificador de sesión para /wallet/play, /wallet/balance y /wallet/end-round; sin ella, las llamadas posteriores devuelven un error 400 ERR_IS. El flujo básico abre una ronda con /wallet/play y la cierra con /wallet/end-round cuando terminan las animaciones. Para rondas más largas, el valor round.event de la respuesta de autenticación permite al front reanudar las animaciones donde el jugador las dejó, y el rgs_url no debe codificarse de forma fija porque puede cambiar en tiempo de ejecución.
