Melo Legarda et al.: Before changing difficulty by heartbeat, they built a way not to change it — Fukai Reads

TL;DR — 191 changes, and 83 refusals

Talk about automatic difficulty adjustment usually gathers around one question: how should the system change things? Today's paper spends most of its effort on the opposite question — when should it refuse to change anything? A team in Colombia built a mechanism that moves a game's difficulty according to a chest-strap heart sensor, then logged its behaviour across eight sessions totalling 6 hours and 48 minutes.

The most interesting number is the breakdown of near-transitions. The system actually committed a state change 191 times. It withheld a flip that was about to happen 83 times. Roughly a third of the change-or-hold decisions fell on the side of not touching the dials. Mean response latency was 2.06 seconds.

One caution before reading on. The paper never claims that heart-driven difficulty makes a game more enjoyable. Its claim stops at "the mechanism runs stably in real time." No player impressions were collected at all. Keep that straight, and what remains is a surprisingly practical paper for designers.Human Resource Machine (Tomorrow Corporation, 2015). The teaching game built for this paper belongs to the same family: learn a sorting procedure by playing it. Image: Steam store page

Who wrote it, and what kind of study is it?

The paper is titled "A Dynamic Difficulty Adjustment Mechanism Based on Cellular Automata Using Cardiac Signals for Serious Games." The four authors are Manuel Arturo Melo Legarda, Juliana Chantre Astudillo, José Luis Arciniegas Herrera and Carlos Hernán Tobar Arteaga, based at the Departamento de Telemática of Universidad del Cauca in Popayán, Colombia, and at the engineering faculty of Institución Universitaria Colegio Mayor del Cauca in the same city.

It appears in MDPI's journal Applied Sciences, volume 16, issue 17, article number 8511. Submitted 22 April 2026, revised 18 May, accepted 20 May, published online 27 August. This is a peer-reviewed open-access article, not a preprint parked on arXiv. The DOI is 10.3390/app16178511.

Two reasons I picked it today. First, it is a paper about dynamic difficulty adjustment (DDA — a game changing its own difficulty while you play) whose centre of gravity sits on restraint rather than on adjustment. Second, the core idea transfers to anyone who does not own a heart sensor. What you take away is a procedure, not a piece of hardware.

Why watching performance alone is not enough

The classic approach to DDA is to watch performance: completion rate, time taken, number of mistakes. Good numbers mean push harder; bad numbers mean ease off. It is a straightforward mechanism and needs no extra hardware.

But performance hides things. In the introduction the authors invoke the old opposition — demands below your capability turn the experience monotonous, demands above it produce frustration — and argue that performance figures miss what is happening inside the player. The same completion rate covers both someone cruising through and someone gritting their teeth.

Enter the heartbeat. Heart rate (BPM, beats per minute) and heart rate variability (HRV — how much the gaps between beats fluctuate) can be captured by simply strapping on a sensor, and they partly reflect arousal, roughly "how far the body has stood up." The HRV measures used here are SDNN and RMSSD in the time domain (how spread out the beat intervals are, and how large the differences between neighbouring intervals are) and the LF/HF ratio in the frequency domain (the tug-of-war between slow and fast fluctuations).

Driving difficulty from physiological signals is not new; commercial games have done it. What the authors object to is the coarseness of what follows. Many proposals look at a single indicator, never reconcile short-window with long-window evidence, and have no mechanism for calming the moment a state flips. This paper puts its weight on the third problem.Nevermind (Flying Mollusk, 2015). Connect a heart sensor and the world distorts as the player gets more frightened — a commercial precedent for driving play from a body signal. Image: Steam store page

From heartbeat to difficulty — a machine that thinks at three speeds

The hardware is a single Polar H10 chest strap. Over the browser's Web Bluetooth API it delivers BPM roughly once a second plus the R–R intervals (the gap between beats, in milliseconds). For sensor accuracy the paper cites prior validations: BPM correlation r ≈ 0.93 with errors of about ±3–5 BPM, and R–R correlation ≈0.997 with beat detection above 99%.

The game is a purpose-built teaching title called Sorting Quest, which walks players through six sorting algorithms: bubble sort as "Floating Bubbles" (~105 s), insertion sort as "Cards in Hand" (~50 s), selection sort as "Treasure Hunter" (~50 s), quicksort as "Dividing Warrior" (~50 s), merge sort as "Tower Builder" (~60 s) and shell sort as "Space Jumps" (~75 s).

What matters most is the two minutes before any of that. The first 90 seconds have you quietly read instructions, capturing your low anchor (fCmin). The next 90 seconds throw you into a hurried, timed mini-game to capture your high anchor (fCmax). The midpoint between them becomes the target centre fCmid, and the band half-width is 20% of the range, clamped to 3–8 BPM. So the system never says "120 bpm is high"; it says "for you, above this band is high." Observed calibrations were fCmin 65–72, fCmid 95–106 and fCmax 125–140 BPM.

Three clocks run at once. Every 2 seconds, BPM alone assigns low (state 0), target (state 1) or high (state 2). Every 12 seconds, if at least ten intervals have accumulated, SDNN and RMSSD check that label; a one-step mismatch is blended 70% BPM to 30% HRV, and a two-step conflict hands authority to HRV. Every 30 seconds after the first minute, at least thirty intervals are decomposed into frequencies to update LF/HF. A shared cache holds fusion results for 20 seconds so short and long windows can be reconciled.

Then a cellular automaton (a device that updates states by simple rules) stands as the last gate. It remembers the 30 most recent detections, and a new state is committed only if it appears at least twice in the last three. A one-off blip moves nothing. The single exception is the strong-conflict case above, where HRV jumps the queue.

Four dials respond to a committed state: the speed of moving elements, the effective time limit of the level, the tempo of the music, and base difficulty (maximum time, array length, appearance patterns). On top of that, sustained state 2 together with a risk condition releases two reliefs — an extra life and extra time.A level from Human Resource Machine. Sorting makes good teaching material for puzzles, and the paper's Sorting Quest plays on the same ground. Image: Steam store page

What eight sessions and 6 hours 48 minutes showed

The evaluation covers eight sessions totalling 6 hours 48 minutes, averaging 51.0 minutes each (SD 7.1). The sensor delivered 24,316 BPM notifications, with 1.10% of slots missing, and 3.21% of R–R intervals rejected as artifacts (the eligibility window is 300–2000 ms). By these numbers the signal came through cleanly.

Speed is the headline result. The 2-second decision ran 10,116 times, and the delay from sensor input to an actual change in the game averaged 2.06 s (SD 0.29), with a median of 1.98 s and a 95th percentile of 2.78 s (Table 6). The 12-second check ran 1,668 times and the 30-second spectral analysis 128 times.

Then the number from the top of this article. 191 state transitions were committed and 83 flips were withheld by the automaton. Dials moved 1,046 times in total: speed 278, time limit 260, music tempo 232, base difficulty 276 (Table 7) — spread fairly evenly across the four. The reliefs fired 8 times for an extra life and 12 times for extra time.

There is one external check. Public R–R segments were tagged with coarse activation labels (low, moderate, high) and replayed through the same pipeline. Across 50 windows, agreement was (9+14+11)=34, giving accuracy 0.68, a weighted Cohen's κ (agreement with chance discounted) of about 0.51, and a macro-averaged F1 of 0.69. The authors deliberately do not oversell it, writing that the proxy marks activation level only and checks whether the rules line up with an external three-way split.

How can game makers use this?

Almost no studio can hand out heart sensors. This paper still travels well, because what transfers is not the hardware but the etiquette of deciding. Six concrete uses follow.

One: put a deadband on your dials. The two-of-three rule needs no sensor. If your puzzle game offers an automatic hint "when the player is stuck on a level," it will fire because someone left their desk. Change it to "stuck on two of the last three levels" and false triggers drop visibly. Control engineers call this hysteresis.

Two: measure against the person, not an absolute. The paper's yardstick is never "120 bpm"; it is "the midpoint between your rest and your full effort." Translated to puzzles: spend the first two levels calibrating, capture that player's fastest and slowest solve times, and from then on judge fast or slow as a percentage of their own range rather than a fixed number of seconds. The opening two levels become measuring instruments by design.

Three: separate the fast decision from the slow audit. The 2 s / 12 s / 30 s arrangement ports directly. Decide provisionally on immediate feedback (a botched input), confirm against a tens-of-seconds trend (progress through the level), and correct against a minutes-long trend (the whole session). Build only the fast layer and the system twitches; build only the slow layer and it sleeps.

Four: point all the dials the same way. The paper states explicitly that sustained low versus sustained high arousal should shear speed, time budget, tempo and base difficulty in opposite directions. The implementation hazard is granting more time while simultaneously speeding up the enemies, so the two cancel. Derive all four from one committed state instead of writing an independent condition per dial.

Five: release help only when trouble persists. Eight extra lives and twelve time extensions across 6 hours 48 minutes is restrained. Rather than helping at every moment of difficulty, help when difficulty holds. If you are building a hyper-casual falling-block puzzle, rewrite the trigger from consecutive failures to a detected stretch of failure.

Six: log the refusals. That 83 is the record this paper kept in order to doubt its own machinery. Most DDA instrumentation counts only firings. Only when you put the near-misses beside them can you tell whether your system is too twitchy or too dull. Valve's AI Director in the Left 4 Dead games, with its deliberate lull phases, sits on the same side of this idea.Left 4 Dead 2 (Valve, 2009), known for an AI Director that reads tension and reshapes encounters. Not pushing is itself part of the design. Image: Steam store page

What this study does not tell us

The authors' own caveats are refreshingly blunt. They state that what is demonstrated is the functional coherence of the stack — timing, co-registered telemetry, pooled counters — and that it is no substitute for inferring instructional efficacy, longitudinal retention or population-scale UX. There are no factorial arms: no DDA-off condition, no performance-only baseline, no varied assistance quotas. No self-report was gathered ("this pool did not collect concurrent self-report"). Confounds such as posture, breathing, motion, caffeine, medication, fitness and sleep remain undisentangled. Crowded classrooms, minors' biometric norms, retuning for other genres, long-run calibration drift and degraded Bluetooth are all declared out of scope.

Three points I would add. First, the paper never says how many people the eight sessions represent. Section 3.1 describes the equipment and the link, not the number of chests the strap went around. One person eight times and eight people once each imply very different things about how general the calibration is. Second, the external agreement of κ ≈ 0.51 is moderate, and the comparison is against coarse three-level labels attached to public data across 50 windows. Reading that as "arousal was recovered" goes too far, in my view.

Third, the mechanism never validates the direction in which it turns the dials. Ease off when arousal stays high, push when it stays low — plausible, but low arousal from boredom and low arousal from settled concentration are hard to tell apart from the heart alone, and adding ease to the first makes things worse. The authors do not claim this direction is validated, so it is not an error in the paper but a hole for someone to fill. Their own future work — concurrent subjective measures, factorial behavioural studies, heterogeneous field testing — points at the same gap.

How Fukai reads it

From here it is my own reading. I want to place this work in a drift where DDA debates move from "how do we measure?" to "how do we hold back?" In control-engineering vocabulary that is the introduction of hysteresis; in design-criticism vocabulary it is closer to automating the pause. What strikes me is that the weight of the paper's claim sits not on the 191 commits but on the 83 refusals. When we build adaptive systems we tend to mistake responsiveness for quality. From the player's side, though, a world that reacts to your every twitch feels less like support and more like surveillance. Some fraction of those 83 refusals, I read, were moments where a player was protected without ever noticing.

What to read next to see the map

If you want to go deeper: the natural companion is Elshamy et al. on adaptive level generation, covered here earlier, which widens adaptation from dials to the level itself. That work redraws levels according to skill — and the change-or-hold decision studied today is just as necessary there.

To question the relationship between difficulty and experience itself, two pieces make a map: Lu et al. on flow (is flow produced by difficulty or by the effort you pour in?) and Jeong et al. on answer format and cognitive load. Today's paper takes on moving difficulty from a body signal; where that difficulty lands in the experience is written on their side.

References

Papers and materials referenced in this article:

・A Dynamic Difficulty Adjustment Mechanism Based on Cellular Automata Using Cardiac Signals for Serious Games (Manuel Arturo Melo Legarda, Juliana Chantre Astudillo, José Luis Arciniegas Herrera, Carlos Hernán Tobar Arteaga, 2026, Applied Sciences 16(17):8511, peer-reviewed open access)

・DOI: 10.3390/app16178511

・Related: Elshamy et al.: redrawing the level itself from the player's skill — Fukai Reads

・Related: Lu et al.: is flow produced by difficulty or by effort? — Fukai Reads

・Images: Human Resource Machine (Steam store page) / Nevermind (Steam store page) / Left 4 Dead 2 (Steam store page)