El estrés de Darkest Dungeon: diseñar para el desgaste

Hay un momento en Darkest Dungeon en el que te das cuenta de que llevas rato jugando al juego equivocado. Vas ganando todos los combates, nadie ha bajado de la mitad de vida, y aun así la expedición está perdida: el Crusader se ha vuelto abusivo e insulta al grupo cada vez que actúa, la Vestal está a 180 de estrés y el Highwayman se niega a recibir curación porque ha decidido que ya no le importa nada. No ha muerto nadie. El grupo está a punto de colapsar.

Eso no es un desequilibrio, es la tesis del juego. Darkest Dungeon separa la victoria táctica de la victoria estratégica en dos recursos distintos, y solo uno de los dos se restaura gratis. Este artículo es un análisis del segundo, el estrés, de cómo convierte cada expedición en una gestión de desgaste, y de cómo implementar la idea sin heredar sus asperezas.

1. El HP no es el recurso que gestionas

En la mayoría de los RPG por turnos, la vida es el recurso central: baja durante el combate, la recuperas con curación o descanso, y el bucle se cierra. La consecuencia es que un jugador competente puede convertir cualquier combate en un problema de aritmética. Si el daño entrante por turno es menor que la curación disponible por turno, el combate ya está ganado, solo falta ejecutarlo.

Darkest Dungeon rompe eso con una decisión casi administrativa: al terminar una expedición, la vida de los héroes se restaura sola y gratis, y el estrés no. El HP pasa a ser un recurso táctico, algo que solo existe dentro de un combate y como mucho dentro de una mazmorra. El estrés es el que cruza la frontera de la expedición y aterriza en la pantalla del pueblo, donde ya no se cura con hechizos sino con oro, con semanas y con espacios limitados en la taberna.

Ese es el truco estructural completo, y es más importante que cualquier número concreto del sistema: el recurso que persiste entre sesiones de juego es el que define la dificultad real de la campaña. Todo lo que se restaura gratis al terminar una misión es, por definición, un problema resuelto.

2. Dos umbrales, no una barra

El medidor de estrés va de 0 a 200 y tiene exactamente dos puntos donde ocurre algo. A los 100 se dispara una tirada de resolución (el resolve test), que decide si el héroe se rompe o se crece. A los 200 llega el ataque al corazón: el héroe cae directo al umbral de la muerte, y si ya estaba ahí, muere.

Esa estructura de dos umbrales es la razón por la que el sistema se lee bien mientras juegas. Una barra que penaliza de forma continua y proporcional (por ejemplo, "cada punto de estrés resta un 0.5% de precisión") es matemáticamente elegante e informativamente inútil: el jugador no puede notar la diferencia entre 61 y 68, así que deja de mirarla. Dos escalones duros, en cambio, convierten el medidor en una cuenta atrás con dos fechas marcadas, y el jugador empieza a planificar en torno a ellas.

La implementación base es un contador con memoria de si ya se hizo la tirada, no una simple suma acotada:

1public enum StressEvent { None, ResolveTest, HeartAttack }
2
3public sealed class StressMeter
4{
5    public const float ResolveThreshold = 100f;
6    public const float BreakingPoint = 200f;
7
8    public float Value { get; private set; }
9    public bool ResolveTested { get; private set; }
10
11    public StressEvent Add(float amount)
12    {
13        if (amount <= 0f)
14        {
15            Value = Math.Max(0f, Value + amount);
16            return StressEvent.None;
17        }
18
19        Value = Math.Min(BreakingPoint, Value + amount);
20
21        if (Value >= BreakingPoint)
22            return StressEvent.HeartAttack;
23
24        if (!ResolveTested && Value >= ResolveThreshold)
25        {
26            ResolveTested = true;
27            return StressEvent.ResolveTest;
28        }
29
30        return StressEvent.None;
31    }
32}

El detalle que importa es ResolveTested. Sin esa bandera, un héroe oscilando alrededor de 100 dispararía una tirada tras otra y el sistema se volvería ruido puro. Con ella, la primera mitad de la barra es una advertencia y la segunda mitad es una condena lenta: dos tramos con significados distintos usando un solo número.

3. La tirada de resolución: aflicción o virtud

Al llegar a 100, el juego tira los dados. Aproximadamente tres de cada cuatro veces el héroe sufre una aflicción (paranoico, masoquista, desesperado, irracional, abusivo, egoísta, temeroso) y una de cada cuatro se convierte en virtud (valiente, concentrado, poderoso, resuelto, vigoroso). Las aflicciones degradan estadísticas y, sobre todo, hacen que el héroe actúe por su cuenta. Las virtudes hacen lo contrario: mejoran al héroe y reducen el estrés del grupo.

Ese 25% es la pieza de diseño más subestimada de todo el sistema. Un sistema de desgaste sin válvula de escape es simplemente una condena con pasos intermedios, y el jugador termina desconectando emocionalmente porque sabe cómo acaba. La posibilidad minoritaria de que el momento peor de la expedición se convierta en el mejor es lo que mantiene la tensión viva: no estás esperando el desastre, estás jugándote un resultado.

1public enum ResolveKind { Affliction, Virtue }
2
3public readonly struct ResolveOutcome
4{
5    public readonly ResolveKind Kind;
6    public readonly string Trait;
7
8    public ResolveOutcome(ResolveKind kind, string trait)
9    {
10        Kind = kind;
11        Trait = trait;
12    }
13}
14
15public sealed class ResolveTest
16{
17    private const float BaseVirtueChance = 0.25f;
18
19    private readonly WeightedTable afflictions;
20    private readonly WeightedTable virtues;
21
22    public ResolveOutcome Roll(IRandom rng, float virtueModifier)
23    {
24        float chance = Math.Clamp(BaseVirtueChance + virtueModifier, 0f, 1f);
25
26        return rng.NextFloat() < chance
27            ? new ResolveOutcome(ResolveKind.Virtue, virtues.Pick(rng))
28            : new ResolveOutcome(ResolveKind.Affliction, afflictions.Pick(rng));
29    }
30}

El virtueModifier es el gancho que conviene dejar abierto desde el principio. En el juego original hay rasgos, campamentos y objetos que empujan esa probabilidad, y ese es justo el tipo de contenido que hace que el jugador sienta que puede pelear contra el sistema en vez de solo sufrirlo. Si la tirada es una constante inmutable, el estrés deja de ser un recurso gestionable y se convierte en climatología: habrá días con sol (toca una virtud) y otros con tormenta (y tu mejor unidad se vuelve contra el clérigo).

4. El contagio: por qué el desastre cascadea

Un héroe afligido no es solo un héroe peor, es una fuente de estrés para los demás. Empieza a generar estrés en el grupo cuando actúa, provoca ataques al corazón indirectos y, en algunos casos, se salta su turno o ataca a un aliado. El resultado es un bucle de realimentación positiva: la primera aflicción hace más probable la segunda, y la segunda hace casi inevitable la tercera.

Muchos diseñadores tratarían eso como un bug de balance. Aquí es el punto. La espiral es lo que hace que un solo error temprano tenga consecuencias visibles veinte minutos después, y es lo que transforma "esta expedición va regular" en "esta expedición hay que abortarla". Sin contagio, cada héroe sería un contenedor de estrés aislado y el grupo nunca colapsaría como unidad, solo se desgastaría en paralelo.

1public sealed class AfflictionContagion
2{
3    private const float WitnessStress = 8f;
4    private const float PerTurnStress = 5f;
5
6    public void OnHeroAfflicted(Hero source, Party party)
7    {
8        // Ver a un compañero romperse ya cuesta estrés
9        foreach (Hero ally in party.Members)
10        {
11            if (ally == source || !ally.IsAlive) continue;
12            ally.Stress.Add(WitnessStress);
13        }
14    }
15
16    public void OnAfflictedTurn(Hero source, Party party, IRandom rng)
17    {
18        if (!source.HasAffliction) return;
19
20        Hero target = party.RandomLivingAlly(source, rng);
21        if (target == null) return;
22
23        target.Stress.Add(PerTurnStress * source.Affliction.ContagionScale);
24    }
25}

5. La antorcha: dejar que el jugador fije su propia dificultad

La mayor parte del estrés que entra en una expedición no viene de los monstruos, viene de la oscuridad. El nivel de luz baja con cada movimiento, y a menos luz el grupo recibe más estrés y sufre más críticos, pero también encuentra mejor botín y los enemigos dan más recompensa. La antorcha es un dial explícito: el jugador decide cuánto desgaste quiere comprar a cambio de cuánto beneficio.

Esto resuelve un problema clásico del diseño de dificultad. Un selector de dificultad en el menú es una decisión abstracta que se toma una vez, sin información. La antorcha es la misma decisión, pero tomada cien veces, en contexto, con consecuencias inmediatas y reversibles a mitad de mazmorra. El jugador no elige "difícil", elige "puedo aguantar dos habitaciones más así". (Y de paso es una decisión de diseño muy bien integrada y diegética).

Al implementarlo, lo importante es que la oscuridad sea un multiplicador sobre las fuentes de estrés y no una fuente aparte, porque así escala con todo el contenido futuro sin tocarlo:

1public readonly struct StressSource
2{
3    public readonly string Id;
4    public readonly float BaseAmount;
5    public readonly bool ScalesWithDarkness;
6
7    public StressSource(string id, float baseAmount, bool scalesWithDarkness)
8    {
9        Id = id;
10        BaseAmount = baseAmount;
11        ScalesWithDarkness = scalesWithDarkness;
12    }
13}
14
15public sealed class StressPipeline
16{
17    private const float MaxDarknessBonus = 1.5f;
18
19    public float Resolve(StressSource source, float lightLevel, float stressResist)
20    {
21        float darkness = 1f - Math.Clamp(lightLevel / 100f, 0f, 1f);
22
23        float multiplier = source.ScalesWithDarkness
24            ? 1f + darkness * MaxDarknessBonus
25            : 1f;
26
27        float resisted = 1f - Math.Clamp(stressResist, 0f, 0.9f);
28        return source.BaseAmount * multiplier * resisted;
29    }
30}

Con esa forma, el estrés total de una expedición se puede expresar como un presupuesto que el jugador administra:

Donde $b_i$ es el estrés base de cada evento, $d$ la oscuridad normalizada, $k$ el peso máximo de la oscuridad y $r$ la resistencia del héroe. Lo interesante de escribirlo así es que deja ver dónde puede intervenir el jugador: puede reducir el número de eventos (rutas más cortas, evitar reliquias arriesgadas), bajar $d$ (gastar antorchas), o subir $r$ (equipo, rasgos). Tres palancas distintas sobre el mismo recurso, que es más o menos la definición de un sistema gestionable.

6. La retirada: diseñar el fracaso parcial

Darkest Dungeon tiene una opción de retirada que casi ningún RPG táctico modela bien: puedes abandonar la mazmorra a medias, quedarte el botín recogido hasta ese momento y volver al pueblo con la misión fallida. Cuesta estrés extra, puedes perder objetos, y la misión sigue apareciendo como fracasada. Pero los héroes vuelven vivos.

Ese estado intermedio es lo que hace funcionar todo lo anterior. Si las únicas salidas de una expedición fueran completarla o perder al grupo, la gestión de estrés no tendría ninguna decisión asociada: verías la barra subir sin poder hacer nada al respecto salvo apretar los dientes. La retirada convierte el medidor en un instrumento de navegación, porque existe una acción que responde a lo que dice.

Conviene además que la retirada tenga un coste explícito y legible, no gratis y no ruinoso. Gratis significa que el jugador reinicia expediciones hasta que le salga una buena, y eso destruye el desgaste entre sesiones. Ruinoso significa que nadie la usa, y vuelves al problema anterior.

7. Qué copiar y qué no

Lo que merece la pena robar de este sistema, en orden de utilidad:

• Un recurso que sobreviva a la misión. Es la palanca más potente para que el jugador piense a medio plazo. No hace falta que sea estrés: puede ser desgaste de equipo, deuda, fatiga o reputación. Lo que importa es que no se restaure gratis en la pantalla de resultados.
• Umbrales duros en vez de penalizaciones continuas. Dos escalones legibles comunican más que una curva perfecta.
• Una válvula de escape minoritaria. Ese 25% de virtudes es lo que separa la tensión del fatalismo.
• Un dial de riesgo en manos del jugador. La antorcha demuestra que la dificultad se disfruta más cuando se elige en contexto, no en un menú.
• Una salida con pérdida parcial. Sin ella, el resto del sistema es decorativo.

Y lo que no conviene copiar sin pensarlo mucho:

• La duración del castigo. Curar estrés en el pueblo cuesta oro, semanas y espacios limitados, y eso solo es tolerable porque hay una plantilla grande de héroes para rotar. Si tu juego tiene un grupo fijo de cuatro personajes, el mismo sistema se convierte en tiempo muerto obligatorio.
• La opacidad de los números. El juego original esconde bastante bien cuánto estrés genera cada cosa. Eso alimenta el terror, pero también hace que el jugador aprenda por repetición dolorosa en vez de por deducción. Es una decisión de tono, no una buena práctica.
• La densidad de fuentes de estrés. Casi todo genera estrés: críticos recibidos, muertes, reliquias, trampas, hambre, oscuridad. Funciona porque el juego entero está construido alrededor de eso. Añadir un recurso de desgaste a un juego que no lo está produce solo una segunda barra molesta.

La lección de fondo es que el estrés no es un sistema de castigo, es un conversor: transforma el rendimiento táctico en coste estratégico, y con eso obliga a valorar cada combate no por si lo ganaste, sino por lo que te costó ganarlo. Es la misma idea que hace interesantes los growth rates de Fire Emblem, y aparece siempre que un juego decide que el resultado de una batalla no cabe en un booleano.