Qüizo: Un Juego de Trivia Multijugador Para Eventos en Vivo

La mayoría de los productos multijugador asumen una audiencia cautiva y técnica —una app ya instalada, una conexión estable, jugadores dispuestos a esperar una pantalla de carga. La audiencia de Qüizo es la opuesta: doscientos desconocidos sobre el wifi del lugar, entrando desde cualquier navegador que ya tengan abierto, esperando estar jugando a los treinta segundos de que aparezca el código QR. Cualquier fricción en ese camino —un join lento, una cuenta regresiva que se traba, un botón de respuesta que no registra el toque— se lee como que el show se rompió, no como un ticket de bug.

Además, un solo operador tiene que manejar todo el evento solo: arrancar el juego, cambiar de quiz en medio de la sala, reiniciar una ronda que salió mal, echar a un jugador que no debería estar, todo desde una laptop, sin bajar nunca el proyector. Y como la respuesta correcta es información genuinamente secreta, cada capa que toca el estado del juego —la base de datos, el servidor, tres serializadores distintos— tiene que mantenerla así aun mientras retransmite el estado de la sala varias veces por segundo.

Elegimos el onboarding más simple que se nos ocurrió: un código QR y un código de sala de seis caracteres en la pantalla grande, un apodo, y nada más. Sin email, sin contraseña, sin descargar nada —todo el "sign-up" pasa en el tiempo que toma escribir seis letras. El código de sala sale de un alfabeto sin los caracteres visualmente ambiguos, porque un anfitrión leyéndolo en voz alta para doscientas personas no se puede dar el lujo de que la sala confunda un cero con una O.

La otra decisión de la que se desprende todo lo demás: el servidor es la única fuente de verdad de todo el juego, y no se confía en nada más. Cada pregunta tiene un único deadline autoritativo, calculado y guardado en el momento en que se abre —nunca en el cliente, nunca derivado de un timestamp del cliente—, así que un celular que se reconecta a mitad de pregunta después de un bache de wifi retoma la cuenta regresiva exactamente donde está la sala, en vez de arrancar con veinte segundos frescos que no se ganó.

Cada mutación en Qüizo —unirse, contestar, arrancar una pregunta, echar a un jugador— pasa por una Server Action, nunca por un endpoint REST; los únicos dos Route Handlers de la app son streams de Server-Sent Events de solo lectura, y hasta esos solo llaman a una función de lectura. Esa única regla es lo que mantiene honesta la máquina de estados: hay exactamente un lugar donde puede cambiar la fase de una sesión, protegido por una versión de concurrencia optimista grabada en cada fila de sesión, así que una acción del anfitrión tocada dos veces termina siendo un no-op en vez de saltear o duplicar una transición.

El proyector, el controller del anfitrión, y cada celular de la sala son tres vistas sobre ese mismo estado del que es dueño el servidor, sincronizadas por Server-Sent Events alimentados por un canal de Postgres LISTEN/NOTIFY —con un poll cada pocos segundos como respaldo de corrección ante cualquier notificación perdida. Una conexión que sobrevive a un bache de wifi del lugar sigue mostrando el último estado que conocía, muestra una pequeña pastilla de "Reconectando…" en vez de quedar en blanco, y retoma el estado real de la sala apenas vuelve —porque el proyector apagándose en medio del juego es la única falla que toda una sala nota al mismo tiempo.

Tres modos de juego corren sobre esa misma máquina de estados. Classic mantiene a todos en la misma pregunta al mismo tiempo, gana el puntaje más alto; Elimination saca a un jugador con una respuesta incorrecta o un timeout, y guarda en qué pregunta murió en vez de solo un booleano, así que un wipeout todavía se puede rankear por cuánto aguantó cada uno. El modo Deferred es la excepción a propósito —un anfitrión abre una ventana con límite de tiempo y cada celular juega todo el quiz a su propio ritmo, porque los dos modos sincronizados están acotados a una sola sala por diseño, y Deferred existe específicamente para levantar ese límite.

Esa razón es una lectura cuadrática: cada conexión abierta relee sola toda la lista de jugadores de la sala cada pocos segundos, lo que da aproximadamente N²/3 filas de jugador por segundo en toda la sala —unas 13.300 filas por segundo con doscientos jugadores, el tope duro de Classic y Elimination, solo para renderizar "esperando al anfitrión". Por eso existe el modo Deferred: su reloj por jugador elimina por completo el broadcast a toda la sala, así que sus lecturas se mantienen a costo constante sin importar cuánta gente juegue, y el tope de 200 jugadores que acota a los modos sincronizados simplemente no le aplica.

Escribir preguntas de quiz a mano no escala para un cliente que tiene un evento la semana que viene, así que un agente de IA las redacta a partir de un prompt de una línea —pero estructuralmente no puede tocar la base de datos. Tiene exactamente dos tools, ambas de solo lectura y scopeadas por el client id de quien llama, nunca por algo que provea el modelo, y cada otra capacidad que el framework del agente trae por defecto —una shell, un sistema de archivos, acceso a la web, sub-agentes— está explícitamente deshabilitada. La salida del modelo es un draft tipado que termina en el mismo editor y la misma validación por la que pasa una pregunta escrita a mano; solo un humano que aprieta Guardar escribe una fila.

Qüizo corre en inglés, español y árabe, y las dos nociones de "idioma" son sistemas deliberadamente distintos: en qué idioma renderiza la interfaz del anfitrión, y en qué idioma juega el contenido de un quiz, unidos en exactamente un solo lugar en vez de mezclados por todos lados. Una pantalla de presentador puede llevar dos idiomas de contenido a la vez para una multitud bilingüe, mientras cada celular renderiza en el idioma que su propio jugador eligió al unirse —con el flip de derecha a izquierda incluido—, y una clave de traducción desconocida falla como error de tipos en el build en vez de como un texto en blanco frente a una sala en vivo.

Más allá del loop de juego principal, Qüizo creció hasta ser una herramienta completa de operación de eventos:

Qüizo pasó de un repositorio vacío a una plataforma de eventos en producción en unas tres semanas, construida casi enteramente por un solo ingeniero trabajando con agentes de IA para programar —un workflow documentado con el mismo nivel de detalle que el producto en sí, hasta una doctrina de arquitectura de 650 líneas que los propios agentes leen antes de tocar una sola línea de código.