Cómo configurar parche automático mediante launcher en MU Online

Distribuir un parche de MU Online parece trivial hasta el día en que modificas tres archivos y necesitas garantizar que cientos de jugadores, en máquinas y conexiones distintas, tengan exactamente los mismos bytes que tú. Ahí es donde un flujo de parche automático deja de ser un lujo y pasa a ser infraestructura. En esta guía vas a montar el proceso completo del lado del servidor — detección de cambios, empaquetado, versionado, publicación y rollback — que alimenta al launcher que corre en la máquina del jugador.

Este es un tutorial de cliente: trata sobre los archivos que el jugador descarga y ejecuta, y sobre cómo el launcher los mantiene sincronizados. No cubrimos la configuración del game server en sí — si todavía estás montando el servidor, empieza por la guía de cómo crear servidor de MU Online. Aquí el foco es la línea de producción de parches.

Qué es "parche automático" de verdad

Mucha gente llama parche automático al simple hecho de que el launcher descargue archivos. Eso es solo la mitad. El parche automático completo tiene dos lados:

• Lado servidor (build/deploy): un proceso que compara la carpeta del cliente actual con la última versión publicada, identifica qué cambió, genera un manifiesto con hashes y sube los archivos modificados al servidor de distribución.
• Lado cliente (launcher): la herramienta que lee el manifiesto, lo compara con lo que está instalado y descarga solo las diferencias.

El nexo entre ambos es el manifiesto, un archivo JSON con la lista de archivos y sus hashes. Cuando automatizas la generación de ese manifiesto, eliminas la mayor fuente de bugs en servidores de MU: el parche publicado "a medias", con el manifiesto apuntando a un archivo que no se subió o con un hash desactualizado.

MODIFICAS ARCHIVOS
      │
      ▼
[ SCRIPT DE PARCHE ]  ── recorre, calcula hash, compara con versión anterior
      │                  genera manifiesto + separa archivos modificados
      ▼
[ SERVIDOR DE DISTRIBUCIÓN ]  (Apache/Nginx con HTTPS)
      │  version.json + /patches/<versión>/...
      ▼
[ LAUNCHER DEL JUGADOR ]  ── descarga solo el diff, valida hash, aplica
      │
      ▼
Main.exe actualizado

Requisitos previos

Un requisito conceptual: define qué es distribuible. No todo en la carpeta del cliente debe ir al parche. Logs, configuraciones locales del jugador (resolución elegida, volumen) y archivos temporales deben quedar afuera. Crea una lista de exclusión desde el inicio.

Paso 1 — Estructurar el versionado en el servidor

Antes de automatizar, define la estructura de carpetas en el servidor de distribución. Recomiendo versionar por carpeta, manteniendo el historial:

/var/www/cdn/
├── version.json                 ← manifiesto ACTUAL (el que lee el launcher)
├── manifests/
│   ├── 3.1.0.json               ← historial de manifiestos (para rollback)
│   ├── 3.2.0.json
│   └── 3.3.0.json
└── patches/
    ├── Data/
    │   ├── Item.bmd
    │   └── Local/Text.bmd
    ├── Interface/
    │   └── loading01.jpg
    └── Main.exe

Aquí usamos un esquema en el que patches/ siempre contiene la versión más reciente de cada archivo (espejo del cliente distribuible), y manifests/ guarda el historial. El version.json en la raíz es simplemente una copia del manifiesto de la versión vigente. Esto simplifica el launcher: descarga cualquier archivo en patch_base_url + path y siempre obtiene la versión actual.

> La estructura Data/, Interface/, Main.exe es un ejemplo típico de Season 6. La organización real de las carpetas y qué archivos BMD existen varían según season/cliente. Ajusta la lista de exclusión y las rutas a tu distribución.

Paso 2 — El script de parche automático

El corazón del sistema es un script que hace todo: recorre, calcula hashes, compara con la versión anterior, arma el manifiesto y reporta qué cambió. Este script PowerShell es el modelo:

# publicar-patch.ps1
param(
    [Parameter(Mandatory)] [string] $NovaVersao   # ej: "3.3.0"
)

$clienteDir  = "C:\Build\ClienteMU"      # cliente distribuible (fuente)
$saidaDir    = "C:\Build\Publicar"       # lo que se enviará al servidor
$baseUrl     = "https://cdn.meuservidor.com/patches/"
$exclusoes   = @("*.log", "config.local.ini", "Screenshots\*", "*.tmp")

# --- 1. Recorrer archivos, aplicando exclusiones ---
$arquivos = Get-ChildItem $clienteDir -Recurse -File | Where-Object {
    $rel = $_.FullName.Substring($clienteDir.Length + 1)
    -not ($exclusoes | Where-Object { $rel -like $_ })
}

# --- 2. Calcular hash de cada archivo ---
$lista = foreach ($f in $arquivos) {
    $rel  = $f.FullName.Substring($clienteDir.Length + 1).Replace('\','/')
    $hash = (Get-FileHash $f.FullName -Algorithm SHA256).Hash.ToLower()
    [ordered]@{ path = $rel; hash = $hash; size = $f.Length }
}

# --- 3. Comparar con el manifiesto anterior (diff) ---
$anterior = @{}
if (Test-Path ".\version.json") {
    (Get-Content ".\version.json" -Raw | ConvertFrom-Json).files |
        ForEach-Object { $anterior[$_.path] = $_.hash }
}

$alterados = $lista | Where-Object { $anterior[$_.path] -ne $_.hash }
Write-Host "Archivos modificados/nuevos: $($alterados.Count)"

# --- 4. Copiar solo los modificados a la carpeta de publicación ---
if (Test-Path $saidaDir) { Remove-Item $saidaDir -Recurse -Force }
foreach ($a in $alterados) {
    $origem  = Join-Path $clienteDir ($a.path -replace '/','\')
    $destino = Join-Path $saidaDir  ($a.path -replace '/','\')
    New-Item -ItemType Directory -Force -Path (Split-Path $destino) | Out-Null
    Copy-Item $origem $destino
}

# --- 5. Generar manifiesto nuevo ---
$manifesto = [ordered]@{
    version        = $NovaVersao
    patch_base_url = $baseUrl
    main_exe       = "Main.exe"
    files          = $lista
}
$json = $manifesto | ConvertTo-Json -Depth 4
$json | Out-File ".\version.json"           -Encoding utf8
$json | Out-File ".\manifests\$NovaVersao.json" -Encoding utf8

Write-Host "Parche $NovaVersao listo. Envía:"
Write-Host " - contenido de $saidaDir  ->  /var/www/cdn/patches/"
Write-Host " - version.json           ->  /var/www/cdn/version.json"

Lo que este script garantiza:

1. Detección automática de lo que cambió, comparando hashes con el manifiesto anterior — nada de recordar manualmente qué archivos editaste.
2. Empaquetado incremental: solo los archivos modificados van a la carpeta de publicación, reduciendo el upload.
3. Manifiesto siempre íntegro: los hashes provienen del mismo recorrido que generó la lista, así que nunca quedan desincronizados.
4. Historial versionado en manifests/, requisito previo para el rollback.

Paso 3 — Orden de publicación (la regla de oro)

La causa número uno de un cliente roto durante un parche es el orden de upload equivocado. El launcher puede buscar el version.json en el instante exacto en que estás subiendo los archivos. Si obtiene el manifiesto nuevo antes de que los archivos existan, recibe un 404 y falla.

El orden correcto es siempre:

1. Sube primero todos los archivos de parche a /patches/.
2. Confirma que están accesibles (curl -I en algunos de ellos).
3. Solo entonces sube el version.json actualizado.

# en tu terminal, después de ejecutar el script:
# 1) archivos primero
rsync -avz C:/Build/Publicar/ usuario@servidor:/var/www/cdn/patches/

# 2) verificar
curl -I https://cdn.meuservidor.com/patches/Main.exe   # espera 200

# 3) manifiesto al final
scp version.json usuario@servidor:/var/www/cdn/version.json

Así, durante todo el proceso los jugadores ven el manifiesto antiguo (consistente) hasta el momento en que el nuevo entra en vigor ya con todo disponible.

Paso 4 — Configurar el servidor de distribución

El servidor web necesita servir los archivos como contenido estático, con dos cuidados: sin caché en el manifiesto y con caché en los parches (que son inmutables por hash). Ejemplo de configuración Nginx:

server {
    listen 443 ssl;
    server_name cdn.meuservidor.com;

    root /var/www/cdn;

    # el manifiesto nunca debe cachearse
    location = /version.json {
        add_header Cache-Control "no-cache, no-store, must-revalidate";
        add_header Pragma "no-cache";
    }

    # los parches pueden cachearse por mucho tiempo
    location /patches/ {
        add_header Cache-Control "public, max-age=604800";
    }
}

Si usas una CDN al frente, respeta la misma lógica: el version.json debe tener un TTL bajísimo, y los archivos de patches/ pueden tener un TTL largo, ya que cualquier cambio de contenido cambia el hash y, por lo tanto, el comportamiento del launcher.

Paso 5 — Rollback cuando un parche rompe algo

Tarde o temprano un parche va a salir mal: una textura corrupta, un Main.exe de la season equivocada, un archivo Data con formato inválido. Como el sistema se basa en hash y guardaste el historial, el rollback es rápido.

Estrategia de rollback en tres pasos:

1. Identifica la última versión estable (ej.: 3.2.0).
2. Asegúrate de que los archivos de esa versión aún existen en patches/ — si el parche malo sobrescribió alguno, restáuralo desde tu build versionado.
3. Vuelve a publicar el manifiesto estable como version.json:

# revertir a 3.2.0
cp /var/www/cdn/manifests/3.2.0.json /var/www/cdn/version.json

En la próxima apertura, el launcher compara los hashes actuales de los jugadores con el manifiesto 3.2.0, detecta la divergencia en los archivos afectados y descarga de vuelta las versiones estables. El jugador ni siquiera necesita saber que hubo un problema.

> Guarda siempre al menos las dos o tres últimas versiones completas del cliente distribuible. El rollback solo funciona si los bytes antiguos aún existen en algún lugar.

Paso 6 — Comunicar el parche al jugador

Un buen flujo de parche también informa. Publica un news.json que el launcher muestra, con el changelog:

{
  "version": "3.3.0",
  "date": "2026-07-10",
  "highlights": [
    "Nuevo evento de temporada habilitado",
    "Corrección de textura en el mapa Kanturu",
    "Ajuste de balance de drops"
  ]
}

Mostrar el changelog reduce el soporte ("¿qué cambió?") y transmite la sensación de un servidor activo y bien cuidado — lo que retiene jugadores.

Errores comunes y soluciones

Buenas prácticas del flujo de parche

• Automatiza todo en un solo comando: publicar-patch.ps1 3.3.0 debe hacer el build completo. Los pasos manuales son donde nacen los errores.
• Prueba en una carpeta espejo antes de publicar en producción. Apunta un launcher de prueba a un manifiesto de staging.
• HTTPS en todo el camino, desde el manifiesto hasta los parches. Un parche sin TLS es un vector de inyección de malware en el cliente.
• Versiona el cliente distribuible (Git LFS o carpeta fechada) para viabilizar un rollback confiable.
• Nunca incluyas archivos locales del jugador en el parche (config de video, sonido, capturas). Usa la lista de exclusión.
• Registra cada publicación: versión, fecha, archivos modificados. Ese log salva investigaciones cuando algo se rompe.

Lista de verificación de lanzamiento

• Estructura de carpetas del servidor definida (version.json, manifests/, patches/)
• Script publicar-patch.ps1 probado y generando el diff correcto
• Lista de exclusión cubriendo logs y configs locales del jugador
• Orden de upload respetado (archivos antes que el manifiesto)
• Cache-Control: no-cache en el version.json; caché largo en patches/
• HTTPS activo en el subdominio de distribución
• Historial de manifiestos guardado para rollback
• Build versionado de las últimas versiones del cliente
• Procedimiento de rollback probado en ambiente de staging
• news.json/changelog publicado junto al parche
• Launcher de prueba validando el parche antes de liberarlo a todos
• Log de publicación actualizado tras cada parche

Preguntas frecuentes