Cómo crear una página de changelog automatizada para el sitio de tu MU Online

Comunicar actualizaciones de forma consistente es uno de los hábitos que más fortalece la confianza de la comunidad en un servidor privado de MU Online —pero mantener una página de changelog manualmente, copiando y formateando texto cada vez que algo cambia, es un trabajo repetitivo que la mayoría de los administradores termina abandonando después de algunas semanas. Una página de changelog automatizada resuelve esto: escribes el cambio una sola vez en un archivo estructurado, y el sitio, Discord y cualquier otro canal se actualizan a partir de esa misma fuente. Este tutorial muestra cómo estructurar ese archivo, categorizar los cambios de forma útil y conectar todo a una automatización simple de publicación.

Por qué un changelog estructurado (y no solo publicaciones sueltas)

Un changelog estructurado trata cada actualización como un registro de datos (fecha, versión, categoría, lista de cambios) en vez de un texto libre suelto en una publicación de blog o mensaje de Discord. Esta estructura permite generar la página del sitio automáticamente, filtrar por categoría, buscar por palabra clave e incluso alimentar otros canales (Discord, redes sociales) a partir de la misma fuente única de verdad, eliminando el retrabajo de escribir la misma información en formatos diferentes para cada canal.

Eligiendo el formato del archivo fuente

Para sitios que ya usan Markdown para otras páginas de contenido (como tutoriales), mantener el changelog también en Markdown con front matter reaprovecha el mismo pipeline de build, reduciendo la complejidad de mantener dos sistemas de parsing diferentes.

Estructura recomendada de cada entrada

Cada entrada de changelog debe contener, como mínimo: fecha o versión, título corto, categoría (o categorías) y una lista de ítems de cambio. Un ejemplo en formato front matter:

---
version: "1.4.2"
date: "2026-07-15"
categories: ["balanceamento", "correcoes"]
title: "Ajustes de balanceo tras el evento de guild war"
---
- Reducido el daño de Twisting Slash en un 8% contra jugadores (solo PvP).
- Corregido un error que impedía que las recompensas de guild war se entregaran a miembros offline en el momento de la victoria.
- Aumentado el drop de Jewel of Bless en Kanturu Relics en un 5%.

Este formato es lo suficientemente simple para que cualquier persona del equipo lo escriba sin necesidad de entender el código del sitio, pero lo suficientemente estructurado para que el build lo procese automáticamente.

Categorización útil para el jugador

Separa los cambios en categorías que reflejen los distintos intereses de la comunidad: Novedades (ítems, sistemas, eventos nuevos), Balanceo (ajustes de daño, drop, tasas), Corrección de errores y Eventos/Temporada. Un jugador enfocado en PvP quiere escanear rápidamente la categoría Balanceo sin tener que leer sobre correcciones de errores irrelevantes para él, y esa separación clara aumenta la probabilidad de que la información relevante realmente se lea.

Generando la página automáticamente a partir del archivo fuente

En el proceso de build del sitio (ya sea un generador estático como Next.js/Astro/Hugo, o un script personalizado), configura la lectura de todos los archivos de la carpeta de changelog, ordénalos por fecha/versión descendente, y renderiza la página agrupando por categoría o por entrada cronológica, según la preferencia de la comunidad. El punto central es que la página nunca debe editarse directamente en HTML —todo cambio de contenido pasa por el archivo fuente, garantizando consistencia e historial versionado (especialmente si el sitio usa control de versiones como Git).

Versionado: números de versión vs. fechas

Si el servidor hace actualizaciones grandes y bien definidas (nuevo sistema, rebalanceo amplio), numerar las versiones (v1.4.0, v1.4.1) ayuda a la comunidad a referirse a "esa actualización" de forma precisa en tickets de soporte y discusiones. Si las actualizaciones son más frecuentes e incrementales (pequeños ajustes semanales), usar solo la fecha como identificador principal suele ser más intuitivo, evitando la burocracia de decidir si un ajuste pequeño "merece" un nuevo número de versión.

Integración automática con Discord

Configura un webhook de Discord en el canal de anuncios del servidor, disparado automáticamente cada vez que se publica una nueva entrada de changelog (vía GitHub Actions, un cron job que verifica nuevos archivos, o un hook en el propio deploy del sitio). El mensaje debe incluir el título, la categoría principal, un resumen de 2-3 ítems y un enlace directo a la entrada completa en la página del sitio, evitando reescribir manualmente el mismo contenido en dos lugares.

# Ejemplo simplificado de script de notificación vía webhook
curl -X POST "$DISCORD_WEBHOOK_URL" \
  -H "Content-Type: application/json" \
  -d '{"content": "**Nueva actualización: v1.4.2**\nBalanceo tras guild war. Ve todo en: https://tusitio.com/changelog/1-4-2"}'

RSS o feed para jugadores que siguen de cerca

Para servidores con una comunidad más técnica o alianzas con sitios de noticias de MU, generar un feed RSS a partir del mismo archivo fuente de changelog permite que jugadores y sitios de terceros sigan las actualizaciones sin depender de visitar el sitio manualmente o estar en Discord en el momento exacto del anuncio.

Buenas prácticas de escritura para el changelog

Escribe cada ítem de cambio desde el punto de vista del impacto en el jugador, no desde el punto de vista técnico interno ("Reducido el daño de X en Y%" es mejor que "Ajustado el multiplicador de la skill en el archivo de configuración"). Evita la jerga de desarrollo que el jugador común no entiende, y siempre que un cambio afecte la economía o el PvP de forma sensible, considera agregar una línea de contexto explicando el motivo del ajuste —eso reduce las quejas de la comunidad por sentir el cambio como arbitrario.

Errores comunes y soluciones

Lista de verificación de implementación del changelog automatizado

• Formato del archivo fuente definido (JSON, YAML o Markdown con front matter).
• Estructura de campos estandarizada (fecha/versión, categoría, ítems).
• Categorías definidas de forma útil para los distintos perfiles de jugador.
• Build del sitio generando la página automáticamente a partir del archivo fuente.
• Webhook de Discord configurado para notificar nuevas entradas.
• Convención de versionado (números o fechas) definida y documentada para el equipo.
• Linter/validación del archivo fuente configurado antes del deploy.

Con el changelog automatizado en marcha, la comunicación de actualizaciones deja de ser trabajo manual repetitivo y pasa a formar parte natural del proceso de deploy —para profundizar en la estructura general del sitio y del servidor detrás de él, consulta el tutorial de creación de servidor de MU Online.

Preguntas frecuentes