Una propuesta de juego personalizado es la descripción de un sistema, y la cifra que aparece al final está vinculada al alcance de ese sistema. Dos estudios que presupuestan lo que parece la misma tragaperras pueden estar presupuestando dos sistemas distintos, porque los mercados en los que se venderá el juego determinan qué componentes, qué informes y qué evidencias debe incorporar el desarrollo.
Por eso el precio es lo primero que no conviene comparar, y por eso el juego es la unidad equivocada. Este artículo expone la unidad que sí es comparable —un sistema certificado por mercado— y las cinco líneas que convierten un montón de propuestas en una tabla donde la diferencia de precio tiene nombre.
Nadie publica un precio, y eso no es el obstáculo
En este mercado ningún estudio independiente publica un precio de paquete para un juego por encargo, y esta publicación tampoco. Una cifra anunciada sin una base de alcance no es información: es una posición de partida en una negociación que el comprador no puede evaluar.
La ausencia de una lista de precios no es, por tanto, el problema. El problema es que las propuestas están redactadas en unidades distintas. Una describe entregables, otra describe fases, otra describe un equipo y otra describe una cuota mensual con una estimación de lanzamiento adjunta. Si se ponen una al lado de otra, el único campo que significa lo mismo en las cuatro es el total.
La solución es mecánica: elegir una unidad, forzar todas las propuestas a esa unidad y poner precio a la diferencia.
Qué certifica realmente España
El expediente español de homologación es la declaración publicada más clara de cuál es la unidad de certificación, porque es un documento de inventario y no una revisión de un juego.
El Anexo III de la resolución de la DGOJ establece una estructura de nueve apartados para el informe de certificación definitiva de funcionalidad: identificación de la certificación, descripción del objeto de la certificación, resumen ejecutivo, cumplimiento de cada requisito técnico, análisis específicos, pruebas de integración, lugar, equipos y fechas de los trabajos, cualquier entorno de pruebas distinto del entorno de producción del operador y el soporte digital que acompaña al informe.
El segundo apartado es el que cambia una conversación comercial. El objeto de la certificación debe identificar los elementos de software utilizados en el sistema con el fabricante, el nombre de producto y la versión de cada uno, enumerar los componentes calificados como críticos junto con sus huellas digitales, indicar los centros de datos y relacionar los canales de acceso certificados. En el caso de una licencia singular debe además indicar los sitios web y nombres comerciales certificados, el papel del operador, la oferta de juego certificada con sus variantes y las tecnologías de acceso.
Ningún párrafo de esa lista dice “el juego”. Dice el sistema, con el juego dentro como un elemento versionado. Un cliente español no compra una tragaperras: compra una tragaperras que figura en un inventario aprobado con una huella digital, junto a un capturador y un almacén que pertenecen al sistema de control interno del operador y que no son del estudio.
La secuencia lo agrava. La homologación se desarrolla en dos etapas: un control previo documental con un informe preliminar y, después de concederse la licencia, informes de certificación definitiva sobre el sistema técnico realmente en uso, presentados en un plazo de cuatro meses desde la notificación de la concesión, un plazo que la resolución califica de no ampliable. Una propuesta que presupuesta un desarrollo pero no la producción de esa evidencia de segunda etapa está presupuestando un sistema que no puede homologarse.
La guía del inventario de componentes recorre toda la estructura del Anexo III, incluidos los campos del análisis del RNG.
Dónde te sitúas en la cadena cambia el alcance
Italia plantea lo mismo desde el lado opuesto, y es la pregunta más útil que se puede hacer a un proveedor.
La ADM exige que la verificación de conformidad técnica se aplique al sistema del concesionario en su conjunto, y no a elementos individuales considerados por separado. Ahora bien, cuando un concesionario utiliza un sistema de juego ya certificado y puesto a disposición por un concesionario proveedor de servicios, el organismo de verificación comprueba únicamente la integración de ese sistema de juego con el resto del sistema.
De esa única excepción se derivan dos productos comerciales. Un proveedor que se convierte en concesionario proveedor de servicios certifica un sistema de juego una vez y lo vende a operadores que después solo verifican una integración: la vía más barata para el comprador y la más lenta y más intensiva en capital para el proveedor. Un proveedor que coloca su título dentro del sistema de un operador es un pasajero en la fecha de certificación de ese operador.
Así que la primera pregunta sobre cualquier propuesta no es qué incluye. Es en qué lado de esa línea está el estudio, porque eso decide si el juego llega ya certificado o llega como una cosa más que el operador tiene que hacer verificar.
La vía italiana también fija la disciplina del código fuente. El código entregado para su inspección debe incluir, para cada archivo, módulo o función, su componente, una descripción breve y un historial de cambios, con la versión certificada identificada de forma única por versión. Los archivos críticos se identifican por resumen digital, y el organismo de verificación debe poder demostrar que los binarios examinados son el resultado de compilar el código que se le entregó. La guía del calendario italiano cubre la estructura de plazos y la verificación de producción que se realiza en el primer arranque de producción de cada tipo de juego.
La regla de cambios forma parte del precio
Todas las propuestas incluyen soporte posterior. Muy pocas enuncian la regla de clasificación que decide cuánto cuesta ese soporte, y esa regla varía lo suficiente entre mercados como para cambiar un total.
Gran Bretaña enuncia el principio y después da ejemplos en ambos sentidos. Una actualización mayor es cualquier cambio de software que pueda afectar a la equidad de un juego, y la equidad se define como cualquier cambio en el generador de números aleatorios, en el escalado y el mapeo, o en las reglas del juego, incluida la forma en que el software procesa esas reglas. El ejemplo publicado que pilla a los estudios es la reconstrucción de los arrays de símbolos para reducir la carga de CPU: no cambió ninguna regla, pero sí cambió la implementación de las reglas, así que requiere pruebas externas. Frente a eso están los elementos menores: formatos de sonido, el color de un sombrero, gráficos de fondo sustituidos porque caducó una licencia, un cuadro de diálogo que se muestra mal en un navegador.
España aplica una obligación continua más ligera pero con un filo más duro: un procedimiento documentado de gestión de cambios, un informe trimestral que describe los cambios realizados y mantiene actualizada la descripción del sistema, y autorización previa para modificaciones sustanciales que afecten a componentes críticos, pudiendo el regulador exigir la retirada hasta obtener la homologación. Italia establece un ciclo de autorización de doce meses y exige la certificación de conformidad de un cambio de emergencia en un plazo de dos semanas.
Si se juntan las tres, el “soporte de certificación” deja de ser una línea de presupuesto. Es una capacidad permanente: alguien que pueda clasificar un cambio, producir el artefacto que exige esa clasificación y volver a hacerlo el trimestre siguiente. El análisis del control de cambios ordena las superficies, y el alcance posterior a la aprobación cubre la versión de esa misma pregunta en la revisión de plataforma.
Cinco líneas que hacen comparables las propuestas
Fuerza cada propuesta a estas cinco líneas y los totales empezarán a significar lo mismo.
Identidades del desarrollo. La versión de las matemáticas, la versión del frontal, el conjunto de RTP ofrecido y la procedencia del RNG. El análisis del RNG que exige España pide el fabricante, el nombre de producto y la versión, la huella digital del binario, si es hardware o software, si es aleatorio o pseudoaleatorio y sobre qué fenómeno físico, si la instancia es compartida y con qué juegos, el algoritmo y las librerías en los que se apoya, cualquier procedimiento de resembrado, la longitud de bits del espacio y las pruebas estadísticas realizadas. Una propuesta que no puede nombrar todo esto no ha acotado el desarrollo: ha acotado una demo. El análisis de variantes de RTP explica por qué cada configuración de retorno es un objeto certificado propio.
La matriz de mercados y localizaciones. Una fila por mercado, una columna por localización y un certificado en cada celda. Un juego localizado es un desarrollo certificado y no una traducción, así que una propuesta que ofrece cuatro idiomas en tres mercados está ofreciendo hasta doce objetos certificados o una decisión documentada de lanzar menos.
Los artefactos de certificación, y quién es responsable de cada uno. Quién redacta el informe técnico, quién lo presenta, quién es el solicitante de registro, si el estudio es un proveedor ya homologado en ese mercado y quién paga al laboratorio de pruebas. La exigencia española de identificar el fabricante y la versión de cada elemento de software obliga a asignar esa responsabilidad a una persona, no a un departamento.
La superficie de integración. El RGS, el monedero, el agregador y cualquier reporte al sistema central. La interfaz es donde la estimación de un estudio resulta menos fiable, y las pruebas de integración que ejecuta un agregador son la evidencia de aceptación de esa línea.
La base de cambios y soporte. La regla de clasificación, las ventanas de aviso, el coste de re-test por nivel y la definición de defecto frente a petición de cambio. Es la línea que más a menudo queda como una tarifa sin clasificación detrás.
Qué esconde “no incluido”
Las exclusiones son donde más divergen las propuestas, y cinco de ellas mueven dinero real: las tasas de certificación y de laboratorio; la localización del desarrollo certificado; el inventario de componentes y su mantenimiento tras la entrega; la integración con un segundo agregador o un segundo monedero; y el primer lote de cambios posterior al lanzamiento.
Una disciplina útil es exigir que cada exclusión tenga precio en una unidad declarada —por mercado, por localización, por informe, por nivel de cambio— en lugar de quedar como “a consultar”. Una exclusión con unidad es una comparación. Una exclusión sin unidad es un marcador de posición para la negociación que ocurre después de haber reservado la campaña de lanzamiento.
Lo que no se puede comparar
Dos cosas de una propuesta no son comparables y no deberían puntuarse: las fechas y las aprobaciones.
Ningún estudio controla la cola de revisión de una plataforma ni el calendario de un regulador, y cualquier propuesta que prometa una fecha de lanzamiento está describiendo el mejor de los casos. Un estudio sí puede comprometerse con el plan de evidencias —qué artefacto produce quién, para cuándo y qué ocurre si se rechaza una presentación— y esa es la parte que merece compararse. El plan de lanzamiento multijurisdiccional expone la secuencia de la que debe derivarse una fecha realista.
La misma contención se aplica a los resultados. Una propuesta puede enunciar una hipótesis sobre lo que se supone que un título exclusivo o de marca debe hacer por el operador, y la instrumentación que la probaría, sin afirmar un efecto medido que no tiene. Si un juego debe juzgarse por el comportamiento entre el registro y el primer depósito, la propuesta puede nombrar el evento, la ventana de atribución y la línea base con la que se leerá. Lo que no puede hacer es convertirlo en una mejora prometida, porque nadie ha ejecutado todavía la prueba controlada. Di que se puede probar; no digas que aumenta nada.
La tabla, en la práctica
Construye una sola tabla. Las filas son las cinco líneas, después las exclusiones y después el plan de evidencias. Las columnas son las propuestas recibidas. Cada celda contiene un artefacto con nombre o un “ausente” explícito. La última columna contiene el precio unitario de todo lo que la propuesta excluyó.
Una propuesta que sobrevive a ese tratamiento es comparable, y la diferencia entre totales se convierte en una lista de cosas que un proveedor incluyó y otro no. Esa es una conversación sobre alcance, la única conversación que un comprador puede ganar.
Si estás montando esa tabla y quieres que las identidades del desarrollo, la matriz de mercados y el plan de evidencias estén resueltos antes de que se cotice una cifra, solicita una cotización de proyecto. La guía de encargo cubre cómo se arma el brief, y las comprobaciones del estudio cubren las cuestiones de licencia, titularidad y entrega que deciden qué queda cuando el proyecto termina.
Preguntas que hacen los compradores
¿Por qué los estudios de juegos personalizados no publican precios de paquete?
Porque el precio es función del alcance, y el alcance lo fijan los mercados y las localizaciones para los que debe certificarse el desarrollo, no la lista de características del juego. Un precio de paquete publicado tendría que asumir un conjunto de mercados, y cualquier suposición acertada sería errónea para la mayoría de los compradores. Un presupuesto con base de alcance es el documento más útil: permite al comprador ver qué unidad impulsa el total y eliminar una.
¿Qué significa “sistema certificado” si estoy comprando un juego?
Significa que el objeto que aprueba el regulador es más grande que el juego. En España el informe de certificación debe identificar cada elemento de software con su fabricante, nombre de producto y versión, y enumerar los componentes críticos con sus huellas digitales, de modo que el juego llega dentro de un inventario aprobado. En Italia la verificación se aplica al sistema del concesionario en su conjunto, y cuando se usa un sistema de juego precertificado el organismo de verificación solo comprueba su integración. En cualquier caso, la unidad que compras es un sistema que incluye tu plataforma.
¿Debería el soporte de certificación ser una línea aparte en la propuesta?
Sí, y desglosada más de lo que ofrecen la mayoría de los estudios. El desglose útil es por artefacto —informe técnico, inventario de componentes, análisis del RNG, evidencia de pruebas de integración, la propia presentación—, con cada artefacto asignado a un responsable y a un mercado. Una única línea de “soporte de certificación” esconde la parte que más varía entre proveedores, que es quién redacta el informe y quién responde cuando el regulador hace una pregunta.
¿Cómo comparo propuestas que cubren listas de mercados distintas?
Normaliza primero a la intersección y después pon precio a las adiciones. Toma el conjunto común de mercados y localizaciones, compara lo comparable dentro de él y trata cada mercado que un proveedor ofreció fuera de la intersección como una adición opcional con su propia lista de artefactos. La misma regla se aplica a las localizaciones: una localización es un desarrollo certificado, así que un idioma extra es un objeto de certificación extra y no una fila de traducción.
¿Puede una propuesta comprometerse con una fecha de lanzamiento?
Puede comprometerse con las partes que controla, que son la entrega de un desarrollo y su evidencia, y con una lista declarada de dependencias para las que no controla. La revisión de plataforma y la certificación regulatoria quedan fuera del control de un estudio, y una fecha que asume una cola de revisión es una previsión, no un compromiso. Pide la lista de dependencias y el plan de evidencias, y construye la fecha a partir de ellos y no del titular.
