El frame

El juego se ejecuta en un iframe, en una página de uloggd hecha solo para ese juego. La política de la página deja que el frame contenga tu origen y ningún otro, y el frame queda cubierto hasta que el SDK completa el handshake.

El sandbox

<iframe
  src="https://orbit.example.com/?frame_id=...&instance_id=...&platform=desktop&locale=es&mode=live&protocol=1"
  sandbox="allow-scripts allow-same-origin allow-forms"
  allow="autoplay; gamepad; ..."
  referrerpolicy="strict-origin"
></iframe>

Nunca se conceden: ventanas emergentes, navegación de la página superior, diálogos modales, descargas, la Storage Access API, bloqueo de orientación ni presentación. En la práctica:

• window.open, los enlaces con target="_blank" y top.location fallan. En la v1 un juego no puede abrir ningún enlace; la página de la tienda lleva los enlaces a tu política de privacidad, tus términos y tu soporte.
• alert, confirm y prompt no hacen nada. Dibuja tus propios diálogos.

Permisos

El atributo allow delega autoplay y gamepad. Todo lo demás se niega, con el atributo y con la Permissions-Policy de la página del reproductor: cámara, micrófono, geolocalización, pagos, USB, serie, HID, Bluetooth, captura de pantalla, WebAuthn y las demás APIs de credenciales, fuentes locales, gestión de ventanas, detección de inactividad, picture-in-picture, las APIs del privacy sandbox y el acceso a la red local. Firefox ignora la cabecera Permissions-Policy.

El acceso a la red local se niega en todas las páginas de uloggd menos una: la página de tu URL de desarrollo, y solo cuando esa URL está en tu propia máquina. Allí, la política de la página y el allow del frame dejan que el frame alcance ese origen local, y nada más de tu red. El navegador todavía puede preguntarte antes.

La pantalla completa es de la página de uloggd, y el juego la pide con el SDK (abajo).

La primera petición a tu URL de entrada lleva Referer: https://uloggd.com/, nunca la ruta de la página.

Almacenamiento y cookies

• El almacenamiento está particionado por el sitio superior. localStorage, IndexedDB, la Cache API y los service workers dentro de uloggd están separados de los del mismo juego abierto en tu propio sitio, y un jugador que borra los datos del sitio de uloggd los borra también. Guarda en tu servidor lo que importa.
• Las cookies no están particionadas de forma fiable. Safari bloquea las cookies de terceros y Firefox las separa por sitio, pero Chrome todavía envía tus cookies sin particionar, y las de cada tercero que el juego incorpora. No construyas sesiones sobre cookies: cuando tu servidor haya verificado un token de identidad, dale al juego un token tuyo y envíalo en una cabecera Authorization. Si necesitas una cookie, márcala SameSite=None; Secure; Partitioned.
• Un service worker que registres vive en la partición de uloggd y sigue sirviendo lo que guardó a los jugadores que vuelven, sirva lo que sirva tu servidor hoy, y las verificaciones de uloggd no lo ven. Si usas uno, ata su caché al build.

Un documento, de principio a fin

• Cualquier navegación del frame saca el juego de la pantalla: un segundo evento load, un canal de mensajes cerrado o una navegación que bloqueó la política de la página. El jugador ve que el juego se reinició, con un botón para volver a jugar. Los juegos de varias páginas y location.reload() no se admiten.
• La política de la página solo admite exactamente tu origen, así que el navegador bloquea una redirección o un enlace a cualquier otro.
• Los frames que anides dentro del juego heredan el sandbox, pero siguen tu propia Content-Security-Policy, no la de uloggd. Declara en el lanzamiento cada tercero que incorpores.
• Nunca llames a history.back(): desde un frame con sandbox puede mover la pestaña entera del jugador.

Empezar, seguir vivo, cerrar

• Handshake. createArcadeSDK envía a uloggd un handshake, y uloggd responde con un canal de mensajes privado. El frame queda cubierto hasta entonces; a los 30 segundos, el jugador ve que el juego no cargó. Crea el SDK como lo primero que hace la página, antes de descargar archivos grandes, para que el jugador vea tu propia pantalla de carga.
• Señal de vida. uloggd envía un ping al juego cada segundo, y el SDK responde. Tras 2 segundos sin respuesta, el frame se cubre de nuevo y el jugador ve que el juego no responde; la siguiente respuesta lo descubre. Deja libre el hilo principal: divide los trabajos largos o llévalos a un worker.
• Pestaña oculta. Tras 5 minutos oculta (15 con la capacidad background-audio), uloggd envía CLOSING y quita el frame.
• Cerrar. Cuando el jugador pulsa Cerrar, el juego recibe CLOSING y hasta 1 segundo para guardar antes de que se quite el frame. Guarda sobre la marcha en lugar de contar con ese segundo.
• Suspensión. Si uloggd suspende el juego, las nuevas aperturas se rechazan al instante, y los frames en marcha se cierran con el código 4010 en menos de 60 segundos.

Pantalla completa y bloqueo del puntero

• El frame no puede pasar a pantalla completa por su cuenta. Llama a arcade.commands.requestFullscreen() desde un clic o una tecla: uloggd pone su propio contenedor en pantalla completa, con su barra todavía visible, u ocupa toda la pantalla en un iPhone. Sin un gesto reciente, la llamada falla con requires_gesture.
• Declara la capacidad pointer-lock para usar requestPointerLock(). uloggd no ve un bloqueo que tu juego mantiene, así que, en un lanzamiento con ella, el diálogo de consentimiento nunca se abre solo: cuando authorize lo pide, la barra del jugador muestra la petición con un botón Responder y avisa que Esc libera el puntero, y el diálogo se abre desde ese clic. Sin la capacidad, authorize abre el diálogo directamente.

Parámetros de apertura

uloggd añade su propia query a tu URL de entrada:

?frame_id=Q1r9...&instance_id=0b7e...&platform=desktop&locale=es&mode=live&protocol=1

Nada en ella identifica al jugador, así que tus registros y analíticas pueden guardarla. El SDK la lee por ti, y los mismos valores llegan en context cuando ready() se resuelve.

Límites que debes conocer

• La revisión certifica un momento, no un build. Las verificaciones diarias, las nuevas revisiones, las denuncias de jugadores y la suspensión son como uloggd sigue de cerca un juego tras la aprobación.
• Las direcciones IP de los jugadores llegan a tus servidores y a cada tercero que carga el juego.
• Donde el navegador no da a los frames de otro sitio un proceso propio (Safari, Firefox para Android y Chrome para Android), un juego que bloquea su hilo principal congela también la página de uloggd que lo rodea, hasta que lo suelta.
• Ninguna cabecera impide escribir en el portapapeles tras un gesto. Pedir al jugador que pegue o ejecute algo va contra las reglas (consulta Política de revisión).