Balatro: the hand is only the beginning

The design bet: let the same hand mean something different

Balatro combines poker hands with a roguelike structure, score targets, and rule-changing Jokers. Its official description emphasizes combinations rather than competitive poker. LocalThunk’s development timeline records Chips × Mult in an early prototype, before the full set of surrounding systems existed.

Our reading is that the familiar hand categories provide a stable language while the scoring system changes what that language is worth. A player can recognize a pair without already understanding the run they are about to build. Familiarity reduces one learning burden; combinations provide another.

This is a useful pattern for a small developer: keep one layer understandable while allowing another to become surprising. If every card, action, goal, and score rule is unfamiliar at once, the player has nowhere to stand while learning.

There are several decisions hiding inside “play a hand”

At the shortest scale, you choose which available cards to commit. At a longer scale, you shape the tools that will make later hands useful. Across a run, you decide whether an emerging strategy is strong enough to keep investing in. These questions interact, but they are not interchangeable.

Consider an original card prototype. You can play a small reliable combination now or spend a limited redraw hoping for a larger one. If a modifier rewards the reliable combination, the calculation changes. If a future target is much higher, the safe choice may keep you alive without giving the build enough room to grow.

The important design resource is the relationship between present survival and future capacity. If every upgrade is immediately better with no cost or commitment, the longer decision collapses into accepting good news. If every useful upgrade requires an unknowable future event, planning can feel like wishful thinking.

A good experiment therefore includes both a near target and a later one. A single hand can test whether scoring is readable. It cannot test whether players can build a strategy that survives changing demands.

Play it: the same modifiers, a different result

Here is an original scoring toy using Chips × Mult as a starting relationship. It has two plain modifiers: add four to Mult and multiply Mult by three. Swap their order and calculate the result before revealing it. These are invented teaching values, not recreations of specific Jokers.

The interesting question is not whether multiplication works. It is whether a player can see why arranging the same pieces differently changes the result. A combination system needs to teach its order of operations somewhere the player can inspect.

A collection becomes a build when you have to choose

Imagine a version of our toy that lets you keep every modifier you ever find. Unless some modifiers conflict, the decision is mostly about accumulating. Now allow only three slots. A new effect asks you to give something up. The question moves from “is this good?” to “is this good for what I already have?”

This is why evaluating an item alone can miss its purpose. A modest effect that triggers often may fit a build better than a spectacular effect that rarely applies. An item that solves this round’s weakness may be valuable even if it contributes less to the eventual dream combination.

Use a simple design table for your own modifiers. Write the condition, the payoff, the cost of making that condition happen, and at least one companion that changes its value. If the companion merely adds more of the same number, ask whether that is enough. Sometimes it is. Sometimes you want an effect that changes which actions become attractive.

Then look for an option that accidentally fits everything. If one modifier improves every reasonable strategy at little cost, it may crowd out the choices meant to give runs different identities. Removing a universal answer can create more room for interesting combinations than adding another dozen items.

A plan should bend before it breaks

In a run built from uncertain offers, the player needs ways to respond when the preferred piece does not appear. Otherwise the game encourages repeatedly asking for the same answer and restarting when it refuses.

For an original prototype, offer upgrades that can play more than one role. A card that adds a small amount of score now and supports a future condition later creates a bridge between strategies. A tool that changes the available cards can help the player adapt instead of merely waiting for the right draw.

This does not mean every run needs a guaranteed rescue. It means the player should have decisions before failure. A constrained offer can be interesting when it prompts a revised plan. It is less informative when every option is unusable for reasons the player could not anticipate.

Test the awkward offers deliberately. Prepare three upgrade sequences: one that supports the obvious plan, one that invites a pivot, and one that looks tempting but is too slow for the next target. Watch whether players recognize the differences. If they cannot, inspect the information and pacing before adding more randomness.

The score display is a lesson in causality

An enormous total is a payoff. The sequence that produced it is information. If a player can connect an effect to a number changing, they gain a model they can use in the next decision. If all effects happen at once, success can be exciting and still leave the player unsure what to repeat.

There is a tradeoff. Showing every intermediate operation slowly can become a tax once the player understands the build. Hiding everything immediately can make a new effect difficult to learn. For your own scoring game, prototype a readable first presentation and a faster repeat presentation.

Do not use animation to cover an unclear rule. Ask someone to predict the direction of a change before playing. They need not calculate the exact total to understand that a multiplier should come after an addition in this particular toy. If the interface makes that relationship invisible, clearer sequencing may help more than louder effects.

A useful failure case is an unexpectedly low score. Can the player find the condition that did not trigger? A system that explains only its successes leaves half the learning loop unfinished.

The finished structure was discovered, not delivered whole

LocalThunk’s timeline describes an early card-game idea that changed direction, the later arrival of Jokers and boss blinds, and periods of stopping and returning. In a separate interview, the developer describes trial and error as central to finding the design.

The transferable lesson is modest: preserve room to discover what the prototype wants to be. It is not evidence that planning is useless, that every side project should expand, or that another developer should copy the same personal circumstances. A retrospective gives us one person’s account, not a universal production schedule.

For a small team, write down the interaction that is already interesting and the uncertainty that remains. That record lets you change the surrounding structure without losing track of what you were trying to preserve. The prototype can be wrong about its genre label and right about one compelling relationship.

A large deck of effects is an outcome, not a starting scope

A beginner can look at a rich combination game and conclude that depth requires a huge content list. That is an expensive assumption. Ten effects with no meaningful interactions can produce less discovery than four effects whose conditions and payoffs change one another.

Start with the interaction matrix. Which pairs have an interesting relationship? Which pair is redundant? Which pairing destroys the difficulty curve? If every useful discovery requires a third or fourth effect, the player may spend too long assembling a machine that has not started to feel different.

Also keep theme and math distinct. You can explore conditional scoring through cooking orders, train routes, garden harvests, or your own subject. Copying card names, artwork, and presentation does not help you answer whether your underlying decisions work.

Play it: buy the help, or keep the money?

The scoring toy isolates arithmetic. This second experiment connects a purchase to later choices. You run an original little parcel business over three rounds. A parcel scores 10 points, each round pays 3 coins, and cash left after a purchase earns one extra coin if it is at least 3. You have two upgrade slots. Every price, effect, and target is invented for this lesson.

The full schedule is visible. Round two pays more for blue parcels; round three needs a larger total. A cheap stamp gives reliable points now. A blue-route contract pays more conditionally. A sorting machine multiplies the result but costs more. You may buy one item at each shop or keep your coins. Predict the consequence before committing.

Try two successful plans and one failed plan. Notice when the stamp's immediate help is worth its cost, when saving preserves access to the machine, and when you must replace an earlier purchase. This is not a miniature Balatro ruleset. It is a way to inspect the present-versus-future tension discussed above.

Follow the cost into the next decision

An upgrade price is not just the number subtracted from a wallet. Buying can also cost a later offer, a slot, flexibility, or the income associated with holding money. Those consequences make a modest purchase worth discussing. A player can rationally prefer a smaller immediate score if the remaining resources support a stronger next round.

In our toy, all future demands are known. That is useful for learning the relationship, but it removes an important uncertainty from a run-based game. After you understand the toy, cover the third target on paper and replace it with a visible range. Does the safe purchase become more attractive? How much uncertainty can you add before planning stops being meaningful?

A failed plan deserves a readable explanation. Show the target, the score components, the condition that did or did not trigger, and the resource that constrained the next offer. If the only feedback is “not enough points,” the player may learn that a build failed without understanding how to improve it.

A run should change the question

A promising sequence moves from establishing basic output, to finding a combination, to deciding what the combination cannot handle. Simply raising every target can expose weak output, but a changed demand can expose a build's dependence on one condition. That gives the player a different problem to solve.

For your prototype, prepare a reliable route through the offers and a more conditional route. Give each a moment when it looks attractive and a moment that tests its weakness. Then watch whether the player can identify the tradeoff before the score reveals it. Avoid a surprise that disables the entire plan with no warning or response.

This is also a production decision. Four interacting effects, two slots, and three meaningful demands can support a revealing test. A large item catalog makes weak relationships harder to diagnose. Expand when the small set produces understandable plans and interesting pivots, then add effects that create a new question rather than another near-identical answer.

Build a three-round combination game

The first milestone is a player saying, “I want this because of what I already have,” and being able to explain the connection. That is a more useful sign of a working combination system than a counter reaching a silly number. Though the silly number can be nice too.

1. Choose one familiar action, two score quantities, and a clearly visible target.
2. Make four original modifiers: a reliable addition, a conditional addition, a multiplier, and one effect that changes which actions are possible.
3. Allow only two modifier slots. Between three rounds, offer a choice that requires keeping, replacing, or declining an effect.
4. Prepare the upgrade sequence by hand before randomizing it. Confirm that at least two different plans can finish.
5. Ask the player to explain the next expected score change, then watch the result together. Record surprises and missing information.

Sources & further reading

Official material and creator accounts behind this analysis. The interpretations, examples, and interactive models are Dashpop’s own.

• Balatro: official Steam description
• LocalThunk: The Balatro Timeline
• LocalThunk interview, DayOne (March 2024)