El roster como recurso: la economía de escasez de Darkest Dungeon

Cuando muere un héroe en Darkest Dungeon, el juego no te ofrece cargar partida. Escribe el nombre en una lápida, lo saca de la plantilla, y la siguiente semana la diligencia trae a dos desconocidos. El único mensaje que recibes es el de la Ruina, que ya se ha llevado un montón de gente antes que a ese.

Es tentador leerlo como crueldad estética, y hay bastante de eso. Pero por debajo hay una decisión económica muy concreta: en Darkest Dungeon los héroes no son el personaje del jugador, son el consumible con el que juega. El personaje es el pueblo. Este artículo trata de esa inversión de roles, de la gestión de plantilla que provoca, y de una economía diseñada desde el primer día para que nunca tengas suficiente de nada.

Este es el segundo artículo sobre el juego. El primero cubría el estrés y el diseño del desgaste, que es el sistema que alimenta casi todo lo que viene aquí.

1. El pueblo es el personaje

En un RPG clásico, el progreso vive en los personajes: subes de nivel, mejoras el equipo, y si el personaje muere de forma permanente pierdes el progreso. Por eso casi ningún RPG tiene muerte permanente de verdad, y los que la tienen suelen empujarte a recargar.

Darkest Dungeon mueve el progreso permanente a otro sitio. Las mejoras del pueblo (la herrería, el gremio, la abadía, la taberna, la diligencia, el sanatorio) son irreversibles y no se pierden nunca. Un héroe muerto se lleva su equipo, sus habilidades entrenadas y sus rasgos, pero no toca ni un edificio. Al terminar cualquier campaña fallida, lo que queda no es un archivo de guardado con cuatro veteranos, es un pueblo mejor que reclutará héroes mejores.

Ese único movimiento arquitectónico resuelve el problema que hace inviable la muerte permanente en otros juegos. La pérdida deja de ser un retroceso de progreso y se convierte en un coste operativo: caro, doloroso, pero pagable. El jugador puede permitirse perder porque la curva de progreso a largo plazo no está en la cosa que muere.

En términos de estructura de datos, la diferencia es literal. El estado persistente del jugador vive en el pueblo, y los héroes son entidades con ciclo de vida propio que entran y salen de ese estado:

1public sealed class EstateState
2{
3    // Progreso permanente: sobrevive a cualquier muerte
4    public Dictionary<string, int> BuildingLevels { get; } = new();
5    public Wallet Wallet { get; } = new();
6    public int Week { get; private set; }
7
8    // Progreso volátil: se destruye y se repone
9    public Roster Roster { get; } = new();
10    public List<string> Graveyard { get; } = new();
11
12    public void AdvanceWeek()
13    {
14        Week++;
15        Roster.RefreshRecruitPool(Week);
16    }
17
18    public void OnHeroDied(Hero hero)
19    {
20        Graveyard.Add(hero.Name);
21        Roster.Remove(hero);
22        // Deliberadamente: no se toca nada de BuildingLevels
23    }
24}

2. El roster como recurso renovable con techo

La plantilla empieza con nueve huecos y se amplía a lo largo de la partida hasta unas dos docenas. Cada semana, la diligencia deja un puñado de candidatos nuevos, prácticamente gratis, con niveles, rasgos y habilidades distintas. Reclutar no cuesta casi nada. Lo que cuesta es el hueco.

Ese techo es lo que convierte un flujo de héroes en un sistema de gestión. Si la plantilla fuera infinita, el jugador acumularía cuarenta héroes mediocres y no tomaría ninguna decisión: siempre habría alguien descansado. Con techo, cada recluta interesante obliga a mirar la lista y preguntarse a quién se despide, y despedir a alguien es reconocer que semanas de oro invertidas en él no van a rendir.

1public sealed class Roster
2{
3    public int Capacity { get; private set; } = 9;
4
5    private readonly List<Hero> heroes = new();
6    private readonly List<Hero> recruitPool = new();
7
8    public bool IsFull => heroes.Count >= Capacity;
9
10    public bool TryRecruit(Hero candidate)
11    {
12        if (IsFull) return false;
13
14        recruitPool.Remove(candidate);
15        heroes.Add(candidate);
16        return true;
17    }
18
19    public void Dismiss(Hero hero)
20    {
21        // El oro invertido no se devuelve: es coste hundido, y debe doler
22        heroes.Remove(hero);
23    }
24
25    public IEnumerable<Hero> Available(int missionLevel) =>
26        heroes.Where(h => h.IsRested && h.AcceptsMission(missionLevel));
27}

El método AcceptsMission esconde la regla más importante de todo el sistema: un héroe veterano se niega a bajar a las mazmorras de nivel bajo. No puede farmear contenido fácil, ni acompañar a novatos, ni servir de escolta. Los veteranos solo sirven para el contenido duro.

La consecuencia es que el jugador no mantiene un grupo, mantiene una cantera. Necesita a la vez un equipo de nivel alto para las misiones difíciles y una hornada de novatos subiendo por debajo, porque el día que muera un veterano no habrá forma de improvisar un reemplazo. Es una regla de una línea que multiplica el ancho de la gestión.

3. El coste de oportunidad: invertir en algo mortal

Reclutar es gratis, pero un héroe funcional no lo es. Entrenar habilidades en el gremio, mejorar arma y armadura en la herrería, curar un rasgo negativo en el sanatorio y quitar estrés en la abadía cuestan oro, y ese oro se convierte en valor acumulado dentro de una entidad que puede morir en cualquier expedición.

Esa es la tensión real de la economía. No es "no tengo oro", es "cada moneda que gasto en este héroe es una apuesta a que sobrevivirá lo suficiente para devolverla". Se puede escribir como una decisión de valor esperado:

Donde $R$ es la recompensa esperada, $p_{exito}$ la probabilidad de completar la misión, y $V_h$ la inversión acumulada en cada héroe del grupo. Lo interesante es lo que dice la fórmula: cuanto más invierte el jugador en un héroe, más caro sale arriesgarlo, así que el propio éxito va estrechando el margen de maniobra. Un grupo muy mejorado es a la vez el más capaz y el más caro de perder.

Merece la pena hacer ese valor explícito en el código, aunque no se muestre en la interfaz, porque es el número con el que se equilibra todo lo demás:

1public sealed class HeroInvestment
2{
3    private readonly Dictionary<CurrencyType, int> spent = new();
4
5    public void Record(CurrencyType currency, int amount)
6    {
7        spent.TryGetValue(currency, out int current);
8        spent[currency] = current + amount;
9    }
10
11    // Valor en oro equivalente, solo para balanceo y telemetría
12    public int EstimatedValue(IReadOnlyDictionary<CurrencyType, float> weights)
13    {
14        float total = 0f;
15        foreach ((CurrencyType currency, int amount) in spent)
16            total += amount * weights[currency];
17
18        return (int)total;
19    }
20}

4. Abalorios: el único activo que se puede mover

Toda la inversión de la sección anterior tiene una propiedad incómoda: es intransferible. El arma mejorada, la armadura, las habilidades entrenadas y los rasgos curados viven dentro del héroe y desaparecen con él. Los abalorios son la excepción, y por eso funcionan como una capa económica distinta.

Un abalorio no se compra, se encuentra. Sale de las mazmorras, de los curios y de los jefes, no se fabrica en ningún edificio, y se puede quitar y poner en otro héroe cuando el jugador quiera. Es capital líquido del pueblo, no valor acumulado en una persona. Esa liquidez es lo que le permite al juego meter bonus mucho más agresivos que los del equipo: un abalorio puede dar un veinte por ciento de daño extra a cambio de hundir la resistencia al estrés, o subir la velocidad y bajar la precisión. Como el objeto se puede mover, el jugador no está eligiendo una build permanente, está eligiendo con qué configuración baja esta semana.

Lo interesante es cómo el juego evita que esa liquidez desactive el riesgo. Si un héroe muere, sus abalorios solo se recuperan si el grupo gana el combate y hay hueco en el inventario del pueblo, que también tiene tope. Si el jugador se retira, se van con el cadáver. Equipar el mejor abalorio del inventario en el héroe que va a la misión más dura es, otra vez, una apuesta: el objeto que más te ayuda a sobrevivir es el que más duele perder.

1public sealed class TrinketSet
2{
3    public const int SlotCount = 2;
4
5    private readonly Trinket[] slots = new Trinket[SlotCount];
6
7    public bool TryEquip(Trinket trinket, Hero hero, int slot)
8    {
9        // Restricción de clase: no todo vale para todo el mundo
10        if (!trinket.AllowsClass(hero.ClassId)) return false;
11
12        slots[slot] = trinket;
13        return true;
14    }
15
16    // Los abalorios se transfieren; el arma, la armadura y las habilidades no
17    public IEnumerable<Trinket> Unequip()
18    {
19        for (int i = 0; i < SlotCount; i++)
20        {
21            if (slots[i] == null) continue;
22
23            yield return slots[i];
24            slots[i] = null;
25        }
26    }
27}
28
29public static class DeathLoot
30{
31    // Solo se recuperan si el grupo aguanta y hay sitio en el pueblo
32    public static void OnHeroDied(Hero hero, CombatResult result, TrinketVault vault)
33    {
34        if (result != CombatResult.Won) return;
35
36        foreach (Trinket trinket in hero.Trinkets.Unequip())
37        {
38            if (!vault.TryStore(trinket))
39                vault.RegisterLost(trinket);   // Alimenta el contador del Chillón
40        }
41    }
42}

Y aquí aparece la única concesión de todo el diseño. El juego cuenta los abalorios que has perdido y, al llegar a ocho, aparece el Chillón: un jefe opcional que, al morir, devuelve el botín robado. Puede parecer una contradicción con el aviso de la sección anterior sobre no reembolsar nunca, pero no lo es, porque el objeto es distinto. El oro es fungible y farmeable: si lo pierdes, puedes conseguir más. Un abalorio de jefe es único y puede no volver a caer en toda la partida. Perderlo para siempre no crea tensión, crea un callejón sin salida, y un callejón sin salida no es una decisión.

5. Rasgos: el héroe que se encarece solo

Las expediciones dejan rasgos. Cada héroe tiene cinco huecos de rasgos positivos y cinco de negativos, y cuando se llenan, cada rasgo nuevo desplaza a uno de los viejos. Es un sistema de deriva: el jugador no elige nada, solo mira cómo la ficha de sus héroes se va ensuciando expedición tras expedición.

La parte importante es que los rasgos negativos que no se tratan pueden fijarse. Un rasgo fijado ya no se desplaza nunca por otro y su tratamiento en el sanatorio pasa a ser bastante más caro, con un coste que además escala con el nivel del héroe. Traducido a economía: el coste de mantenimiento de un héroe crece con el tiempo, por sí solo, sin que el jugador tome ninguna decisión, y crece más rápido en los héroes en los que más ha invertido.

Algunos de esos rasgos no son un modificador numérico, son un bloqueo. Hay rasgos que hacen que el héroe interactúe con los curios sin permiso, o que robe, o que le impidan usar según qué actividad de alivio de estrés. Un héroe con la combinación equivocada puede quedarse sin ninguna forma viable de quitarse estrés hasta que pase por el sanatorio, que solo puede tratar un rasgo negativo por héroe y semana. El cuello de botella temporal de la sección anterior se estrecha justo cuando más falta hace.

1public sealed class QuirkSheet
2{
3    public const int SlotsPerSign = 5;
4
5    private readonly List<Quirk> positive = new();
6    private readonly List<Quirk> negative = new();
7
8    public void Add(Quirk quirk)
9    {
10        List<Quirk> target = quirk.IsPositive ? positive : negative;
11
12        if (target.Count < SlotsPerSign)
13        {
14            target.Add(quirk);
15            return;
16        }
17
18        // Desplaza el más antiguo que NO esté fijado; si todos lo están, se ignora
19        Quirk oldest = target.FirstOrDefault(q => !q.IsLocked);
20        if (oldest == null) return;
21
22        target.Remove(oldest);
23        target.Add(quirk);
24    }
25
26    // Al volver de expedición: los negativos sin tratar pueden fijarse
27    public void RollLocks(IRandom random)
28    {
29        foreach (Quirk quirk in negative.Where(q => !q.IsLocked))
30        {
31            quirk.WeeksUntreated++;
32            if (random.NextFloat() < quirk.LockChance)
33                quirk.IsLocked = true;
34        }
35    }
36
37    public bool BlocksActivity(string building) =>
38        negative.Any(q => q.BlockedBuildings.Contains(building));
39
40    public int TreatmentCost(Quirk quirk, int heroLevel) =>
41        quirk.BaseCost * (heroLevel + 1) * (quirk.IsLocked ? 3 : 1);
42}

El efecto de conjunto es una obsolescencia suave. El juego no le pone caducidad a los héroes ni les baja las estadísticas con el tiempo, que es lo que haría un sistema de durabilidad y se sentiría como un castigo arbitrario. Lo que hace es dejar que el coste de tener a ese héroe en condiciones suba hasta que un recluta nuevo, gratis y limpio, empiece a parecer mejor opción que el veterano al que hay que pagarle tres tratamientos. El jugador llega solo a la conclusión de que toca despedir, y como ha sido su cuenta, no lo lee como una imposición del juego.

6. Por qué castigar el apego no se siente injusto

Darkest Dungeon hace algo aparentemente contradictorio: construye maquinaria de apego a toda velocidad (nombres propios, retratos, rasgos que se leen como personalidad, motes que el jugador acaba usando) y después mata a esos personajes sin ceremonia. Debería sentirse como una traición, y casi nunca lo hace. Hay tres razones, y todas son de diseño.

La primera es que la muerte casi siempre es legible hacia atrás. Cuando muere un héroe, el jugador puede reconstruir la cadena: bajé con dos antorchas, ignoré el estrés en la tercera sala, no me retiré cuando debía. La aleatoriedad remata, pero no decide sola. Un sistema letal necesita ese rastro causal; sin él, la muerte se percibe como arbitraria y el jugador deja de aprender.

La segunda es que hay una alternativa a morir, y estaba disponible. La retirada, el gasto en provisiones, la rotación de plantilla: todas son formas de comprar seguridad con recursos. Cuando existe una salida que el jugador decidió no pagar, la pérdida se lee como consecuencia.

La tercera es que el juego separa el drama del héroe del progreso del jugador, que es de lo que hablaba la primera sección. El apego puede ser intenso justo porque el coste está acotado: el jugador se permite querer a un personaje mortal porque sabe que perderlo no invalida la partida.

7. Monedas que no se convierten entre sí

La economía del pueblo tiene dos capas que no se tocan. El oro paga todo lo relacionado con los héroes: provisiones, entrenamiento, equipo, tratamientos, alivio de estrés. Las reliquias (bustos, retratos, escrituras, blasones) pagan las mejoras de los edificios. Van a bolsillos distintos y, en la práctica, no hay una conversión libre entre ellas.

Es una decisión de diseño deliberada y muy efectiva. Con una sola moneda, cualquier escasez se resuelve acumulando: el jugador ahorra y compra. Con monedas no fungibles y de fuentes distintas, la escasez pasa a ser estructural. Puedes tener oro de sobra y no poder ampliar la plantilla, porque el edificio que amplía la plantilla no se paga con oro. La única forma de conseguir la reliquia correcta es ir al tipo de mazmorra que la suelta, y eso convierte una decisión de compra en una decisión de dónde jugar la próxima semana.

1public enum CurrencyType { Gold, Bust, Portrait, Deed, Crest }
2
3public sealed class Wallet
4{
5    private readonly Dictionary<CurrencyType, int> balances = new();
6
7    public int Get(CurrencyType currency) =>
8        balances.TryGetValue(currency, out int value) ? value : 0;
9
10    public void Add(CurrencyType currency, int amount) =>
11        balances[currency] = Get(currency) + amount;
12
13    public bool CanAfford(IReadOnlyDictionary<CurrencyType, int> cost)
14    {
15        foreach ((CurrencyType currency, int amount) in cost)
16            if (Get(currency) < amount) return false;
17
18        return true;
19    }
20
21    public bool TrySpend(IReadOnlyDictionary<CurrencyType, int> cost)
22    {
23        if (!CanAfford(cost)) return false;
24
25        foreach ((CurrencyType currency, int amount) in cost)
26            balances[currency] = Get(currency) - amount;
27
28        return true;
29    }
30
31    // No existe Exchange(): la no fungibilidad es la mecánica
32}

Hay una tercera moneda que el juego no dibuja en ninguna parte: la semana. Cada expedición consume una, y un héroe que pasa la semana quitándose estrés en la taberna no está disponible para la siguiente misión. Como los espacios de la abadía y la taberna son limitados, el tiempo se convierte en el cuello de botella final. No importa cuánto oro tengas si solo puedes tratar a dos héroes por semana.

1public sealed class TownActivities
2{
3    private readonly Dictionary<string, int> slotsPerBuilding;
4    private readonly Dictionary<string, List<Hero>> assignments = new();
5
6    public bool TryAssign(string building, Hero hero, Wallet wallet, int cost)
7    {
8        List<Hero> queue = assignments.GetValueOrDefault(building, new List<Hero>());
9
10        if (queue.Count >= slotsPerBuilding[building]) return false;
11        if (hero.IsAssignedThisWeek) return false;
12        if (!wallet.TrySpend(new Dictionary<CurrencyType, int> { [CurrencyType.Gold] = cost }))
13            return false;
14
15        queue.Add(hero);
16        assignments[building] = queue;
17        hero.IsAssignedThisWeek = true;   // No irá a la expedición
18        return true;
19    }
20}

8. Provisiones e inventario: la decisión antes de la mazmorra

Antes de cada expedición el juego enseña una tienda de provisiones: antorchas, comida, palas, vendas, antiveneno, láudano, llaves, agua bendita. Compras a ciegas, sabiendo el tipo y la longitud de la mazmorra pero no lo que hay dentro. Y todo lo que compras ocupa espacio en un inventario de dieciséis huecos que también tiene que albergar el botín.

Ahí está la parte elegante. Las provisiones no compiten con el oro, compiten con la recompensa. Llevar comida de sobra significa volver con menos tesoro, y tirar comida para hacer sitio a una pila de oro significa que el grupo pasará hambre en la última sala. La misma decisión aparece dos veces con signo contrario, una al principio y otra al final, y las dos se toman con información incompleta.

1public sealed class ExpeditionInventory
2{
3    public const int SlotCount = 16;
4
5    private readonly List<ItemStack> stacks = new();
6
7    public int UsedSlots => stacks.Count;
8    public bool IsFull => UsedSlots >= SlotCount;
9
10    public bool TryAdd(ItemDefinition item, int quantity)
11    {
12        ItemStack existing = stacks.FirstOrDefault(s => s.Item == item && !s.IsMaxed);
13        if (existing != null)
14            return existing.TryStack(quantity);
15
16        if (IsFull) return false;   // Aquí es donde el botín obliga a tirar provisiones
17
18        stacks.Add(new ItemStack(item, quantity));
19        return true;
20    }
21}

9. Reglas trasladables

Del bucle de gestión completo, esto es lo que se puede llevar a otro juego casi tal cual:

• Guarda el progreso permanente fuera de la unidad que puede morir. Es el requisito previo de cualquier sistema con pérdida real. Sin él, la muerte permanente solo enseña a recargar partida.
• Pon techo a lo que se acumula. Un recurso renovable sin límite no genera decisiones. El hueco de plantilla es más valioso que el héroe que lo ocupa.
• Prohíbe en vez de incentivar. Que los veteranos no puedan hacer el contenido fácil obliga a una plantilla ancha sin necesidad de bonus.
• No devuelvas la inversión. El coste hundido es lo que hace que despedir y perder signifiquen algo.
• Separa el equipo ligado a la unidad del transferible. Lo intransferible sostiene el progreso; lo transferible, con contrapartidas fuertes, genera decisiones cada semana.
• Reembolsa solo lo irrepetible, y cóbralo aparte. Perder para siempre un objeto único no crea tensión, crea un callejón sin salida. Devolverlo a cambio de tiempo y riesgo sí es una decisión.
• Deja que el mantenimiento suba solo. Es mejor que la caducidad: la obsolescencia por coste hace que el jugador decida retirar a la unidad en vez de que el sistema se la quite.
• Usa monedas no fungibles con fuentes distintas. Es la forma más limpia de que la escasez no se resuelva ahorrando.
• Haz que el tiempo sea una moneda con espacios limitados. El cuello de botella más interesante casi nunca es el dinero.
• Que la reserva compita con la recompensa por el mismo espacio. Es lo que convierte una tienda en un problema.

Y una advertencia general: este bucle funciona porque todas las piezas se apoyan entre sí. El estrés hace necesaria la rotación, la rotación hace necesaria la plantilla amplia, la plantilla amplia hace escaso el oro, los rasgos que se fijan hacen que ese oro no llegue nunca, la escasez de oro hace dolorosa la muerte, y el pueblo permanente hace tolerable todo lo anterior. Sacar una pieza sola y pegarla en otro juego suele producir solo una molestia. Lo que hay que copiar no es el sistema, es la relación entre los sistemas.