Dev Log — Clima, mundo vivo y bastidores de la infra
Dev Log — Clima, mundo vivo y bastidores de la infra
Hace tiempo que no escribo un dev log aquí. Los últimos meses fueron intensos
en dos frentes que van de la mano: el mundo del juego cobró más vida y la
infraestructura detrás de él se convirtió en una máquina decente. Esta
entrada es un recorrido rápido por ambos lados.
El mundo ganó clima — y estaciones de verdad
Lo primero que se nota al abrir el juego ahora es que el cielo ya no es un
escenario estático. Tel-Annat tiene un ciclo diurno y nocturno suave; los
árboles se mecen cuando sopla el viento; y cuando llueve, llueve de verdad.
El giro técnico fue simple en la descripción, pero largo en la ejecución: cada
mapa carga coordenadas geográficas (latitud/longitud) provenientes directamente
del CMS. Con eso el motor calcula en qué hemisferio se encuentra el jugador
y qué estación del año está transcurriendo. El clima de cada bioma es solo
un valor por defecto — es posible forzar una tormenta en un desierto vía
consola si se quiere probar una escena específica.
Los árboles tuvieron un capítulo aparte. Fueron varias iteraciones de shader
hasta que el viento quedó visible sin que las hojas “explotaran” fuera del
cuadro del sprite. Unos 8 commits seguidos solo para ajustar la amplitud,
la frecuencia y el punto donde la base del tronco permanece inmóvil.
Una consola para depurar el mundo
Junto con el sistema de clima llegó una consola interna en el juego. Hoy
la abro y envío cosas como “¿cuál es el clima actual?”, “cambia la estación a
invierno”, “muestra los próximos eventos meteorológicos”. Para mí, como dev
solo, eso ahorra bastante tiempo — probar una nevada específica antes exigía
un ir y venir de save/load; ahora es una línea de comando.
weather: nubes, precipitación, viento, estación y la geolocalización del mapa.También resolví un bug tonto pero molesto: abrir la consola pausaba el juego,
y cerrar la consola lo despausa — incluso si el juego ya estaba pausado antes
por otro motivo. Ahora el estado anterior se preserva.
Entre bastidores: la reestructuración de la infra
Esta parte es menos visual, pero fue uno de los cambios más importantes de los
últimos meses. El servidor que ejecuta el backend del juego (API, CMS, auth)
pasó de una configuración bastante improvisada a una estructura en la que
confío para dejar corriendo sola.
Backup de verdad, todos los días
Antes tenía esa sensación de “ah, si el disco duro falla ahora…”. Hoy existe
un pipeline de backup que se ejecuta automáticamente todos los días a la 01h
de la mañana. Este:
- Congela los uploads por algunos segundos para garantizar la consistencia
- Realiza un snapshot del banco de datos y de los archivos del CMS
- Deduplica y cifra todo (usando una herramienta llamada restic)
- Envía copias a Google Drive y a Amazon S3 al mismo tiempo
- Aplica retención grandfather-father-son (diarios, semanales, mensuales)
Y lo más importante: hay un drill trimestral programado, es decir, cada
tres meses restauro efectivamente el backup en un entorno de prueba para
confirmar que funciona. El backup que nadie prueba no es backup, es fe.
Monitoreo en tres capas
Ahora el servidor avisa cuando algo deja de funcionar — y el aviso llega antes
de que me dé cuenta por el juego bloqueado. El esquema es en tres capas:
- Heartbeat interno — cada job crítico (backup, worker de
brainstorms, etc.) llama a un endpoint diciendo “estoy vivo” en cada
ejecución. Si permanece mudo por mucho tiempo, alerta. - Health checks continuos — el sitio público realiza un poll de salud
de la API cada 30 segundos. Ese indicador discreto de “Servidor: online/offline”
en la esquina de la página proviene de ahí. - Banner público de alerta — si el último backup falló o lleva más de 26h
de retraso, un aviso aparece automáticamente en el panel administrativo, y
además se envía un correo a los administradores de la infraestructura.
Inicio de sesión unificado
Otra cosa que parecía pequeña pero que ayudó bastante: el juego, el sitio y el
backend ahora comparten el mismo sistema de inicio de sesión (ejecutándose
sobre un servidor de identidad dedicado). Si accedes al panel admin del sitio,
el juego ya sabe quién eres. Si la sesión expira, aparece un overlay pidiendo
volver a entrar — sin perder el trabajo que estaba en curso.
Contenido en su lugar correcto
Un principio que se convirtió en regla: todo el contenido del juego nace en
el CMS. Ítem, monstruo, NPC, mapa, bioma, misión, diálogo — todo. El juego
lee esto en runtime y monta los recursos solo. Esto significa que yo (o
cualquier colaborador) puedo editar una habilidad o ajustar una loot table
directamente desde el panel web, sin tocar el código del juego.
Junto con esto llegó un sistema de planes en el propio CMS — donde divido
cada proyecto grande en fases y actividades, marco el progreso y puedo “retomar”
el trabajo desde donde lo dejé (incluso con ayuda de la IA). Es bastante meta:
estoy usando el CMS para gestionar el desarrollo del propio juego que el CMS
alimenta.
Lo que viene
El próximo frente es la wiki pública — un espacio dentro del sitio donde
quienes juegan pueden leer sobre el mundo, la lore, los personajes, sin
necesidad de descubrir todo dentro del juego. El backend ya está en producción;
ahora falta el visual.
En paralelo, sigo puliendo el ciclo día/noche (quiero que la luz de las
hogueras tenga más presencia por la noche), y quiero experimentar con el
clima afectando el gameplay — lluvia apagando antorchas, frío reduciendo la
stamina, ese tipo de cosas.
Si llegaste hasta aquí, gracias. Mensageiros do Vento es un proyecto en
solitario hecho en los rincones de la madrugada, y cada comentario, seguidor o
compartido marca la diferencia.
Hasta el próximo log.
— 𒀀𒀀