Qué es Quark: el núcleo que mueve toda la network

QuarkCraft llegó a un punto en el que actualizar el servidor se había vuelto una tarea imposible. La network dependía de decenas de plugins públicos y de proyectos antiguos sin soporte, cada uno con su propia forma de hacer las cosas y ninguno hablando con el resto. Cambiar de versión, tocar una pieza o probar una idea nueva significaba rezar para que no se cayera media docena de sistemas por el camino. Quark nace para romper ese techo: no es un plugin más que instalas en un servidor, es el sistema nervioso de toda la network y el idioma común que todos hablan.

Su razón de ser es centralizar lo que antes vivía disperso, poder actualizar el servidor con comodidad y —lo más importante a largo plazo— construir implementaciones nuevas rápido y de forma mantenible, sin romper otros sistemas al hacerlo. En vez de encadenar plugins de terceros que nadie mantiene, tenemos un núcleo propio y un solo sitio que sabe qué está pasando en cada momento. A partir de ahí, cada cosa nueva encaja en lugar de pelearse con lo anterior.

Tres piezas y un idioma común

Quark se apoya en tres módulos que separan responsabilidades a propósito. El protocolo define cómo se habla; el cliente sabe cómo conectarse y mantener la conversación viva; el backend es el que decide. Todo lo demás —los servidores de Minecraft, el proxy, un bot de Discord, un panel web— son simples invitados que se conectan usando esas tres piezas.

• protocol — la fuente única de verdad del formato de cable. Define los tipos de mensaje, cómo se serializan y un registro compartido. No depende de Minecraft ni de ningún framework: quien quiera hablar con Quark, sea un servidor Paper o un backend propio de economía, importa esta pieza y ya habla el mismo idioma.
• client — el cliente agnóstico de plataforma. Encapsula todo lo tedioso del transporte: conectar, registrarse, mandar latidos, reconectar solo con reintentos progresivos si se cae la red, entregar los mensajes en orden y correlacionar respuestas. Lo usa igual un servidor de Minecraft que un servicio de estadísticas.
• backend — el cerebro. Es un servicio central que mantiene la topología de la network en memoria: qué servidores existen, en qué grupo están, su estado y su carga. Es quien decide a dónde va cada jugador y cuándo, quién guarda las sesiones, gestiona las colas y agrega las métricas.

Cada servidor se conecta al backend por una conexión persistente y se registra diciendo qué tipo de cliente es. A partir de ahí manda un latido cada pocos segundos: mientras late, está vivo; cuando deja de latir, el backend lo da por caído y actúa. Los mensajes viajan como tramas compactas con una cabecera mínima y el contenido en JSON, y el detalle importante es que casi nunca hace falta inventar un mensaje nuevo: hay un sobre genérico que cualquier función usa para hablar por 'canales', sin tocar el protocolo. Eso es lo que hace que añadir una economía, unas estadísticas o un sistema de clanes no obligue a rehacer los cimientos.

El protocolo se piensa una vez. Todo lo que construyes encima lo hereda gratis: si el idioma es bueno, las features dejan de pelear con la fontanería.

Grupos: la network vista como topología

El concepto central de Quark es el grupo de servidores. Un grupo es una unidad lógica que junta uno o varios servidores físicos y define cómo se entra, cómo se reparte la carga y qué pasa cuando algo se cae. En vez de pensar en 'el servidor survival-mundo', piensas en 'el grupo survival', y el backend se encarga de traducir eso al servidor concreto en cada momento.

Hay tres formas de comportarse, y en el fondo comparten casi todo el mecanismo; lo único que cambia es cómo se elige el servidor y si se recuerda dónde estabas:

• Modalidad — varios servidores que forman una misma experiencia (spawn, mundo, warps, dungeons). Entras 'al grupo', no a un servidor: si ya jugaste antes, vuelves a tu último servidor; si no, al de entrada del grupo.
• Pool de lobbies — varios servidores intercambiables entre los que el backend reparte por carga, mandándote al que está más libre. Es el candidato natural a red de seguridad de toda la network.
• Servidor único — una modalidad que vive en un solo servidor. Es solo un grupo de tamaño uno, sin lógica especial: mismo trato de estados, colas y aforo que el resto.

Que el cerebro esté centralizado arregla dos cosas que antes daban muchos problemas. La primera es la transferencia: cuando un jugador cambia de servidor, el backend reserva su hueco en el destino antes de moverlo —un ticket de llegada que evita que dos jugadores se peleen por la última plaza— y la orden la ejecuta el proxy, que confirma si salió bien. Nada de mover a ciegas y cruzar los dedos. La segunda es la caída: si un servidor se cae, el backend ya sabe quién estaba dentro y los evacúa a un destino válido de forma escalonada, para no tumbar al servidor que los recibe con una estampida. El jugador, en el peor caso, nota un parpadeo en vez de un cierre de sesión.

Encima de eso hay estados que se cambian en caliente y se propagan a toda la network al instante: abierto, con whitelist, en mantenimiento, drenando (no entra nadie nuevo pero los de dentro siguen) o cerrado. Sirven para actualizar un grupo sin echar a nadie a lo bruto y para abrir betas a una lista concreta de jugadores. La topología entera vive en un solo sitio, así que reasignar un servidor a otro grupo o poner algo en mantenimiento no obliga a tocar cada máquina: se cambia en el backend y todos se enteran.

Colas: una sola línea para todas las modalidades

Antes teníamos el mismo mecanismo de cola duplicado en dos sitios que no se hablaban, con la típica consecuencia: bugs distintos en cada uno, jugadores 'fantasma' que se quedaban en la cola tras desconectarse porque un lado limpiaba y el otro no. Quark lo unifica en un motor de colas único, y el reparto de responsabilidades es la parte elegante del diseño.

Quark gestiona la línea; la modalidad gestiona el resto. Es decir: Quark mantiene el orden, calcula tu posición, te promociona cuando toca, te saca si te desconectas y pinta el HUD de 'estás en la posición N' de forma uniforme para cualquier cola de la network. Lo que Quark no conoce —cuánta capacidad tiene el destino y qué acción concreta ejecutar cuando te toca— lo aporta la modalidad: ella avisa 'hay hueco, saca a uno', y Quark decide a quién sacar según prioridad y orden de llegada. Ni la capacidad ni la acción salen nunca de la modalidad; ni el orden ni la limpieza salen nunca de Quark.

El motor está pensado desde el día uno para tres formas de emparejar, aunque hoy la de capacidad cubra el cien por cien de lo que existe: por hueco liberado (colas de entrada), por juntar N jugadores (matchmaking de un futuro minijuego) o por lotes cada cierto tiempo. Y hay una regla que evita líos: un jugador solo puede estar en una cola a la vez en toda la network; entrar en una nueva te saca de la anterior de forma limpia. Añadir un tipo de cola nuevo el día de mañana es sumar, no reescribir lo que ya está en producción.

Quark gestiona la cola, la modalidad gestiona el resto. Esa frase es medio diseño y medio filosofía: lo genérico se escribe una vez, lo específico se queda con quien lo entiende.

Métricas: medir la network sin espiar a nadie

La otra pata es saber qué está pasando de verdad. Quark lleva un framework de estadísticas de sistema —no de jugadores individuales, sino de la network: cuántas partidas se juegan, cuánto dura una sesión media, cuántos jugadores distintos vuelven al día siguiente, el ratio de victoria de una dungeon, cuánta gente hay online en cada modalidad. Señales agregadas para tomar decisiones, no fichas de nadie.

Cada medida se declara con un tipo —contador, medidor, histograma o 'cuántos distintos'— y unas etiquetas de baja cardinalidad (la modalidad, el mapa, la variante de un experimento). El backend estampa solo de qué servidor y de qué grupo viene cada dato, así que una estadística puede leerse fusionada por grupo o desglosada por servidor sin que quien la emite tenga que saber nada de la topología. Y como todo se agrega antes de guardarse, juntar dos servidores del mismo grupo es sumar sus números; los jugadores únicos se cuentan con una estructura probabilística que se fusiona sin doble conteo y ocupa una miseria de memoria.

El diseño está muy marcado por una restricción real de nuestra base de datos: no permite consultas arbitrarias, solo leer por identificador. En vez de pelearnos con eso, lo abrazamos: cada resumen se guarda con un identificador determinista calculado a partir de la métrica, las etiquetas, el ámbito y la ventana de tiempo. Pedir 'los últimos 30 días' es calcular 30 identificadores y leerlos directos, sin escanear nada. Cada servicio solo puede escribir en su propio espacio de nombres, pero todos pueden leer todo: una web o un bot de Discord se conectan como un invitado más, preguntan y pintan.

Conectividad: al final, todo es un invitado

Si tuviera que resumir Quark en una imagen sería esta: un cerebro central y, alrededor, una constelación de invitados conectados a él hablando el mismo idioma. Un servidor de Minecraft es un invitado. El proxy que mueve a los jugadores es un invitado. Un backend de economía es un invitado. Un panel web que enseña estadísticas es un invitado. Todos usan las mismas tres piezas para conectarse, y el backend hace de central de reparto entre ellos.

Esa mensajería por canales es lo que permite que dos funciones se hablen sin inventar nada nuevo en el protocolo. Un servidor pregunta '¿cuánto dinero tiene este jugador?' por el canal de economía y recibe la respuesta correlada, sin saber ni dónde vive ese servicio. El día que quieras añadir clanes, un mercado o un sistema de rangos, no tocas los cimientos: te conectas como un invitado más, declaras tu canal y ya estás dentro de la conversación.

Por qué esto importa tanto

Durante años QuarkCraft dependió de plugins públicos y proyectos viejos sin mantenimiento, hasta que actualizar el servidor dejó de ser difícil para volverse directamente inviable. Quark es exactamente lo contrario de eso: en vez de encadenar piezas de terceros que nadie sostiene, centraliza lo importante en un núcleo propio que podemos actualizar cuando queramos y ampliar sin miedo. Añadir una modalidad, una economía o un sistema de clanes deja de ser una operación a corazón abierto para convertirse en enchufar un invitado más a la conversación.

Lo valioso no es ninguna función suelta, es la forma. Separar el idioma (protocolo), la conversación (cliente) y las decisiones (backend) hace que cada cosa nueva encaje sin pelearse con las anteriores, y que tocar una no arrastre a las demás. Es la misma idea que aplicamos a todo en ENTROPY: coger algo disperso y darle una forma que aguante. Quark es esa idea llevada al núcleo de la network, para que esta vez la base la controlemos nosotros y no la sigamos pagando en cada actualización imposible.