Los cimientos de Rivuko

Este es el primer informe de una serie. Cuenta qué se ha construido y por qué, sin entrar en el código. Solo cubre una parte del trabajo hecho (los cimientos). El resto (el emulador por dentro, los plugins, el motor gráfico y el cliente) tendrá su propio informe.

1. Resumen

Rivuko es una plataforma propia, construida desde cero: el servidor, el motor gráfico, el cliente y el migrador se han diseñado y escrito por nosotros.

El trabajo se organiza en cuatro piezas:

Pieza	Tecnología	Papel
Rivuko Emulator	Rust	El servidor del hotel y su lógica
Rivuko Engine	TypeScript	El motor gráfico del mundo
Rivuko Client	SolidJS	La interfaz, distribuida como librería
Rivuko Migrator	Rust	Traslada un hotel existente a Rivuko

Todas las piezas se desarrollan juntas, con herramientas compartidas.

Dónde estamos: el diseño completo está cerrado y las primeras piezas ya funcionan: el protocolo, la base de datos, la configuración y el núcleo del servidor. Quedan por llegar los dominios de juego, los plugins, el motor, el cliente y el migrador.

2. Principios

Dos reglas guían todo el proyecto:

Sin retrocompatibilidad. Ni Flash, ni el protocolo antiguo, ni el esquema antiguo. La única excepción es el migrador, que lee el hotel antiguo una vez y desaparece.
Conservar funcionalidades, no implementaciones. Todo lo que el hotel antiguo sabía hacer debe poder hacerse en Rivuko, pero no necesariamente como se hacía.

3. Auditoría: saber qué hay antes de tocarlo

Antes de escribir una línea nueva se repasó todo lo que un hotel debe saber hacer, en siete documentos (emulador, base de datos, protocolo, motor, cliente, plugins y funcionalidades).

El resultado más útil es la matriz de funcionalidades: un inventario con más de 1 300 filas que dice, para cada cosa que el hotel sabía hacer, si se conserva, se cambia o se descarta. Es la fuente de verdad del proyecto: si una función está en la matriz, tiene que existir en Rivuko.

4. Arquitectura: cuatro piezas, fronteras claras

La arquitectura se resume en una idea: cada pieza tiene un único trabajo y una frontera bien definida.

El navegador del jugador ejecuta el cliente y el motor gráfico.
El servidor del hotel ejecuta el emulador, sus plugins y la base de datos PostgreSQL 18.
Entre ambos hay una única vía de juego: un WebSocket seguro con un protocolo propio.
El panel de administración del operador (la web de cada hotel) habla con el emulador por una API de administración aparte, en HTTP y JSON.

Una consecuencia importante: la base de datos es exclusiva del emulador. Ni la web ni los plugins la tocan directamente. Esto simplifica la seguridad y permite evolucionar el esquema sin romper a nadie.

Decisiones destacadas

Se han documentado seis decisiones de arquitectura. Tres de ellas, en lenguaje llano:

Un solo contrato para dos lenguajes. El protocolo se escribe una vez y de ahí salen automáticamente los tipos de Rust y de TypeScript. Así servidor y cliente no pueden desincronizarse sin que la compilación lo detecte.

Protobuf como formato de mensajes, elegido con medidas. Se compararon cuatro opciones (Protobuf, MessagePack, FlatBuffers y un formato binario propio) en tamaño, velocidad, validación y facilidad para evolucionar. Ganó Protobuf porque es el único que cumple todos los requisitos eliminatorios: contrato explícito, validación en los dos lados y detección automática de cambios que rompen compatibilidad. A cambio, los mensajes ocupan algo más que con un formato a mano (en torno a un 34 %), un coste que se asume a sabiendas.

Concurrencia por actores. Cada sala del hotel es una unidad independiente que gestiona su propio estado, y cada jugador conectado tiene su propia sesión. Esto evita bloqueos entre salas y hace el comportamiento fácil de razonar.

5. El protocolo: el idioma del hotel

El protocolo de Rivuko es propio y se diseñó desde cero. Sus características públicas:

Esquema explícito y tipado: cada mensaje tiene campos con nombre y tipo reales, no un «orden de llamadas».
Validación estricta: lo que no cumple el contrato se rechaza, en el servidor y en el cliente.
Versionado desde el primer día, con comprobación automática de cambios incompatibles.
Cubre todo el hotel: 39 archivos de contrato organizados por dominio (salas, muebles, catálogo, inventario, amigos, grupos, mensajería, mercadillo, comercio, mascotas, bots, logros, juegos, moderación, cámara, automatismos y más).
API de administración independiente: cuentas, contenido, configuración, moderación, estado y gestión del hotel, para que cada operador construya su propio panel.

Para comprobar que Rust y TypeScript se entienden, se generaron 9 352 vectores de prueba compartidos que ambos lados deben leer exactamente igual, además de pruebas de fuzzing que lanzan datos aleatorios y malformados contra el decodificador.

6. Base de datos: un esquema nuevo

El esquema de PostgreSQL 18 se diseñó desde cero, con 190 tablas, y se acompaña de:

consultas críticas verificadas al compilar: si una consulta no encaja con el esquema, el proyecto no compila;
planes de ejecución revisados sobre volúmenes sintéticos de datos, para detectar consultas lentas antes de que existan usuarios;
un paquete de contenido que separa lo que el operador publica (catálogo, muebles, textos) de los datos de los jugadores;
la correspondencia documentada entre el esquema antiguo y el nuevo, que usará el migrador.

7. Configuración: dos archivos, sin sorpresas

Un hotel se configura con dos archivos y nada más:

config.toml: lo que el operador ajusta (límites, monedas, ritmos, comandos, plugins).
.env: los secretos (contraseñas, claves), nunca mezclados con lo anterior.

Hay un orden de precedencia claro, validación al arrancar con mensajes que indican qué clave está mal, y un comando para comprobar la configuración sin arrancar el servidor.

8. El núcleo del emulador: ya conecta

Lo último en completarse es el núcleo del servidor del juego. Hoy el emulador ya puede:

arrancar y apagarse de forma ordenada, guardando lo pendiente;
aceptar conexiones WebSocket seguras (con TLS opcional) y validar el origen y la IP real tras un proxy;
autenticar con tickets de un solo uso de 60 segundos;
mantener la conexión con latido, límites de ritmo y de tamaño y cierres con códigos claros;
proteger contra abusos: límites de conexiones nuevas, de conexiones sin autenticar y de intentos de saludo fallidos;
impedir sesiones duplicadas: si el mismo usuario entra desde otro sitio, la sesión anterior termina de guardar antes de que empiece la nueva;
ofrecer comandos de línea: serve, migrate, config check y ticket.

Este núcleo pasó además por una revisión adversaria (un revisor sin el contexto de la implementación) y por pruebas de mutantes sobre las partes críticas, para comprobar que las pruebas realmente detectan los fallos.

9. Calidad: cómo se vigila

Formato y análisis estático sin avisos en Rust y TypeScript.
Pruebas automáticas contra una base de datos PostgreSQL 18 real, no contra simulaciones.
Comprobación de licencias de todas las dependencias: solo licencias permisivas en el servidor.
Integración continua que ejecuta todo lo anterior en cada cambio.
Documentación comprobada: más de 3 900 enlaces y 156 diagramas verificados automáticamente.

10. Lo que viene

Este informe cubre una parte de lo hecho. En próximas entregas:

Los dominios del emulador: salas, movimiento, muebles, catálogo, social, economía...
El sistema de plugins: componentes WebAssembly con permisos reales y 91 puntos de extensión.
El motor gráfico y el cliente: el diseño visual completo, con un sistema de ventanas propio.
El migrador: trasladar un hotel existente a Rivuko.

Rivuko es software propietario de Faladium Studios.