Por qué el escalado multiplicativo no rompe Balatro

Tras jugar varias horas a Balatro, muchas de las puntuaciones finales que se alcanzan son parecidas a "3.2e14". Lo curioso es que el jugador no procesa ese número como una cifra muy grande, sino como la sensación de "Voy ganando mucho". Eso es raro. Un juego que muestra notación científica en su UI debería sentirse ilegible, y sin embargo Balatro es uno de los sistemas de puntuación más claros que he podido jugar.

La respuesta obvia ante esto es pensar: "los jokers son geniales". Y es cierto. Pero tienen un problema, y es que no explican nada. No ayudan a entender de dónde salen esas puntuaciones tan grandes. En cambio, lo que sostiene todo el sistema es un contrapeso que equilibra la capacidad de puntuar del usuario con los requisitos de cada Ante (apuesta), que crecen rápidamente. El número absoluto que se muestra en pantalla nunca mide nada realmente; lo que importa es el número relativo respecto al muro a superar, que se mueve con el jugador.

1. La interfaz es la fórmula

Balatro hace algo que casi ningún juego con sistemas parecidos se atreve a hacer: enseñar la fórmula. Utiliza Chips × Mult (situado en la parte superior de la pantalla), que se actualiza cada vez que una nueva carta se juega desde la mano. No hay un menú con una ventana de estadísticas, o un panel oculto para mostrarlas. El cálculo completo siempre está a simple vista.

Esto sustituye a un tutorial entero. No necesitas explicarle al jugador qué hace un joker de "+4 Mult" si ya está mirando cómo el número de la derecha sube de 8 a 12 en tiempo real. La interfaz no describe el sistema, es el sistema. Cualquier duda sobre qué hace una carta se resuelve jugándola una vez y mirando qué número cambió.

2. Sumar y multiplicar no son lo mismo

Que un joker sume o multiplique el Mult es la distinción central de Balatro, y lo que permite diferenciar entre una build mediocre y una que revienta el Ante.

Un joker de "+4 Mult" añade una constante. Un joker que otorga una modificación de "×1.5 Mult" multiplica todo lo que ya había calculado. La diferencia parece pequeña, pero cuantos más jokers acumulas, mayor comienza a notarse.

Con un Mult base de 4, ocho jokers de tipo aditivo dejan el valor en 36. En cambio, ocho jokers de tipo multiplicativo dejarían el mismo valor por encima de 100. La curva aditiva es una línea recta, la multiplicativa es una exponencial. Esa asimetría es la razón por la que las builds "rotas" de Balatro no dependen de encontrar un joker especial, sino de encontrar suficientes multiplicadores en el orden correcto. Esto genera también más variedad de partidas y builds posibles.

Lo interesante es que los valores base de las manos de póker (antes de añadir cualquier valor de los joker) escalan únicamente de forma lineal. Subir de nivel una mano con una carta de Planeta añade una cantidad fija de chips y de mult, y es siempre la misma por nivel (por ejemplo, un Par pasa de 10 chips / 2 mult en nivel 1 a sumar +15 chips / +1 mult por cada nivel adicional). El motor base del juego crece en línea recta. Toda la exponencialidad del sistema vive en los jokers multiplicativos.

3. El contrapeso: Ante

Los requisitos de puntuación por Ante no crecen de forma lineal. En cambio, crecen de forma agresiva desde el principio y se vuelven superexponenciales en cuanto el usuario sale del contenido base.

Requisitos base de la Ciega Pequeña en White Stake. La Ciega Grande multiplica esta base por 1.5. La mayoría de Boss por 2.

Sobre esa base, la Ciega Grande multiplica por 1.5 y la mayoría de Ciegas de Jefes (Boss) por 2 (con excepciones puntuales, como El Muro, que llega a ×4).

En el modo Endless, la fórmula deja de ser una progresión simple y pasa a depender del propio número de ante como exponente. Esto produce lo que en la comunidad se conoce como "killscreen", alrededor del ante 39. El juego no se rompe por diseño, sino que los requisitos de la partida superan con creces lo que cualquier build puede escalar.

Esta curva permite que el escalado multiplicativo de los jokers no sea un problema de balance. Da igual si el usuario consigue que el Mult llegue a 4 dígitos antes del Ante 3, porque ese mismo no te va a exigir 4 dígitos para superarlo. El diseño nunca compara el poder contra un número fijo, sino que lo compara contra un número que crece con el usuario, por lo que el poder es relativo al muro actual al que se enfrenta.

4. El orden de evaluación como mecánica

Balatro toma una decisión de diseño que la mayoría de juegos evitarían por incómoda: expone el orden de evaluación como parte jugable del sistema, no como un detalle de implementación escondido.

La secuencia de cómo se evalúan dichos valores es:

1. Las cartas jugadas se resuelven de izquierda a derecha. Por lo tanto, es igual de importante qué carta se juega, como su valor y multiplicador. Cada carta aporta sus chips base, luego sus modificadores (potenciador/sello/edición). Después, se disparan los jokers (también de izquierda a derecha) que reaccionan cuando una carta puntúa.
2. Los reintentos, tanto jokers como los sellos rojos que se añaden a las cartas, se resuelven justo después de la activación normal de esa carta, repitiendo toda la secuencia de esa carta una vez más antes de pasar a la siguiente.
3. Una vez resueltas todas las cartas jugadas, entran los jokers independientes, aquellos que no dependen de una carta concreta, como los de +Mult o ×Mult fijos. Aquí se mantiene también el orden de izquierda a derecha.
4. Por último se activan las cartas que quedaron en la mano, con sus propios efectos y sus propios jokers asociados si activan.

Durante toda esta interacción, se mantiene el orden de izquierda a derecha. Por lo que siempre hay que tener presente ese orden a la hora de jugar la mano. Y esa es la razón por la que reordenar los jokers en el tablero cambia el resultado final aunque se jueguen las mismas cartas.

Con un joker de +10 Mult y uno de ×2 Mult se ejemplifica perfectamente. En matemáticas siempre se dice que el orden de los factores no altera el producto. Aquí no se cumple. No es lo mismo que a una puntuación de 2 le sumes 10, y al resultado de 12 lo multipliques por 2, que da 24, que si primero multiplicas por 2, dando 4, y luego le sumas 10, para llegar a 14. Esa pequeña diferencia puede alterar si el jugador alcanza el objetivo del Ante o no.

5. Diseñar para que el jugador lo rompa

Balatro no pone ningún tope de diseño visible para la puntuación salvo el técnico: el motor almacena la puntuación como un double de 64 bits, lo que da como resultado un límite teórico alrededor de 1.7977 × 10³⁰⁸.

Algunas builds creadas por la comunidad como combinaciones de jokers Barón, Mime y cartas de sello rojo sobre Reyes de Acero, han conseguido llegar a puntuaciones del orden de 10^500.000, muy por encima de donde el juego empieza a mostrar notación científica.

Lo más interesante de esto no es el bug en sí, sino la actitud de diseño detrás. Balatro no se defiende contra las builds que rompen su propio sistema numérico, sino que las deja pasar y convierte en el objetivo final del modo Endless. Ese techo de puntuación no es un fallo de balance. En cambio, es la recompensa que persigue el jugador que ya completó el "juego normal".

6. Implementar un pipeline de modificadores ordenado

Para implementar este sistema no basta simplemente con un chips × mult. Es necesaria una arquitectura que permita que el orden de una lista de efectos altere el resultado de forma predecible para el jugador.

En C# se puede montar un contexto de puntuación que pasa por una lista ordenada de modificadores, cada uno con acceso de lectura y escritura al estado acumulado:

1public class ScoreContext
2{
3    public double Chips { get; set; }
4    public double Mult { get; set; }
5
6    public double FinalScore => Chips * Mult;
7}
8
9public interface IScoreModifier
10{
11    void Apply(ScoreContext context);
12}
13
14public class AddMultModifier : IScoreModifier
15{
16    private readonly double _amount;
17
18    public AddMultModifier(double amount) => _amount = amount;
19
20    public void Apply(ScoreContext context)
21    {
22        context.Mult += _amount;
23    }
24}
25
26public class MultiplyMultModifier : IScoreModifier
27{
28    private readonly double _factor;
29
30    public MultiplyMultModifier(double factor) => _factor = factor;
31
32    public void Apply(ScoreContext context)
33    {
34        context.Mult *= _factor;
35    }
36}

El pipeline es una lista ordenada de IScoreModifier, que se resuelve de una forma ordenada y secuencial. El orden de esa lista se refleja en el orden del tablero:

1public class ScoringPipeline
2{
3    private readonly List<IScoreModifier> _modifiers;
4
5    public ScoringPipeline(List<IScoreModifier> modifiers)
6    {
7        _modifiers = modifiers;
8    }
9
10    public ScoreContext Resolve(double baseChips, double baseMult)
11    {
12        var context = new ScoreContext { Chips = baseChips, Mult = baseMult };
13
14        foreach (var modifier in _modifiers)
15        {
16            modifier.Apply(context);
17        }
18
19        return context;
20    }
21}

Con esto, [AddMultModifier(10), MultiplyMultModifier(2)] y [MultiplyMultModifier(2), AddMultModifier(10)] producen resultados distintos, como se comentaba antes. Y lo mejor es que no hace falta programar ninguna lógica especial, simplemente es una consecuencia directa de que el orden de la lista es informativo.

7. Qué copiar y qué no

De todo este sistema hay tres ideas que me parecen interesantes tener en cuenta:

• La separación aditivo/multiplicativo como herramienta de expresividad. No es necesario inventar mecánicas nuevas para dar sensación de progresión. Basta con tener dos categorías de modificador, con curvas de crecimiento distintas, y que sea el jugador quien decida cuánto y cuándo invertir en cada una.
• El contrapeso. Explícito entre el poder del jugador y la exigencia del sistema/nivel/reto. Un techo que escala con el jugador permite que el crecimiento del mismo sea sostenible indefinidamente. O hasta donde el desarrollador quiera que llegue.
• Exponer el cálculo al jugador. Siempre y cuando el sistema lo permita. No todos los juegos pueden hacerlo. Mostrar la fórmula central de los cálculos del sistema puede ser una ventaja o una desventaja. Pero cuando el sistema es la mecánica principal, ocultarlo solo añade fricción en su aprendizaje.

Aun con todo esto, también hay que recalcar que la dependencia de un overflow de precisión numérica, como parte del diseño, sin que tenga una decisión real detrás, es un problema del juego y una ventana a bugs. Y los jugadores siempre tendrán paciencia para encontrarlo.

Capturas de pantalla: Balatro © LocalThunk / Playstack Ltd. Imágenes oficiales de la página de Balatro en Steam, usadas con fines de análisis y comentario. Balatro es una marca registrada de LocalThunk LLC.