Hades: cuando morir es avanzar

Hay un momento muy concreto en cualquier roguelike en el que el jugador decide si va a seguir jugando o no. No es la primera partida, ni la primera victoria. Es la quinta o sexta muerte, cuando ya ha visto los primeros niveles varias veces, el jefe del segundo piso le ha vuelto a ganar y la pantalla de game over le dice, otra vez, que todo lo que hizo en los últimos cuarenta minutos se ha perdido.

Hades (Supergiant Games, 2020) está diseñado alrededor de ese momento. Cuando Zagreus muere, sale de un charco de sangre en la casa de su padre, y lo primero que pasa es que alguien le habla. Hypnos comenta cómo ha muerto. Su padre le suelta algún reproche. Un personaje que hace tres partidas que no veía tiene algo nuevo que contarle. La muerte no es un corte en la partida, es la escena que conecta una partida con la siguiente.

En el artículo sobre RNG en roguelikes hablé de cómo el azar mantiene cada partida fresca. Este va del otro lado del problema: qué hace que volver a empezar no se sienta como un castigo.

1. El problema de la muerte en un roguelike

En un roguelike clásico, la muerte es un reseteo completo. Todo el progreso de la partida desaparece, y lo único que el jugador se lleva es su propia habilidad. Es un diseño honesto y funciona muy bien con un tipo concreto de jugador, el que disfruta de dominar un sistema desde cero cada vez. Pero tiene un coste: la curva de abandono es brutal en las primeras horas, cuando el jugador todavía no tiene la habilidad suficiente para notar que está mejorando.

Los roguelites intentaron resolverlo con meta-progresión: monedas que sobreviven a la muerte y desbloquean mejoras permanentes. Eso suaviza la curva, pero introduce otro problema. Si las mejoras permanentes son demasiado fuertes, el juego se resuelve por acumulación (juegas mal cuarenta veces y al final ganas porque tus números son más grandes). Si son demasiado débiles, el jugador no las percibe y la muerte sigue sintiéndose como una pérdida.

Hades no elimina ese dilema, pero lo esquiva añadiendo una segunda capa de progreso que no tiene nada que ver con los números: la historia. Y esa historia solo avanza de una forma, muriendo.

2. Cuatro economías que sobreviven a la muerte

Al volver a la casa, Zagreus conserva varios recursos que ha ido recogiendo durante la partida. Cada uno alimenta un sistema distinto, y lo interesante es que no todos hacen al personaje más fuerte:

• Oscuridad, que se gasta en el Espejo de la Noche. Son las mejoras permanentes clásicas: más vida, más daño, resurrecciones extra (Desafío a la Muerte). Es la meta-progresión de poder.
• Llaves ctónicas, que desbloquean armas nuevas y nuevas filas del espejo. Amplían las opciones del jugador más que su potencia.
• Gemas, que se gastan con el contratista de la casa en decoración y en algunas mejoras de la propia mazmorra. Buena parte de ese gasto es puramente cosmético.
• Néctar (y más adelante, Ambrosía), que se regala a otros personajes. A cambio, se reciben recuerdos (objetos equipables con efectos pasivos) y, sobre todo, avanza la relación con ese personaje, lo que desbloquea más diálogos y escenas.

La consecuencia es que, incluso en una partida desastrosa, el jugador casi siempre vuelve con algo que gastar. Y como cada recurso tiene su propio destino, la decisión de en qué gastarlo es en sí misma un pequeño juego que ocurre entre partidas. La casa funciona como una pausa activa: el jugador no está esperando a volver a intentarlo, está haciendo cosas.

3. Una historia escrita para morir

La mayoría de juegos con narrativa tratan la muerte del jugador como algo que la historia no reconoce. Cargas la partida, y el mundo hace como si no hubiera pasado nada. Hades hace lo contrario: la muerte es canónica. Zagreus es inmortal, el inframundo devuelve a los muertos a la casa de Hades, y todos los personajes saben que intentó escapar y no lo consiguió.

Eso permite que el guion trate cada muerte como contexto. Hypnos, en la entrada, comenta la causa concreta de la muerte (ese jefe, esa trampa, ese enemigo). Si el jugador muere varias veces contra el mismo jefe, otros personajes acaban mencionándolo. Si derrota por primera vez a un jefe, hay una reacción para eso. Y si lleva muchas partidas sin morir contra alguien concreto, también.

Según Supergiant, el juego tiene más de veinte mil líneas de diálogo grabadas. La mayoría de jugadores no las verán todas, y precisamente por eso funciona. La sensación que se busca no es "he visto toda la historia", sino "el juego siempre tiene algo nuevo que decirme". Durante decenas de horas, cada vuelta a la casa trae al menos una línea que no se había escuchado antes.

La estructura principal también está construida sobre la repetición. Escapar una vez no termina el juego, solo abre el siguiente capítulo de la historia, y llegar al final requiere escapar varias veces. El objetivo narrativo (salir del inframundo) y el objetivo mecánico (completar una partida) coinciden, pero el narrativo exige repetirlo. Lo que en otro juego sería grind, en Hades es el argumento.

4. Subir la dificultad por elección propia

Si la historia exige escapar muchas veces y el jugador se vuelve más fuerte con cada intento, en algún momento el juego se queda corto. Hades resuelve ese problema con el Pacto de Castigo: después de la primera huida, el jugador puede activar condiciones que hacen la partida más difícil (más enemigos, más daño recibido, límite de tiempo, jefes con nuevas fases...). Cada condición suma puntos de Calor.

El Calor no se impone, se elige. Y para que el jugador quiera elegirlo, el juego lo paga: completar una huida con un arma en un nivel de Calor que no había superado antes con ella da recompensas raras (Sangre de Titán, diamantes, ambrosía) que no se consiguen de otra forma. El jugador acaba subiendo la dificultad para seguir progresando, no porque el juego le obligue.

En el otro extremo está el Modo Dios, un modo de asistencia que se puede activar en cualquier momento. Empieza con un 20% de resistencia al daño, y esa resistencia aumenta un 2% con cada muerte, hasta un máximo del 80%:

donde $n$ es el número de muertes desde que se activó. Es un diseño muy elegante: el modo de ayuda no es un interruptor fijo, sino un sistema que escala con la frustración del jugador. Cuantas más veces muere, más le ayuda, pero sin quitarle nunca la necesidad de jugar.

5. Implementar un pool de eventos narrativos

La parte técnica más interesante de Hades es cómo decide qué dice cada personaje en cada momento. No conozco el código de Supergiant, pero el comportamiento observable se puede modelar con un sistema bastante sencillo: un pool de eventos de diálogo, cada uno con requisitos, una prioridad y un registro de si ya se ha reproducido.

Cada evento declara qué condiciones necesita para poder aparecer (haber derrotado a un jefe, haber muerto por una causa concreta, tener cierto nivel de relación con un personaje, haber visto otro evento antes...). Cuando el jugador interactúa con un personaje, el sistema filtra los eventos que cumplen sus requisitos, descarta los ya vistos y elige el de mayor prioridad.

1public class NarrativeContext
2{
3    public int RunCount;
4    public string LastDeathCause;
5    public HashSet<string> Flags = new HashSet<string>();
6    public HashSet<string> PlayedEvents = new HashSet<string>();
7    public Dictionary<string, int> Affinity = new Dictionary<string, int>();
8}
9
10[CreateAssetMenu(menuName = "Narrative/Dialogue Event")]
11public class DialogueEvent : ScriptableObject
12{
13    public string Id;
14    public string Speaker;
15    public int Priority;
16    public bool Repeatable;
17    public List<NarrativeRequirement> Requirements;
18    [TextArea] public List<string> Lines;
19
20    public bool IsEligible(NarrativeContext ctx)
21    {
22        if (!Repeatable && ctx.PlayedEvents.Contains(Id)) return false;
23        return Requirements.TrueForAll(r => r.IsMet(ctx));
24    }
25}

Los requisitos son pequeñas piezas componibles. Cada uno comprueba una sola cosa, y un evento combina los que necesite. Así, el guionista puede escribir "Hypnos, si la última muerte fue contra la Hidra y es la tercera vez" sin que nadie tenga que tocar código:

1[Serializable]
2public abstract class NarrativeRequirement
3{
4    public abstract bool IsMet(NarrativeContext ctx);
5}
6
7[Serializable]
8public class DiedTo : NarrativeRequirement
9{
10    public string Cause;
11    public override bool IsMet(NarrativeContext ctx) => ctx.LastDeathCause == Cause;
12}
13
14[Serializable]
15public class HasFlag : NarrativeRequirement
16{
17    public string Flag;
18    public override bool IsMet(NarrativeContext ctx) => ctx.Flags.Contains(Flag);
19}
20
21[Serializable]
22public class MinAffinity : NarrativeRequirement
23{
24    public string Character;
25    public int Amount;
26    public override bool IsMet(NarrativeContext ctx) =>
27        ctx.Affinity.TryGetValue(Character, out var value) && value >= Amount;
28}

6. Elegir qué se dice: prioridad y relleno

Con el pool montado, la selección es casi trivial. Lo importante está en cómo se reparten las prioridades. En la práctica funcionan bien tres bandas:

• Eventos de historia (prioridad alta). Avanzan la trama principal o una relación. Si hay uno disponible, siempre gana.
• Eventos reactivos (prioridad media). Comentan algo que acaba de pasar: la causa de la muerte, un jefe derrotado por primera vez, un arma nueva. Son los que hacen que el mundo parezca atento.
• Relleno (prioridad baja, repetible). Líneas genéricas para cuando no queda nada específico que decir. Su función es evitar el silencio, no contar nada.

1public DialogueEvent PickEvent(string speaker, NarrativeContext ctx, IEnumerable<DialogueEvent> pool)
2{
3    var candidates = pool
4        .Where(e => e.Speaker == speaker && e.IsEligible(ctx))
5        .ToList();
6
7    if (candidates.Count == 0) return null;
8
9    int top = candidates.Max(e => e.Priority);
10
11    // Entre los de mayor prioridad, uno al azar para que el relleno no se repita en orden.
12    var best = candidates.Where(e => e.Priority == top).ToList();
13    return best[UnityEngine.Random.Range(0, best.Count)];
14}
15
16public void MarkPlayed(DialogueEvent evt, NarrativeContext ctx)
17{
18    // Llamar al terminar la conversación, no al elegirla.
19    ctx.PlayedEvents.Add(evt.Id);
20}

La clave de que el sistema parezca vivo no está en el algoritmo, sino en la cantidad y la granularidad de los eventos reactivos. Un evento que reacciona a "has muerto" no se siente personal. Uno que reacciona a "has muerto contra este jefe, por tercera vez, con esta arma" sí. El coste es de escritura, no de código: cada requisito nuevo multiplica las combinaciones posibles, y alguien tiene que escribir algo para las que importan.

7. Qué copiar y qué no

De todo el diseño de Hades, estas son las ideas que me parecen más trasladables a otros juegos:

• Hacer que la muerte sea un evento, no un estado. Lo que ocurre justo después de perder es el momento de más riesgo de abandono. Si en ese momento pasa algo nuevo (una conversación, una recompensa, una decisión), el jugador tiene una razón inmediata para seguir.
• Separar la meta-progresión en varias economías. Una parte que da poder, otra que da opciones y otra que no da ninguna ventaja mecánica. Así se puede recompensar mucho sin romper el balance.
• Dejar que el jugador ajuste la dificultad en ambas direcciones. Pagar por subirla y ayudar sin juzgar cuando hace falta bajarla.
• Un sistema narrativo basado en requisitos y prioridades. Es sencillo de implementar y escala con la cantidad de contenido, no con la complejidad del código.

Lo que no copiaría a ciegas es la escala. El sistema de Hades funciona porque hay un volumen enorme de diálogo detrás, escrito, grabado y doblado. Con el mismo sistema y una fracción del contenido, el jugador empieza a escuchar el relleno demasiado pronto, y la ilusión se rompe antes de que la historia haya terminado. Antes de montar el sistema, conviene calcular cuántas vueltas a casa va a dar un jugador medio y cuántas líneas hacen falta para que casi todas traigan algo nuevo.